Multiple digits 7 segments display

[Joel Rainville]

But how long is each iteration?, if you call the routine 10 times before the timer ends, then that's 60 cycles wasted, lots more than the interrupt routine overhead.

The iteration lasts whatever time the main program takes to do its normal processing.

My polling strategy's flaw is that it takes for granted that the 60 cycles (for example) or so used in polling aren't needed by the main program anyway, since the processing is done.

But once the main program takes too much time to allow for a good refresh rate, I will lose my display, or at least some quality. This solution, while it *can* be more efficient in some instances, will be more often than not more costly than the interrupt version. I get it now

Thanks!

 

[Joel Rainville]

Duty cycle is the portion of time each digit is turned on in one complete cycle... If you have an 8-segment 9-digit display and you're turning on digits sequencially, your duty cycle is approximately 11% (1/9)... If you're turning on segments sequencially, your duty cycle is approximately 12.5% (1/8)... The higher the duty cycle the better the brightness... Don't go less than 10% duty cycle...

There's some good information there Mike, thanks!

PS: where did you get this little 99 cent 9-digit display?

It comes from a local electronics surplus store called Addison Electronics (**broken link removed**). Their website is as crappy as their customer service and all around "customer experience". But the prices on the surplus stuff are well worth the visit! And at 99 cents, this is a very nice development LED display!

See the attached picture. It looks like it's from the 70's or 80's. It has a strange déjà vu kinda look. I was born in 1978, maybe there were appliances with that kind of display around the house!...

N.B. Yes, there is a broken segment. It died during a soldering accident. Luckily, it's the only digit that died. The first digit (same segment) did suffer a little though, you can tell by the picture it is a bit dimmer...

 

[eblc1388]

These look like display for calculators in the 70's.

N.B. Yes, there is a broken segment. It died during a soldering accident...

How can soldering kill a segment? Too much heat for too long?

 

[Joel Rainville]

How can soldering kill a segment?

I don't know, but it sounds better than : "I applied 5V directly without current limiting resistors"...

Don't you think?

 

[eblc1388]

If you have an 8-segment 9-digit display and you're turning on digits sequencially, your duty cycle is approximately 11% (1/9)... If you're turning on segments sequencially, your duty cycle is approximately 12.5% ..

I understand turning on digit sequentially but what do you mean by turning ON segment sequentially? How would you do that?

 

[Nigel Goodwin]

If you have an 8-segment 9-digit display and you're turning on digits sequencially, your duty cycle is approximately 11% (1/9)... If you're turning on segments sequencially, your duty cycle is approximately 12.5% ..

I understand turning on digit sequentially but what do you mean by turning ON segment sequentially? How would you do that?

It's just the same really, if you've got 9 digits of 7 segments, you can either drive it as 9x7 or 7x9, the multiplexing is very similar either way.

The comment obviously refered to the decimal point as well, which makes it 9x8 or 8x9.

 

[eblc1388]

Got it.

For a 12-digit mux display, I need 8(segments)+4(decoder to 16 digits)=12 port pins.

But for the segment scan method, I need 12(digits)+3(decode to 8 segments)=15 pins.

Is the calculation correct? The segment method in this case would give better brightness.

 

[Mike - K8LH]

Mike, K8LH wrote:
If you have an 8-segment 9-digit display and you're turning on digits sequencially, your duty cycle is approximately 11% (1/9)... If you're turning on segments sequencially, your duty cycle is approximately 12.5% ..

I understand turning on digit sequentially but what do you mean by turning ON segment sequentially? How would you do that?

As Nigel mentioned, you can "scan" or "drive" that multiplexed display a couple different ways...

<1> Scan the Digits
Source voltage to the Common Anode on a single display while supplying active low signals to all 7-segments and the decimal point, then repeat the sequence for the next display... The Common Anode driver needs to source up to 100-ma or so to light up to 7 segments and the decimal point... The Segment driver only needs to sink a single segment load (typically 10-20ma)...
<2> Scan the Segments
Supply the active low signal to a single segment and supply the positive voltage to the Common Anode of any digits which need to have that particular segment lighted, then repeat the process for the next segment... The segment driver needs to sink 100-ma or so to light that segment on up to 9 displays... The Common Anode driver on each digit only needs to source a single segment load (10-20ma)...

