Release of Source Code v0.1.6

Version 0.1.6 of the source code has been posted under the resource tab above.  There are several small changes - mostly refinements with the TACH mode of operation as well as integration with an external BMS typically used in LiFeP04 batteries.  The accompanying documentation has also been updated to reflect these changes, again under the resource tab above and now release 0.1.3

Here is a summary of the changes:

• Corrected fatal coding error in withdrawn release v0.1.5 - manage_alt();  (Uninitialized variable: enteredMills)
• Corrected ASCII error in CPE; string, not reporting float_to_float values correctly.
• Improved feature_in() handling to retain last know state while checking for debouncing.
• Much improved Tach mode code
• Setting tach PWM via $CST: command will become effective immediately, even during engine warm-up hold off period.
• Tach mode will hold min PWM during transition into Float, allowing tach to continue to run when initially entering float mode.
• Reduced MAX_TACH_PWM from 100 to 75, to better protect battery from too high a PWM floor.
• Added new Amp-Ah based exit criteria for Float and Post-float
• Added Alternator state: FORCED_FLOAT mode - enabled by feature-in port with CPE#8 for use with external BMS system
• AST; modes mode numbers updated to include new alternator mode FORCED_FLOAT
• Changed SST; status to include version number as opposed to compile date/time.
• Increased NTC usable temperature range, now reporting -54f to 300f
• Shortened engine warm-up hold off period from 60 seconds to 30 seconds
• Dash lamp now illuminated during engine warm-up hold off period, to emulate typical 'lamp test' behavior during startup

Many of these refinements came about through the hard work of Antti-Pekka Virjonen who has deployed the Smart Alternator Regulator with a nice new LiFeYPO4 battery in conjunction with a BMS.  I really appreciate the feedback from others, and the help of Antti-Pekka in helping me.  We not only made several improvements to the tach mode of operation, but also refined the function of the feature-in port when used in conjunction with an external BMS.

And I am glad to report the PID tuning worked spot-on with his system!  No changes needed at all!  I can see where perhaps adding in a little 'I' might tighten regulation up some, but as is the system held target  voltage with 25mV of the goal during trial runs.

Please make sure to download both the new documentation as well as the source and note the few changes in status strings (SST and AST).

Thank you again A-P, and happy sailing this summer!

Still here - how is YOUR summer?

Just a quick note, no have not gone back to the future :-)    But have been kind of distracted with maintenance needed on our boat after it sat unattended for a full year.

Even with that, have been working with someone who is just about to deploy a nice LiFeP04 system - very high tech.  And with that we are refining some of the approaches used to integrate the regulator and other devices, specifically the BMS.

I do have a new revision of source in the works, but am holding off releasing it until we get some hours on the LiFeP04 system.   If anyone is interested in joining the conversation, or is having issues of their own with the current source out there - drop me a line.

-al-

Release of Source Code v0.1.5

 << NOTE:  THIS RELEASE HAS BEEN WITHDRAWN;  USE v0.1.6 >>

Today I posted source version 0.1.5 for the Arduino Alternator Regulator.  See the file under the Source resource tab at the top.  There are really two major changes with this source:

1) It targets Arduino IDE 1.6.0 - now the 'official' released IDE from Arduino.cc
2) It has refined PID tuning based on users feedback as well as testing on Viking Star.


See the prior post for some more details about the new Arduino IDE, along with needed support files to enable the 3.3v bootloader.   I also needed to make some small syntax changes in the source to reflect subtle changes to the Arduino IDE around PROGMEM.  Going forward future released will be tested with the mainstream 1.6.0 and after release of the Arduino IDE code.

PID tuning.  The past weeks I have had a chance to try different combinations of PID tuning on Viking Star, mainly using our DC generator (Which shares a common source base in the manage_alt() function).  That, combined with feedback I have received from a few uses (THANK YOU so much!) I have what I believe is 'better but not final' PID values.  They are a bit less twitchy when deployed in a system that has a larger alternator vs. battery size - like many AGM batteries, or perhaps LiFeP04 systems.  I do not believe these are the final values, and in fact I am still only using the P&D values, the new I is disabled.  But I do believe they are better, and am looking forward to gaining feedback on them form others.

The PID tuning is perhaps the greatest challenge facing this project today.  Most all other functions are rather stable.  But as more experience is gained with different combinations of alternators and batteries, I can expect there will be additional insights.  Ideally we can find a common set of PID values what works well in all cases, but in the end it may be that some type of sampling / real-time adjustment will be needed.   But that is down the road even more.

