Actisense NMEA 2000 & Autopilot Issues with Raspberry Pi Open CPN

[Tehani]

Going back to your first entry, I see that you say you have GPS data from an AIRMAR unit on the mast.
Simple GPS receivers rarely provide magnetic declination (variation) information. Conventional gateways (Yacht devices, Actisense, Ship Modul, ...) do not calculate this declination, in the same way that they do not calculate "set and drift". They just limit themselves to translating.
We can see if the declination data exists by looking at the RMC sentence in the NMEA debug screen in OpenCPN. Take a screenshot and show it.
In your case, the YDNU needs the declination to correctly generate the navigation PGNs. It is written in the manual.

J.L.

[SirChaunchy]

Originally Posted by Tehani

Going back to your first entry, I see that you say you have GPS data from an AIRMAR unit on the mast.
Simple GPS receivers rarely provide magnetic declination (variation) information. Conventional gateways (Yacht devices, Actisense, Ship Modul, ...) do not calculate this declination, in the same way that they do not calculate "set and drift". They just limit themselves to translating.
We can see if the declination data exists by looking at the RMC sentence in the NMEA debug screen in OpenCPN. Take a screenshot and show it.
In your case, the YDNU needs the declination to correctly generate the navigation PGNs. It is written in the manual.

J.L.

Tehani, Here is a screenshot I took of the NMEA Debug window yesterday showing the RMC sentence and others.

[SirChaunchy]

Originally Posted by Tehani

Yes, 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.



