Battery indicator from comparator, problems! - Page 1
Forum section: electronics / projects

author: step_s
author_rank: Regular Contributor
timestamp: October 19, 2015, 03:19:58 pm
content: 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).

author: Marco
author_rank: Super Contributor
timestamp: October 19, 2015, 03:37:23 pm
content: 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+.

author: step_s
author_rank: Regular Contributor
timestamp: October 19, 2015, 05:20:54 pm
content: Hi Marco.Thanks, I will try adding feedback to have it switch more rapidly.About the comparator, do you recommend another for this project?

author: Marco
author_rank: Super Contributor
timestamp: October 19, 2015, 09:57:09 pm
content: 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).

author: IuriC
author_rank: Contributor
timestamp: October 20, 2015, 01:57:24 am
content: 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.

author: rs20
author_rank: Super Contributor
timestamp: October 20, 2015, 02:22:51 am
content: 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.Quote from: step_s on October 19, 2015, 05:20:54 pmYou 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.Quote from: IuriC on October 20, 2015, 01:57:24 amNo. 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.

author: rs20
author_rank: Super Contributor
timestamp: October 20, 2015, 02:26:24 am
content: 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.

author: IuriC
author_rank: Contributor
timestamp: October 21, 2015, 12:36:05 am
content: 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.

author: rs20
author_rank: Super Contributor
timestamp: October 21, 2015, 03:28:47 am
content: Quote from: IuriC on October 21, 2015, 12:36:05 amJust curious, that's still solvable with straightforward proper design, I don't see where thetweakingaspect comes in?

author: step_s
author_rank: Regular Contributor
timestamp: October 22, 2015, 03:46:32 pm
content: @RS20I 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?

author: rs20
author_rank: Super Contributor
timestamp: October 23, 2015, 02:53:52 am
content: Quote from: step_s on October 22, 2015, 03:46:32 pmWrongThe design I showed can be extended to 3 LEDs with no new components (e.g. MOSFETs) or concepts introduced.

author: IuriC
author_rank: Contributor
timestamp: October 23, 2015, 04:07:16 am
content: Quote from: rs20 on October 21, 2015, 03:28:47 amI 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

author: rs20
author_rank: Super Contributor
timestamp: October 23, 2015, 05:20:41 am
content: @step_s: SPOILER ALERT (solution showing three LEDs):https://rs20-static.firebaseapp.com/pano/threeleds.jpgI 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 worriesEDIT: Fixed broken image link.

author: step_s
author_rank: Regular Contributor
timestamp: November 24, 2015, 11:51:09 pm
content: Sorry for the long response-time- Hope you will help me out anywayHave only just gotten around to testing the designs you guys have given me.@rs20The 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?

author: eneuro
author_rank: Super Contributor
timestamp: November 25, 2015, 12:10:45 am
content: Quote from: step_s on November 24, 2015, 11:51:09 pmI'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 PWMThis is what I want to do in my next generation charger -one RGB led as battery quick indicator without messign with any LCD displays , etcUpdate: Those colors can be made without any PWM flickering using one RGB LED

author: rs20
author_rank: Super Contributor
timestamp: November 25, 2015, 02:09:20 am
content: Quote from: step_s on November 24, 2015, 11:51:09 pmWhat'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.Quote from: eneuro on November 25, 2015, 12:10:45 amStating the obvious: PWM doesn't flicker if you use a sensible frequency.

author: step_s
author_rank: Regular Contributor
timestamp: November 25, 2015, 03:03:36 am
content: Thanks for the swift replies, as always@eneuroI 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?@rs20MCP6542 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?

author: uski
author_rank: Frequent Contributor
timestamp: November 25, 2015, 04:57:32 am
content: Quote from: step_s on November 25, 2015, 03:03:36 amPIC10F220 + a few lines of C and it's doneMight 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, ...

author: eneuro
author_rank: Super Contributor
timestamp: November 25, 2015, 07:42:26 am
content: Quote from: step_s on November 25, 2015, 03:03:36 amNot 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.Quote from: rs20 on November 25, 2015, 02:09:20 amWhich is this frequency in your opinion for 5mm 20mA yellow LED?digikey: Characterizing and Minimizing LED Flicker in Lighting ApplicationsQuote...QuoteFlickering 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

author: rs20
author_rank: Super Contributor
timestamp: November 25, 2015, 08:03:16 am
content: Quote from: step_s on November 25, 2015, 03:03:36 amWith 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.Quote from: eneuro on November 25, 2015, 07:42:26 amUm, I dunno, anything from 200 Hz to 10,000,000 Hz?Quote from: eneuro on November 25, 2015, 07:42:26 amIf 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 thatMagentameans 25% is just horrible engineering.Quote from: eneuro on November 25, 2015, 07:42:26 amAlso a good usecase for PWM.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 25, 2015, 09:51:53 am
content: 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.

author: rs20
author_rank: Super Contributor
timestamp: November 25, 2015, 10:47:05 am
content: Quote from: Jeroen3 on November 25, 2015, 09:51:53 amSuch as? Do you mean C, or standard libraries?

author: eneuro
author_rank: Super Contributor
timestamp: November 25, 2015, 01:42:27 pm
content: Quote from: Jeroen3 on November 25, 2015, 09:51:53 amDid 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 effcientHowever, 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 codeI 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, etcJust calculate index, read flash program memory R,G,B values and adjust PWM for each output LED pins.

author: rs20
author_rank: Super Contributor
timestamp: November 25, 2015, 01:45:31 pm
content: You're making this sound vastly more complex than it needs to be. Remember, we're trying to help, not intimidate.

author: eetech00
author_rank: Regular Contributor
timestamp: November 25, 2015, 01:48:44 pm
content: HiI didn't read through this whole thread, but if your re-doing this project, why not just use an LM3914?

author: eneuro
author_rank: Super Contributor
timestamp: November 25, 2015, 01:56:22 pm
content: Quote from: eetech00 on November 25, 2015, 01:48:44 pmBecause of it haven't got custom RGB pallette I might want to use or ... not available for example there in SMD version, where I'd like to order other components?http://www.tme.eu/en/details/lm3914n/led-drivers/texas-instruments/lm3914n-1nopb/

author: step_s
author_rank: Regular Contributor
timestamp: November 25, 2015, 10:46:44 pm
content: Quote from: rs20 on November 25, 2015, 01:45:31 pmYe, the thread is starting to be a bit confusingQuote from: uski on November 25, 2015, 04:57:32 amThis one looks quite promising! Since i'm a complete newbie in this field, i would just like to know if there is any easy way to get started?What kind of USB interface would i need to program this chip?Hope you can ease me into this

author: eneuro
author_rank: Super Contributor
timestamp: November 25, 2015, 11:18:27 pm
content: Quote from: rs20 on November 25, 2015, 01:45:31 pmThere is nothing complex to store look up table in MPU flash program memory on AVR ATTiny85:Code:unsigned char rgbtab PROGMEM ={{0,0,0}, // OFF{255,0,0}, // Red{0,255,0}, // Green{0,0,255}, // Blue..// What ever RGb color you like...{255,255,255} // White}; // RGB tableThen start ADC measurement and mean time find indexed look up table based eg. moving average of read ADC values:Code:R= pgm_read_byte( &rgbtab );G= pgm_read_byte( &rgbtab );B= pgm_read_byte( &rgbtab );Few colors can be hardcoded, but it can be done easy in a way shown above.One can change this RGB table without recompiling MPu software-just by overwriting byte code and programming with custom RGB table...This is like "Hello MPU World !!!" simply C code