A final approach (?) for charging LiFePO4 batteries?

As a follow up to this posting: http://arduinoalternatorregulator.blogspot.com/2014/07/a-closer-look-at-lifepo4-battery-needs.html

  I have continued to review available materials and learning around LiFePO4 batteries, with the goal of adjusting the 'default' CPE in the Arduino Alternator Regulator - hopefully settling on a usable built in default (remember, one can ALWAYS change the CPEs either via ASCII commands, or by updating the source code).  I have spent a bit of time on this to get it right, as I intend to extend the CPE concept back into other projects - specifically the DC generator and new BMS device.  OK, some 'revaluations' and insights :-)

• LeFePO4 batteries do NOT like to be over-charged, nor undercharged.
• They exhibit a largely (though not truly) flat SOC/volts curve with noticeable changes when approaching empty and full
• They seem to be unaffected by battery temperature (in terms of adjusting target voltages), but do have rather restrictive charge cut-off lower voltage.
• Much is still being learned, but there is a body of thought out there that things running them between 20-80% SOC might give longest life.  This is largely unproven as the battery technology is still new.
• Almost all LiFePO4 work has been done in the EV (Electric Vehicle) market-segment.

What does all this mean?  Well, in my mind - there is still a lot to learn about how best to integrate this new battery technology.  And though we can look to the EV market space for some insight, there are some dramatic differentiates between battery banks deployed in an EV and those for house use.  Perhaps the biggest difference is House banks follow a dramatically different change / discharge cycle.  EV's tends to be isolated charge, followed by isolated heavy discharge (with perhaps regent included) while house usage tends to be charge, moderate to light discharge cycles, and they may occur concurrently.

A case in point:  what to do about 'Float'?   Consider this usage scenario:

• Depart dock with fully charged battery for weekend at anchor.
• Decide to do laundry underway, powered via your large inverter.
• What State of Charge do you want your House Bank to be when you arrive at the Anchorage? 
• Fully Charged?
• About 50% depleted?

The EV guys will never see this, as they have no way to recharge while underway (Not too much hobby serial hybrid is out there) - but there is a camp that says one should not 'float' a LiFePO4 battery.  Charge it and turn off the charger.  Adopting this approach will result in you arriving for your weekend with low batteries, but then there is oh so little out there about how LiFePO4 batteries will respond with a nominal voltage being applied to them...

Just a few areas still in the learning curve!

==============================================================

REVISED DEFAULT LiFePO4 Charge Profile Entry

With all this, and more thinking, I have revised the default LiFePO4 CPE - the new one will be included in the next source code release.  There are a couple of guiding principals I have kept in mind when setting the new default:

• At all times we want to protect the battery - if there is a question about getting to close to the edge, back off.  (You can always adjust things to get closer if you want)
• This is a House Battery, not an EV deployment.  Need to keep in mind many use cases and scenarios that can and do differ from simple charge / discharge usage patterns.  

With that, here is the new default CPE #8 for LiFePO4 batteries.  Remember, these are for a 'normalized' 12v / 500Ah battery.

• Bulk / Acceptance Vmax: 14.0v                   
• Acceptance Termination:  14.0v & Amps < 50a   (C/10,  Stops at about 90% SOC))
• Float:  Max VBat:  13.36v
• Float:  Max Amps:      0A         (This is new, see below)
• Resume Charge at:  13.3v         (Resume when battery reaches SOC 10% based on Vbat  or .... )
• Resume Charge at:  -50Ah        (Resume when 10% of battery capacity has been removed)

Charging will stop at a very conservative 14.0v.   Not only is this withing the range that may give good battery life, it is well below most HVC limits for BMS systems, reducing the risk of a battery disconnect happening in a non-integrated system.   How to handle the hold, or 'float' state is a bit different.  Two new capabilites have been added:

1. The ability to regulate Amps into the battery during Float.
2. An exit float  criteria based on Ahs that have been removed from the battery.

First, to allow house loads to be carries by the Alternator we can not shut it down when the battery is fully charged.  However, there is little know about doing slow trickle charges into a LiFePO4 battery during traditional voltage based 'floats', so a new capability has been enabled: managing the number of Amps placed into the battery during Float.  By setting this parameter = 0 for LiFePO4 batters we assure that no additional energy is pushed into a 'fully charged' battery, but at the same time allow the alternator to carry house loads.  The Float Voltage of 13.36 is actually a backup, and it may need to be adjusted if in your installation it is to restrictive and you see current flowing out of your battery.

