Post by thread:[EE]: Yet another PIC (or AVR) based intelligent b

part 1 1935 bytes content-type:text/plain; charset=us-asciiHi All, For a few months I have been thinking about building an PIC or AVR based intelligent NiCD/NiMH battery charger (however I couldn't find time to acomplish it). I have found a few nice projects, built by the others, a) www.angelfire.com/electronic/hayles/charge1fig3.html b) http://www.microchip.com/Download/appnote/category/rdesigns/30451c.pdf However I still have some doubts. If one charges a 1.2V battery from eg. 5V source without inductive elements, then the efficiency may not be higher than ca. 25%. For the ideological (economy+ecology) reason I'd like to make the charger as efficient as possible, so I'd like to use a kind of DC/DC converter to efficiently charge my battery. The proposed schematics is shown in attached files (no GIFs because of LZW patent issues) in PNG and PDF format. T1,R1,R6,D1 and D2 create switch with current limit (to avoid danger of saturation of L1's core). R6 speeds up the switching off. The Zener's diode D4 (eg. 3.3V) protects the voltage sensing input against damage, when battery is disconnected (one may use the normal diode connected in opposite direction to the PIC's Vcc). R2 measures the battery charge current, and R3,C3 form the lowpass filter for mean current measurement. R4,R5 and T2 create the battery discharge system. So one needs two A/D pins and two digital pins for each battery, and one PWM output for all batteries (well it is possible to use two PWM output to charge different size batteries simultaneously). The device will use unstabilized AC/DC power supply, with additional low power 5V stabilizer for PIC alone, so the overall efficiency should be high... I'd appreciate any comments/suggestions. The design when (or "if" ;-) ) finished will remain open source/open hardware. -- TIA & Regards Wojciech M. Zabolotny spam_OUTwzabTakeThisOuTise.pw.edu.pl part 2 2046 bytes content-type:application/octet-stream (decode) part 3 5031 bytes content-type:image/png (decode) part 4 3692 bytes content-type:application/pdf (decode) part 5 105 bytes (decode)

Hmm, you can simplify it a bit, get rid of R1, D1 and D2. You really don't need them. You don't need D4 either for that matter. For simplicity sake try a simple series resistor before the battery, then take two ADC taps, one before and one after the resistor. This will give you battery voltage and current. In the SMPS trials I found you can use a 1mH or 1.5mH prewound tiny RF inductor, good for 100mA, maybe even 200mA. These are cheap and small. My preference would be to keep it real simple in hardware, then use the PIC for the other stuff like current averaging and battery testing. :o) -Roman Re the gif issue, you can also use the "ancient" RLE format .PCX, works pretty good for 2 colour circuit diagrams, and more people can access it. Wojciech Zabolotny wrote: {Quote hidden}> > Hi All, > > For a few months I have been thinking about building an PIC or AVR based > intelligent NiCD/NiMH battery charger (however I couldn't find time > to acomplish it). > I have found a few nice projects, built by the others, > a) www.angelfire.com/electronic/hayles/charge1fig3.html > b) http://www.microchip.com/Download/appnote/category/rdesigns/30451c.pdf > > However I still have some doubts. If one charges a 1.2V battery from eg. 5V > source without inductive elements, then the efficiency may not be higher > than ca. 25%. For the ideological (economy+ecology) reason I'd like to > make the charger as efficient as possible, so I'd like to use a kind of > DC/DC converter to efficiently charge my battery. > > The proposed schematics is shown in attached files (no GIFs because of > LZW patent issues) in PNG and PDF format. > T1,R1,R6,D1 and D2 create switch with current limit (to avoid danger of > saturation of L1's core). R6 speeds up the switching off. > The Zener's diode D4 (eg. 3.3V) protects the voltage sensing input against > damage, when battery is disconnected (one may use the normal diode connected > in opposite direction to the PIC's Vcc). > R2 measures the battery charge current, and R3,C3 form the lowpass filter > for mean current measurement. > R4,R5 and T2 create the battery discharge system. > So one needs two A/D pins and two digital pins for each battery, and one PWM > output for all batteries (well it is possible to use two PWM output to > charge different size batteries simultaneously). > The device will use unstabilized AC/DC power supply, with additional low > power 5V stabilizer for PIC alone, so the overall efficiency should be > high... > > I'd appreciate any comments/suggestions. The design when (or "if" ;-) ) > finished will remain open source/open hardware. > > -- > TIA & Regards > Wojciech M. Zabolotny > .....wzabKILLspam@spam@ise.pw.edu.pl > > --------------------------------------------------------------- > > Name: piclad.fig.gz > Type: GNU Zip Compressed Data > Part 1.2 (application/x-gzip) > Encoding: base64 > Description: XFig source of schematics diagram > > Name: piclad.png > Part 1.3 Type: image/png > Encoding: base64 > > Name: piclad.pdf > Part 1.4 Type: Acrobat (application/pdf) > Encoding: base64 -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