Supporting release 1.6.0 of the Arduino IDE

Arduino has released a major update to their toolset, now version 1.6.0.  It includes better support for the ARM type Arduino CPUs and is now the 'primary' release stream.  Of impact to the Arduino Alternator Regulator is this release also has updated the GCC compiler - resulting in about a 5% reduction in code size!

But they have also changed some of the file structures with regards to enabling custom bootloaders.

If you look under the Arduino Libs resource tab above you will see a new folder to support the Arduino IDE 1.6.0 with a fixed Optiboot to allow the watchdog to function (as opposed to totally wedge the system using the as-included 8Mhz bootloader in the Arduino IDE).  Just follow install the new Arduino IDE release 1.6.0, copy down the files from the resource tab above and follow the instructions in the readme.txt file to allow the newest Arduino development environment to support the improved bootloader for 8Mhz operating of an ATmega328p cpu.

Released v0.1.4 of Source Code

Today I am posting up version 0.1.4 of the Arduino Alternator Regulator source code.  IT corrects several small bugs, and has one major change:  the expansion of the core alternator regulator engine from a PD** one to full  PID** logic.

** PID:  Proportional Integral Derivative  http://en.wikipedia.org/wiki/PID_controller

I had originally only used the rather uncommon PD parameters in the DG Generator regulator as it was suggested by someone with a strong experience, it was simpler to implement (there are some odd issues around the I factor), and it produced good results. However, as the Arduino Alternator Regulator was deployed with different combinations of alternators and batteries, excess cycling started to appear.  At all times the battery was protected from over voltage due to the 'load dump' safety checks, but those same load-dump checks also tended to exasperate the cycle.

I have expanded the controller engine in V0.1.4 of the source code to implement all three parameters (PID) for voltage, amperage, and wattage regulation.  Which brings up a whole new class of work:  Tuning...

Tuning the PID engine is going to take some time, and I hope input from others.   It may be that a common set of tuning parameters cannot be found to cover all variations of alternators / batteries - and some reduced set be selected based on DIP switching settings.  OR it may be that some type of run-time self adjustment factor is needed.  This is all TBD.  For now, the v0.1.4 release has the original tuning values in it, and I have entered a 0 for the 'I' factors - disabling that component in the default.  In this way, this release will function as prior releases have.  If there is anyone out there with insight into PID engines, perhaps they can share?

There are several other small changes / corrections as well.  Including:

• Improved summing logic in manage_alt().  Prior summing logic for the different regulator factors (volts, amps, watts, etc..) would allow too large of an increase in the PWM when one of the factors only wanted a small change.  Example, if Volts decided a +1 was needed, the rest of the regulated values would often push that up to a +2.  New code makes sure the smallest change is brought forward.
• Sudo-dynamic rate-of-PWM-chage-cap.  There is a hard cap of +2 PWM changes at any given 100mS sampling period (slowing during the ramp up period).  The new summing logic above effectively reduced that max ROC value as one of the regulated values gets close to its target.  With this, in future releases I may be able to increase somewhat the max ROC value from +2 to say +4 or +5 - but want to make that change in combinations with any PID tuning results.
• int2frac() at would cause 13,998v to be presented as 13.00 as opposed to 13.99 or 14.00v  Corrected (now will just show 13.99v - no rounding factor)
• DBG; string has been adjusted  - see source code for what it now shows in detail.
• #TESTING mode 'battery' model enhanced - to allow more realistic simulation modes.  See  read_INA226() function.
• Added fixed correction offset for hardware design issue with Amp shunt level shifter - which caused a display of 14-17A when the shunt was not connected.

This last issue is a rather tricky one - there is a hardware design fault around the Amp Shunt level shifter U6 / R22 / R24 that can caused a current to be falsely reported when it is not present.  The problem is reusing the 3.3v rail as a reference point to center + and - current sampling around.  U6 and U2 do a great job of removing common-mode noise, but the problem is R22 / R24 present a differential divider - and hence the common noise is reduced on the Vin+ pin of U2, but not the Vin- pin.  This noise gets interpreted as current.

The source of the noise is the LDO 3.3v regulator U1 as it manages voltage around 3.3v - and reports back from folks using the Arduino Alternator Regulator match my measurements and seem consistent.  And as there are already several examples of this regulator out there, implementing a hardware fix might be problematic.   As such, v0.1.4 of the source code has a correcting factor of 522 added to the raw Amp Shunt reading to adjust for this asymmetrical division of common mode noise via R22 / R24.  See 'VERY BAD!'  read_INA226()