Refering back to that duty cycle... I once had to drive a 12-digit 7-segment display and I found I couldn't get the brightness I needed by scanning the digits (1/12th duty cycle) so I scanned the segments instead (1/8th duty cycle = lots brighter)...

The hardware implications are that you move the high current driver from the common anode lines to the segment lines...

Sorry if this may seem confusing... Scanning the digits of your 9 digit display should work fine and the software algorithm is a little easier...

Regards, Mike

 

[eblc1388]

Thanks for the explanation, Mike.

 

[demestav]

Hello all.

was reading this thread and I was wondering about what Mike had said.

Duty cycle is the portion of time each digit is turned on in one complete cycle... If you have an 8-segment 9-digit display and you're turning on digits sequencially, your duty cycle is approximately 11% (1/9)... If you're turning on segments sequencially, your duty cycle is approximately 12.5% (1/8)... The higher the duty cycle the better the brightness... Don't go less than 10% duty cycle...

Well as I understand it shouldn't the brightness varying according to the refresh rate?
Brightness should be based on how much time electricity passes through the digit for some amount of time (right??). So even if i had only two digits 50% the ratio of current/time is set by the refresh rate. For example if i am refreshing something at 100Hz it should be much brighter than something at 20Hz since more current is passing through the digit.

But why duty cycle? I mean if you need 10usec (just for example) to update one digit it should not matter if you had 1 or 100 digits to refresh.

I am sorry if i got it all messed up, but this is how i realise it. Could you please explain it better? Thanks.

 

[Mike - K8LH]

Well as I understand it shouldn't the brightness varying according to the refresh rate?
Brightness should be based on how much time electricity passes through the digit for some amount of time (right??)

Brightness IS based for the most part on how much time electricity passes through the digit over some period of time...

Perhaps an example will help...

10 Digits, 10% Duty Cycle, Refresh Rate = 100-Hz
Each digit is turned on for 1-msec... It takes 10-msecs to complete a cycle... There are 100 cycles in a second (1-sec/0.01-sec)... Each digit is turned on a total of (100 cycles/sec * 1-msec) 100-msecs / second...

10 Digits, 10% Duty Cycle, Refresh Rate = 50-Hz
Each digit is turned on for 2-msecs... It takes 20-msecs to complete a cycle... There are 50 cycles in a second (1-sec/0.02-sec)... Each digit is turned on a totla of (50 cycles/sec * 2-msec) 100-msecs / second...

I hope that makes sense? Different Refresh Rates but the same amount of "on time" per digit per second... Refresh Rate does not affect the total amount of "on time" per second... Duty Cycle does... Please try the math to confirm this for yourself...

Regards, Mike

 

[Nigel Goodwin]

The refresh rate doesn't matter that much, although if it's too slow you see the flicker, and if it's much too fast you will start to get problems as well.

Simple example!, two digits:

1Hz, current set at 1A by a resistor, so digit 1 gets 1A for 0.5 seconds then digit 2 gets 1A for 0.5 seconds - so each digit gets an average of 0.5A, but the display will obviously exhibit extreme flicker!.

1000Hz, same resistor, digit 1 gets 1A for 0.5uS, then digit 2 gets 1A for 0.5uS, so each display gets EXACTLY the same average of 0.5A.

While both displays are getting the same average current, and displaying the same average brightness, because you can see the 1Hz flashing ON and OFF it will appear brighter while it's ON, but the average is still the same (as it appears totally dark when OFF).

At any sensible refresh rate you can't see the switching, so each digit lights with 50% of the current, and the refresh rate makes no visible difference.

 

[demestav]

Hello again.

Well i agree with the calculations of both posts. What it seems strange to me is this

so digit 1 gets 1A for 0.5 seconds then digit 2 gets 1A for 0.5 seconds

Why should each digit get 0.5seconds??? All it needs is some miliseconds right?

I made a figure to show you how i think of it

At the top figure you can see that digit 1 is updated every TIME A.
(1) TO MIKE: Even if more digits are added ,digit 1 will STILL be updated every TIME A. So why adding more digits will make it less brighter???
(2) If the refresh rate is increased (bottom picture) Digit 1 is updated every TIME B which is much less than TIME A that was before, meaning it would be brighter since current passes much more frequently.