Another new capability that has been enabled is a mini SOC meter:  Once we decide the battery is fully charged, the regulator will monitor any amperage draw from the battery - counting the total number of Ahs.  (say in the case of where the alternator is not able to fully support a heavy house load).  This is then used to trigger the regulator to restart a new recharge cycle.  Again a voltage threshold (13.3v) is retained as a backup.


As experience is gained with the deployment of LiFePO4 battery systems in a house load situation, I am sure the above will get changed and refined.  Until then it is a good starting point to consider the needs of a House battery vs. an electric car one.

I need to complete bench testing of the revisions, and then will post a new release of the source.

Capturing log data for assessment

The Arduino Alternator Regulator will output a stream of ASCII data via the service port providing details on its current operation.  I have used these dumps to help improve the PID engine tuning as well as resolve issues.  In this Blog post I want to describe one way to capture log data into a .txt file, and perhaps ask that folks send in a few of these so I can improve the base code.

To capture the ASCII stream, you will need to do the following:

1. Attach a USB <--> TTL adapter to the Service Port
2. Open up the Arduino IDE
3. Select the serial port used by the USB <--. TTL adapter in Step #1 via Tools/Serial Port
4. Make sure the correct Board type is selected via Tools/Board (Smart Regulator.. for the 3.3v regulator)
5. Open the Controller 'sketch' (source code).
6. Un-comment the line #define DEBUG  (remove the two // at the start of the line)
• This will cause an extra set of debug information to be sent to the serial port.
7. Consider changing   "#define   SDM_SENSITIVITY    10"  in the source code from 10 to a smaller number, especially if looking at load-dumps, or some odd issue.  This #define controls how may times through manage_alt() before a debug string is sent out.  Setting it to 1 gives the most data, and the largest files.. 
• 10 was chosen to allow operation via the Bluetooth at 9600 baud.
• If you reduce this number to say 1 (which is needed many times when debugging), you should turn off the Bluetooth module, and then change '#define  SYSTEM_BAUD'    from 9600 to      115200 and run the serial terminal at that speed.
8. Upload the new sketch.

Example debug output.

You now have an option.  You can remain in the Arduino IDE and open the Terminal window to see the ASCII data - I find unclicking 'auto scroll' helps make things run a bit smoother.  Then after some amount of data is there, so a copy-n-paste into a standard text editor (ala, notepad), finally saving the file in .TXT form.

Oh you can use a 3rd party terminal program.  Myself, I like to use PuTTY as it is simple,  reliable, fast, and you can enable it to automatically capture the .txt file.  To use PuTTY take note which serial port is being used by the Arduino IDE to communicate with your controller (Step #3).  Then download PuTTY using the following link:   http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Once installed, open PuTTY and make the following changes:

• On the opening screen (Session screen), enter the Serial port and Speed from step #3 above.  Click the 'Serial' button.
• On the Session/Logging screen, click the 'Printable output' button and enter a log filename.  Each time you run PuTTY data will be captured into this log file.
• On the Window screen, change the columns to something large, like 400.
• Not really needed, the log file will be OK w/o this change. 
• Just makes the visible screen look a little nicer.
• Then go back to the Sessions screen and click the 'default setting' profile and press the Save button.

Now each time you start PuTTY it will open to the correct port, and automatically start saving a data log.  Press the 'Open' button on the bottom to connect to the controller and start a data capture session.  When finished, just close the window and the log file will be saved.  Rename this to something meaningful, and perhaps edit using notepad to add in some details about the captured run, ala alternator / engine / battery size.  Any unusual event - like a washer/dryer running during Float mode, other charging sources.  Anything you think might be relevant.

If you would then Email it to me, I can use it to help look for ways to improve the code.

You can search for 'DBG:' in the source code to get an idea what data is being sent out.  And if you do have any issues with the regulator, make sure to set the sensitivity to 1 and capture all the data.  Note that the 1st number sent out is a time mark, so in the preamble it would be good to comment on what you see going wrong, and referencing to the approx timestamp if you can.

And when finished you can reload the firmware with the #define DEBUG commented out - disabling the ASCII strings.  Make sure to restore '#define  SYSTEM_BAUD' if you changed it.

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:

http://arduinoalternatorregulator.blogspot.com/2014/09/a-final-approach-for-charging-lifepo4.html

===============================================


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.

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 2^nd 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  2^nd 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 2^nd battery used  perhaps to power a bow-thruster, or even a starter where there is no 2^nd 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 2^nd battery.

Charging 2nd battery combiner profile

Here the 2^nd battery parallels the charge profile of the main battery, and because we are not actively managing the 2^nd battery we cut off the Acceptance phase after a relatively short time ( Points ‘C’ to ‘Y’ above) to reduce the risk of overcharging  the 2^nd 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 2^nd 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.

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 Mouser.com, 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:
www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf

  

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:  http://mightyohm.com/blog/products/hv-rescue-shield-2-x/


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).

