Default Charge profiles

The past few days I have been pouring over different battery manufactures tech manuals and their recommended charge profiles.  What strikes me is the rather wide variation in approaches for charging, even the good old Flooded Lead Acid batteries, everyone seems to have a slightly different idea on what makes a Good Charger.

But one thing all  battery manufactures have in common is the idea of ending charging when the battery is truly fully charged, and with the exception of LiFeP04 batteries - that all really depended on measuring the Amp the battery is accepting.

I have posted many of the technical manuals I found on the Google drive, click on the 'Reference' tag above.

It was interesting to research the LeFiP04 batteries.  These have the look to becoming a standard in a few years, prices need to drop a little, but they have lots of good reasons to use them over FLAs.  With a proper Battery Manager on each cell, most all issues of the past go away.  Charging them looks to also be simple:  LiFeP04 batteries exhibit a rather flat discharge curve - holding their voltage constant until they are just about exhausted.  When recharging, it is about the same - they hold a steady voltage until they are full, then the volts start to rise quickly!  I placed in a default LiFeP04 profile that seems to match a few of the larger batteries out there, but truth be told I thin the profile will need to be customized for each battery and BM combination.

Here is the default table I have as of now:

Click for larger view.

This is a large table, click on it to get a larger view.  (And see the source code for more details, ala how to drop out of Float mode and get back into Bulk mode)

If interest is #7, this was an advanced charge profile recommended by one manufacture for their large industrial batteries.  Not the 4th phase which is Amp limited, letting the voltage rise.  Also of key note is the Exit Absorption phase  by Time and/or Amps.  Almost without exception, battery manufactures prefer using Amps as a trigger point for deciding the battery is fully charged.  In fact, many will recommend a dramatically shorter max time (like 3hrs) if Amps are NOT being measured, to prevent overcharging.

Voltage Only deployments as a default condition?

One of the major goals of this regulator is the ability to measure Amps and use that information to better determine the actual battery state of charge.  However, there are some people who may wish to avoid the hassle of installing an Amp Shunt, and just use the regulator in plain old Voltage Only mode.  Maybe they have a 48v system and just need a regulator.