Finally.  I was able to at last install this source code into a live alternator aboard Viking Star - so it has had at least one test run!   Over the coming weeks I will be doing more and more test runs, likely refining the software and making changes to the tuning engine.

And a last note:  The code is growing.  With the above additions I ended up being over-sized in TESTING + DEBUG mode.  So, I disabled ASCII INPUTS via a check in loop() while in TESTING mode.  I may try to look for code reduction opportunities in the future, but for now take note of this change.  As the tuning firms up some, if it turns out the new 'I' factor is not needed - will pull it from the code to recover some of that code space.

Refreshed Optiboot bootloader

I have been having a few reliability issues with the optiboot source code included in the Arduino IDE - which I used to compile a special bootloader for the regulator project:
(http://arduinoalternatorregulator.blogspot.com/2014/06/burning-arduino-33v-8mhz-atmega328p.html)

So today I refreshed the complied bootloader using the latest source code from optiboot source repository: https://code.google.com/p/optiboot/

The resulting .HEX file is found under the Ardino Libs tab above, look for the 'SmartRegBoot' subdirectory - and follow the instructions in the blog link at the beginning of this post.

This refreshed optiboot still is configured for 8Mhz, 57600, and no-LED flashing.  With my limited trials, I have found it to be a bit more stable...

Feedback leads to updates!

The past few weeks I have been in back-n-forth conversations with two people who have recently built up an Arduino Alternator Regulator, and are testing it out.   One person is based in NZ and is using it with his DC Generator, while the other is based in Finland and is currently playing with it on the bench (in a lab with TONS of cool equipment) - looking to install it later this winter into his sail boat.

I am excited about this for three reasons:

1. They are excited about the regulator!
2. They are testing things out, and providing feedback (See more below)
3. They have vastly different systems then I have on Viking Star.

Starting with point #3:  Viking Star has an old-school FLA (Flooded Lead-Acid) battery bank, and a big one at that.  Over 1,400lbs worth.   It is made up of 6x 85-29 industrial cells, be thinking forlklift battery, and can provide over 1,800Ah of storage capacity.  Attached alternators are a 270A in the mains, and a 185A (limited by the controller) in our DC generator.

A really large battery, and good sized alternators = a max Alt/Bat ratio of:  270/1800 = 0.15x

Now in NZ, the setup is the opposite.  He has a good sized AGM setup of 240Ah with a 160A alternator, or a Alt/bat ratio of 160/240 = 0.7x   More then 4 times the ratio of what we have on Viking Star.

In Findland has a 70A alternator and is looking to deploy a 200Ah LiFeP04 bank.  Right now he is doing lots of bench-testing and simulation in  a lab with oh so many nice toys and equipment.

There may be others workogn away, but these two have been in communication and providing feedback, which leads back to point #2:   A few bugs, and optomizaitons have been IDed.  I will be working to update the source code, and perhaps getting some folks to give it a 'trial run' before releasing th enext version.   So far, here is what will be looked at / changed:

• Fix ASCII reporting error when voltages are 13.95-13.99 it reports out as 13.0 instead of 14.0
• Add in dynamic field PWM change cap.  Currently the fasted the PWM can increase is 2x each 100mS, which is good when getting close to the wire.  But systems are able to withstand a bit more aggressive ramping when far away from the goals, so will add code to cap dynamically from say 10x down to 1x change up every 100mS (as always, battery protection is 1st priority and there is no cap in reduction of PWM drive values)
• A bit of fine tuning around load-dump traps when changing from Absorption to Float, let the system drive down a bit as opposed to triggering the load-dump traps and pulling field drive back to 0.
• Refignment of the adaptive time-based absorption to float transition.  This capability is in there to protect the batteries in the case one leaves the docks wiht a fully charged battery, and the Amp shunt is not installed or fails.  It will measure the amount of time the battery spent in Bulk, and use a multiplier of that to cap the time allowed in Absorption.  To prevent boiling of the battery.   But, if the Amp shunt is working - it is much better to follow that, and let the battery tell us what it needs.  So, will be adding a bypass to Adaptive time-based trap when the Amp shunt is functional.
• Adjust PID engine.  The large alternator vs battery ratio showed some weaknesses in the current PID engine used to regulator voltage.  With adjustments we are able to make it work much more stabilily, but I am thinking I need to implement a full PID as opposed to a PD engine.  This will take some time, but having real-life examples to trial on is gold!

Overall I am humbled by the folks who are seeing value in this project, more each day it seems.  And I am so grateful for those who take the time to help refine it.  Somewhat to that end I have started a Google Group for the Arduino Alternator Regulator called: Smart-Alt.  ( https://groups.google.com/forum/#!forum/smart-alt ).  This group will cover the current stand-alone regulator here, as well as the future CAN enabled alternator regulator as that system of projects are developed.

PCB Design v0.1.4 posted

Tonight I posted to the links above v0.1.4 of the design.  This corrects most errata in v0.1.3 and would be a good choice for anyone wanting to FAB blank PCBs and make up a stand along regulator.

And along that line, I have a couple of people interested in blank PCBs - but I have ran out...   So, am thinking of doing a run of blank boards, they would be available some time in January.  If anyone is interested, please drop me a line so I can get an idea of how many to have made.

Released v0.1.3 of Source Code

This morning I posted v0.1.3 of the Source Code for use with the Smart Alternator Regulator.  I also updated the documentation to match.  Refer to the Source Code tab and Documentation tab above.

There are a few key additions to this source code, and I would encourage all to install this update.  Changes include:

1. Corrected bug that caused early termination of Acceptance in some configuration states.
2. Scrubbed the CPE tables to assure default values reflected the 'normalized' 12v/500Ah battery.
3. Greatly revised the LiFePO4 CPE entry.
4. Added feature-in option to 'force to float' in combination with LiFePO4 CPE.
5. Added CPE options to exit Float and/or post-float mode based on accommodated AHs.
6. Changed both Voltage Multipliers and Battery Amp Size multipliers to allow Floating Point numbers.
7. Added ASCII command to compensate for reversed connections to the Amp Shunt.

LiFePO4 oriented changes:  Two of the items (#3, #4) are directly a result of talking more with folks about how to address the needs of LiFePO4 batteries.  Item #5 also can help.   In short, I have backed off the default CPE for LiFePO4 batteries to very conservative termination numbers.  Now Bulk to Float will occur at 14.0v, with transition into Float occurring at the 10% of battery acceptance capacity rate, or a max of 1 hour.  All told, this should get LiFePO4 batteries into the 95% or so SOC, and also be well under the trip points of most BMS systems.  If you want to drive your battery harder, modify the CPE using the ASCII commands - after all, the Smart Alternator Regulator is very flexible!

There is also a new capability to force the regulator into float by activating the Feature-in port.  It is intended that this can be used to provide a loose coupling with an external BMS system, depending on how you set things up.   #4 above is only enabled with CPE #8, the one associated with LiFePO4.   Over time I am not sure if this will prove useful, and feedback would be appreciated.

#5 is a major addition and change that is enabled by the current measurement capability of the Smart Alternator Regulator.  Float mode is traditionally intended to 'keep' the battery in a stable state, and often based on measured voltages.  But in fact, what one is really trying to do is keep the energy in the battery while being able to support house loads via the alternator.  Monitoring Voltages can give an indication of this, but monitoring energy withdrawn is a better indication.  A new exit criteria based on Amp Hours withdrawn after entering Float has been added to Float and Post-Float modes.  These can be modified via ASCII commands adjusting the CPE's

#6 also addresses greater flexibility.  Rather then fixing the volt and amp multiplier adjustment factors used to scale the CPEs for batteries other then the normalized 12v/500Ah battery, floating point number can now be used.  If you have a 32v/400Ah battery, then use 2.67 and 0.8 respectively to fine tune things.

And #7 is a 'Oh Man' thing.  If you get the wires to the Amp Shunt backwards, rather then having to rewire things - just 'flip the switch'!


A side note:   Because of all the changes, specifically in the CPE, if you already have configurations saved in the Flash of the CPU, those will be reset and you will have to reconfigure your regulator via the ASCII commands again.  Perhaps down the road an external app hosted on a PC or such can help automate these types of transitions, but there jsut is not sufficient horse power in the little ATmega328 uC to do such things. . . .


CAUTION:  As with prior releases, I have ONLY been able to bench-test this release.  I hope to get back to the boat this Winter and will be able to do some live testing.  But until then, be very cautious things  - and do give me feedback on how things work!

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.