# Possible causes for 7-segment LED flicker

I'm working with a vendor overseas to revamp an existing product. We're trying to keep cost down.

Currently the product consists of:

• 4 large buttons
• 4 double digit 7-segment LEDs. (each button has double digit underneath it)
• 1 LCD (8 characters...each character display is composed of a 3x8 grid of LCD dots)
• a speaker
• a microcontroller
• LCD driver

In the revamp, the vendor wants to address an issue with the current product. All 4 of the double-digit LEDs have a noticeable flicker.

The vendor is giving us an estimate that includes using a new microcontroller, some circuit redesign, and redoing the whole program! (we just want to swap out audio files and fix the flicker...I don't think that the general logic for the product needs to change at all)

I'm not sure exactly how the previous circuit was designed, but potentially the flickr could be due to the mcu not being fast enough to PWM when lighting the LEDs.

In general, based on experience, what could be some other causes of flickering 7-segment LEDs. I just want to understand the issue so that I can discern whether the vendor is budgeting additional work when it is not needed.

• Hail-Mary hack: double (or more) the MCU oscillator frequency. It probably won't work, but, hey, why not? – tyblu Apr 24 '12 at 0:08

Flicker is a result of too slow refresh. You need to refresh each segment at a few 100 Hz minimum. However, there are some tricks that can reduce apparent flicker while not actually doing faster refresh. The naive approach is to refresh the digits in order. But, if you alternate them a bit, the whole number will appear to flicker less. For example, do digits 1, 3, and 5, then come back and do digits 2, 4, and 6.

Without knowing the processor and seeing the source code, it's impossible to say whether the vendor is trying to string you along or the mess really needs to be re-written. Keep in mind that 99% of firmware engineers write horrible firmware. There could be hard coded constant all over the place that make assumptions about the clock frequency, the LED refresh rate, etc. With well written firmware, increasing the refresh rate assuming the processor has the necessary cycles already should be easy. With badly written firmware, it could be a lot more trouble than to ditch the mess and write it right.

How come the original designer didn't address the flicker? Perhaps the firmware is so badly architected that simply increasing it wasn't possible? If the flicker is that obvious, then why was the product ever created the way it is? That alone makes it likely the original designer made a mess. If he could have easily fixed it, he probably would have.

The really funny thing is now you're doing it again. You are going overseas because you want to keep costs down. Good design costs real money, but bad design costs much more. Even though you have been bitten by that, you have still not apparently learned it. With good design in the first place you wouldn't be in this position, and even if you were, it should be easy to change. There is no excuse for changing stored audio not being a simple operation.

How do you know if it's a bad idea or not to change the microcontroller and the circuit if you don't know what either are? Buying engineering strictly on price is the most expensive way to go.

I don't remember where I heard about refreshing digits non-sequentially, but I have tried it and found it to help. I think it works for the same reason interlaced TV appeared to flicker at the field rate instead of the frame rate. For NTSC, the whole picture was redrawn at 30 Hz, but the apparent flicker was 60 Hz because of the interlacing refresh. You're not going to get 2:1 like that by interlacing digits, but it does help.

No, 60 Hz is not fast enough, not even close. 60 Hz is about where most people don't see flicker anymore for a square wave. Someone staring directly at a LED driven 50% of the time at 60 Hz may not see the flicker, but that's not the only way people perceive it. Unless you only have two digits, the LEDs will be on brighter for a smaller fraction of the time, which makes the flicker more apparent. The center of your retina is the slowest in responding. You will notice flicker more at the periphery of your vision. However the real objectionable part is when you move your eyes. Flicker is easily apparent at 60 Hz. You can't make the flicker invisible due to this phenomena, so the problem is to make it less annoying. 60 Hz is still quite annoying for most people. As I said, you want a few 100 Hz at least. If you have to pick a number, I'd start by trying to achieve at least 500 Hz.

As for getting good engineering, that's a whole topic on its own. There is nothing inherently wrong with going overseas. Competent people live in various places. The issue is first to recognize that bad design will cost a lot more than hiring a top engineer to do it right in the first place. Second, you have to realize that finding and vetting engineering talent takes some work. You're going to spend 1000s of $, probably 10s of 1000s of$. Treat it like other purchase decisions of that magnitude. Ask around, interview, get references and actually follow up on them.

As long as you're serious and the job is real, I'd say you have the right to expect around 2 hours of initial consultation before any committment is made. Keep in mind that goes both ways. Part of this time is for you to evaluate the engineer, but of course the engineer is evaluating you too. They are trying to decide whether this job fits in line with what they want to be doing, whether you are going to be a pain in the butt customer, etc. Either way, there should be plenty of time to get into the requirements and talk about initial impressions of what path the engineer will persue towards the solution. This should tell you a lot about how they think, how much they just implement whatever you told them versus drilling down and trying to get at the real problem and making sure that is solved, suggesting alternate solutions, etc.

None of this says the engineer can't be oversees, but it does make logistics and good evaluation difficult. If you have a couple of strong recommendations from people you trust, then that helps a lot. If you're logic is only that Bob in Boston wants $130/hour and is estimating 4 weeks while Naresh in Bangalore wants$35/hour and can do it in 2 weeks, you're headed for serious trouble.

• +1 for all around. I also never knew that refreshing them out of order can reduce flicker, good piece of trivia. A quick google search didn't really return any information to that fact. Do you have a link/reference that explains that phenomenon? I am curious about the reason that the brain would behave that way. – Kris Bahnsen Apr 23 '12 at 23:58
• refresh each segment at a few 100 Hz minimum Wouldn't 60 Hz (refresh rate of games, LCDs etc.) suffice? – m.Alin Apr 24 '12 at 0:31
• Olin: You have a good point about getting good engineering. What would you suggest? Engineer domestically and then produce it overseas? – milesmeow Apr 24 '12 at 2:12
• @m.Alin: See addition to answer. – Olin Lathrop Apr 24 '12 at 12:30
• @kris: See addition to answer. – Olin Lathrop Apr 24 '12 at 12:30

I agree 100Hz min refresh rate. That should be pretty easy to do in code for any uC. Any other symptoms of low clock f? like low pitch in speaker?

All Mux'd displays assume a fixed %Duty cycle = On/Cycle time so average current is constant regardless of Refresh time. So how the ON time and Cycle time must be understood when making changes.

If you KNOW HOW, it's trivial. If you do not, it's really really expensive.

I understand that the flicker can be seen in all units of that same product model, so it is not that something has been damaged. I would also say that you just need to increase the refresh frequency, and of course not to change the whole program.

It might be the case that the MCU is not fast enough to refresh those double digits at a higher rate, but I doubt it. Can you tell us what MCU is it?