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