It is possible to configure the regulator to behave using only volts and time values via the (CPE (Charge Profile Entry) tables, setting the EXIT_AMPS values = 0.  In doing so, only the EXIT_TIME criteria will be looked at. 

But in the default configuration, all the EXIT_AMPS criteria have values - it is after all a core goal of the design!  The user can change these using the ASCII strings (ala, $CPA:7 xx,xx,xx.xx) to modify a default CPE entry - removing the Amps criteria.  But that takes work.

But I can add a feature.  If the measured Amps NEVER exceed 1A,  I can ASSUME the Amp Shunt is not connected, and in that situation will ignore the AMP exit criteria as well - just rely on the time values.

As a safety check, if the user has not defined a timeout value, will not do this - to prevent a miss-configuration from boiling the batteries dry.  But even so, this would introduce a down side: For deployments where the Amp measurement is set up, it is fails currently the alternator will quickly go into Float.  However, if I do make this change, such a failure in the Amp Shunt would cause the regulator to start time-outs for each phase. . . . Before I make the code change, need to ask:  would this be OK?

More things a 3.3v Arduino will not do..

Been working on revising the firmware to accommodate the new RN-41 Bluetooth module, and have ran across some more differences between the 5v Arduino and the 3.3v one.  As a reminder, I changed the core of the design from a mixed 5v/3.3v to a single 3.3v one - just simplified things.  (the Bluetooth modules need 3.3v).   In doing so I also had to reduce the clock speed from 16Mhz to 8Mhz, as the Atmel CPU just can not fly as fast on less power!  So, here are some for the things I have noticed from this change:

3.3v Arduino vs 5v Arduino:

• Uses different boot-loader, need to select in Arduino programming environment:  Tool/Board -> Arduino Pro (3.3v / 8Mhz) w/ATmega328
• Boot loader is larger!  3.3v leaves 30,720 bytes available to use vs. 32,256 in the standard 5v Arduino
• Struggles with higher serial port rates. I had lots of trouble communicating reliability with the RN41 Bluetooth at 115,200 baud, specifically receiving.  O'Scope showed no problems with the signals, but a Google turned up that even at 5v the Arduino is on the edge for 115,200.  (I have backed off to the nice solid 9600 baud)
• 3.3v / 3.6v Zeners have terrible characteristics.  Under 5v, and Zeners use a different physics to work, with a resulting poor knee.  This continues to cause issues around protection, and I will be looking to likely pull them all out...  (More on this in a later post)  (And ya, this is not really an Arduino issue I know :-)
• Will not support watchdog resets!  Still need to dig into this, and hope I do not need to come up with custom boot-loader..  Right now I have a workaround for forced reset of the controller (ala, after receiving config changes via the Bluetooth), but IF the watchdog triggers  - rather then rebooting, the systems halts and needs a power cycle.  At least it will take down the Field FET drivers, so the battery / alternator is protected!  But I do want to fix this down the road.

Maybe that is it for now.  If I find anything else out, will update this list.

PCB v0.1.1 Errata

I have completed my initial hardware debugging of v0.1.1, as  reminder - key changes were:

• Moved from switching 5V / lin 3.3v regulator to cascaded linear regulators (Zenor pre-regulator, and 3.3 LDO for final stage).
• Update Bluetooth module to FCC certified one.
• Updated FET Driver to allow full support of 48v batteries.  (specifically, equalizing).

In debugging the last version of the hardware, I have found the following errata:

Click image for larger view

 I still have a little more firmware work to clean up, specifically I need to make changes in the Bluetooth code around reassigning the connection name/password, and I also need to look into this whole 3.3v issue with Arduino not supporting the watchdog.

Will be thinking on the next steps, if to render and post a revised PCB set now or hold off until some field testing can be completed...  Any thoughts?

Oh Bother . . . Arduino does not support watchdog in 3.3v boot loader.

I have been using the Arduino programming environment for this project to take advantage of its rather simple and integrated approach.  It also does make code a bit simpler to follow, for example:
 
    pinMode(FIELD_PWM_PORT, OUTPUT);

does tend to read better then:
  
     DDRA = 0b11111111;

However it also comes with downsides.  Such as slightly larger code (example, the DDRA code above sets 8 ports at a time), and other side effects.  One of which I came across today...

Seems the default Arduino boot loader does not always support watchdog timers in the 3.3v version.  (See here for some insight:  http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1123964 )

Bother.

This impacts the current code in two ways:

1. Reliability with availability of Watchdog
2. Us of watchdog function to force a reset of the code (ala, during a recoverable fault)

I will need to research a bit more how to get the watch dog functioning.  Clearly I can modify the boot loader, and that in the end might be what needs to be done.  But bother - kind of gets away from the 'simple integrated programming environment'

Revised Charge Pump

Almost all boot-strap FET drivers rely on a less then 100% duty cycle in order to drive the charge-pump; actually have found only ONE  exception - the LT1910f.  A great part, worked clean and well - but would not support voltages sufficient to deploy in a 48v environment (Specifically to support Equalize mode on a High Drive configured alternator).   So I looked at ways to add an external charge pump to more traditional FET drivers by using an unused pin from the Amtel  CPU as the PWM driver and a voltage doubler.  My original idea was this:

Soft Switching R9/21 was not sufficient for IRS2127 leakage

Kind of a modified voltage doubler, it utilized the soft switches of R9 and R21 to handle the 'boost'.  I had hoped that the modest current demands of driving FETs would allow this simple approach to work.  But it did not, the internal Vb impedance of the IRS2127 was such that too much of the charge was bled off, rendering the soft-switching idea unworkable...

So, I modified it replacing the soft resister switches with a hard FET.  I found an interesting approach of configuring a FET to self-switch, eliminating the need for an inverted PWM driver with all its associated issues of race conditions.  (reference: "A Self-Boost Charge Pump Topology for a Gate Drive High-Side Power Supply" by Park and Jahns.  IEEE March 2005).  Building upon this idea I now have:

Revised hard switching Charge Pump

In operation, when Q5 is enabled C12 will charge to around 11v via D9, R19, and D11.  When Q5 turns off, R9 then starts to bleed some of that 11v back to the net named 'Floor'.  This starts Q6 to turn on as we now have the 11v in C12 applied across Q6's Gate-Source (with D11 now blocking the bead-back)..  As Q6 turns on, it pulls the Floor up to the level of the main FETs Source (Vs on U3), pushing C12 up with it via R19.  Resulting in the 'Pump' net to ultimately be sitting 11v above the floor - transferring this charge pump voltage into C11 via D8.  R19 is in place to limit peak surge current, protecting both the FETs and the Diodes.

There is a bit of inefficiency in this design (ala R19), but as the frequency is very low (455hz) we really do not need to worry about things like switch loss, etc too much.  I have mocked up this modified charge pump and it works great.  Spice modeling shows this will also more then handle 2mA of current demands, more then sufficient for any leakage in U3. 

One side effect of this was needed to create a 12v voltage source.  I did this by raising the intermediary voltage in the power supply from 8V to 12v (simply changing the per-regulator Zener).  A down side of this is the 3.3v regulator now needs to do more work and is starting to get a bit on the edge for heat dissipation.  So one will need to add either a small separate heat sink to it, or drill and mount it to the main heat sink.


Has been fun to come up with this, but will tell you:  Sure wish the LT1910f would had about 10v more headroom in it. . . .