Signal-K and the Alternator Regulator

Here is it!  For some time I have been working on and off with the Signal-K team to add electrical components.  Slow work, at times on the back burner  - but today I can share this with you:





What you are seeing is a simple Signal-K display showing real-time alternator voltage and current, as well as temperature (in kelvin - 308 --> ~35c/94f)  On the bottom right is the % field drive (57% at this time).

Currently the 'connection' is made via a serial port, with a javescript provider converting the ASCII status strings from the regulator into Signal-K JSON messages.  The 'provider' is located here:
https://github.com/thomasonw/signalk-parser-OSEnergy

The script will work with Gen 2 or Gen 3 regulators, no problem.  And if you have the blue-tooth module installed you could point the incoming ASCII steam to the script wirelessly!

It is based on the  NMEA0183 --> SignalK converter, thank you to Fabian Tollenaar.   I do have an issue right now, and perhaps folks can help:  I use a windows client for pushing files up to github.  Seems there is an issue with this where the 'executable' permission flag is lost.  The impact is if you try to run the demo on a Linux or Apple machine you will get a 'non-executable' trap.  Presently one has to change the permission of the file 'osenergy-from-file' to allow execution.   There may be a way to configure github to force this, again if there are any github experts out there - please speak up!


OK - a start.  There is still work to be done, the Signal-k spec needs to be expanded, I need to solve the global-variable issue above, and the next step will be to create a CAN based bridge.  My RPi and CAN shield are already on order!

Major release: New hardware, firmware, doc -- and some assembled units as well!

After over a year of work, today I am posting the release of the CAN enabled Alternator Regulator, along with new firmware and revised documentation.  The CAN enabled regulator allows communication of its status over a high reliability Control Area Network (CAN), used for decades in the auto,  trucking, heavy equipment, faming,  and industrial  applications the CAN is proven robust and low cost.  For those in the marine world, it is also the basis for NMEA2000

By adding a CAN to the Alternator Regulator, it is able to effectively communicate its status – and through the application of the open source protocol RV-C is able bring a whole new paradigm to alternator regulators:  Ability to fully cooperate with other charging sources to deliver to the battery what it needs in a well coordinated and prioritized way.  Stay tuned for more about this whole new approach, which as always is opened sourced and fully documented.  Key features of the Generation 3 regulator include:

• Continued support for 12v to 48v systems with no hardware changes
• Continued ability to use different voltages for the field vs. the battery (Allows 12v alternator to be used as high efficiency 28v battery charger)
• CAN communications:
•  Reduced wiring / installation by remotely sensing the battery voltage, current, and temperature
•  Full coordination of multiple charging sources to assure battery needs are meet
•  Prioritization of those charging source – Let Solar finish up recharging vs. burning diesel
• Wide range of status outputs
• 'NMEA2000'** status messages

The Firmware has also undergone a major revision, mainly to support the new CAN capabilities, but also to assure backwards compatibility with Generation 2 regulators. The source code will make needed selections based on the target CPU you have selected for each regulator (ATmega328 for Gen2, ATmega64m1 for Gen3).  Do note that there have been several additions and some changes to the ASCII status and commands strings, refer to use users documentation under the reference tab above.

And even more news, I have a small number of assembled Generation 3 regulators on hand.  See the side bar at the right. 

Going forward look forward, look for additional details on the ‘Systems’ approach to charging sources, as well as integration with other devices such as MPPT and BMS.  Will also be working on integration to the SignalK effort, and there is even the potential for a users application to assist in monitoring and configuration the regulator.  Maybe even a 3D printed case design!  Join the mailing list to hear more!

 ** Note:  NMEA2000 is a registered trade mark of  the National Marine Electronics Association.  Though the Alternator Regulator is able to provide some data which can often be read by NMEA2000 equipment, it is not NMEA2000 certified, not offered as a 'NMEA2000 device'

Posted Hardware Design for CAN enabled Alternator Regulator