Suppose the problem is in the translation of PGN 129285 and 129291:
-129285 is "route /WP information". Its translation from RMB/APB is a bit confusing, and in fact not vital (Actisense NGW-1 doesn't even translate it). It basically contains the IDs and ASCII names of the route, or at least the route leg. I had to use Raymarine NMEA2000 captures to simulate something compatible. Your YDNU may not be doing it correctly, but I don't think that's the problem.
-129291 is "set and drift". Your pilot will probably read this PGN only when in "NO DRIFT" mode. Actisense NGW-1 generates it from VDR (NMEA0183), but OpenCPN does not send VDR. In any case, according to the documentation, your YDNU is not able to generate it.

Seeing all this, it is not possible that NGW-1 or YDNU is malfunctioning because they have many users of all brands of AP. Although I don't think it is because of this, since the loop problem has appeared when sending GGA/RMC, I suggest you check if your YDNU device is in "SILENT OFF" mode. In this mode it sends information to NMEA2000, otherwise it does not send it. Read chapter 5 and 11 of the YDNU manual to proceed.

If in spite of everything the NAV mode still does not work, the solution is much more complicated and involves directly analyzing the data in NMEA2000 with a logic analyzer, or with its YDNU in Raw mode.

Tehani, are you saying that I should put the YDNU in the "SILENT OFF" mode? I think it comes out of the box in the "AUTO" mode and I didn't do anything to change it. Next time I go to the boat I will look at the manual that came with it to see if I can tell which mode it's in.

[Tehani]

I believe the YDNU is in "SILENT OFF" mode from the factory. In any case, the fact that instability problems have appeared when putting GGA and RMC, suggests that the YDNU is sending data to NMEA2000.

I have not found precise information on the PGNs of the AIRMAR WeatherStation, I have only read that it sends position and COG/SOG. In NMEA2000 there is a PGN 129025 for position and a PGN 129026 for COG/SOG. The pilot needs the PGN 129029 (GNSS Position) and we do not know if the AIRMAR device also sends it, could you ask your supplier?

From what I see, OpenCPN has the declination (12,500E at the end of RMC), so you can try adding only RMC to the output sentences, since it is now filtered (colored red).
Do you have the WMM plugin installed? It would be interesting to know who is calculating the declination, because I doubt it is the WeatherStation.
J.L.

[Tehani]

Originally Posted by SirChaunchy

Tehani, Here is a screenshot I took of the NMEA Debug window yesterday showing the RMC sentence and others.

In any case, I think it will be better to do a full capture of a few seconds using the VDR plugin.
That way we will see everything that OpenCPN is receiving. If the AIRMAR sends the PGN 129029 that the AP needs, in the VDR file we will see input GGA or GNS sentences.

[rgleason]

Sir Chaunchy,
You've lucked out, JL is being a huge help. Regarding the VDR_pi (Voyage Data Plugin) which you will find in Options > PlugIns. First update the catalog and then install VDR, and then don't forget to check the "Enable" box, and Apply or close the Plugin listing. Two VDR icons will appear in the right hand Toolbar, one is for Recording and one for Playing. You want the Recording button and then you can "Create a file" by browsing to a Documents directory and then enter an appropriate file name and then hit "Save". The Recording will start, and only stop when you hit the record button again.

[Tehani]

Originally Posted by SirChaunchy

Yesterday I got the Yacht Devices USB Gateway YDNU-02 device that Rick recommended above and I took it to the boat today to test it out. I connected it to the NMEA 2000 backbone as directed in the pretty useful user's manual and plugged the USB cable into my RPi 4 and opened the "Serial App" included with Open Plotter. I created a "device" as a serial/dev/ttyACMO and declared the alias as ydnu and the data type as NMEA 2000. I then opened Open CPN 5.6.0, went to the Options window and created a "serial" connection using port /dev/ttyACMO and selected the baud rate of 230400...

I think this may be a cause of the problem.
The YDNU-02 communicates with OpenPlotter and OpenCPN on NMEA0183. Change the NMEA2000 data type to NMEA0183, because OpenPlotter may be sending NMEA2000 frames to the YDNU-02 on its NMEA0183 side..

In fact, you could directly use OpenCPN without the need for Openplotter. Fewer layers = less mess.

[SirChaunchy]

Originally Posted by Tehani

I think this may be a cause of the problem.
The YDNU-02 communicates with OpenPlotter and OpenCPN on NMEA0183. Change the NMEA2000 data type to NMEA0183, because OpenPlotter may be sending NMEA2000 frames to the YDNU-02 on its NMEA0183 side..

In fact, you could directly use OpenCPN without the need for Openplotter. Fewer layers = less mess.

It turns out I already had the VDR plugin on my Pi so I just had to enable it. I made short recordings with the data type=2000 and no RMC turned on in the connection, data type=0183 with RMC turned on, data type=0183 no RMC turned on. Unfortunately, all three of those recordings are too big to attach here, but I see that it's sending RMC data in all of those. I also took a picture of the NMEA debug window in the data type=2000 with the RMC off in the connection. I'm attaching that picture here. I took a similar picture with the RMC on and it did show that RMC was being transmitted (i.e., blue) but none of these settings including changing the data type to 0183 made the autopilot work. It still gives the autopilot data missing error. Although I wasn't able to attach the whole file, I took a screenshot of one page from the VDR data type=2000 no RMC so hope that helps.

[SirChaunchy]

Originally Posted by Tehani

I believe the YDNU is in "SILENT OFF" mode from the factory. In any case, the fact that instability problems have appeared when putting GGA and RMC, suggests that the YDNU is sending data to NMEA2000.

I have not found precise information on the PGNs of the AIRMAR WeatherStation, I have only read that it sends position and COG/SOG. In NMEA2000 there is a PGN 129025 for position and a PGN 129026 for COG/SOG. The pilot needs the PGN 129029 (GNSS Position) and we do not know if the AIRMAR device also sends it, could you ask your supplier?

From what I see, OpenCPN has the declination (12,500E at the end of RMC), so you can try adding only RMC to the output sentences, since it is now filtered (colored red).
Do you have the WMM plugin installed? It would be interesting to know who is calculating the declination, because I doubt it is the WeatherStation.
J.L.

Tehani, I plugged back in the Actisense NGT-1 which is connected as a CANBUS to SignalK and then went to the SignalK Databrowser. It shows I'm getting the following PGNs: 128267,130311, 130306,127257, 129026, 129029, 127250, 128275, 127258, 129025, 127251, 128259, and 127245

[stevead]

I've refrained for commenting on this thread for quite some time.

I personally think it is extremely unlikely that you will be able to control your Simrad AC-12 autopilot which uses NMEA 2000 by using NMEA 183 sentences (RMC, APB, XTE) generated by OpenCPN and converted to their NMEA 2000 equivalents with a gateway.

The PGN's your mentioned in your last post are all generated by the sensors on your boat:
128267 Depth
130311 Temperature/Humidity
130306 Wind
127257 Attitude
129025 Position (Rapid)
129026 COG/SOG (Rapid)
129029 GNSS Position
127250 Heading
128275 Distance Log
127258 Variation
127251 Rate of Turn
128259 Water Speed
127245 Rudder Angle

They are converted by either SignalK or by your Yacht Devices gateway into SignalK or NMEA 183 and consumed by OpenCPN. Other than Rudder Angle, none of these PGN's would be of interest to the AC-12.

What you need to capture are the NMEA 2000 messages, transmitted onto the network by the Yacht Devices gateway upon reception of XTE and APB sentences generated by OpenCPN.

As Tehani indicated, if you generate RMC sentences from OpenCPN, they will create a data loop when received & converted by the gateway. You also need to configure the Yacht Devices gateway to convert & transmit stuff onto the NMEA 2000 network. A good read of the user manual would be recommended.

To the best of my knowledge, at a bare minimum, the following PGN's may be required by the autopilot:
127237 Heading/Track Control
129283 Cross Track Error
129284 Navigation Data
in addition to any manufacturer proprietary PGN's.

Without seeing the NMEA 2000 output from the Yacht Devices gateway when it converts XTE and APB sentences it is impossible to tell whether they are being correctly converted and supply the necessary data for the AC-12.

What would personally be useful to me, is a capture of the NMEA 2000 network when you are using your B&G controller (I presume a Triton) to operate the autopilot. (Eg. On/Off/Standby, Heading/Wind/Nav mode and course corrections such as +/- 1 or 10 degrees).

Good luck.

[Tehani]

According to the Yacht Devices manual, the conversions from NMEA0183 to N2k are:
RMB:
129283 Cross Track Error
129284 Navigation Data
129285 Navigation — Route/WP information
XTE:
129283 Cross Track Error (Redundant if RMB is already used)
ABS:
129283 Cross Track Error (Redundant if RMB is already used)
Here, the APB translation is incomplete, but except for the perpendicular passed waypoint alarm, everything else matches the RMB content, so it is also unnecessary in all cases.

Thus, we can simplify the matter a bit, making OpenCPN only send RMB.
But Steve is right, we should compare what goes between a B&G plotter and an AC12 with what YDNU sends to NMEA2000/Simnet.

I did something like this with an Axiom and an Evolution pilot. The only intelligible PGNs were 129283, 129284 and 129285, but there were 2 more that were proprietary.
However, generating 129283, 129284 and 29285 was enough to get the AP Evolution working (With the latest software version of that AP, since there were also many problems at the beginning).

Steve, 127237 Heading/Track Control is sent by the pilot, not the navigator...

[Tehani]

Originally Posted by Tehani

ABS:
129283 Cross Track Error (Redundant if RMB is already used)
Here, the APB translation is incomplete, but except for the perpendicular passed waypoint alarm, everything else matches the RMB content, so it is also unnecessary in all cases.

Sorry, APB

[SirChaunchy]

Originally Posted by Tehani

According to the Yacht Devices manual, the conversions from NMEA0183 to N2k are:
RMB:
129283 Cross Track Error
129284 Navigation Data
129285 Navigation — Route/WP information
XTE:
129283 Cross Track Error (Redundant if RMB is already used)
ABS:
129283 Cross Track Error (Redundant if RMB is already used)
Here, the APB translation is incomplete, but except for the perpendicular passed waypoint alarm, everything else matches the RMB content, so it is also unnecessary in all cases.

Thus, we can simplify the matter a bit, making OpenCPN only send RMB.
But Steve is right, we should compare what goes between a B&G plotter and an AC12 with what YDNU sends to NMEA2000/Simnet.

I did something like this with an Axiom and an Evolution pilot. The only intelligible PGNs were 129283, 129284 and 129285, but there were 2 more that were proprietary.
However, generating 129283, 129284 and 29285 was enough to get the AP Evolution working (With the latest software version of that AP, since there were also many problems at the beginning).

Steve, 127237 Heading/Track Control is sent by the pilot, not the navigator...

Tehani and Steve,
Thank you for you latest inputs. I'm trying to digest them and research them now to see if I can figure out what to try next. I'm attaching a picture of page 36 of the AC-12 Autopilot Manual. It says that for Navigation the AC-12 needs PGNs 129283 (Cross Track Error), 129284 (Navigation Data), 129285 (NMEA Route Navigation & Waypoint Data), 129029 (GNSS Position Data), and 129291 (Set & Drift, rapid update). I'm not sure how to tell if those PGNs are going back across the YDNU-02 device to the NMEA backbone so the autopilot has access to them. Is the data going back across the YDNU from the Pi to the NMEA 2000 backbone included in the VDR recordings or just the data going from the backbone across the YDNU to the Pi?

[Tehani]

Originally Posted by SirChaunchy

Tehani, I plugged back in the Actisense NGT-1 which is connected as a CANBUS to SignalK and then went to the SignalK Databrowser. It shows I'm getting the following PGNs: 128267,130311, 130306,127257, 129026, 129029, 127250, 128275, 127258, 129025, 127251, 128259, and 127245

Well, one option would be to connect the NGT-1 to another PC to be able to see the traffic between the YDNU-02 placed on the Raspberry and Symnet. I guess that will require another Symnet cable...

But remember: Has the data type for the YDNU-02 connection in OpenPlotter already changed? It must be NMEA0183 and I think that may be the source of the problem.

[SirChaunchy]

It seems that PGN 129283 (Cross Track Error) is equivalent to APB and XTE, 129284 (Navigation Data) is equivalent to some combination of APB, BWC, BOD and BWW; 129285 (NMEA Route Navigation & Waypoint Data) didn't seem to have a direct equivalent but mostly is achieved with RMB which is a combination of PGNs 129283 and 129284, 129029 (GNSS Position Data) is a combination of GGA, GLL, RMC, and ZDA; and 129291 (Set & Drift, rapid update) is equivalent to VDR. Do I have all that right?