Meet the newest member!

OK,  There has been some work underfoot.   Over the past months I have been revising the Arduino Alternator Regulator design,and here is the 1st prototype just as it was preparing for its 1st trial run:

Revised design - ready for its 1st run

Still using the same proven core code this regulator features one major enhancement:  It includes a CAN port for communications to the outside world.  How can this be used?  I am looking at three protocols to enable:

• J1939 based NMEA-2000:   Report out status
• CiA / CANopen:  Accept CAN based charger enable/disable commands
• J1939 based RV-C: Protocol to communicate remote battery voltage, temp, etc (reducing wiring) and enable a coordinated 'systems' approach to DC charging sources.

View of CAN ports, the two RJ45 connectors for CAT-5
Stuffing options allow traditional headers to be used instead.

Each of these have a slightly different benefit.  NMEA-2000, popular with some boaters, will allow you to display your alternators status in enhanced monitors.

With the increasing deployment of Li-based batteries (especially LiFeP04 and related) there is a need for the BMS to communicate to the alternator to enable or disable it.  Today this is handled (very well, btw) using the FEATURE-IN port and a wire.  Some more advanced BMS devices though are able to send a class of commands to accomplish this same goal.   Using CAN will reduce wiring, simplify installation, and increase reliability.

My final phase will be to enable a CAN based BMS which not only informs the alternator to turn on and off, but also is able to do the same with any charging source.  And be able to coordinate all charging sources for priority (let the Solar panels top off the batteries), as well as assure that all sources are working to the same goal (battery voltage, amps, charge phase, etc..).  In addition we can send the real time battery measurements over the same CAN cable - no need to run separate wires to the battery for each device.  For this I am considering RV-C, as well as keeping an eye on other J1393 based CAN protocols.  Never fear, fall-back modes and safety steps will be included in case there is a communications failure.  No more 'fried batteries' if that remote voltage sensing wires gets cut somehow (I have seen this more then once with traditional regulators by the way).

Bottom view

Other differences include on-board USB adapter for programming as well as advanced configuration. The design also utilizes SMT components.  It is my hope to make some or all of this available in some way professionally assembled, and if anyone is interested in assisting with this aspect - please contact me





The CPU selected for this project is the Atmel ATmega64M1.  It has several nice features, most notable a built in CAN controller.  In addition to the hardware there has been much work done on the foundation software which will be needed, including:

•  Basic support for the newest Arduino IDE for the  ATmega64M1 CPU.

                      https://github.com/thomasonw/ATmegaxxM1-C1                     
 

• CAN driver lib modeled after existing Due lib to enable the built in CAN controller in the ATmega64M1

                      https://github.com/thomasonw/avr_can    

• Working with Timo Lappalainen to extend his NMEA-2000 lib for support using the above.

                    https://github.com/ttlappalainen/NMEA2000 

• ‘Link’ file to bring NMEA-2000 to AVR_CAN 

                  https://github.com/thomasonw/NMEA2000_avr      



There is more work to do - including some overall systems configuration HUI that could perhaps simplify the installation and setup.  Again, if anyone is interested - please drop me an Email!

Caution when burning the bootloader - TURN OFF THE DIP SWITCHES!

In reviewing the design I noticed that by dual-purposing two of the pins on the ICSP connector (SCK & MISO) there is a potential for problems when attempting to flash in the bootloader.

Before flashing in via the ICSP port, make sure to TURN OFF ALL THE DIP SWITCHES FIRST!

Specifically DIP1, 7 & 8.    Doing so will power down the Bluetooth module, reducing power demands on the 3.3v supply - helping to assure we have a nice stable source while flashing the bootloader.   It will also free up SCK and MISO pins from being pulled hard to ground, preventing them from working and perhaps also causing damage to your ICSP device.

None of this is needed while loading sketches / firmware via the Serial adapter (Normal Arduino way).  It is only critical when using the ISCP port.

v0.1.7 source released

Today I posted v0.1.7 of the Arudino Alternator Regulator source code, look under the SOURCE resource tab above.

This release is based largely on field feedback (thank you A-P) and is able to better 'regulate' the temperature of an alternator.  It has two changes in it:

    1) Bug Fix - Prevent any PWM increase if the Alt is at (>=)  its target temperature.
                       Prior would block PWM  increases only when the alt was over temp. (>)
     2) Refinement - Increased gain of PID tuning for Alt Temperature.
              #define KpPWM_TA_SENSITIVITY                0.500      
              #define KdPWM_TA                                        0.750
                ( Was:  0.200 / 0.500  )

The old code 'worked', but tended to allow the alternator to overshoot its upper temperature limit and ultimately triggering an over-temperature pull-back.   With the above changes we can now expect to see a more stable and smooth regulation around alternator temperature when needed.

I want to thank A-P for his live field feedback on this area.  Having feedback from a wide range of installations helps this project tremendously.

As kind of a review, the Arduino Alternator Regulator actually has 4 regulation points (vs. the 1 or perhaps 2 of more common regulators).

• Battery Voltage - most all regulators do this :-)
• Battery Current
• System Wattage / Engine load
• Alternator Temperature - some 'advanced' regulators do this as well

