Multiplexing high-current, high-voltage 7-segment

[Peabody]

I'm participating in a thread over on the Arduino forum, but I'm just a hobbyist, and need some expert advice from the EEs here.  The OP wants to build a display of up to 11 digits of what I assume are large 7-segments.  I don't have a link, but he describes them as CC having Vf = 7.8V, Imax = 60mA.  The special requirement is that the display has to show up properly on video as well as in still pictures.  Ouch.

Originally he planned to have continuous drive, with one high-current, high-voltage 595 equivalent on each digit.  But those steroidal 595s are expensive, and I wondered if it would be possible to multiplex the display using one such suped-up 595 driving all the digits in common, and two similar chips sinking the 11 common cathodes one at a time.

I've worked out software that runs a timer interrupt at 100us, and for a Nano or Uno at 16MHz it takes up about 1/3 of the time in servicing the interrupts.  I've tried it with a normal digit, and pictures taken at 1/1000 sec look pretty good.  But what concerns me is whether it's reasonable to be switching maybe 50mA at 10V or so at a speed of 10KHz over a distance of something in excess of one foot.  Actually, it's a bit worse than that because during the ISR, current is shut down while the changes are taking place so as to prevent ghosting.  So in the case of two adjacent digits both having the same segment turned on, current would be switched off, then back on, over just a few microseconds.

I've never done anything like this,  and just don't have a feel for whether it is at all reasonable.  It may be that 11 digits with this much current and voltage, at this distance, is just a bridge too far for multiplex. Any opinions would be appreciated.  Is it "no problem", or "no chance"?

[Andy Chee]

As long as the average current remains within spec, LEDs can generally take a fair amount of punishment when being pulsed with high currents.

As for the 595 driver, you will have to buffer it with something like the ULN2003.

[MathWizard]

What about just making some higher voltage BJT drivers for the LED's ? Just some 2N2222/2N3904/BC547, anything like those would be plenty fast for switching LED's up to the kiloHertz or whatever you would need to be picked up by a camera.

[pqass]

10KHz?

You only need 60Hz per digit, so an 11 digit multiplex is 660Hz, or an interrupt every 1.5ms.
However, you should probably make it an odd rate like, say, 83Hz per digit or 913Hz total, or an interrupt every 1.1ms.
That way it won't coincide with any standard shutter rate.
ISR-time should be minimized; just be sending out the display buffer and not execute complex calculations.

I've successfully multiplexed 16 digits; sending out one byte via SPI every ISR call (1600Hz, or every 625us).
The common cathodes were driven from two ULN2803s via two cascaded CD4017 counters.
The cascade arrangement was such the Q1..Q8 of each counter enabled a single cathode in sequence.
The first counter would stop at Q9. The second counter would count only after the first was stopped then reset both at its Q9.
Q0 of the first counter would signal the MCU via MISO when the count was just before the first digit (to re-synchronize if necessary).
The counter clocks were driven from the MCU device select/reg. load pin for the '595 (low-high-low on RCLK).

[Peabody]

Thanks very much for all the comments.

We're looking at the MIC5891 for the anodes.  That's a 595-type shift register, which handles much higher voltage and current.  Its outputs are open emitter darlingtons, so I was hoping there would be no need for a ULN2003.  And besides, I thought the ULN2003 could only sink - it has a common emitter and open collectors.  His displays are common cathode, so we need to source high current into the individual segments.  I don't know of a cheap 7-gate darlington array with open emitters.

Then he already has the TPIC6C595 on hand, which would be on the low side, with one input connected to the CC output of each digit.  He would need two of them to handle 11 digits.

Is this for a scoreboard or something like that?  I really wonder if 60mA/11 digits = 5mA average would be bright enough.

I don't know what it's for, but I have the same question about brightness.  But these days LEDs are so efficient that it might work.  However, it might be possible to split up the digits into 6 and 5, and drive each half with its own MIC5891.  The two TPIC6C595's would still be enough since there are still only 11 digits.  That would effectively double the brightness on the same current since each segment would be lit for twice as long.  So it would be 60/6 = 10mA average current.  But that's still better than 11 MIC5891's at $3 a piece.