On Saturday 13 October 2001 06:53 am, Wojciech Zabolotny wrote: > R2 measures the battery charge current, and R3,C3 form the lowpass filter > for mean current measurement. > R4,R5 and T2 create the battery discharge system. > So one needs two A/D pins and two digital pins for each battery, and one > PWM output for all batteries (well it is possible to use two PWM output to > charge different size batteries simultaneously). Well, your sense resistor R3 has to be very small for efficiency, so the voltage will be very low (that is, if you want to limit losses in this part of the circuit to 5%, then the voltage across the resistor will be roughly 60mV). Unfortunately, 60mV is only about a third of the minimum PIC A/D +VRef of 2V. My guess is that you'll want to amplify this sense voltage. -- Ned Konz currently: Stanwood, WA email: .....nedKILLspam.....bike-nomad.com homepage: http://bike-nomad.com -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

> The proposed schematics is shown in attached files (no GIFs because of > LZW patent issues) This is silly. First, I thought Compuserve paid off Unisys for the right to use LZW compression in GIF files a long time ago. Second, I have never heard of Unisys going after individual users of GIF files although they clearly know it is going on a great deal. Also, there are many free, shareware, and commercial software packages that support GIF files, and I've never heard of Unisys going after any of these either. Again, I think this is all due to the deal with Compuserve. Anyone know for sure? ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, olinspam_OUTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

----- Original Message ----- From: Olin Lathrop <KILLspamolin_piclistKILLspamEMBEDINC.COM> > > The proposed schematics is shown in attached files (no GIFs because of > > LZW patent issues) > > This is silly. First, I thought Compuserve paid off Unisys for the right to > use LZW compression in GIF files a long time ago. Likely for for Compuserve & their customers to make and use GIFs, but what about everyone else? >Second, I have never > heard of Unisys going after individual users of GIF files although they > clearly know it is going on a great deal. Also, there are many free, > shareware, and commercial software packages that support GIF files, and I've > never heard of Unisys going after any of these either. Again, I think this > is all due to the deal with Compuserve. Anyone know for sure? Individual users no. But Unisys has been very weird about the whole thing. They let it go until it gets rediculously popular and supposedly they started demanding royalties software companies that sell GIF capable products. IIRC Most commercial products have those royalties paid for. The whole thing is silly and most individuals need not concern themselves unless Unisys goes weird. Jeff -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

Olin Lathrop wrote: >> The proposed schematics is shown in attached files (no GIFs because of >> LZW patent issues) > > <snip> > Also, there are many free, shareware, and commercial software packages > that support GIF files, and I've never heard of Unisys going after any > of these either. Again, I think this is all due to the deal with > Compuserve. Anyone know for sure? > > ******************************************************************** </snip> I think that as long as you're using a commercial product to generate the gif images, you should be alright. The company paid the royalty for the algorithm! Jim Korman -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Unisys owns the patent on LZW and specifically permits the use of the LZW in the GIF compressors and decompressors for non-commercial use only. Commercial use requires a license. This causes many Open Source fans to avoid GIF at any cost and many other people to avoid it too. It is not clear whether a schematic published in a public forum in GIF format can be 'commercial use', even if it is posted by a registered firm. Peter PS: I am not a lawyer. The above reflects what I know about the issue. Things may have changed very recently. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads