Battery indicator from comparator, problems!

[step_s]

Hey EEVblog.
I'm currently doing a small project that involves a Red-Yellow-Green battery indicator for a Lithium-cell.
I have been using an lm393 dual comparator, and it works, but in-between the cutoffs it seems to have problems.
If the battery voltage drops to the point where the next comparator should kick in, it seems to have a transition phase, where the leds will flicker and act strangely. The cut-off needs to be a lot more sharp, so as soon as the yellow comes on, the red turns off, and as soon as the green comes on, the yellow turns off.
I have included a jpg of the design.
Hope you can help!

Instead of the mosfets in the design, i use SI2300 (N-channel) and SI2301(P-channel).

[Marco]

Use some feedback for hysteresis, first things first though ... that comparator needs headroom, it's not meant to work with common mode voltages at V+.

[step_s]

Hi Marco.
Thanks, I will try adding feedback to have it switch more rapidly.
About the comparator, do you recommend another for this project?

[Marco]

Feedback isn't meant to make it switch faster, it's meant to introduce hysteresis so noise won't turn it off and on.

You can use this comparator, just add a divider for the positive input as well so it's at least 1V under the rail (you have to change the dividers for the negative inputs to take that into account obviously).

[IuriC]

Hysteresis will do fine eliminating the flickering as Marco said, but you have to tweak it fine or you will have states transitions where 2 leds will be on or even both off.

[rs20]

That schematic is absolutely horrible; took me ages to figure out what's going on. I suggest you figure out how to use net labels and power labels (like the GND points) to prevent half the lines on the screen just being meaningless power rails. Label which LEDs are red, yellow and green, or use "LED1", "LED2", "LED3" in your text. What are R7 and R12 doing? Delete them, R8 has that job covered.

Judging from your design, LED1 and LED2 are opposites, whenever LED1 is on, LED2 must be off. Whenever LED2 is on, LED1 must be off. Since LED3 is on sometimes as well, this seems to be at odds with your description which implies that only one LED is on at a time.

About the comparator, do you recommend another for this project?

You could use a comparator that supports inputs around Vcc (google for "above the rail comparator"); but the more standard approach is to divide your battery voltage by 1/2 (using a voltage divider) and comparing that against suitable halved references. That way you get exactly the same results ( x > y implies x/2 > y/2 ), but you can use any old comparator for the job.

...but you have to tweak it fine or you will have states transitions where 2 leds will be on or even both off.

No. In the given design, there are two comparators, and they are set up to trigger at different voltages. What is there to tweak??  The OP seems to be employing the correct method, which is using boolean operations after the comparator to ensure that there's no need for silly tweaking.


Finally, you don't need mosfets for this. Hint: here's a schematic for a two-LED battery indicator -- it requires a comparator with rail-to-rail (instead of open drain/collector), but is very simple:



Challenge for the OP: see if you can extend this design to three LEDs.

EDIT: Fixed broken image link.

[rs20]

Also, you can buy three-legged LEDs which contain both red and green dies; it's actually easier to do a green-yellow-red sequence with these, since yellow is just what you get when red+green are on at the same time.

[IuriC]

My concern about tweaking was related to the feedback resistors necessary to achieve hysteresis. I was building from what Marco had said, I should have been more clear.

[rs20]

My concern about tweaking was related to the feedback resistors necessary to achieve hysteresis. I was building from what Marco had said, I should have been more clear.

Just curious, that's still solvable with straightforward proper design, I don't see where the tweaking aspect comes in?

[step_s]

@RS20
I excuse the poor design of the drawing. This was only to test the concept in a sim.
Never though of the design you show in your post. . . that could make it a lot easier to do, but in that case it would need a mosfet configuration to cut the power for these two LED's so that when the third LED is on, these aren't. The two LED's could be yellow and green.
In that case the mosfet could be driven by the other comparator, so that it turns on that mosfet, while turning off the RED low voltage indicator LED.
How does this sound for improvement?

[rs20]

@RS20
I excuse the poor design of the drawing. This was only to test the concept in a sim.
Never though of the design you show in your post. . . that could make it a lot easier to do, but in that case it would need a mosfet configuration to cut the power for these two LED's so that when the third LED is on, these aren't.

Wrong    The design I showed can be extended to 3 LEDs with no new components (e.g. MOSFETs) or concepts introduced.

[IuriC]

My concern about tweaking was related to the feedback resistors necessary to achieve hysteresis. I was building from what Marco had said, I should have been more clear.

Just curious, that's still solvable with straightforward proper design, I don't see where the tweaking aspect comes in?

I was thinking in the thresholds, now that I wrote the design on a paper it makes no sense to me either. They will not need tweaking 

[rs20]

