Autopilot -> Shipmodule N2K -> signalK
Hi All,
I have an Raymarine ACU-200 with an Evo-1 and P70 connected to a STng network. Attached is a shipmodule N2K converted which is linked to SignalK with usb.
Unfortunately it’s not possible to control the Autopilot from standby to auto. The GUI shows that the pilot is in current state stanby with the compass course.
Did anyone manage to get this setup working?
18 Replies
Did you check the device id of the ev1 and configure it in the plugin?
I actually don’t remember if the ship module stuff supports sending out n2k
Hi Scott, thanks for the reply. It looks like something is going wrong on the status indication. It doesn’t matter if the autopilot is in auto or standby. It always reports standby on pgn 65379. Will try to figure this issue out first
How do you have the Data Connection setup in sk?
The ShipModul multiplexer will repeat all data it receives from NMEA-0183, USB, ST1 and WiFi to N2K.
From their website:
Each NMEA 0183 input, host port and a ‘virtual’ input providing conversion results is visible on the NMEA 2000 network as an individual device, and can thus be selected as a Data Source on receiving NMEA 2000 devices like plotters and displays.
Where 'hostport' can be USB, UTP and I think WiFi as well.
Which doesn’t really answer the question
"I actually don’t remember if the ship module stuff supports sending out n2k" sounded as question to me. As I have one of those thought it would take away that doubt.
Hi Guys,
The issue with the control of the autopilot has been solved. Somehow i am still having some issues with the status (steering.autopilot.state PGN 65379) returned on N2K via a $MXPGN message. I do see the status change when i put the pilot in auto or manual in the event log. However in the databrowser (and in the plugin) it always stays on "Standby".
Message when pilot put in auto: $MXPGN,00FF63,78CC,FF02000000409F3B62
Message when pilot put in standby: $MXPGN,00FF63,78CC,FF02000000009F3B66
When i look in the code the 40 in hex represents to mode 64 auto in dec. Does anyone have any Idea?
65379.js
module.exports = [
{
node: 'steering.autopilot.state',
value: function (n2k) {
var mode = Number(n2k.fields['Pilot Mode'])
var subMode = Number(n2k.fields['Sub Mode'])
if (mode == 0 && subMode == 0) return 'standby'
else if (mode == 0 && subMode == 1) return 'wind'
else if ((mode == 128 || mode == 129) && subMode == 1) return 'route'
else if (mode == 64 && subMode == 0) return 'auto'
else return 'standby'
}
}
]
Thr first two bytes are wrong "FF02"
oh wait
ok, so definitely the first two bytes are wrong
somehow the Shipmodule is not converting it properly
but there are other issues, the definition for 65379 is wrong in canboat 5.0.3
it's fixed in the main branch
I will sort the second issue next week
But I don't understand why the Shipmodul is giving the wrong data
Can you explain what is exactly converted wrong? I will report it back to meindert.
Those first two bytes
FF02
They are “Company” and “Industry”
A good one looks likes this "3b,9f,81,01,00,00,03,ff"
"3b,9f"
company == Raymarine , Industry = 4 ("Marine")
Hi Scott, I received the following response from Shipmodule:
""
If you look at the specification of the MXPGN sentence, you can see that the payload is not the bytes of the CAN frame read from left to right (B0 to B7), but exactly the other way around: B7 to B0. These eight bytes are therefore placed as one 64 bit word in the MXPGN sentence, most significant byte first. And then you will see that the last 16 bit word, 9F3B, is exactly the Raymarine manufacturer code in the first 11 bits, supplemented with the reserved field and the industry code in the last/highest three bits.
The pilot mode is then in the bold/red printed part:
FF02000000009F3B (standby)
FF02000000409F3B (car)
I did it this way because you don't have to buffer all the bytes in the receiving software. You can instantly read the payload from the string as a 64 bit hexadecimal number and map it directly to a packed structure that defines the individual fields.
This also makes manually reading a frame easier because you can cut the 64 bit word into pieces to read a 32 or 16 bit value, for example, without having to exchange the bytes first.
I hope it's clearer this way.
Great. Which means not everyone is encoding MXPGN the same.
And I have no way to know which is which
What’s really strange is that I have a ShipModule in my lab. I have not tried it in years, but I thought I had that all working…
I assume adding an option to specify the brand is not an easy implementation?
I’ll figure something out
And hopefully get something release in the next couple days…
ok, I have released a new canboajs that supports this
instructions for enabling in you Signal K here: https://github.com/canboat/canboatjs/pull/277
GitHub
feature: support little endian $MXPGN by sbender9 · Pull Request #2...
To enable this in Signal K, edit ~/.signalk/settings.json, add littleEndianMXPGN to your 0183 connection subOptions :
{
&quo...
&quo...
you'll neeed to force an updat to your signalk-server to get the new canboatjs
Thanks scott, the fix you made is working
just another question, which brand or company is generating the 'other' MXPGN sentence? Shipmodule is investigating what's going wrong.
B&G MFDs send it
Probably the rest of the Navico stuff too, but I’ve only verified the B&G