What about just making some higher voltage BJT drivers for the LED's ? Just some 2N2222/2N3904/BC547, anything like those would be plenty fast for switching LED's up to the kiloHertz or whatever you would need to be picked up by a camera.

I don't think there is a problem generating the current.  The MIC5891 has darlington outputs, which should be good enough.  What I was concerned about was switching the current at 10KHz - I don't know what could go wrong doing that - reflections, or spikes, or whatever things professionals know to watch out for, but hobbyists like me don't.

You only need 60Hz per digit, so an 11 digit multiplex is 660Hz, or an interrupt every 1.5ms.

For video, perhaps, but still pictures are the complication.  What if the shutter speed is 1/1000 sec?  This requirement is the biggest obstacle to this working easily, but he was pretty clear about needing it, and it's why he was planning to make it continuous.  I was just hoping there was a better way using multiplexing.

Well, I'm still not clear about whether switching the currents will cause problems. I know that as lines get longer the frequency that can be supported reduces.  And presumably the same as currents get bigger.  I just don't know at what point that starts to be a practical problem.  I mean, 10KHz is not exactly RF.

[amyk]

Actually, it's a bit worse than that because during the ISR, current is shut down while the changes are taking place so as to prevent ghosting.

Are these LEDs or incandescent bulbs? LEDs react near instantaneously to current.

[Peabody]

Actually, it's a bit worse than that because during the ISR, current is shut down while the changes are taking place so as to prevent ghosting.

Are these LEDs or incandescent bulbs? LEDs react near instantaneously to current.

They are 7-segment LED displays.  Just bigger than normal.

[Benta]

What is the supply voltage? And is it stable and fixed/defined?

[Peabody]

What is the supply voltage? And is it stable and fixed/defined?

I don't know.  Of course something greater than 7.8V, but I don't know what he will be using.

[pqass]

If you're multiplexing then you would only need one MIC5891 (like anodes across all 7-seg displays; all a-segs connected, all b-segs, ... g-segs, dp-segs) and two ULN2003+74xx595 or two TPIC6C595 where each output drives one display's common cathode.  And every ISR call, you'd be sending 3 bytes.  However, the TPIC6C595 has a max of 100mA per output yet each display segment can be 60mA? The ULN2003 can support up to 500mA per output (which is >8segs*60mA/seg).

For 1/1000s stills you'd have to drive all segments full-time.  This can be possible, cheaply, if you employ a common VFD display circuit design; discrete PNP or PFET per segment driven by a '595 output (times 11 displays) but with a negative common cathode.  See attached (simulation here).

[Peabody]

If you're multiplexing then you would only need one MIC5891 (like anodes across all 7-seg displays; all a-segs connected, all b-segs, ... g-segs, dp-segs) and two ULN2003+74xx595 or two TPIC6C595 where each output drives one display's common cathode.

Exactly.

And every ISR call, you'd be sending 3 bytes.

Well, he would be sending one full byte to the MIC5891, but on the cathode side he only has to shift one bit on each interrupt.  So the On bit would move across the register, activating one display at a time.  The latch would be permanently On.  So he would just toggle the serial clock pin, and serial data would always be low except when it rolls around to the first digit.

However, the TPIC6C595 has a max of 100mA per output yet each display segment can be 60mA? The ULN2003 can support up to 500mA per output (which is >8segs*60mA/seg).

I don't read the datsheet that way.  100mA is the continuous current limit per output.  I think the 250mA is a pulse current limit per output.  Now of course 250mA isn't 420mA, so the TPIC6B595 would be a better choice.  But he already has the 6C, and  they might work ok if there aren't too many "8" and "0" values.  But in the worst case, I think he could double up the 6Cs, even soldering two of them together piggyback.

For 1/1000s stills you'd have to drive all segments full-time.  This can be possible, cheaply, if you employ a common VFD display circuit design; discrete PNP or PFET per segment driven by a '595 output (times 11 displays) but with a negative common cathode.  See attached (simulation here).

