Member Since: May 7, 2011

Country: United States

  • News - New Product Friday: Flex … | about 3 months ago

    You don’t see many 3D armadillo’s here in Texas..

  • Product WRL-09582 | about 5 months ago

  • Product WRL-09582 | about 5 months ago

  • Product WRL-09582 | about 5 months ago

  • Product WRL-09582 | about 5 months ago

  • Product WRL-09582 | about 5 months ago

    Breakout Board:

  • Product DEV-10306 | about 7 months ago

    Getting ready for Christmas - $.$

    Sometimes the lights appear to have latency but it is purely cell-phone-camera related.

  • Product BOB-11611 | about 8 months ago

    I thoroughly read the datasheet and saw the obvious intent with the board to provide daisy-chaining, but didn’t notice the entirely alternate wiring shown in the schematic. Per the datasheet, this board could have had a single 5x2 header in, and a single 5x2 header out, with no extra one-wires. It will work, but the daisy-chaining could be greatly simplified by conforming to the datasheet. :( (first-ever frowny face @ sparkfun)

    From AutoDriverSupport.cpp - // SPIXfer()…A very important // note regarding chip select- holding the CS line low results in data being // shifted THROUGH the chip, not into it. To latch data, CS must be released // after each byte. I can’t find a reference to this in the datasheet, which // is AWESOME, and I’ve personally discovered it at least twice."

    This was intentional and expected behavior per the datasheet: Page 37: CS lines should all be tied together; MISO should return to CPU from last driver in chain Page 54: NOP = 0x00

    To command the n-th driver in the chain: 1) Hold CS 2) Transmit (CommandForNthModule + (NOP * (n - 1))) 3) Release CS

  • Product BOB-11611 | about 8 months ago

    These appear to be daisy-chainable, except that CS is not connected per the datasheet example. Please recommend a method for addressing modules in the chain after the first.

  • Product COM-10982 | about a year ago

    I am having the same issue. If/when rotation is detected, it is immediately cancelled by an opposing rotation detected at the same time. Turning the encoder one detent at a time, will not increment a counter. This is already soldered into the RingCoder breakout and I doubt it’s going to come back out easily.

No public wish lists :(