@step_s: SPOILER ALERT (solution showing three LEDs): https://rs20-static.firebaseapp.com/pano/threeleds.jpg

I should mention that my solutions don't include hysteresis, so they may actually still have the same problem you described in your OP. But positive feedback can be trivially added of course.

@IuriC: No worries 

EDIT: Fixed broken image link.

[step_s]

Sorry for the long response-time- Hope you will help me out anyway
Have only just gotten around to testing the designs you guys have given me.

@rs20
The design would work, but it would need another comparator, since the LM393 is open-collector, and only pulls current when it's "low".
Since the design get's a whole lot more complicated with the LM393, and some sort of push-pull circuit, would you recommend any rail-to-rail dual comparator for this project?

[eneuro]

Have only just gotten around to testing the designs you guys have given me.

I'd rather replaced those all LEDs with one RGB and small MPU to sense voltage on ADC and use PWM to drive RGB led or combine its three R,G,B channels and get many colours possible without any flickering PWM 

This is what I want to do in my next generation charger -one RGB led as battery quick indicator without messign with any LCD displays , etc 

Update: Those colors can be made without any PWM flickering using one RGB LED 

[rs20]

Since the design get's a whole lot more complicated with the LM393, and some sort of push-pull circuit, would you recommend any rail-to-rail dual comparator for this project?

What's you preferred source for components? There are literally tens of thousands of potential parts, I don't think me saying any particular one is particularly helpful. But FWIW, from digikey I'd look at the MCP6542 as a starting point. 1.6V - 5.5V operation range, 2mA output guaranteed (depending on your application, this is plenty to drive a quality LED, and there's an absolute max of 30mA so you can look into seeing how the output would sag for higher drive currents). And it's a dual device, so you only need one part. US$0.57.

...flickering PWM 

Stating the obvious: PWM doesn't flicker if you use a sensible frequency.

[step_s]

Thanks for the swift replies, as always

