do I need two large digit drivers to power my display?

I can't readily find a datasheet for that part #. And it seems Sure's website is down at the moment so it's hard to say. If the displays are individual then you should be ok. If they are connected (they probably are) then I'd be very cautious. This product was really designed for individual digits. If you have a datasheet, please let us know.

9 displays all connected.

In principle, yes. The TPIC6C596 is limited to 250mA per segment so don't go above that and you should be fine.

Hi Jonathan - Thanks for taking the tour!

The display on the safe cracking robot is a bad example. When the motor changes direction quickly it (sucking up a few amps) pulls down the 12V power supply significantly, which causes the display to flash. The display doesn't lose its memory, it just looks bad. I added caps in an effort to reduce blinking of the display but the caps didn't end up helping (I didn't have ones big enough). I was using 25V/1000uF caps placed across the 12V/GND pins.

These displays can pull a fair amount of current. You might try adding more decoupling to your power supply but random flashing is weird, it will usually be associated with something going on in your system (such as motors turning or some piece pulling in a low of current). If you're experiencing flashing either isolate your 12V supply or be sure your 12V supply has enough current to keep the 12V rail above 12V.

What a fun question to try to answer!

The LIDAR-Lite v3 can achieve 500Hz with a max read range of 40m. If you were to cover roughly 38m in 1/500 of a second that would be 19,000m per second or 42,500 miles per hour.

If you are building a copy of the speed trap there are other bottle necks to consider. Namely, the maximum read rate while running the Arduino sketch. The sketch is here and waits 50ms between reads. This is 20Hz. And for this discussion let's say the LIDAR (v2) can read to about 15m reliably so using the same math we get 300m per second or 671 mph.

I'm curious, what are you building?

Awesome project idea!

Hmm, dimming might be tricky. You could used a variable power supply and lower the 12V to say 10V. This should dim the LEDs quite a bit but I'm not sure how finicky the dim-ability will be.

Maybe you could update the TPIC IC really to get PWM control of the segments. You'd need to move the postNumber routine to an interrupt that ran regularly and probably faster than 60Hz (so that your eye doesn't notice it).

Ok, spent longer than it should have taken me, but finally figured out that the demo code had some ints in there, and once you get over 32,767 it'll start to freak out. I've switched it to use longs and everything started working. Here's the code that ended up doing the trick for me:

/*
 Controlling large 7-segment displays

 Arduino pin mapping:
 5 -> LAT (Blue)
 6 -> CLK (Green on the 6-pin cable)
 7 -> SER on the IN side (Yellow)

 Power Arduino with 12V and connect to Vin -> 12V (Red)
 5V -> 5V (Orange)
 GND -> GND (Black)

*/

//GPIO declarations
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
byte segmentLatch = 5;
byte segmentClock = 6;
byte segmentData = 7;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

void setup()
{
  Serial.begin(9600);
  Serial.println("Large Digit Driver Example");

  pinMode(segmentClock, OUTPUT);
  pinMode(segmentData, OUTPUT);
  pinMode(segmentLatch, OUTPUT);

  digitalWrite(segmentClock, LOW);
  digitalWrite(segmentData, LOW);
  digitalWrite(segmentLatch, LOW);
}

long number = 0;

void loop()
{
  long num_to_show = number * (long)111111;
  showNumber(num_to_show); //Test pattern
  number++;
  number %= 10; //Reset x after 9

  Serial.println(num_to_show); //For debugging

  delay(500);
}

//Takes a number and displays 5 numbers. Displays absolute value (no negatives)
void showNumber(long number)
{
  for (byte x = 0 ; x < 6 ; x++)
  {
    int remainder = number % 10;

    postNumber(remainder, x==3);

    number /= (long)10;
  }

  //Latch the current segment data
  digitalWrite(segmentLatch, LOW);
  digitalWrite(segmentLatch, HIGH); //Register moves storage register on the rising edge of RCK
}

//Given a number, or '-', shifts it out to the display
void postNumber(byte number, boolean decimal)
{
  //    -  A
  //   / / F/B
  //    -  G
  //   / / E/C
  //    -. D/DP

#define a  1<<0
#define b  1<<6
#define c  1<<5
#define d  1<<4
#define e  1<<3
#define f  1<<1
#define g  1<<2
#define dp 1<<7

  byte segments;

  switch (number)
  {
    case 1: segments = b | c; break;
    case 2: segments = a | b | d | e | g; break;
    case 3: segments = a | b | c | d | g; break;
    case 4: segments = f | g | b | c; break;
    case 5: segments = a | f | g | c | d; break;
    case 6: segments = a | f | g | e | c | d; break;
    case 7: segments = a | b | c; break;
    case 8: segments = a | b | c | d | e | f | g; break;
    case 9: segments = a | b | c | d | f | g; break;
    case 0: segments = a | b | c | d | e | f; break;
    case ' ': segments = 0; break;
    case 'c': segments = g | e | d; break;
    case '-': segments = g; break;
  }

  if (decimal) segments |= dp;

  //Clock these bits out to the drivers
  for (byte x = 0 ; x < 8 ; x++)
  {
    digitalWrite(segmentClock, LOW);
    digitalWrite(segmentData, segments & 1 << (7 - x));
    digitalWrite(segmentClock, HIGH); //Data transfers to the register on the rising edge of SRCK
  }
}

I'm running into a similar problem, I picked up six of these and have been testing adding them one at a time. I can get up to four with no problem (just cycling through all 1's, all 2's, etc), but once I add a 5th, the numbers will freak out once they get to the 3's (and the same thing happens if I add the sixth digit).

They do all reset back to 0's once the loop hits the modulus limit, and I've tried adding delays before writing the latches, but nothing seems to be working. Anyone have any ideas?

https://github.com/sparkfun/Speed_Trap

https://github.com/sparkfun/Speed_Trap

Hi John - Really sorry to hear your board got fried :/ I wanted to point folks at the hookup guide - we do recommend a bit of electrical tape to isolate the backpack for this specific reason. Sorry you had a bad experience but I'm glad you found the culprit!

It should be working now! :)