I think you're probably right about the 1/1000s stills, but it might be worth just trying it out on one digit that's turned on 1/11th of the time.  It probably won't be bright enough, but I think it's worth a try.  Attached is such a 1/1000s picture that looks ok, but that's using my super-efficient red display, not whatever he's using.  But it also used 220R resistors, so it could have been brighter.

[BennoG]

I would skip multiplexing.
Modern film/photo camera have shutter times in the 1/10000 s (on a sunny day), so if you want do do multiplexing and don't see it on the camera you need to multiplex (every segment at least 1 time on) at least 50kHz.

Benno

[pqass]

The latch would be permanently On.

It doesn't work that way.  RCK only works on the rising edge (see description 8.3.1 on page 12). 
It's not a transparent latch like C on the '373.

[Peabody]

The latch would be permanently On.

It doesn't work that way.  RCK only works on the rising edge (see description 8.3.1 on page 12). 
It's not a transparent latch like C on the '373.

You're right.  I was looking at the MIC5891, which is level triggered, and just assumed it was the same.  So I would toggle the serial clock once, then toggle the latch clock.

[mikerj]

A boat load of shift registers and transistors seems like the lowest cost solution without resorting to very high speed multiplexing.  This will also take negligible CPU time, just load a buffer up with the next display data and let the SPI peripheral squirt it out, just once very fast interrupt per byte.

The TLC6C598 will directly drive LEDs up to 50mA and even in 10s quantity is quite reasonably priced ~$0.60

[Peabody]

The TLC6C598 will directly drive LEDs up to 50mA and even in 10s quantity is quite reasonably priced ~$0.60

Well, again, the TLC6C598 is open drain.  It won't work with his common cathode display.  He would need something similar, but which can source current into the segment anodes.  The MIC5891 was all I could find that does that at 9V, but it's not cheap.

[Benta]

CC 7-segment displays are always a pain with a lot of level shifting involved. Best would be to switch to a CA type instead.
If not possible, here's a completely different approach:
A floating "HV" display supply that will have its positive voltage referenced to the controller's positive voltage. That will bring all output switching and current control for the LEDs into the low-voltage realm of the controller.
The cathode voltage will be "dangling" down there somewhere, but who cares? all the rest is 3.3 or 5.0 V circuitry.