Each of these 4 regulation points along with other traps and system monitors (e.g., battery temperature, RPMs, etc) can have an effect on how hard the alternator is driven.  Alternator Temperature can come up in a cramped engine space, and to be honest if an install is operating under this mode one should perhaps look at the overall installation:  Perhaps the alternator is too small (or overrated, aka "Too Much Marketing" put into it).  And/or there is a significant cooling issue in the engine room.   But in any case - rest assured, the Arduino Alternator Regulator will manage things as best as can be done given each installation.

Oh, one more change:  I am now using notepad++ as my default editor.  One of its features is the ability to automatically replace tabs with spaces.   And I have turned that on.  Prior source was edited with a tab spacing = 8, and I know many folks use spacing = 4.  By just using spaces the code should 'look good' no matter which editor you are using.

VERY ROUGH - NMEA-2000 bridge source posted

Over the past couple of days I have put together a VERY ROUGH NMEA-2000 bridge, see source code under above resource link (and make sure to copy down the needed libs from their resource tab as well).

This bridge is designed to run on an Arduino DUE connecting to the Serial ports on one or two Arduino Alternator Regulator.  It will receive ASCII strings via Serial 1, and Serial 2 (up to two regulators can be monitored), parse the received data, and place them into a local data structure for further use.

The 2nd part of the bridge will formulate a limited number of NMEA-2000 packets from this received/parsed data and send it out via the CAN0 port. It leverages work done by:
      Collin Kidder (collin80)  https://github.com/collin80/due_can
      Timo Lappalainen (ttlappalainen)  https://github.com/ttlappalainen

For now I have extended Timo's libs to include new PGNs, so make sure to use the libs from the resource tab above.  Once things are a bit proven I will submit the changes back to Timo for inclusion in the main source.

A final capability of the software is to self-generate simulated ASCII strings.  By including the current Arduino Alternator Regulator source and running it in TESTING mode ASCII strings are made available on Serial3 - just use jumpers to connect the Tx3 back to Rx1 and/or Rx2 for Bench testing.

Speaking of proving.  I do not have at this time sufficient hardware to do complete validation of this code.  Specially, I am not at this time able to receive and verify the NMEA-2000 packets.  (I have been able to validate the ASCII string receiving / parsing is working well).  I do have some additional hardware on order, but do not expect to be able to get access to it for a month or two.  (Life on the Float)

I am also a bit underwhelmed on the level of information available within the NMEA-2000 spec.  This source makes use of two PGNs:

•  PNG:127506 DC Detailed Status
•  PNG:127508 Battery Status 

One task is to review the PGNs populated and settle on the appropriate ones.

OK, this is a very very rough effort at this point.  And work is still needed (hence the 0.0.0 revision). But I know a few folks have expressed interest in this, and I am curious to see how it works out.  With regard to further proofing / refinements I would like to suggest we utilize the Google group Emailing list: https://groups.google.com/forum/#!forum/smart-alt    That way all folks interested can participate.

 OK, this will be interesting - and perhaps a small start to a proper integrated CAN  regulator project.

NMEA-2000 bridge

A few people have asked about connecting an Arduino Alternator Regulator to the NMEA-2000 bus - just to report out status.   This morning I spent some time googling to see what was out there, and think there can be a rather simple bridge built based off of an Arduino Due.

Using the Due has a couple of advantages vs. using an Arduino + CAN sheild.  The 1st is perhaps cost - Even overseas, a Uno + a sheild comes in at about the same price as a Due.  Though it is true one will still need to add a transceiver to the Due.  But another advantage is the Due is a 3.3v device - so no 'logic level' conversion will be needed.  It also has a built in CAN controller, with available libs to support it.  And there is even a +5v source that can be used with the CAN transceiver.  And it even has several serial ports, so would be able to act as a bridge for more than one regulator.

Taking in the ASCII status strings from the regulator, parsing them and translating them into some NMEA-2000 packages looks to be a simple task, and I even found a couple of sample sketches that goes a long ways towards that goal:

https://github.com/ttlappalainen/NMEA2000_due

forum.arduino.cc/index.php?topic=50893.30

http://copperhilltech.com/arduino-due-can-bus-transceiver-breakout-boards/

being a few links.


I have a Due on hand, perhaps can look into making up a simple bridge - or if anyone else wants a go at it, let me know and will make sure to link it in!

Hint during installation - remove the old stuff!

This past week I received a hint that I wanted to pass on:  when installing the new Smart Alternator
Regulator make sure to FULLY remove any of the old 'stuff'' attached to the alternator that might have been needed by your old regulator.  Things like boot-strap diodes / resistors (including Dash lamps) - make connections instead as noted in the documentation.    

And be on the look out for hidden resistors.  One person found a large 270 ohm 5W resistor attached from the old D+ terminal (no longer used) to GND.  Originally intended to help drive the dash lamp and also provide a minimum load to keep the alternator driven tach running, this extra phantom load played havoc with the Smart Alternator Regulators attempt to stabilize things with its own tachometer mode turned on.


So, pull out the extra stuff - you have been warned!

Release of Source Code v0.1.6

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

Here is a summary of the changes:

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

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

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

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

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

Still here - how is YOUR summer?

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

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

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

-al-

Release of Source Code v0.1.5

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

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

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


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

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

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

Supporting release 1.6.0 of the Arduino IDE

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

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

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