With the recent surge in Omicron cases, shipping may be slower than stated times. We are working to build, ship and respond to everything as quickly as possible. Please see all COVID-19 updates here. Thank you for your continued support.


Member Since: November 7, 2007

Country: United States

  • I think you missed the point. PRT-10968 is roughly the same size, has many more components, and costs $5.95. The ICs may be cheaper, but you listed all of the things that supposedly justify an extra $30 for the product on this page that would also apply to PRT-10968, but obviously don't for some reason. "Designed the board" - the design of this board probably took 20 minutes. It's basically a bunch of escape routes to a 0.1" header and a few capacitors that are laid out exactly the way the datasheet specifies. Design not found.

    I've been selling a similar device for $20 and I'm making a huge profit. $50 for this breakout is an unbelievable gouge. Sometimes you guys are pretty arrogant with your pricing. Just because you have a well known presence doesn't mean you need to rip people off. There are too many products on your website with similar price-gouging to even bother trying to list them all. You guys do good work, but this is just wrong.

  • I emailed Sparkfun about the firmware bug 3 years ago, which was even before I posted my comments proving it does NOT work as advertised. I came across this again just now and noticed the firmware is still posted with COLOR_DEPTH set to 7. Bad, bad, bad. It would have taken less than a minute to correct this error, which would have likely saved many hours of debug among the people who have purchased it.

  • Upon further inspection, I realized the suggested interrupt routine in the item description isn't interrupting at 32.768KHz, but it does require an unnecessary amount of overhead as a prescaler can often be used to generate exactly 1 second overflows of an 8 bit counter.

  • 0x80 = 128. You meant to type 0x8000.
    There is a much more efficient way to determine when each second has elapsed. Instead of interrupting every 30.5uS like what is suggested in the item description, use the features built into the microcontrollers to minimize the resources needed to do this.
    For example, if you connect this crystal to the TOSC1/2 pins in an AVR microcontroller and then configure TIMER0 to use that clock instead of the main system clock, it can be divided to give different interrupt frequencies. Enabling the TIMER0 overflow interrupt and running it with a prescaler of 1 will interrupt every 1/128 seconds (7.8125ms). If you change the prescaler to 128, it will interrupt at exactly 1 second. Doing it this way will reduce your power consumption by an incredible amount if you are using it as a real time clock. It will also require much less processing time as it is only interrupting at 1Hz instead of 32.768KHz.

  • You most definitely can use a shift register to control this. I've done it several times and it requires much less overhead (and expense) than using an additional microcontroller to do something as trivial as this. A simple timer overflow ISR can multiplex and update the shift registers with no main program loop intervention.

  • Based on the schematic it looks like RST is simply the MCU reset pin. It is internally pulled high so leaving it disconnected should be fine. Has the device responded to other types of inputs such as updating the digits?

  • Yes, it is BGA which is not friendly to soldering by hand.

  • I have no idea why they say 10 either. This line of code is directly from their firmware:
    I also gave a quick glance over the algorithm and there is nothing limiting this to just 10 (or 16) except that line. It could be a function of speed as the main loops are somewhat clunky, but the hardware should be able to support it unless they've got something else limiting it that I didn't see.
    One other thing - it's not a good programming practice to write variables as all caps. That is universally accepted as the form of a #define.

  • This is correct. To have red-red-blue-blue you have to enable Row1 red and then enable Column1 and Column2 GND only. Then you'd have to enable Row1 blue and Column3 and Column4 GND. This is not a very efficient method especially for LEDs as the maximum duty cycle was just reduced to 50% for every LED on that row. It is then further reduced if any time is spent serially updating the other rows. If each row/column can be scanned simultaneously, e.g. with a shift register, then you are better off but still at 50%. Add in the third color and you've just reduced it to 33%.

  • Just an FYI to anyone using their firmware - it is not 24 bit color. All you get from this firmware is the equivalent of 9 bit color. COLOR_DEPTH is defined as 7 which allows only 8 possible color values per color (0-7, anything greater than or equal to 7 behaves the same way). Since 8 is 2^3, the total bit depth is 9, not 24.
    Here is the relevant snippet of code:
    if(row == 0) frame_num = (frame_num + 1) & (COLOR_DEPTH);
    frame_num can never be greater than COLOR_DEPTH which I already showed is defined as 7.
    Therefore, this line inhibits true 8 bit depth per color:
    if(greenf[LED] > frame_num) lineByte |= (1 << (column + GREEN_POS));
    The values of each individual LED are stored in greenf[] and should be able to vary from 0 to 255 for true 8 bit color. However, frame_num can never be greater than 7 as I showed earlier, so any value of greenf[] greater than frame_num is treated exactly the same - maximum brightness. Values between 0 and 7 are truly different, but setting any element of any of the color arrays to a value greater than 7 will yield the exact same brightness.
    The firmware is capable of 24 bit color, but not the way it is currently presented. Either the define needs to be changed or the description needs to say 9 bit color.

No public wish lists :(