Member #383017

Member Since: November 26, 2012

Country: United States

  • OK… Weird happenings with this guy… I have a an I2C device MLX90614 Temperature Sensor Properly pulled up to 3.3V SDA, SCL. + .1 uf Bypass cap @ the MLX90613 3.3 V in (measures 3.25V) Interfaced to UView Pins A4 A5

    But the MicroView only properly reads I2C from MLX when this programmer is inserted between my host circuit and the uView.. (Regardless as to whether connected to USB or not)

    Does anyone have any ideas?

    The schematic says the only Pins 1 8, 9, 10, 15 are touched on the UView programmer.

    Is that really true? If I wanted to simulate the same loading, or capacitive effect of the programmer, what would you recommend to make the host circuit act like the uView programmer?

  • What pins are dedicated for MicroView USB Programmer use? I’ve find I have some odd behaviors when I leave the programmer inserted between the MicroView and the host “shield” (my interface to a couple temp sensors, FET, and piezo-beeper.)… Just beginning to chase this down.. It would be great if a schematic were posted somewhere. Trying to use D2 D3, D4.

  • Hey… Got one… VERY cool… Love it.

    BUT… powering it is weird. Looking for a battery method to power it.. Looks like a single LiPo is s no-go. Two LiPo’s in series would work, but but charging two LiPo’s. is a pain. All chargers available from Sparkfun, Adafruit and Chinese guys on Ebay are single-cell. So..

    Does anyone have any suggestions for a SMALL battery arrangement for this?

    I could go with 4 AAAA cells (yes AAAA), but cannot find a four-cell AAAA battery holder anywhere. A 9 Volt is just to fat for the project in mind.

    Open to any ideas!

  • For connection to a processor (Yun, Teensy, Uno, etc…) the long button presses to get this thing on/ off / standby is a bit onerous. And monitoring the LED status pin to see what mode it is in is also painful since it can be blinking and you would have to monitor it for a period of time and decode it to tell what is really going on. Ug!…Has anyone implemented an interface library that is non-blocking to handle such tasks? I just hate to re-invent the wheel. Thanks!

  • Proving we really eat, sleep, and breath with our products.

  • Our staff is intimately involve with our product.

  • Does anyone know if this could be use to record/learn a dog bark and recognize and trigger based on that?

  • Weird characteristic… This board powers itself from the Rx line if power is removed from the USB-VCC pin.

    Even if R19, a 10K pullup is removed, a signal from a Yún (Yun) D{#) out (used via software-serial library) is enough to power up and maintain CY8C29466 as “ON”

    Any suggestions welcomed. I would like to be able to turn this completely OFF simply by removing power from the USB-VCC pin (5V).

  • Problem…

    In the Adafruit Neopixel library, sketches / objects and their members overall work fine… Except when you try to use the class member to set a single pixel to all white:

    // Set pixel color from 'packed' 32-bit RGB color:
    void Adafruit_NeoPixel::setPixelColor(uint16_t n, uint32_t c) {
    

    And employ it on an Arduino Yun/Yún with a call like:

    Console.println("White");
    strip.setPixelColor(0, strip.Color(255, 255, 255)); // White
    strip.show();
    delay(4000);
    

    The pixel Flashes white, then goes to black (off)

    However if you change the above with:

    strip.setPixelColor(0, strip.Color(255, 255, 254)); // or make any of the 3 values so that they are not all 3 the same...
    

    Then the pixel works fine… stays (almost) pure white as possible.

    What is the library or HW bug where (on the Yun/Yún, at least) where if these three color values are the same non-zero values, it flashes that color then instantly changes to off?

No public wish lists :(