@eneuro
I haven't really gotten around to messing with MPU's yet, but it would certainly open up a whole new world of possibilities.
You have any specific MPU and ADC (if it isn't integrated on the MPU chip), that would be very small, cheap and easy to use, but still do the job?

@rs20
MCP6542 looks promising, since om using a 5.2V power source for driving the comparator and the LED's. Very affordable as well.
What are your thoughts on the idea of using an MPU instead? Too much work? More expensive, more room needed, programming needed?

[uski]

@eneuro
I haven't really gotten around to messing with MPU's yet, but it would certainly open up a whole new world of possibilities.
You have any specific MPU and ADC (if it isn't integrated on the MPU chip), that would be very small, cheap and easy to use, but still do the job?

PIC10F220 + a few lines of C and it's done
Might cost less than your analog solution especially if you factor the cost of assembly of the parts, and it should use less board space too.

I don't have the requirements of the project so I can't give more specifics, there are tradeoffs to be made if you want to optimize for cost, power consumption, ...

[eneuro]

@eneuro
You have any specific MPU and ADC (if it isn't integrated on the MPU chip), that would be very small, cheap and easy to use, but still do the job?

Not the cheapiest one Atmel AVR but small SO-8 package:
http://www.tme.eu/en/details/attiny13a-ssu/avr-smd-atmel-microcontrollers/atmel/
Use right three pins for RGB led control with current limiting resistors, another two left ADCs to sense voltage and current, etc.

Probably  there are cheapier PIC, but I use ATMEL AVR MPUs-MPU choice will depend on how many such battery indicators you need to manufacture. Principle remain the same-in your case 1 MPU pin for ADC, three for RGB LED control via three curent limiting resistors.

...flickering PWM 

Stating the obvious: PWM doesn't flicker if you use a sensible frequency.

Which is this frequency in your opinion for 5mm 20mA yellow LED?

digikey: Characterizing and Minimizing LED Flicker in Lighting Applications

Tests show that humans find it difficult to directly sense light flickering at these higher frequencies, but that seems to hardly matter. Scientists have conducted research that indicates the human retina is able to resolve light flickering at 100 to 150 Hz, even if the subject is not aware of it, leading to the conclusion that the brain may well be reacting.

...

Until recently, lighting engineers have been relatively unconcerned by the effects of imperceptible flicker. However, the tightening of health and safety rules, better research, and increasing complaints from staff working in offices illuminated by ubiquitous fluorescent tubes have led to calls for action.

Flickering perception by humans is one thing, another when you have I/O pins changes on MPU it affects ADC measurements, but in the case of battery indicator it shouldn't be a problem, but sometimes it can be.

While it looks like we can have from RGB LED green,red,yellow colors without any PWM needed, so any reason to use PWM when we do not need it?
We might need it, if we added light sensor to this battery indicator, so it could adjust indicator light to ambient light, so in the dark we could use PWM to make LED darker at night, while more intense in daylight conditions 

[rs20]

@rs20
MCP6542 looks promising, since om using a 5.2V power source for driving the comparator and the LED's. Very affordable as well.
What are your thoughts on the idea of using an MPU instead? Too much work? More expensive, more room needed, programming needed?

With the MCP6542, you can just assemble the circuit and it just immediately works, and you gain some analog experience. With an MPU, you have to spend time writing the code, arranging for a programming header on the board (or, some alternative hack); but it can wind up being cheaper and lower component count than otherwise. You also gain MPU experience. Very much a personal choice for hobbyist usecase. What seems more intriguing to you?

For a large-scale manufacturing usecase, you'd want to figure out the costs (including (pre-?)programming the chips), and choose the cheapest approach that meets all requirements.

Stating the obvious: PWM doesn't flicker if you use a sensible frequency.

Which is this frequency in your opinion for 5mm 20mA yellow LED?

Um, I dunno, anything from 200 Hz to 10,000,000 Hz?

Flickering perception by humans is one thing, another when you have I/O pins changes on MPU it affects ADC measurements, but in the case of battery indicator it shouldn't be a problem, but sometimes it can be.

While it looks like we can have from RGB LED green,red,yellow colors without any PWM needed, so any reason to use PWM when we do not need it?

If the end user is best-served by the familiar Green-Yellow-Orange-Red sequence, then that's what you deliver, even if Orange requires PWM. Defining user interfaces based on "problems" that aren't even real problems (as you pointed out) and expecting the user to understand that Magenta means 25% is just horrible engineering.

We might need it, if we added light sensor to this battery indicator, so it could adjust indicator light to ambient light, so in the dark we could use PWM to make LED darker at night, while more intense in daylight conditions 

Also a good usecase for PWM.

[Jeroen3]

I've done similar for a motorcycle battery not-charging led.
I used an Attiny10, 6 pin sot, one transistor for Red, one transistor for Green. These share the TPI, so on-target programming is still possible.
Put 1 pin in ADC mode, and perform simple comparison with hysteresis to convert ADC values to Red/Orange/Green pwm ranges. You cannot really do maths in the thing.
Bonus feature is red blinking on overcharging (>16v) / undervoltage (<9v) (broken voltage regulator).

It's a challenge to put C in an attiny10, but not impossible. Some C features immediately overflow the 1kByte flash.

[rs20]

I've done similar for a motorcycle battery not-charging led.
I used an Attiny10, 6 pin sot, one transistor for Red, one transistor for Green. These share the TPI, so on-target programming is still possible.
Put 1 pin in ADC mode, and perform simple comparison with hysteresis to convert ADC values to Red/Orange/Green pwm ranges. You cannot really do maths in the thing.
Bonus feature is red blinking on overcharging (>16v) / undervoltage (<9v) (broken voltage regulator).

It's a challenge to put C in an attiny10, but not impossible. Some C features immediately overflow the 1kByte flash.

Such as? Do you mean C, or standard libraries?

[eneuro]

It's a challenge to put C in an attiny10, but not impossible. Some C features immediately overflow the 1kByte flash.

Did you ever watched assembler listing of compiled C source code for ATTiny?

Maybe you tried used floating numbers and some builtin functions from C, but for LED blinking one might want setup timer lets say at 1kHz-10kHz and during this interrupt define own clock, where 1s second is 1000ms (at 1kHz),
start ADC conversion which will take at 250kHz choosen ADC clock about 13 steps, so even at 10kHz timer interrrupt it will finish within 10kHz interrupt time while we have close to 19kHz sampling rate, make calculations during ADC conversion and turn on/off given RGB LED pins, read ADC result and store reading-if you code this in C and optimise for size -0s with avr-gcc than see asember code of course you dot need any standard C libraries to do this, so assembled code will be small and effcient 
However, you can also write critical parts in assembler, when you see in compiled binary that MPU code could be even more effcient or do tricky things with registers, etc.
For it is standard, that I look into assembler code to see compiled C source code 
I need such battery indicator, too so I will write such code but rather for Attiny25/45/85 depending on price, since probably I will store in its flash program memory precomputed RGB palette for R,G,B channels of hot iron thermal imagining palette, while I like colours change in this palette, so for 256 colors we need 3x256 bytes 0.75KB, so slightly more flash program memory than 1KB might be needed for additional logic, but effect should be quite interesting-the same thermal imagining palette can be used for temperature indicator, etc
Just calculate index, read flash program memory R,G,B values and adjust PWM for each output LED pins.

[rs20]

You're making this sound vastly more complex than it needs to be. Remember, we're trying to help, not intimidate.

[eetech00]

Hi

I didn't read through this whole thread, but if your re-doing this project, why not just use an LM3914?