Thank you very much.

 

[Mike - K8LH]

I'm afraid your drawings (and conclusions) are somewhat meaningless if you don't include the important parameters and work through the math...

I apologize for not being able to explain this concept better...

I've tried to make the drawing below similar to your Example A... In this case, yes, you could add a Digit 5 right behind Digit 4 and the display would have the same brightness... But that's because you left holes for extra digits within each Refresh Period... If you work through the math you'll see that Digit 1 still has the same Duty Cycle because you did not change the Digit "on" time or the Refresh Period...

Regards, Mike

 

[Mike - K8LH]

Here's an example where adding a digit would change the Duty Cycle and Refresh Rate...

Again, I apologize for not being able to explain this better...

Regards, Mike

 

[Mike - K8LH]

Finally, here is the missing drawing for my first example;

10-Digit, 10% Duty Cycle, 100-Hz Refresh Rate and
10-Digit, 10% Duty Cycle, 50-Hz Refresh Rate

Here you can see that for any given period of time each Digit is "on" for the same amount of time because the Duty Cycle has not changed, only the Refresh Rate has changed...

If this doesn't help, I promise to stop (grin)...

Best regards, Mike

 

[demestav]

Hello and thnx for the reply

I'm afraid your drawings (and conclusions) are somewhat meaningless if you don't include the important parameters and work through the math...

I dont quite agree with you here. No numbers are needed to show you my point of view! Even if more digits are added the time taken to refresh digit 1 (and every other digit) is not changing by the number of digits!. If the digit will be refreshed 10 times per second or 1000 timer per second has nothing to do with how many digits they are, but with how many time the refresh occurs.

I've tried to make the drawing below similar to your Example A... In this case, yes, you could add a Digit 5 right behind Digit 4 and the display would have the same brightness... But that's because you left holes for extra digits within each Refresh Period...

As I realise it you dont want your mcontroller to be dedicated to the digits. The "holes" is the processing of whatever else the mcontroller has to do like drive motors, take measurement etc. However when the next refresh frame arrives, the mcontroller will refresh the digits again and go back to whatever is doing.


Now looking at your figures, i think understant our difference. You consider that between the refresh rates, ALL of the time should be used to light up the digits. Therefore the more the digits, less the time they will be light up hence less brightness. Hmm yes. I hope this is what you mean.

In any case, I considered that for each digit, a constant amount of time should be spent, whatever the number of digits therefore is the refresh rate that makes the difference.

Thank you.

If this doesn't help, I promise to stop (grin)...

Why? We have a nice discussion here (more like you try to teach me something, but anyway :roll: )...

 

[Mike - K8LH]

Good, Great, Fantastic... I think we both know the same thing but perhaps described it differently... I apologize... Thank you for being patient with me...

As for driving or scanning the Display... I normally use Timer 2 generated 1-msec interrupts and an Interrupt Service Routine to drive the display as an automatic background task (no delay routines, no wasted time)...
------------

I know I promised "no more drawings" but I have one more I'd like to share with the Forum, if anyone is interested...

This drawing shows how you could increase or decrease display brightness by changing the duty cycle (while keeping the same Refresh Rate)... This could be used perhaps to dim a Clock display during night time when all the lights are off... Basically you change the amount of "on" time for each digit to effect a change in duty cycle (and brightness)... You could even change settings in smaller increments over a larger range, say 10% to 16.6% Duty Cycle, for a wider ranging brightness control...

Best regards, Mike

 

[Joel Rainville]

Some parts of that thread would make a nice and detailed tutorial on LED display multiplexing...

Anyone willing to reformat/edit the whole thing?

:? :lol:

Thanks for all the info guys!...

 

[Nigel Goodwin]

Well i agree with the calculations of both posts. What it seems strange to me is this

so digit 1 gets 1A for 0.5 seconds then digit 2 gets 1A for 0.5 seconds

Why should each digit get 0.5seconds??? All it needs is some miliseconds right?

Yes, the time examples were only to show that the actual time doesn't affect the brightness, and as I explained the 0.5 second example would exhibit extreme flickering.

My seven segment multiplexing tutorial actually uses 16mS refresh.