This is what I mean:
(Nice is that it's constant-currnet drive at 25...30 mA per segment)

[Peabody]

Yes, @pqass also proposed that method in reply #9.  I'll pass that along.

[T3sl4co1l]

Well, switching on and off depends on the speed of the drivers doing it, and ringing depends on the impedance of the route.

60mA isn't extreme; the peak current from a 5V CMOS logic chip into a 70 ohm trace is ~30mA.  The voltage here is higher, and the current is higher; in EM terms, it's basically the same.

Microseconds aren't important: for feet of wire, you're looking at whole nanoseconds; a bit more including LED and driver capacitances.  Microseconds are basically DC, handled in the nearby bypass cap (or even a fairly distant one).

As a general rule, only use what bandwidth you need.  This might not be optimal, as you're starting with the risetime of the Arduino, and the driver IC(s), and so filtering would be needed -- a tedious parts cost.  Otherwise, construct it with good enough signal quality and shielding to behave: ground plane most important of all, perhaps source termination resistors and/or ferrite beads on longer signals, etc..

The same applies to the (3.3/5V?) SPI signals, if using shift registers; or even just GPIOs really.  Newer AVRs, and most(?) anything ARM, have drive strength or slew rate control which can help ease things, and source termination is about all you need for signal quality on CMOS lines (small capacitance load at far end).  SPI ran over long cables should be shielded, keep the shield connection short and well connected to ground plane.

Tim

[DavidAlfa]

Grab any generic PNP transistor for each anode.
Most logic won't handle 7V, use a ul2003 or a bunch of NPNs to drive them.

[Psi]

I would skip multiplexing.

+1 for this.

If it has to look good on video drive each segment with DC only.
This obviously means you cant use matrix LEDs but normally 7 segments are just common'ed, so totally fine to drive with DC from a latched shift register or something

[ArdWar]

You can try TBD62783 for the high side switch and drive it with normal 595. No need for additional rail.

Otherwise, yeah, bunch of discrete transistors is probably still the cheapest option here. Sourcing (high side) driver is so uncommon that any monolithic solution will be at a premium.

[Peabody]

Well, switching on and off depends on the speed of the drivers doing it, and ringing depends on the impedance of the route.

60mA isn't extreme; the peak current from a 5V CMOS logic chip into a 70 ohm trace is ~30mA.  The voltage here is higher, and the current is higher; in EM terms, it's basically the same.

Microseconds aren't important: for feet of wire, you're looking at whole nanoseconds; a bit more including LED and driver capacitances.  Microseconds are basically DC, handled in the nearby bypass cap (or even a fairly distant one).

Thanks very much for the reply.  Looking at the continuous option first, since an HV 595 would be right next to each digit, and the cathodes will be grounded, there shouldn't be any problem with the load lines.  But the Uno would be directly driving the SPI lines, and the serial clock in particular would be fanned out to each of the 11 chips, at varying distances.  I've seen schematics of button boards and such where this is done, but don't know if it actually works.  Serial data would only go to the first chip, and is then refreshed going to the next chip in the cascade.  But I guess if the clock line is a problem, a single-gate buffer of some kind could solve that.

In the multiplex option the SPI lines would be quite short, and only going to one chip.  But the load current lines would fan out over some distance.  I figured out a way to avoid having to power down those lines during changes (to avoid ghosting)  by triggering all the latch pins from a single GPIO pin so both the anodes and cathodes change state at the same instant.  That means that if the refresh period is 100us, that's the maximum speed at which the load lines would change state.  If I understand what you've said, that's not likely to cause a problem so long as the layout done properly.

As a general rule, only use what bandwidth you need.  This might not be optimal, as you're starting with the risetime of the Arduino, and the driver IC(s), and so filtering would be needed -- a tedious parts cost.

Sorry, you've lost me.

  Otherwise, construct it with good enough signal quality and shielding to behave: ground plane most important of all, perhaps source termination resistors and/or ferrite beads on longer signals, etc..

The same applies to the (3.3/5V?) SPI signals, if using shift registers; or even just GPIOs really.  Newer AVRs, and most(?) anything ARM, have drive strength or slew rate control which can help ease things, and source termination is about all you need for signal quality on CMOS lines (small capacitance load at far end).  SPI ran over long cables should be shielded, keep the shield connection short and well connected to ground plane.

Tim

In multiplexing, the SPI transfer would be initiated toward the end of the timer ISR, and only needs to complete before the next interrupt.  The slowest you can run SPI on the Uno is at 1/128th the speed of the 16MHz system clock, which would be 125KHz.  I think the ISR will be fairly short, so that should work timing-wise.  I just don't know how good the GPIOs would be in driving these lines.

[Peabody]

I would skip multiplexing.

+1 for this.

If it has to look good on video drive each segment with DC only.
This obviously means you cant use matrix LEDs but normally 7 segments are just common'ed, so totally fine to drive with DC from a latched shift register or something

It seems to me that video is the lesser problem.  The frame rate will likely be either 30fps or 60fps, and if multiplexing is fast enough that should be doable.  But stills is another matter, particularly if shooting outside.

I'm finishing up some test code that he can run with one digit to test brightness and photogenicity.

Edit:  One thing I haven't considered is the effect of rolling shutter in CMOS sensors.   I don't know if that makes things better or worse.

[Peabody]

You can try TBD62783 for the high side switch and drive it with normal 595. No need for additional rail.

Thanks very much for that find.

Otherwise, yeah, bunch of discrete transistors is probably still the cheapest option here. Sourcing (high side) driver is so uncommon that any monolithic solution will be at a premium.

Yes, that appears to be the case.  A good reason to use common anode displays I guess.