Actisense NMEA 2000 & Autopilot Issues with Raspberry Pi Open CPN

[wholybee]

I've only skimmed through this thread and will report my autopilot experience. (It works)

First, I don't use Signal-K. It just seems to be an extra complication and I hardly understand why it exists. (there are a few use cases, but for 99% of everyone it seems to be unnecessary)

I have both a YDWG-02 and an Antisense NGW-1(NEMA2000->0183 converter)
I have a Raymarine autopilot, but I think this would apply to B&G as well.

Both are configured in OpenCPN with one as a backup to the other. Only one is enabled at a given time.

In OpenCPN I have output filtering set to transmit only RMB,RMC,APB
For the YDWG-02 I only had to set the server to both transmit and receive on the TCP port. I don't enable the proprietary Raymarine options.

The Actisense required a firmware update (it was several years old) and I had to enable several PGN's that were listed in the Raymarine manual using the Actisense software. Basically the NMEA2000 equivalents to RMB,RMC,APB. The Actisense doesn't support the proprietary Raymarine options, and works fine without them.

I have seen the "Autopilot data missing" error on the autopilot control head. I don't think I ever saw it will the YDWG-02, only with the Actisense before that was configured properly.

I also have a second NGW-1 in my navpod at the helm which I connect to a Garmin GPSMAP 78sc. I can use the garmin to run the autopilot as well.

As to why I need a backup, the YDWG-02 will crash after running about 2 days. It affects all devices connected to it (Tablet with Navionics etc) After crashing it requires a hard reset, and reconfiguring the whole thing. I began working with the Yacht Devices support, updated the firmware etc., but I just don't have the time right now, as I am sailing more often than not, approaching the end of my circumnavigation. And when I am on a passage and the thing dies, my priority is to re-establish navigation systems, not run diagnostics and pull logs. Maybe in 6 months when I am back in one place for a while...

[teppokurki]

I am quite late to the party, but as there is quite a bit of SK related confusion - I'll try to clear things up where and if I can.

SirChauncy: here's a rewrite of your original system description as I understand it, corrections are welcome.

