Multiplexing and Peak Current

Hello everybody,

I'm taking my first foray into multiplexing in order to reduce the number of IC's I need to run a 4 digit 7-Segment display. I used to run a 7-Segment display I got from goldmine electric that had pinouts for each individual segment (32 pins total) with a common anode using four 74HC595's. My larger project that I'm working on requires that the footprint of my PCB be smaller than it was in its previous iteration.

What I'm doing now is I'm running the 16 pin 7-Segment common anode display I got from sparkfun with a single 74HC595. The Arduino is driving the digit assignment, and the 595 is controlling the segments. I have my code working fine so far...

Even though I have only four digits running, my duty cycle for each digit appears to be around 10% (according to my admittedly inadequate multimeter), and my refresh rate is about 50hz. I'm assuming some of the duty cycle is being lost in communication with the 595 IC, other code, etc.

Looking at the datasheet, my peak forward current is 30mA and continuous forward current is 20mA, both at 2.1V. To be safe, I currently chose my resistors (one for each segment 150 Ohms) based on the continuous current.

The specs for the peak forward current are 1khz and 10% duty cycle. I've seen graphs of the effect of the duty cycle, but not refresh rate. How does the refresh rate effect the peak forward current? I'm trying to figure out how to maximize the output brightness without blowing out the display.

I've seen graphs of the effect of the duty cycle, but not refresh rate.

Wouldn't the "Duty Cycle" of the LED be the same as its "Refresh Rate" (or directly related)?

As I meant it, the refresh rate in my case is 50hz (50 times a second), and the duty cycle being 10% means that each digit is on for 1/500 of a second. Does it mean something else?

You have answered your own question. Knowing the refresh rate you can calculate the actual (or total) duty cycle. The time between "refreshes" just adds to the amount of time the LED is off.

Every 50ms you active an specific element for what amount of time? Your 10% Duty Cycle is part of that time. Add in the amount of time you aren't accessing the specific element and now you know your true duty cycle (which is much less than 10%).

I took the readings off the anode of one digit of my display, not a segment (especially since the digit changes it would vary greatly). The whole digit is turning on once every 50th of a second for 1/500th of a second right? How do I determine how much current is safe for the individual segments at that rate?

What did you use to make that measurement?

My multimeter with the positive lead attached to my digit's anode and the negative lead attached to ground with the setting to read HZ then to read duty cycle.

Okay so in that context, frequency is how often something transitions (from LOW <-> HIGH) and duty cycle is how long it stays HIGH.

So if you are saying the multimeter read a frequency of 50Hz, you are correct. Every 50mS the LED turns on for 10% of the total time. So every 50mS your LED segments are turning on for 5mS.

My first reply was hinting at the fact the datasheets won't have anything on "refresh rate." This is a term you've made up. Well okay well have. Duty Cycle is the total amount of time the LED Is on versus the total amount of time the LED is off. As I said before your refresh rate is part of that time.

Ah, okay. I obviously used the wrong term.

What I meant was, the datasheet says this:

Peak forward current(Duty Cycle=1/10, 10KHz) = 30mA

How is it effected that my duty cycle is 1/10, at 50Hz?

10% of 10KHz = 1KHz.
1KHz = 1ms

The LED can tolerate 30mA for up to 1ms.

In your case, the segments appear to be operating for 5ms, so you should probably keep your current limited to 20mA.

Awesome!

Thanks, I learned something today :smiley:

Looking through my own code in response to another person's multiplexing thread, I realized that I know exactly how long my led's are on for.

digitalWrite(place + 2, HIGH);  //turns on the digit (again, lazy: 0th digit is digital pin 2)
  delay(4); //digit stays on for 4ms
  digitalWrite(place + 2, LOW);  //turns of the digit

You could look into a multuplexing chip from maxim-ic.com if you are looking to reduce footprint.
1 surface mount chip, driving up to 8 digits, controlled by just 2 or 3 pins from the uC.
http://datasheets.maxim-ic.com/en/ds/MAX6950-MAX6951.pdf

The max6951 is just 16 pins, really small footprint since its surface mount only.
Article on how it works.

Hard to say if its appropriate with out knowing more about your display.

Maybe you could mount the display over a driver chip - some displays are quite wide and could overlay a standard DIP part with its 0.3" wide package. Or moun the display on top of the board and driver chips on the bottom, see the Nano as an example http://arduino.cc/en/Main/ArduinoBoardNano

It's just a simple 4-digit 7-segment common anode display with dots and colon from sparkfun. 16 pins, and all the digits share the same A, B, C, D, E, F, G, and dot cathodes.

I thought it was a good one to play with because it appears to be impossible to use properly without multiplexing, and that way I don't need to join together all the A, B, C, etc cathodes.

A M74HC595 is small and can be DIP (because I've found I stink at surface mount soldering, despite my many attempts). I previously tried to make my project in SMD to make it smaller. Now I'm trying to do it in DIP, but as efficiently as possible. I intend to integrate an avr or other microcontroller into the PCB to communicate between the sensors, user input, and display anyway. I have a lot of background in java programming, so the arduino IDC is really appealing to me.

I see, so you have to shift out with Common Anode A high, then shift out with Common Anode B high, then repeat for C, and then for D.
& repeat. Guess that's doable. Might get flickery if you have a lot of other stuff going on.
So, it looks to me that the displays sits up pretty high, I bet it would straddle a DIP part, or maybe raise it a little by having a row of socket pins it would plug into:

I was just on mouser earlier trying to find a display driver, and I felt it was just too far over my head, and more than half of them were just enormous.

On the last iteration of this project, I lifted up the display using those machine headers over at sparkfun, but I don't think I'd be able to fit the 595 dip package under this one, or would want to. I think I may use the headers anyway to lift it up for ventilation so it'll have a better life span, and I can replace it easier.

We'll see about flickery. There's not a huge amount of stuff happening with the sensor... I worry most about when I put the rotary encoder in there... I'll probably be back in the forum because I'm not thrilled with the solution I came up with last time. (too much code and not enough precision)