Burning Arduino 3.3v 8Mhz ATmega328p optiboot bootloader..

Wow, what a title... 

But it reflects what I have been doing the past several of days.  Flashing in an opti-boot bootloader that will work at 3.3v and 8Mhz.  As pointed out here:
http://arduinoalternatorregulator.blogspot.com/2014/03/oh-bother-arduino-does-not-support.html 

Arduino's normal Bootloader had a bug in it that prevents the watch dog from working.  Most people will not see this as Arduino Uno's are now loaded with the improved optiBoot, which corrected this bug.  However, in selecting the 'defaut' 3.3v / 8Mhz 328p board type, one gets the old bootloader - faults and all.

So I worked to locate the OptiBoot loaders and more specifically a binary for an 8Mhz 3.3v 328p deployment.  Found it at the optiboot source repository, but it too had an issue - it is configured to load sketches at 115200Baud.  This is a bit too fast for the 3.3v deployment of the ATmega328.  In addition, all of these were compiled to flash the LED 3 times upon bootup - OK for an UNO which has an LED on port 13, but bad for the regulator which hard wires that to DIP-7...

So, I set out to make my own!

Though all that is needed (source, tools, etc) are included in the Arduino IDE distrubution, here has been several updates and improvements to the code vs. the one included with Arduino.  So I decided to download the latest version of optiboot from google code: https://code.google.com/p/optiboot/

To use the new bootloader, look under the Arduino Libs Used tab above for a sub folder called 'SmartRegBoot'.  Copy this entire folder to your local Arduino working directory in the hardware sub directory.  (C:\Users\Win7\Documents\Arduino\hardware on my machine)   After  restarting the Arduino IDE a new board will appear called "Smart Regulator (fixed Optiboot - 3.3V, 8 MHz) w/ ATmega328p".   Select this one if you ever need to flash in the bootloader; you will also need to select it when compiling a revised sketch to download to the regulator.


============================================================

Now it is Burn-Baby Burn!


Once all the above is done, it is a simple matter of flashing in the bootloader!  For this I used a USBasp tool purchased off of Ebay.  It has the advantage over using the Arduino in that it can be jumped to run at 3.3v, which is needed for the regulator.  Move the jumper to 3.3v; also jumper JP3 to enable a slower transfer mode, this seemed to help with the 3.3v burning.  Then hook it up and Flash away!

Burning the Bootloader, but wait!  This might not work!

Oh wait, this will not work.  Or perhaps I should say it will not always work.  Of the 9 boards I burned, 4 of them ended up 'bricked'.  This is a situation where the ATmega CPU has sets its internal 'fuses' to a state that will not allow the ICSP port to work, and hence we can now longer communicate / flash a bootloader. . . .

The MOST common error it seems it to select no crystal, instead expecting a nice solid clock signal coming in.  LOTS of talk in the net how to use a temporary external clock to overcome this.  In my case one of the 4 bricked CPUs was solved this way, but the other three were 'done up good'.  Not only was the crystal disabled, but external reset as well . . .  and reset is a critical signal for the ICSP to work.

How did this happen?  My take is power:  The small USBasp has a 3.3v converter that likely works fine for just a CPU, but the Arduino Alternator Regulator has other components on it that use more power.  When I attempted to burn the boot-loader (which as its 1st step configures the 'fuses'), the low voltage caused the whole writing to go very very wrong, leaving the CPU in an unusable state.  How to prevent this?  Add more power!  For reliable burning I simply connected up the Service port in addition to the ICSP; with the combination of  two small voltage sources all worked out well.  Of course, one could also connect 12v or above to the Enable port and let the on board 3.3v regulator power things, THAT would have made sure we had tons of power..