Equipment on your NMEA2000 bus:
- Airmar Weatherstation: GPS, wind, humidity, etc (usually good idea to include the exact model, but doesn't really matter in this case)
- SIMRAD RS35 VHF radio
- SIMRAD AC-12 autopilot
- Actisense NGT-1 (usb)

Signal K is connected to the NMEA2000 bus via NGT-1. It is a serial devices (not socketcan / raw CANBUS like you wrote), and the connection type in Signal K is Actisense NGT-1 (canboatjs).

Signal K to OpenCPN connection is using the SK WebSocket connection, recognizable from the localhost:3000 parameter that you mentioned. This connection carries Signal K data, not NMEA0183. Up until very recently mapping from NMEA2000 to Signal K was missing "satellites in view", so even if O can display sats in view in SK data it was not being sent to O at all.

Data flows like so:

N2K Device 
=> N2K Bus 
=> NGT-1 
=> conversion to SK 
=> SK Server 
=> WebSocket 
=> OpenCPN

Now moving on to autopilot control. I'd like to make a distinction between autopilot control, steering data and AP/navigation computer discovery.

Autopilot control I define as being able to activate the AP and toggle between the different modes (standby, heading hold, steer to AWA, follow autopilot directions). This is typically done from an autopilot control unit or embedded buttons on a tiller pilot. Steering data on the other hand is what you need for 'I want to put a waypoint and give the "navigate to here" command and have the autopilot execute that command or have it follow an activated route' as you wrote: bearing and distance to the next waypoint from current position and from previous waypoint, cross track error and metadata like next waypoint name/id etc. Discovery is for example when an MFD sees a compatible autopilot on the NMEA2000 bus and autopilot control features are enabled on the MFD.

OpenCPN can produce steering data in NMEA0183 format, in APB sentence. Now one way to connect O to your AC-12 is to create a connection from O to SK (as described elsewhere in this thread) and configure SK server to produce the relevant PGNs on the N2K Bus.

OpenCPN
=> NMEA0183/UDP 
=> conversion to SK 
=> SK Server 
=> SignalK-to-NMEA2000 plugin 
=> NGT-1 
=> NMEA2000 Bus
=> AC-12

SignalK-to-NMEA2000 plugin today supports
- Cross Track Error (129283)
- Navigation Data (129284)
- (other PGNS not relevant here)

so this is incorrect:

However to the best of my knowledge, SignalK and the SignalK->NMEA 2000 plugin do not convert NMEA 183 APB, RMC or XTE sentences to their NMEA 2000 equivalents.

Additional conversions for PGNs supported by canboat are pretty easy to add, the code is pretty straightforward: https://github.com/SignalK/signalk-t...er/conversions

However manufacturers often rely not only on the shared PGNs for the basic data but "secret handshakes" between the autopilot and mfd for discovery, using propietary PGNs, as stevead already pointed out with "advertise itself (.... the myriad of proprietary Simrad NMEA 2000 messages) as a Simrad compatible autopilot computer display".

Stevead and Tehani have already covered the range of potential PGNs needed and how to figure this out (data capture whilst operating a "known good system", usually one with everything from one manufacturer). If things don't work just by "ticking the boxes" (= enabling relevant conversions per data flow above) there are some pieces missing, but figuring what exactly takes a bit of experience with this stuff.

There are other related endeavours, like https://github.com/htool/RaymarineAP...avicoAutoPilot that can "Emulate a Simrad AC12 autopilot to be recognized by a B&G MFD and translate bi-directional with a Raymarine S1 Seatalk1 autopilot behind a Seatalk->SeatalkNG converter.". Not a solution to the problem in OP, just sharing for others stumbling on this thread.

what has happened is that the GPS is on the NMEA2000 network, and by adding the GGA and RMC outputs in OpenCPN, you have created a data loop, which jams the NMEA2000 bus.

A small correction: I think the loop was between SK and O: O sending GPS data to SK, SK sending it back to O. Some of that could have spilled over to N2K bus, but Sk does not convert the data it sends to NK back so there is no loop mechanism in that direction.


rgleason: I don't think it is very productive to add content like https://opencpn.org/wiki/dokuwiki/do...gnalk:examples pretty blindly to the official documentation.
Firstly: there are factual errors in it - adding erroneous information to official O documentation increases confusion imho.
Secondly: it is not an "Integration Example". A running account of semi random steps to try if things would work is not one by my standards. How does this help the reader, when the end result was not a working configuration?
I'd be happy to provide assistance in proofreading SK related content. You know how to reach me.

I think that the advice to OP to get a commercial NMEA0183-N2K device was a good one. After all steering data should be a pretty well understood problem by now. But look at the trouble even there: one product's output is buggy and another is not yet compatible with M1 Macs (after 1.5 years of M1 being on the market).

Autopilots is something I wish we had better coverage in SK implementation.

[SirChaunchy]

Originally Posted by stevead

Great that you are narrowing down the problem.

If you could send the log file that would be wonderful, not that we can "fix" the Yacht Devices or Actisense gateways, but rather to better understand the data flows to the autopilot.

From my perspective, either email directly to twocanplugin at hotmail dot com or host the file on some cloud storage such as Google Drive, Drop Box, One Drive etc. and send a link.

Thanks.

Steavad, I sent the log file screenlog.0 to the e-mail address you provided above. Hopefully, the log file is useful. Please let me know if you receive it and if you need anything else from me.

[wholybee]

To help in understanding the required PGNs and to implement in SK.

I have attached 2 NMEA2000 CAN log files. Both are working configurations with OpenCPN, the first with the YDWG02 and the second with the Actisense NGW-1.

I use a Raymarine autopilot, but I don't believe proprietary PGNs are required for basic autopilot track mode.

* These are .txt files. You need to change the file extension from .doc to .txt

[SirChaunchy]

Teppokurki,
Thank you for your informative contribution to this thread. It's been very helpful to me in understanding the flow of data from the instruments to the NMEA-2000 backbone to the gateway device (either the Actisense NGT-1 or Yacht Devices YDNU-02) OpenCPN (either on my Raspberry Pi 4 or my M1 Mac) and then back to the backbone and to the autopilot or other devices. When I first had my boat built down in Chile, all of our instruments were NMEA-2000 based as was the SIMRAD Autopilot so it made sense to go with the NGT-1 because we had no need to convert anything to NMEA-0183. We were using Expedition as our navigation software and it worked with NMEA-2000 as well. The problem with Expedition was, it is a Windows only program and I'm running everything on a Mac. Consequently, I had to run Expedition through Parallels and then Windows and it was always a pain in the butt to get the radar to work with plugging and repulsing and starting and restarting until the program finally recognized the radar license. One very important goal has always been to get away from anything that has to run on Windows. OpenCPN does that and it has basically all of the functionality of Expedition and does some things better—especially the radar. The problem with Open CPN is that it only works with NMEA-0183. i have everything working on my Raspberry Pi4 and my M1 Mac now except as you say the "Steering Commands" so I can follow a route or put a waypoint and give the command "Navigate to this" As Tehani has pointed out to me numerous times, I could resolve my issues with the RPi simply by buying an NGW-1 to replace the NGT-1. Unfortunately, both the NGW-1 and NGT-1 use the same drivers and neither will work with my M1 Mac until new drivers are developed. So, if either Actisense develops new drivers or YD gets my YDNU-02 to properly translate the NMEA-183 sentences to the NMEA-2000 PGNs my AC-12 autopilot requires I should be in good shape. I want to use the RPi with OpenCPN as my primary navigation tool because of it's very low power consumption and my Mac with OpenCPN as my backup in case the RPi goes belly up while out to sea. So as multiple people have explained, and I believe them, the solution to my problem is probably just to buy the NGW-1 once they have new drivers and get on with it. Still, the allure of SK is interesting because the idea of having a server that can translate multiple languages for different age technologies and incorporate engine parameters, etc. is exciting. As verkerkbr has explained to me, I should be able to use the SK to NMEA-2000 to provide the right PGNs to my system, but when I go to that plugin I don'e see PGNs 129283, 129284, or 129285 there. You indicated that I could add these PGNs and gave https://github.com/SignalK/signalk-t...er/conversions as a web page that described the process. I went to that, but didn't see how to add those PGNs right off the bat. I'll need to study that a bit more.

Perhaps you can clarify a couple other points. You said, "Signal K is connected to the NMEA2000 bus via NGT-1. It is a serial devices (not socketcan / raw CANBUS like you wrote), and the connection type in Signal K is Actisense NGT-1 (canboatjs)." In the Serial Application in Open Plotter, however, I did press the button to "Make a CANBUS connection" or words to that effect. Is that what you mean when you say it is just a Actisense NGT-1 (canboatjs) connection? Also, I'm not sure I understand the concept of a WebSocket. Can you explain that a bit more—what's its function and what does it do?

Thanks again for your enlightening input.

[wholybee]

The YDWG-02 is working to steer my autopilot. I don't know how to decode PGN data, but maybe some can look at the logs I posted? I suspect the YDWG might not be the issue.

Regarding the NGW on a Mac. The version I have is nmea200 to nmea0183. Not USB, but nmea0183, RS422. That should work fine on a Mac with a Mac supported USB/RS422 adapter. A bit clunky, but that's how I do it on windows.

[teppokurki]

Originally Posted by wholybee

The YDWG-02 is working to steer my autopilot. I don't know how to decode PGN data, but maybe some can look at the logs I posted?

I put the decoded data at https://gist.github.com/tkurki/a62e2...92cbdb9709b1aa

[teppokurki]

Originally Posted by SirChaunchy

Perhaps you can clarify a couple other points. You said, "Signal K is connected to the NMEA2000 bus via NGT-1. It is a serial devices (not socketcan / raw CANBUS like you wrote), and the connection type in Signal K is Actisense NGT-1 (canboatjs)." In the Serial Application in Open Plotter, however, I did press the button to "Make a CANBUS connection" or words to that effect. Is that what you mean when you say it is just a Actisense NGT-1 (canboatjs) connection?

Oh right. OpenPlotter has its own utilities for configuring the connections and there it may very well be called like you recall. Signal K, OpenPlotter utilities and OpenCPN terminologies are not 100% same.

Originally Posted by SirChaunchy

Also, I'm not sure I understand the concept of a WebSocket. Can you explain that a bit more—what's its function and what does it do?

WebSocket is not really the key concept here. The fact that OpenCPN receives data as Signal K is relevant. Some of the issues that you are seeing, like not seeing NMEA0183 data in the debug window (because there is no data in NMEA0183 format in that connection) are direct results of using SK in the connection and full Signal K support still being work in progress in OpenCPN.

But as a concept WebSocket is a streaming mechanism for sending and receiving arbitrary messages. SK server sends data in Signal K format over to OpenCPN over the WS connection. A key feature of WebSockets, per its name is that web browsers can establish WebSocket connections. This is not relevant between SK server and O though.

[Tehani]

Originally Posted by wholybee

To help in understanding the required PGNs and to implement in SK.

I have attached 2 NMEA2000 CAN log files. Both are working configurations with OpenCPN, the first with the YDWG02 and the second with the Actisense NGW-1.

I use a Raymarine autopilot, but I don't believe proprietary PGNs are required for basic autopilot track mode.

* These are .txt files. You need to change the file extension from .doc to .txt

Here you can see the difference: Actisense is sending "Heading track control" with the heading to steer information and the other empty fields. YDWG02 does not send this information.

Teppo: See PGN 127237, Issuer ID 1 in your decrypted data file.

[stevead]

Well spotted JL.

Here is the comparison of PGN 127237:
Actisense Log

PGN: 127237, Source: 1, Destination: 255
Rudder Limit: 3
Heading Limit: 3
Track Limit: 3
Overide: 3
Steering Mode: 1
Turn Mode: 7
Heading Mode: 3
Rudder Direction 7
Rudder Angle: null
Heading To Steer: 218.233911
Track: null
Rudder Limit: null
Heading Limit: null
Turn Radius: null
Turn Rate: null
Off Track Limit: null
Vessel Heading: null

Yacht Devices:

Rudder Limit: 0
Heading Limit: 3
Track Limit: 3
Overide: 0
Steering Mode: 6
Turn Mode: 0
Heading Mode: 0
Rudder Direction 7
Rudder Angle: null
Heading To Steer: null
Track: null
Rudder Limit: null
Heading Limit: null
Turn Radius: null
Turn Rate: null
Off Track Limit: null
Vessel Heading: null

Essentially the yacht devices gateway is sending a "null" value for the heading to steer.

Sounds like they've acknowledged the fault and hopefully they will release a software update soon.

Not possessing a NMEA 2000 autopilot to play with, what intrigues me is how ,if at all the other fields are populated. In a NMEA 2000 network is that a function of the autopilot control head or computer?

Clearly if OpenCPN is providing the navigation information, APB, RMB & XTE sentences, then how would the Actisense or Yacht Devices gateways know how to populate the other fields ?

In anycase, thanks for the logs, even though it opens the pandora's box of proprietary PGN's!

[rgleason]

JL wrote below:

I am quite late to the party, but as there is quite a bit of SK related confusion - I'll try to clear things up where and if I can

Jose Luis I would like to fix the unhelpful documentation about Sir Chauncy. Should I just remove it?

[Tehani]

Originally Posted by rgleason

JL wrote below:

I am quite late to the party, but as there is quite a bit of SK related confusion - I'll try to clear things up where and if I can

Jose Luis I would like to fix the unhelpful documentation about Sir Chauncy. Should I just remove it?

Rick,

You can remove that page from the documentation:
https://opencpn.org/wiki/dokuwiki/do...gnalk:examples

Everything indicates that the problem is caused exclusively by the type of gateway. OpenCPN is not guilty of anything, nor can it solve it.

I just think one suggestion might be useful: From O's point of view, the basic sentence the AP needs is RMB (It already contains the XTE information). Only with that sentence most of AP already works.
If this is not enough, and especially if the pilot is Simrad / B&G with simnet, APB must be added so that the gateway adds the PGN "heading / track control).

[rgleason]

JL that page is gone now.
https://opencpn.org/wiki/dokuwiki/do...ftware:signalk


RE

Everything indicates that the problem is caused exclusively by the type of gateway. OpenCPN is not guilty of anything, nor can it solve it.

I just think one suggestion might be useful: From O's point of view, the basic sentence the AP needs is RMB (It already contains the XTE information). Only with that sentence most of AP already works.
If this is not enough, and especially if the pilot is Simrad / B&G with simnet, APB must be added so that the gateway adds the PGN "heading / track control).

Is there anywhere you think this should be put?

[Tehani]

Originally Posted by rgleason

Is there anywhere you think this should be put?

I think it may be ok in Connections -> NMEA output filtering. As advice to connect AP.

J.L.

[rgleason]

Added to end of this
https://opencpn.org/wiki/dokuwiki/do...tput_filtering