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!
This sounds like an interesting solution. Just some random thoughts to further the conversation.
ReplyDeleteMy idea was to get a cheap NMEA0183/N2K adapter and just send/receive serial commands to the UNO using its UART but that config needs one per regulator and they are not cheap. Further, it is limited in what data can be shared. The advantage with that config is you run a standard N2k link to each device, so distance is not an issue.
Taking your idea further and having the Due act as a hub/bridge if I understand your concept correctly, the Due could also act as a master for multiple regulators and battery isolators to better work together in an intelligent parallel config,unless your idea is to rework your design to incorporate the DUue onboard the reg. With its 4 UARTS it could also be the BMS/N2K bridge. The issue then becomes linking the devices together with serial 232 or 485.
Basically yes, but I am more thinking of the Due as being a simple ASCII to CAN bridge for reporting out and perhaps simple config vs. more complex real-time operation. For the 'next step' my overall vision is the CAN bus is used to provide real-time communications between multiple devices, each being rather simple and focusing on one task. Example: A regulator, A battery isolator, A BMS, etc... Further - the BMS tells the world what the status of the battery is, and what (if any) charging needs it has. Charging devices respond by delivering energy as they can to meet the needs. The CAN bus itself is used prioritize and isolate functionality in a distributed fashion vs. a central controller.
DeleteSo, the end results is the same: coordination between battery needs and all charging sourced, but rather than a central controller I think using a distributed functionality approach and utilize the CAN buses prioritization is a better architectural approach. More reliable, simpler to install and easier to adapt to different deployments – one installed what they need and it self-integrates integrated into the 'system' over the CAN bus.
But as an short interim project, the Due would perhaps give the bridge function. And if you wanted to extend it to NMEA1083 and have it act as a bridge for that as well, there is some existing code out there! So yes: bridge, status reporting, maybe some light config. But not used as a central clearing house for real time decisions.