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.

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.

1st photos of assembled PCBs from China

This morning I awoke to a cloudy (I can never think of that word without hearing the NOAA computer voice pronunciation in my head "Claudiieeeee") skies and a few high resolution Emails of a sample PCB set that has been assembled in China!

What excitement, and then what - to be honest - disappointment...  It appears these hand-soldering of small runs in China is kind of a new thing, and this one is off to a very poor start.  Here is a lower resolution copy of one of the photos:

Back in my Seko-Epson days, we would call this NG.  How many examples of problems can you find?

A quick review if it showed to me soo many problems:

• Missing components
• One component installed backwards
• workman ship issue with connectors on right hand side (not assembled together before soldering)
• (The missing Bluetooth was agreed to, there was some issue importing RN41 modules into China..)

Most troubling was to very very poor quality of through hole soldering.  Insufficient quantity, insufficient heat.  Some solder flash and potential shorts.  Total unacceptable.

I am really disappointed at this.  Have asked them to review and rework all PCBs, but this should not have been done in the 1st place.  Will see what they come back with. . . . .

Short run of Arduino Alternator Regulators underway

I received an Email from someone today that made me realize I have not updated the Blog with what is going on right now..  Sorry, guess I have been too busy Email back and forth with a small group of about 10 people, so for anyone else, this is what is cooking:

1. About a month ago I posted onto several Email lists about this regulator, and asked if perhaps there was some interest in getting together a group build.
2. There was.
3. Right now, 20x sets of Rev  0.1.3 PCBs have been fabed and are having the SMT parts mounted.
4. 10x of those PCBs will continue to have all the through-hole parts soldered in.
5. All are being done in China (http://smart-prototyping.com/) so no more hand-soldering for me!

I expect to received the assembled (and partially assembled) boards in a couple of weeks.  At which time I will flash in the firmware, spray them with conformal coating, and send them off to the group of folks.  Along with USB programming adapters, mounting hardware, and a heat-sink.  People will need to drill out the heat-sink, bolt it together, source their own Amp Shunt and Temp probes and do the installs.  But hey, we got a thing going!

And if anyone is interested in one of the partly assembled PCBs, drop me a note.  The bare PCB costs around $9, plus about $7 for the small SMT parts that are getting professionally re-flow soldered on.  Finished cost (after purchasing the remaining parts at say Mouser) will add perhaps another $60 or so, but you will have to hand solder those parts..  Then around another $20 for the heat-sink, screws, USB cable, etc..


OK, there is an update of the one or two readers of this blog :-)

Posted PCB release v0.1.3

This morning I posted up the v0.1.3 release of the Arduino Alternator Regulator files.  Look through the resource tabs above, I posted:

• PDF file of the scheamtics
• .ZIP file with PCB GBR files.
• .xls with BOM
• KiCAD  CAD files for Scheamtic and PCB
• Updated custom  libs, mods, etc files used in support of KiCAD.

This release is what we are going to send off to the fab house to have 10x assembled regulator units completed.  Mostly it was scrubbing and commenting the parts list, but I also:

• Added self resetting fuses to the NTC ports.
• Revised Service Port pinout to match 6-pin USB <--> TTL addapter from EBay. (No more modes needed)

I will be sending this package off later today to the FAB house asking for a firm quote, then on to assemble!

Burning up Alternators at Idle....

One thing that has always bothered me was when the engine idles down to a lower RPM and the Alternator is still trying to pump out a massive amount of power - regulator will end up driving the field to Full Power 100% field current trying to keep up. The question is: Are Alternators able to handle this? In some ways it is kind of like lugging an engine uphill in high gear..

I know this is not an Alternator Rotor
But you get the idea..

This last week I had someone contact me.  They have been poring over both this Arduino regulator project, as well as its companion http://smartdcgenerator.blogspot.com and asked the question: "Am I doing anything to reduce Field current at low RPMs". He went on to share an experience of a boat using large frame Leece Neville 4900 series alternators (the same 35lb units I use for our main engine house alternator) driving massive loads  to power engine room blowers via inverters. After an extended period of time at idle (and likely in a very hot engine room - these were MTUs in a $$$ go-fast craft), there was a failure in the field - total melt down of the Field / rotor..


My initial intention of adding the 'Small Alt' mode selectable via the DIP switch was to protect smaller framed alternators from prolonged periods of high current output. Ala, that 200A Hot-Rodded alternator in a standard small frame.. Small Alternator mode will cap an alternators output to 75% of its capability (configurable of course), at all charge points. But it seems perhaps more might be needed - especially given the real life experience of someone melting down my beloved Leece Neville large frame alternators just idling around...

So, I have added a new feature to further restrict how hard the field is driven when the engine is at idle.  By sensing this RPMs vis the Stator wire, I can tell when we are near idle - or at least near the lowest RPMs that the engine has been operated at..  And when at idle I now cap the field to 50% of its max drive.  This % is increased up to the max allowed (100% or 75% depending on the DIP switch, and if the defaults have been adjusted).  And there is a new parameter in the $SCA: command to configure this capability.

Blue line shows default idle capping curve.
Red and green give an idea of some other configurable options via the $SCA: command..

Of course you can also use the $SCA: command to also disable this feature. Right now I have the '50%' hard codded in the firmware; starting to get a bit too many configurable parameters. If someone has any feeling for the right % value to use at idle, let me know.  If you want to change it in the firmware look at the  "set_VAWL(float passedV)"  helper function in "calculate_ALT_targets()" 