Need MORE POWER!   This reliably burned the 3.3v bootloader...

Now one might be thinking:  Yada, yada, yada.  Ok, got a nice 3.3v / 8Mhz Optiboot, get the Need-Power thing.  Glad you recover one board.  But what about the other three that were really bricked?  Well, for that we need even more power, or more correctly, a bigger hammer!   See the next post.




One other note:  the USBasp I purchased from Ebay needed its firmware updated.  Here is the tutorial I followed to do this: http://www.rogerclark.net/updating-firmware-on-usbasp-bought-from-ebay/

The Boards are here, the Boards are here!

After Oh So Many back-n-forths with China concerning to soldering quality and workmanship issues around the hand-soldered through hole components, a well taped DHL box arrived at our doorstep this afternoon!

I have not looked closely yet at the individual PCBs, but will start doing so this afternoon.  Then will bring one unit up, flashing its boot-loader and firmware.  Finally will need to solder on the Bluetooth module and can send them out to those who are participating in the Group Buy.

You might notice there is also a kind of blank PCB.  I had 10x extra units built up with just the small SMT parts on them.  Down the road if anyone wants one of these, they can get a head start and just worry about the through-hold parts (well, plus the RN-41 module of they want it..)

Posted v0.1.1 or source and v0.1.1 of Regualtor Guide

Today I have finished the bench testing and final changes I wanted to do in the source.  Follow the Link to Files tabs above for the latest copy of the firmware source.  Major changes in this include:

• Review and scrubbing of all ASCII commands, trying to have an eye towards an external 'smart' application to make it simple to configure this regulator.
• Improved Tach Mode support.
• Added new Battery protection capability 'Adaptive Accept'. 
• Added new Alternator protection capability for Stalled detection.

Tech Mode is when you have an alternator sourced tech in use (use to be common on diesel engines).  These Tachs rely on stator pulses to signal RPMs.  Well, if the battery is fully charged we turn off the alternator field, and hence stator pulses can drop to 0 as well...  So, when Tach mode is selected (via the DIP switches) a small amount of Field drive is kept - even when the battery is full.  Hopefully this will be below the threshold needed to actually start charging the battery, but above the level needed to be seen by your tachometer.  Worst case, there IS a risk of overcharging the battery..  An improvement in the source is I now look to see if the CPU is seeing Stator pulses, and use that to 'decide' at what level of PWM we need to use for a floor.  (Alternatively, you can fix the value via the $SCT: command).

The new feature Adaptive Accept will cap the amount of time we stay in Acceptance phase to 5 times the amount of time we were in Bulk.  An example of where this comes in handy: if you  start the engine with a fully charged battery  the voltage will quickly raise to the Bulk limit.  If enabled, the Adaptive Accept will then quickly transition from Accept phase into Float. (as opposed to just sitting there, boiling out your battery).    Adaptive Accept is enabled in one of two ways:

1. User has configured it by setting the Exit Accept Amps = -1
2. We have never been able to measure Amps..

 The 5x factor is defined in the source code via   #define ADPT_ACPT_TIME_FACTOR.  There is no way to disable the protection trigger #2 above, outside of modifying the source code.  The ability to measure Amps is a prime function of this project, and if we loose that ability it should be corrected.  At the same time, it is good to take steps to protect the battery in case of a failure.

Also added is a feature which will monitor the RPMs of the engine.  If we notice the RPMs stop, then we will assume the engine has stalled.  In this case we will limit the drive of the field to 50% of its max capability.  As RPMs increase, the field drive cap is raised.  See $SCO: command, the PFB - Pull Back Factor value for more details.

Both of these capabilities depend on the regulator being correctly installed, with all its sensors attached.  It is this rich ability to monitor and measure things which gives is the ability to better manage the system for more efficiency and better protection of both the battery and the alternator.


Also posted is a .PDF file with the latest documentation of how to install, configure, and operate the Arduino Alternator Regulator.  Most all the answers can be found here, and if not, look into the source code...  Look under the Reference tab above for this .pdf file.