Design Refresh!

It has been 3 years sense I last looked at the DC Generator controller board design.  In that time we have accumulated over 1,000 hrs of run-time on our system, and 20x other systems boards have been ‘sent out’  (though I am not sure how many are actually running to be honest).  Over the years I have had a few folks inquire about the design, and if there were any more PCBs left – which I had to say no.  But this winter I want to do a design refresh – bring in the learning from the Alternator Regulator project, and specifically add a CAN connection capability.  CAN (following the OSEnergy open standard) will allow for coordination and cooperation between charging sources, simpler remote panel integration, as well as integration with more modern standards such as SignalK.  Much of the ground work has been put into place, and is being proofed out with the Gen 3 design of the Alternator Regulator.  It is time to refresh the controller its self.

So, here is a 3D rendering of the design I have drafted up:

As before it is a fully integrated engine and alternator controller, with the addition of some additional sensing ports to allow for monitoring of an optional water-maker  (Monitoring for alarm, not active control / automation of the water-maker).  It also includes the aforementioned CAN communications capability.  It does feature a different CPU, the STM32F072, a bit lower cost – but also more programming pace, so the IDE will be a little different (A future project is to see about creating a board-type to support this new CPU under the Arduino IDE).  I have the initial design completed, want to sit on it a while to do desk-reviews, but am looking to make up a prototype this fall, with perhaps a small professionally assembled run later this winter.

Will also be looking at refreshing the optional remote.

A major effort will be bring the firmware up to date.  A major change I want to make is move from include file / compile options for configuring to using the ASCII command approach as on the Alternator Regulator.

OK, this is just kind of a heads up – letting anyone who stumbled across this blog know there is still life in the DC generator project!  If any questions, and if you are perhaps interested in a controller this winter – drop me an Email and/or leave a comment below.

Which CPU can I use for CAN???

With solid requirements a designers job is simpler - choosing the components that meet the needs, at the lowest cost.  But when the requirements are opened ended, it is tougher.  The past few days I have been looking into ways to get CAN and a small micro-controller together, still not sure I have the full answer.

I think 1st I want to limit things to what can be used with the Arduino IDE.   Given the home-brew nature of this project, Arduino's low cost (free) tools, combined with some per-defined wrappers /  libs makes thing a little more easier for a wider range of people.  With this as a framework, I think there are three viable approaches:

1) Use Arduino UNO ATmega328p CPU + MCP2515 CAN controller
2) Use Arduino Due ATSAM3X8EA CPU, it has dual integrated CAN controllers.
3) Use Atmel AT90CAN32 CPU:  A kind of 'grown up' ATmega328 CPU, it has a single integrated CAN controller and  several more I/O ports.

Uno

Option #1 would be the lowest cost ($5.10  using Mouser pricing), and I think I can get all the current controller functionality supported if I shift around some ports and all but eliminate the expansion connector.

Due

Option #2 is perhaps an overkill.  But the two CAN ports could come in useful to support a low-speed and a special low-latency bus.  The ATSAM3X8EA increases program space from 32K to a whopping 512K!  Downside: Cost - $13.51, perhaps a bit higher as I look more into what is truly needed for USB communication.

Something else?

Option #3 is somewhere in the middle.  Its cost is $7.10 - though it does not have the real killer capability as option #2, there are pin compatible versions available which increase the programming space from 32K to 64K and even 128K - for a price of course: $9.00 & $11.33 respectively.


In addition, each of the options will require some extra work in the power supply, and close care with power down modes - as with CAN the controller needs to be alive all the time looking for a call to start generating...


Clearly option #1 is the lowest cost, and its MCP2515 is somewhat supported in the Arduino community.  But I am kind of leaning towards option #3.  Though a little higher cost, it comes with more I/O capability that I could use to provide additional functions w/o an expansion board (ala, controlling external cooling pump & monitoring the watermaker pressures).  Though I could add those capabilities w an expansion board, but the time one purchases the I2C chips, the cost advantage of option #1 is lost.

#2 is such an overkill, and as well as the highest cost.  I also kind of wonder about the future of the Due.  Today I noted two new Arduino offerings, the Treo and the Zero.  Both are high power RISC machines, and I really wonder if the Due's popularity will be effected by them. . . .

Looking at CAN - Control Area Network

For some time now I have been looking at other ways to communicate between the controller and the LCD remote. A big part is that I now use a 2nd ATmega328 CPU on the remote LCD, and it now can do intelligent processing.  The idea would be instead of the controller doing all the display rendering, it simply sends over status and the LCD figures out how to format and display it.  So instead of sending "On line 2, column 4 put a '1', then a '4', then a '.' and finally a '3'" to update battery voltage, the controller will simply send "Battery voltage is now 14.3v".

In addition to distributing the work between the two controllers a bit, this also will allow more advanced options for the LCD display.  Maybe adding a graphic, or some combination of key switches to select more modes of operation / configuration changes.  And perhaps lower costs some as the P82B96's I2C extenders are getting more costly every day, now at $3.10, and under $1.50 when I 1st started using them.

An obvious approach is using ASCII strings much like the Arduino Alternator Regulator does.  Sending and reciving via the serial port, likely using an RS-485 or RS-422 current loop to do the actual communications.  Advantage is the ASCII is human readable, and easily connected to other devices ala PCs..



But I have also been looking into a CAN (Control Area Network) as a way to communicate.    http://en.wikipedia.org/wiki/CAN_bus
This technology has been around a LONG time, is well developed, and parts are common as well as inexpensive.   With 100's of CAN controllers in many automobiles, there are also a wide range of hardened components out there.  It is what NMEA-2000 is built upon.

Using CAN would allow me to have one wire connected between the controller and the LCD remote.  But it also would allow for things like moving all the battery senders off the controller and on to its own little board located at the battery and connected via one wire into the CAN bus.  Vbat, Amps, and Temperate.  More so, this same information could be shared with a CAN enabled Alternator regulator.

Though the low-level hardware stuff is standardize, how information is communicated is a different thing.  There are several 'standards' out there for packaging up data to send over a CAN bus - NMEA2000 being one, but lots others as well.  And beyond that, most deployments tend to define their own standards...

And one downside to CAN:  it is NOT human readable, one needs a PC to receive the data and 'translate' it into something usable for people's eyes.  But that is not that hard,  CAN-USB adapters are available for under $10 - mostly by the auto guys who want to tap into cars CAN networks.  And a small program is not that hard to write to convert...   Once you know the 'standard' begin used to communicate over the hardware.  And I think even if going to CAN bus, would need to retain the Service port / ASCII interface.

My head is spinning more then anything at this time, I welcome any comments from people about the CAN bus and its usability...