2025-02-17, 11:10 AM
I was dig a bit into questions of hardware and network (see my motivation below). This is how I see the situation now, and I am interested in your thoughts. If it was already discussed, I would like to see pointers to that.
I was thinking about gear similar to an NMEA2000 based system. So first I tried to look up open alternatives to its physical and MAC layer, and ways to create devices for such a system.
Hardware layer:
The obvious problem with the hardware layer is its price. The bus topology can reduce the cable mess tremendously, but with this kind of connector and cable prices no wonder NMEA2000 is not more widely adopted. The first obvious choice is to just use fixed connections and waterproof them with adhesive filled shrink tube. It could work with parts which rarely need repair, and if you do not run into an issue which needs to be localized by getting off everything from the network and putting them back one by one. With some inspiration on things in thingiverse I came up with the idea of 3D printing something like the M12 connector, but probably bigger. I am thinking about a system which basically consists of:
What cannot be printed are pins, sockets and O rings. Automotive pins and sockets can be obtained relatively cheaply, and the same for the O-rings.
I probably will design and test this solution when I am over with other projects (like actually building my proa, and setting up a working system out of what openmarine does have now).
Do not be confused: these are still not cheap, you just trade your 3D printing time for real money to spend. (This is an important thing to understand, and the recent events around MAIANA should make it clear: the real cost of any device is parts+time of whoever puts it together+the profit to motivate that whoever. As long as anyone can access all the information to make it themselves, it is okay to ask for whatever price for it, and if multiple whoevers choose to supply the thing, the profit+workhour part will converge to a small but not insulting one. E.g. the real price for a MAIANA system is more than whatever pcbgogo asks for the PCB and the manufacturing of the board. Which I would have tried but choosen to wait for the guys working on that right now and pay them for my device when they are ready. But the pcbgogo route could be a way for someone who wants to become a supplier, but does not have the spectacular soldering skills needed for that piece, or time to spend on boring manufacturing.)
MAC layer:
When looking to alternatives of the MAC layer, I honestly could not find anything which is both totally open and good for the task. Sure, some version based on the same design principles than that of CAN could be designed, or even something on top of RS485 could be quickly hacked up (with worse collision detection), but I guess CAN is so widely implemented and understood, that it is better just go with it. And in this case using NMEA2000 codes is also okay for me. I guess no one cares if we do not call it NMEA2000. And if someone cares, most of it is either software we can easily change or hardware we legitimately use.
Devices:
With the above settled, a lot of part of the devices are "straightforward" (not actually, just the best way is determined by constraints). A CAN controller like MSP2515 with a transceiver chip, and some MCU driving it through SPI. These ingredients are cheap and there is a lot of know-how out there. For the MCU RISC-V is the more open choice, and AVR is the established old guy in the town with more established ecosystem. AVR do have multiple CAN libraries which work with arduino, but there is at least one implementation for RISC-V on github as well.
Probably prototyping with arduino it is more or less the question of adding the CAN circuits to the board (or choosing an arduino board which already have it), sticking on your sensors and actuators, choosing the libs for them, and adding a couple of lines to a sketch.
Motivation:
I was thinking about using smart things, including navi lights on a proa. Thinks like if the light has a technical failure I am alerted (the power consumption of the light can be monitored or a light sensor can be built in with minimal additional cost), or the color of the light changes when the boat detects based on GPS data that I shunted my boat. I guess that even boats having a smart network rarely go down to that kind of details. Given the price of NMEA2000 compatible gear it is not really suprising.
I was thinking about gear similar to an NMEA2000 based system. So first I tried to look up open alternatives to its physical and MAC layer, and ways to create devices for such a system.
Hardware layer:
The obvious problem with the hardware layer is its price. The bus topology can reduce the cable mess tremendously, but with this kind of connector and cable prices no wonder NMEA2000 is not more widely adopted. The first obvious choice is to just use fixed connections and waterproof them with adhesive filled shrink tube. It could work with parts which rarely need repair, and if you do not run into an issue which needs to be localized by getting off everything from the network and putting them back one by one. With some inspiration on things in thingiverse I came up with the idea of 3D printing something like the M12 connector, but probably bigger. I am thinking about a system which basically consists of:
- T parts with 3 female connectors with the "bolt side" of the screw
- Cables with male connectors in one end with the "nut side" of the screw, and the same or a device or simple cable ending at the other end, depending on use.
- Caps which can be screwed on to unused female connectors.
What cannot be printed are pins, sockets and O rings. Automotive pins and sockets can be obtained relatively cheaply, and the same for the O-rings.
I probably will design and test this solution when I am over with other projects (like actually building my proa, and setting up a working system out of what openmarine does have now).
Do not be confused: these are still not cheap, you just trade your 3D printing time for real money to spend. (This is an important thing to understand, and the recent events around MAIANA should make it clear: the real cost of any device is parts+time of whoever puts it together+the profit to motivate that whoever. As long as anyone can access all the information to make it themselves, it is okay to ask for whatever price for it, and if multiple whoevers choose to supply the thing, the profit+workhour part will converge to a small but not insulting one. E.g. the real price for a MAIANA system is more than whatever pcbgogo asks for the PCB and the manufacturing of the board. Which I would have tried but choosen to wait for the guys working on that right now and pay them for my device when they are ready. But the pcbgogo route could be a way for someone who wants to become a supplier, but does not have the spectacular soldering skills needed for that piece, or time to spend on boring manufacturing.)
MAC layer:
When looking to alternatives of the MAC layer, I honestly could not find anything which is both totally open and good for the task. Sure, some version based on the same design principles than that of CAN could be designed, or even something on top of RS485 could be quickly hacked up (with worse collision detection), but I guess CAN is so widely implemented and understood, that it is better just go with it. And in this case using NMEA2000 codes is also okay for me. I guess no one cares if we do not call it NMEA2000. And if someone cares, most of it is either software we can easily change or hardware we legitimately use.
Devices:
With the above settled, a lot of part of the devices are "straightforward" (not actually, just the best way is determined by constraints). A CAN controller like MSP2515 with a transceiver chip, and some MCU driving it through SPI. These ingredients are cheap and there is a lot of know-how out there. For the MCU RISC-V is the more open choice, and AVR is the established old guy in the town with more established ecosystem. AVR do have multiple CAN libraries which work with arduino, but there is at least one implementation for RISC-V on github as well.
Probably prototyping with arduino it is more or less the question of adding the CAN circuits to the board (or choosing an arduino board which already have it), sticking on your sensors and actuators, choosing the libs for them, and adding a couple of lines to a sketch.
Motivation:
I was thinking about using smart things, including navi lights on a proa. Thinks like if the light has a technical failure I am alerted (the power consumption of the light can be monitored or a light sensor can be built in with minimal additional cost), or the color of the light changes when the boat detects based on GPS data that I shunted my boat. I guess that even boats having a smart network rarely go down to that kind of details. Given the price of NMEA2000 compatible gear it is not really suprising.