I hope this will help out some installs.  Though we never had any issue pulling max amps (and max field) for several hours  at a time while idleing around during Christmas Ships with our LN 4900 270A alternator, clearly someone has..   Perhaps I can feel even better now - protecting the Alternator just a bit more...

Confirming Power Dissipation

As I go through to finalize the next rev of the PCB I though I would revisit my heat calculations.  There are two (three really) sources of heat in the regulator:

• Darlington pre-voltage regulator (Q1)
• Final Voltage Regulator (U1)
• Field FETs (Q2 / Q4)

I calculated the Power Dissipated in Watts for each of these, and here are the results:

For the power supplies I assumed a current draw of 165mA, this is approximately  two times the expected maximum internal current draw. 

FET power dissipated is dominated by static losses (simple "P = I^2 * R" calculations).  The Ron of the FETs I adjusted for a 100c junction temperature.  And it should be noted, this is per-FET (remember, there are two of them).  Switching losses (dynamic Pd) is so small; primary because our PWM frequency is very low at 144hz - the max switching loss I calculated was 3.4mW, so we can in effect ignore switching losses.


At first glance the worst case appears to be 2.75W + 2.75W + 12W + 1.3W =  18.8 watts.  The heat-sink I selected for this design (Hongfa HF92B-120) has a Thermal Resistance of 1.1C/w.   At 18.8w we would expect the heat sink to gain 18.8*1.1 = 21c.  Put this into our 120f engine room we get to a nice warm 160f heat sink.


In reality  it is unlikely we will see both the system voltage AND the field current at max at the same time.  After all, if indeed we were running at 80V and drawing 30A of field current, this would be 2.4Kw of power JUST TO DRIVE THE FIELD!!   More likely is as system voltage increases we would see lower Amps drawn by the field. 



Lets take a look at a couple more realistic extreme examples, a single Alternator in a 12v:

• 12v system
• Single large frame alternator drawing 10A field  (This is about 2x what a common alternator will draw)
• 100mA system draw (you will have to trust me on the new Power Supply figures I use below)

 Now total power becomes: 0.3W + 0.3W + 0.4W + 0.75W = 1.9W, or a 2c temperature rise. Now in our 120f engine room we are running at only 124f.  Will not even notice it.



Or, look at a this:

• 48v system
• Single large frame alternator drawing 3A field (a special 48v alternator - Higher volts means lower Amps)
• 100mA system draw.

Comes to: 0.03W + 0.03W + 4.3W + 0.75W =  5.1W  comes out to perhaps 130f.




What about a realistic 'heavy' system?

• 24v system 
• 2x large frame alternators in parallel - 20A field current.
• 100mA system draw.

     1.2W + 1.2W +  1.75W + 0.75W = 4.9W   --> gets us again  up to 130f in a 120f room.

What is the secret?  Looking at the power equation:  P = I^2  * R, to lower Power we can lower I or R.  The 1st was done by using two FETs.  Cut the field current in half between the two (FETs are largely self-balancing when ran in parallel).  We get a ton of bang from this due to the squaring of current in the power equation.   Next I selected a FET with low Ron.  With the low PWM frequency we can trade off higher gate capacantance to get a low Ron and not have to spend $7 per FET.

So, there it is.  Large Field currents, high system voltages, and looks like the Arduino Alternator Regulator will keep its cool.

Working through non-preferred charge management schemas

The core approach for this regulator is that we stay in Acceptance Phase until the battery is full.  And we decide the battery is full my measuring its acceptance amps.  When the battery is full, it says 'Enough' and we move onto float.

But what if the user has some reason to not want to do that?  What if they don;t want to hook up the Amp shunt, or perhaps want to use the Amp Shunt only for a different reason - and they WANT to use only time-based criteria for deciding when to leave Acceptance more. 

It is What If';s such as this I have been working through, to see how the regulator will react.  If the user had configured the regulator to use only time to exit Accept mode (by setting 'Exit_acpt_amps' in the CPE  = 0), then only time would be used.  The 'Exit_acpt_time' duration.  Tonight I added a 2nd option.  Setting the Exit_acpt_amps = -1 will now cause the regulator to move from Acceptance phase either by exceeding Exit_acpt_time duration, -or- by exceeding 5x the amount of time we were in Bulk.  This way of the battery is basically charged when we start up the regulator we will be in Bulk for a very short time, and now we will be in Acceptance for a like very short time.

The 5x is set in the code by
    #define ADPT_ACPT_TIME_FACTOR    5


This new Adaptive Acceptance Time Mode will also be triggered if the regulator is unable to measure amps via its shunt - either because something broke, or because the user did not wire it up.  In either case, by having an adaptive time frame the battery gets a bit more protection when we are unable to actually measures its appetite.

Over the next week or so I intend to work through other such 'non-preferred' scenarios and will be modifying the code accordingly.

Posted v0.1.0 of Source Code.

Tonight I posted up version 0.1.0 of the source code and the users guide as well.  See the resource tabs 'Source' above.  This code has been updated with the default charge profile tables, the new bluetooth RN-41 module, and other small changes.

I still need to work through and verify different modes of operation, ala what happens if the Amp Shunt is not connected.  But as more people are getting involved I wanted to post what I have.