Sunday, July 27, 2014

Thinking about Float - A new approch??

The purpose of Float mode is really two:
  1. Provide makeup energy to compensate the battery for any self discharge
  2. Cover house power demands using the Alternator.
In reality, makeup energy is more of a shore-power topic, while an underway Alternator Regulator would do just fine focusing only on covering house loads.  The traditional approach for managing these two goals is to select a voltage just slightly above the At-rest voltage of the battery and holding it here.  Making adjustments for battery temperature along the way.

But it occurred to me this approach really is back in the world of voltage-only centric thinking, and is in fact an indirect way to achieve the real goal.  After all, what we REALLY want to do is provide some energy to the battery for point #1, and make sure current flow out of the battery is as close to 0A as possible for point #2.

Rather then try to develop a precise voltage to hold in achieving these goals, why not just manage to the goals them self??  Perhaps rather then holding a FLA battery at 13.4v, we instead manage to 1% of its Ah capacity (ala, 1A flowing into the battery).  And for batteries where we don't want to give any self discharge makeup energy, we hold battery amps to 0A.

When I return to the boat I may look at these ideas;  to me it makes more sense to manage towards to real goal then try to walk a thin indirect line hoping we got it right type of goal..

A closer look at LiFePO4 battery needs

 There has been some changes, follow this link for the latest:


Someone is building up a regulator (and integrated engine / DC generator controller) for use with LiFePO4 batteries and an associated BMS.  This has given me the change to share Emails with folks knowledgeable about these quickly establishing technologies.  It has also given me an opportunity to think a bit about how to adjust the Arduino Alternator Regulator to better support their needs.  With the next release of source (will be v0.1.3) the following changes / additions will be included:
  • Revised default CPE #8, better optomized for LiFePO4 batteries
  • New CEP entry 'Min Charge Temp', to mirror existing 'Max Charge Temp'
  • New Feature-in mode --> Force to Float.

The CPE has just a few changes, mostly fine tuning voltages.  In support of these changes I have found a few more manufactures datasheets (See Resource link above).  Anyone has additional info / insight please send it on! Charge profiles for LiFePO4 batteries share a lot in common, but there seems to be some slight variances with some manufactures - perhaps to 'gain a leg up', and perhaps also to lessen lifespan.  The values I have placed in the default are a bit on the conservative side in that if there was an opportunity to 'push the battery a little' - I did not take it.   Case in point the target voltages and the 30 minute cap on Acceptance phase.  Some manufactures have a higher target then I am using, to pack more in - and there is some indication that LiFePO4 batteries really like to leave the table a little hungry.  Meaning, charge them to 95% and stopping makes them happiest (unlike Lead-acid cells that really like to get a full 100% charge for longest life).  Here is what I now have for default (remember, this is for a normalized 12v/100A battery, and will be scaled depending on the DIP switches):
  • Volts target:           14.6v  (3.65vpc)
  • Amp Cap:             50% of Ah capacity (50A)
  • Absorption exit:       3% of Ah capacity (  3A)
  • Float Voltage:        13.6v   (3.40vpc)
  • Revert to Ramp:    13.3v   (3.325vpc)
There also a new low cut-off temperature of 0c (32f), and a more restrictive high limit of  45c (113f).  Some batteries indicate they can be charged at outside these ranges; you will have to set that using the ASCII commands and/or recompile the firmware.

As this is a change in the CPE structures any previously saved ASCII changes in the CPUs flash will be overwritten when you upgrade the firmware..  And the associated ASCII commands have also been changed.

The final addition is a new use for the Feature-in port -> Force to Float.  This will force the regulator to stop charging and go into Float mode (or post-float if you have configured things to bypass float).  It can be used  with an external BMS that has perhaps detected an out of balance / single cell within a battery bank which is full.  It lets the BMS stop the charging to protect that cell and/or the BMS system.

Force-to-float  is only enabled when CPE #8 is selected and is active at all times - including boot-up (e.g., starting the engine when the BMS is indicated 'Do Not Charge' will cause the regulator to immediately go into Float mode.)  As such Feature-in will no longer be able to restore the regulator to default or select Equalize mode.   If you need to do one of those, change the DIP switches to something other then #8 and reset the regulator,  or use the ASCII restore command.

Wednesday, July 16, 2014

Feature-out option: Battery Combiner

It seems a battery combiner are somewhat common when more then one battery is in a boat.  I thought "Hey, why not add some code to let the Arduino Alternator Regulator controlling an external relay and act as a battery combiner".  But I had never really sat down and thought things through - till now.

While reading material found on the web - both from commercial suppliers (aka, people who make combiners), and forums I found a mixed bag.  Talk about sharing current, self adjusting due to internal impedance and its change vs. SOC (State of Charge), Gassing, etc.   The EE in my followed much of the reasoning (where it was provided), but also started to call B.S. on other parts of it.  After all, who knew:
  • ". None of the batteries will ever be 'overcharged' as a result because the charging voltage is controlled."
  • "..the reason for the extra wire length [between a combiner and the batteries] is to act like an electic <sic> spring which allows the [product name] to produce a higher current"
