It does look possible.
I believe it’s relying on data being broadcasted from the Sevcon controller, not the method I have been using (reading the SDOs manually).
If possible I would love to get rid of SignalK and NodeRED in my setup, I will have a go at it.
I will give you an update and share some code if it works.
1 Like
If that could be made to work that would be nothing less than fantastic. With or without incorporating the virtual motor in Node-RED (which is a solution I would have a slight preference for).
The Sevcon controller can certainly be programmed to broadcast heartbeat data for things like rpm amd power, no need to command a read from it – all that should be needed is to get the Cerbo to accept and interpret the data, which I believe is all the Oceanvolt driver does.
If this works there should be no need for Node-RED or Signal-K or even the Large OS… :,)
The big if here is whether the Oceanvolt driver works as-is. If it needs modifications to function for Sevcon, we need to either ‘bake’ our own VenusOS version or get Victron to update the now years old driver for us, neither is trivial I’m afraid. That’s why I’d rather see a Node-RED based solution that takes any required logic/code/lessons/translation tables from both the Oceanvolt driver and @citolen 's solution for reimplementation using standard Node-RED can-bus features and Victron’s virtual motor feature. I’m making an intelligent guess that not having to code the d-bus population with live motor data (as that is what the virtual motor does) will significantly simplify the overall solution.
Absolutely – if the Oceanvolt driver doesn’t work “off-the-shelf” then Node-RED and the virtual motor driver is the way to go.
Bear in mind that “work” here only means “reading heartbeat data transmitted by Sevcon”, not full motordrive control and command which is much more complex – and risky if anything goes wrong, I certainly don’t want the Cerbo to be able to be anything except a dumb observer!
1 Like
Does your solution need to poll for that data or does it pick up on a data stream that gets send onto the can-bus (heartbeat?) by default anyway?
And if not by default, could it be set (once) to do so with the Sevcon sw/hw (iXXAT can-bus dongle). If you did so yourself, could you provide a summary instruction, I do have the sw/hw.
It’s currently polling for that data every second with an SDO read.
No idea if it’s broadcasting any data by default, but we can check.
I haven’t taken the time to look into it, but I should be able to some time this week.
Same as you, my idea was to use the Ixxat dongle and the DVT software to see what’s passing through the CAN bus.
Assuming what’s on the dbus_motordrive repo is correct, the CAN IDs we should look for are:
0x132/0x133 → RPM
0x162/0x163 → Controller Voltage, Current, Temperature
0x248/0x249 → Motor temperature
First step would be to check these messages are actually broadcasted
I’m pretty sure they either are, or can be set to, broadcast. Hard to imagine it being otherwise on a can-bus based system where anything, anybody ánd their mother in law broadcasts everything by default.
For a CANopen slave to transmit its data independently via Tx PDO (broadcast), it must be set to CANopen NMT Operational Mode. This is done by sending a single CANopen NMT message. However, no other CANopen master should be present on the CAN bus.
Also power…
The Sevcon gen4 manual has some interesting information.
What we are looking for are TPDOs.
The controller can be configured to transmit up to 5 PDOs which we could configure to include the objects we are interested in.
The bad news is that it’s something you have to configure and therefore wouldn’t be a generic plug&play solution that can be easily used.
A user would need the dongle and the right software to reprogram the controller.
I’m going to stick with my solution of reading the SDOs directly, it works without a need for a reconfiguration.
I’m still going to check if I can connect it directly to the Cerbo CAN bus.
1 Like
It’s not needed, Venus will automatically infer power from the voltage and current
Configuring the Tx-PDOs is called mapping in CANopen, and is performed before switching to CANopen NMT Operational Mode. Cerbo could theoretically perform this using Node RED. However, the object directory entries containing the speed, voltage, etc. could just as easily be queried via Node RED (e.g., node-red-contrib-socketcan), which is currently still handled by the separate custom board.
1 Like
Hello @JG_embedded , welcome on the forum. If this topic keeps drawing Sevcon owners out of lurking mode things can get quite interesting in here 
I don’t think needing to configure the Sevcon is a problem, that must have already been done when the motor drive was set up, its just another step to be done – for example, setting the correct bit rate, which is essential before any comms will work. But if this can be done by raeding SDOs instead this may still be the best solution.
Thank you.
Aside the obvious value of being able to integrate live motor performance data with the Venus (display) platform, I have one other feature in mind that would be extremely valuable for my (marine)customers: being able to control the maximum power settings of the motor (Sevcon controller really) based on the battery’s actual SoC. This in contrast to tweaking and twiddling with Sevcon’s control curves based on the voltages on the DC-bus to create some sort of ‘low battery, limp home’ function.
Just being able to dynamically set either a maximum power percentage or an absolute power value from within VenusOS / Node-RED to the Sevcon would allow much better use of the lower end of the battery capacity, increasing the safely useable capacity with 10% or even more, which can be a lot at the end of the day. Not to mention the ability to then still allow high power braking (reverse) while limiting the continuous power draw to increase the ‘limp home’ range (limiting sailing speed further below rump speed significantly increases range!)
I’m not convinced that’s the kind of thing that needs automating; like anything else that consumes battery power, it’s down to the user to keep an eye on it and stop SoC dropping to 0% and triggering a LV shutdown – for example, even if the motor was limited, nothing stops them turning on an electric cooker.
The important thing is to present all the information (SoC, drive power) clearly so the user can see it.
Is torque also available?
The reason for asking is that propeller torque rises with rpm^2, so [torque/sqrt(rpm)] is a measure of propeller load and should be pretty much constant – if it rises this signals there’s something wrapped round the prop (very common on the canals!) and this could be flagged to the boater.
(yes I know this would need extra coding and Node-RED, but at least the option would be there)
I think we have several possible approaches here…
- Use Oceanvolt driver and configure Sevcon to broadcast heartbeat data – simplest method (if it works!), Sevcon will probably need programming anyway to match CANbus speed/format
- If this doesn’t work, use Node-RED to read Sevcon data (Sevcon as slave), no reprogramming of Sevcon needed – needs Node-RED installation and coding which many installations don’t have
- Program Sevcon to transmit heartbeat data and use Node-RED to read it – both Sevcon and Node-RED programming needed
In all cases this should be done with just the Cerbo and a CANbus cable, with no extra hardware.