Today I posted the hardware design files for the CAN enabled version of the Alternator Regulator.  It is the revised design I just sent off to have some blank PCBs created and I hope will be the final prototype.  I am still making some small adjustments to the source code, around integration with a remote battery monitor device, and once I have completed that will post the source code.  A side note, the new source code will auto-compile for either this new CAN enabled regulator, or the original stand alone regulator, based on the CPU type.

Some key features of the new design, and (soon to be released) firmware:

• Same core regulator functions:  Voltage, current, temperature, engine load.
• Same Charge Profile capability, and ASCII communications for status / advanced configuration
• Changed USB connector to smaller Micro USB
• Improved Stator sensor / Tachometer repeater circuit 
• Addition of CAN ports
• Stuffing options for CAT-5 connectors or standard wiring header
• Outputs NMEA-2000 like status messages
• Utilizes J1939 / RV-C to implement coordinated 'systems' approach for battery management.

Perhaps the two biggest changes are the CAN port, and the improved Stator hardware.   The CAN port is used to send out status of the regulator / alternator, and currently support NMEA-2000 like messages.  With this one should be able to integrate into existing NMEA-2000 displays, as well as translation efforts such as Signal-K    The improved Stator circuit is very sensitive and able to lock onto stator waves just from the residual magnetism in the alternators core.  This should allow for alternator connected tachometers to function almost all the time, without needing to fine-tune a small field drive..  And this regulator is the 1st of what I hope to be a series of designs which integrate with each other (via the CAN port) to approach battery charging from a 'systems' viewpoint, with all working together in a coordinated / prioritized fashion.  There is much more to come on this last topic!

You will find the CAD files, BOM, Gbr files, and schematic under the appropriate resource tabs at the top.

Finally, I only have one blank PCB left for the v0.1.4 release of the Alternator Regulator.  Once the hardware is stabilized, I want to look into the possibility of doing a short-run of the new design, but fully assembled.  There is a bit of thinking to do here, and I am also looking at porting over to the STM32 line of CPUs (lower cost, more capability) - but in the end I do know many people would find a fully assembled / programmed and tested regulator more appealing than the current blank PCB.  Watch this space over the winter, might do something like a Kick-starter campaign...

First Run - CAN enabled regulator with remote instrumentation!

Over the past month I have been  doing live test runs of the revised Alternator Regulator in 'stand alone' mode; where is senses voltage locally and acts accordingly.  During this time I was working on the CAN protocol to allow communications between a battery monitor and the regulator.  After several hardware simulations, and a few short live trials, today I made a longer (2hr) trial run of the new CAN enabled Alternator Regular working in sync with a battery monitor via the CAN bus.  Initial results look very promising!


For this latest run I disconnected the battery voltage and current sensing wires from the battery and placed them instead on the alternator.  Then using a mocked up Battery Monitor (Arduino Due with an INA226 grafted in) I was able remotely relay the battery voltage and current back to the regulator via the CAN bus.   to keep battery voltage typically within 5-10mV of its goal (max 20mV).  And this is all while there was a 400mV different between the Alternator output and the battery due to voltage drop in the heavy DC cables.


Over the summer I will make more trial runs, and will be releasing the new hardware this winter. There is more to come, but for now here are some of the capabilities enabled by the CAN feature:

•  Remote battery voltage instrumentation:  No need to run separate wires to the battery, all communications occurs over the CAN bus.
•  NMEA-2000 type status reporting on Alternator output, as well as Battery status.
•  Coordination between several charging sources using standard RV-C protocol.
•  Fall-back safety modes in regulator in case of CAN bus failure.

And as  foreshadow, if there is enough interest in this design I might look into having a batch of them professionally assembled.  No more hand soldering! 

Looking at Tachometers – aka, ‘My Tach Stops Working When the Batteries are Full!’

It is common in Diesel engines to sample the Stator output of an alternator as a way to drive a tachometer.  After appropriate calibration it mostly works well – until it does not…