Both of these statements are flat wrong.  Holding a battery at its gassing voltage well pasts the point where its acceptance current indicates a fully charged battery will do nothing but create heat and risk boiling off the battery.  And I for one never know the resistance of a wire could act like an 'electic' <sic> spring!  (But then, 6' of 6g wire does have a little over 2.5uH of inductance - in free air.  And there is always some level of AC superimposed on top of the DC voltage.  So, there is likely some inductive reaction that can be seen.)   

Now combiners are not necessarily bad, but one needs to really think things through before blindly putting one in.  Read the manual, be very careful about max wire size as well as min lengths, and consider combiners which provide a high-voltage cut-off, preventing overcharging (or sorry, preventing excessive heat and boiling of electrolytic from the battery).  Properly installed a combiner can serve a valuable function and not cause damage.

 Here is my take on things to consider with combiners.  First off, I think there are two broad deployments cases.

       Case 1:  Two independent batteries, each with their own charging source.
       Case 2:  Two independent batteries, only one of which has a charging source.

The 1st case is what I have on Viking Star, a starter battery connected to the factory (unmodified) engine alternator, and the house battery with its own large alternator.  Here the starter batter is recharged very quickly after engine starting and it would be nice to shunt some of the unused factory alternators capacity over to the house battery to help during the Bulk phase of its charging.  Case 2 is perhaps an example were a bow-thruster battery has been installed that needs to be recharged, or a small installation where there is only one alternator, connected to the house battery, and we need to use the same alternator to recharge both batteries.  Without risking boiling off the starter/thruster battery.  Here is what I have added to the Arduino Alternator Regulator source to address each of these conditions.

 Case  #1:  Using 2nd battery/alternator to ‘help’ the house battery during Bulk.
In this example there are two fully independent battery and associated charging systems.  And example might be the factory alternator + starter battery, and a house battery with its own alternator using the Arduino Alternator Regulator.  The starter battery will likely be quickly recharged after the engine starts, leaving a significant amount of unused capacity in the starter battery’s alternator. 

Receiving Help combiner profile (default)
The figure above illustrates when we want to combine the two systems (between points ‘X’ and ‘Y’).  Specifically during Bulk we want to:

  • Wait until the house battery reaches 13.2v before enabling the combiner.  If we combined sooner there is a risk of pulling energy from the 2nd battery, as opposed to only asking the 2nd alternator to share its capacity.   13.2v will also reduce the voltage difference between the two batteries thereby minimizing initial surge current. 
  • Break the connection of the two batteries after 14.2v.  With the assumption the 2nd battery has its own charging source that will handle all the recharging needs of that battery, we do not want to ‘override’ those decision.   14.2v was selected under the assumption that many ‘starter’ batteries are connected to a default internally regulator fixed voltage alternator; those are often in the 13.8 to 14.2v range.

Case #2:  Recharging a  2nd battery which has no charging source of its own.
In this example there are still two independent battery, but only one charging source.  A representative example would be a house battery / alternator being controlled by the Arduino Alternator Regulator, and a 2nd battery used  perhaps to power a bow-thruster, or even a starter where there is no 2nd alternator.  Unlike the situation above were we are looking to gain assistance from the other battery/alternator, in this case we are asked to be the charging source for the 2nd battery.

Charging 2nd battery combiner profile
Here the 2nd battery parallels the charge profile of the main battery, and because we are not actively managing the 2nd battery we cut off the Acceptance phase after a relatively short time ( Points ‘C’ to ‘Y’ above) to reduce the risk of overcharging  the 2nd battery, in effect boiling  it off.  

All these parameters are adjustable in the source code, voltages, times, etc.  Select the Feature-out combiner option, add a large capacity relay (being careful not to overload the feature-out current limit of 500mA).  Make sure there is sufficient smaller-gauge wire (ala, 10' of 10g wire) to manage peak currents and you can have a reasonable 'combiner'  But in each case remember:  

Care must be taken in each of these situations to protect the 2nd battery and charging system; remember the Arduino Alternator Regulator will focus on its battery and adjust things to its needs with NO regard to the other batteries needs 

 These capabilities will be in the next posting of the source, v0.1.3 and above.

Thursday, July 10, 2014

A choice: Crystal vs. Ceramic Resonator for the Atmel/Arduino?

I have been reviewing the design of the Arduino Alternator Regulator, looking for ways to make
Which to use?
improvements, as well as moving it towards full SMT components (or at least as many SMT as practical).  One area that I have been poking at is the source for the Atmega328 CPUs clock.  Of course there is the internal 8Mhz RC oscillator, and that might actually work - given there are not really tight timing requirements (outside of the serial port); but for now am still leaning towards an external clock of some sort.  The two primary candidates being: Crystals vs. Ceramic Resonators.

The ATmega will work just fine with either, and both require little external components.  In reading up on them, here is what I have summarized:
  • Crystals are MUCH more accurate, like 100x more so.  (0.0005% vs 0.5%)
  • Resonators are little less costly.  (Often see them used in mass volume applications)
  • Resonators typically have biasing capacitors built in, further reducing costs.
  • Crystals are more fragile, subject to vibration.
  • Resonators are better able to withstand ESD
  • Resonators are often (but not always) physically smaller

Perhaps the largest number of conversation seems to focus around costs.   At least in very high volume deployments.  A ceramic resonator is a little less costly then a crystal and when combined with them often including the bias capacitors in the same package this gives further savings.  Availabity  in smaller packages can give further savings via PCB space.

But resonators are oh so more less accurate then crystals.  And with regards to costs:  looking at, there really is very little cost delta between them and resonators in the small volumes I am playing with.  Pennies.

One thing stood out to me though, and it was kind of buried when searching the web:  Resonators are physically more tough.  In fact, searching for 'crystal automotive' and you will find a few new 'hybrid' devices out there just being brought to market - in an attempt to get the higher accuracy of crystals for more demanding automotive applications.  Currently in cars: resonators are king.

Plus, the Arudino Uno uses a resonator - so I guess it is OK for accuracy. . . .

Bottom line:  I will be revising the design to use a Ceramic Resonator in the next revision.  Both for this as well as for the integrated controller.  And it was the toughness that swayed me.  And fwiw, am also going to use the through-hole 'tear-drop' style (as pictured above).  Reviewing the datasheets for the small SMT resonators reveled they are not sealed, and as such can not be conformal coated...


BTW:  Another question I did some research on was the at times appearance of a 1M resister between XTL1 and XTL2 on the ATmega CPUs.  Most puzzling was I could find no reference to such in the Atmel datasheet, and yet the Arduino UNO has one installed.

Bottom line:  a feedback resister is needed to 'kick-start' things (Negative feedback), and it does not matter if a crystial or resonator is used - one is needed.  However the ATmega CPUs already has one built in.  Adding an extra 1M external does not help anything, and in fact can reduce operating noise margin..

More details in this app note:


Tuesday, July 1, 2014

Breaking out the 5-lb sledge to recover a bricked ATmega CPU

In the prior post I mentioned a more dramatic approach for UN-bricking an ATmega CPU after the fuses get set incorrectly.  Reading the web it seems that often one needs only supply an external clock.  But if things really go south, more can be needed.

There are actually 3 ways to 'program' the ATmega CPU, in order of both simplicity and effort.:
  1. Self Programming of Flash, this is the way the Arduino IDE / Boot-loader loads new sketches into the CPU.
  2. Use SPI communications protocol, the most common way to flash in a boot-loader via the ICSP port.
  3. Use High-Voltage Parallel Programming  (HVPP)
The 1st method is dependent on a working bootloadering already being flashed into the CPU. If there is no bootloader in place, or there is but it is the wrong one, the IDE has no chance to make any updated.

To get a bootloader into the CPU the most common way is by using the SPI protocol, side note:  One can ALSO download sketches this way as well - bypassing the boot-loader if need be.  However, the SPI has a couple of dependency itself: two fuses being set correctly:
  • Enable External reset pin
  • Enable SPI protocol

As you can see both of these ways to program the Atmel ATmega CPU involve some precondition.  But there is one way to make the CPU listen to you no mater what its configuration  is:  High Voltage Parallel Programming.  Perhaps one has noted that Vmax for pins is listed as Vcc+0.6v, with Vcc being max 6v.  But there is one exception:  the reset pin has a Vmax of 13v, and here is why:  Apply greater then 11.5v to reset and the ATmega CPU enters parallel programming mode.  In this mode one can change any or all of the CPU, totaly independent of any fuses or boot-loaders, etc.  it is in effect the 5-lb sledge that says 'Hey, You - Ya, You  - Pay attention to me NOW!'

Here is a great overview of this mode, along with some code and a nice shield to be able to 'rescue' some CPUs that have gone astray:

In the case of the Arduino Alternator Regulator the CPUs were soldered in so I tacked on wires to the bottom of the PCB, removed some of the voltage protection devices (ala, the Reset line clamping diodes, and the 3.3v protection diode as all parallel programming must be done at 5v).  I used an external breadboard to make up two FET switches, one for +12v, and one to switch 5v (as opposed to just using a direct Uno pin).  There are many components on the Regulator board, too many to supply +5v directly from a Uno pin as the HVRescue design does.  So, I used that pin to control an external FET switch.

After all that, here is what you get:

Mass of color-coded wires tacked onto the bottom.  

Hooked up to an existing Uno running the HVRescue code.

Closeup of final protoboard with 2 FET switches (12v and 5v)

Run the HVRescue sketch in my Uno, and quick as a wink I have a CPU that will talk to me again.  Just need a bit of 'persuasion'...

OK so this shows there is a lot that can be done in the Atmel / Arduino community, perhaps one of the reasons for it popularity.  And I was glad to get things back on track w/o having to replace the CPU itself. (Which is another option, at around $2 many folks do that it seems).   My lesson here:  Make sure to cover the power supply (current) needs when flashing in a boot-loader and one will not have any of these issues to begin with (See prior post).