As a regulator senses the battery is fully charged it will cut back the field drive to reduce charging current being forced into the battery.  At some point the regulator might go into Float mode - maintaining just a basic charge – or it might even turn off the alternator all together.   When that happens the Stator output voltage drops rapidly from 14v+ while actively charging to well under a volt. 

During these times people will report their ‘tachometer’ stopped working.   Traditional approaches to correct this include always sending a small amount of field drive, even when no charging is desired.  This ‘Tach Mode’ can work, and is a capability of the this Alternator Regulator.  But it can be fiddly to dial in just right;  getting just the exact right level of field drive needed to produce a sufficient stator signal for the tachometer, while not starting to once again force energy into an already full battery.  It is one area I am looking to improve with the revision to the regulator. 

Here are some O’Scope captures of the two alternators mounted on our Cummins main engine.  Trace 1 is the OEM alternator used to recharge the starter battery, while trace #2 is the large Leece Neville 270A alternator attached to our house battery.  The O’Scope traces are showing Stator output after the engine has sat unused for 2 days.   The engine was started at idle and remained there.  All field drives were disconnected, so we are only seeing output as a result of residual magnetism. 

In this example there is a nice 500mVp-p signal.  Just from residual magnetism (No field drive).  Even after 2 days of sitting around.  The regulator currently uses an AC coupled  74S14 Schmitt Trigger to condition Stator input, requiring about a 1.8Vp-p or better signal to trigger.  Clearly over the 500mV we are seeing above, but well below the 12v-14v level needed to start charging.  There are two different approaches I am considering:

1. Creating a closed feedback look between the PWM drive and the stator Vp-p, managing to around a 5-6Vp-p when ‘no charging’ is required.  This will give a good stable tachometer lock, which not allowing any current to flow from the alternator into the battery.
2. Improve the sensitivity of the Stator input circuit.

Mostly I am leaning towards option #2, looking at a VRS chip such as the LM1815 or the NCS1124.  These have sensitivity in the range of 300mVp-p, and would clearly be triggered in my example above – even after 2 days of ‘sitting’.

Once the regulator is able to get a stable RPM reading it could ‘echo’ that out the Feature-out port to drive an external tachometer.  End results:  no more ‘Tachometer stops working when batteries are full’ situations – and also no risk of continuing to overcharge batteries by artificially providing field current to keep a strong Stator signal. 

Is this something you would find of value in?

Regulator stops working when ENABLE volts drops below 12.5v

Today I received a comment from Jeremy that during bench-testing he noted his regulator would stop functioning when the ENABLE voltage drooped below 12.5v.  Specificity, the Field FETs would not turn on.

Upon reviewing things, I think the issue is in U3 (the FET Driver).   The IRS21850 has an undervoltage cut-out of nominally 8.2v - but can be as high as 8.9v per the spec sheet.   Combined with other worst-case  voltage drops of D16 and Q1, we think this is the issue.

A good corrective action will be to replace U3 with a different driver chip.  The IRS21867 is a dual driver chip (High and low side), but its high-side is pin compatible with the existing PCB layout.   Plus, its under voltage cutout is 4.5v - much more in line with the FETs needs.  So, a proposed errata for v0.1.4 of the PCBs is:

1. Replace U3 with IRS21867 driver ship (Mouser URL:  IRS2186) 
2. Solder bridge U3 pins 3 & 4 (this will pull the unused low-side drivers input to a fixed state)

I have updated the Mouser BOM (link here) to include BOTH the old and the new driver chips.  When ordering you can select which one you wish to use.  Once I am able to verify the function with the IRS2186, I will remove the original IRS21850 option.

V0.1.8 Source released

Under the Source resource tab above you will find release v0.1.8.   This has a very small change to it in startup that corrects a bug preventing the proper recognize of the forced CPE entry override of the $SCO: command.

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.