Actisense NMEA 2000 & Autopilot Issues with Raspberry Pi Open CPN

[SirChaunchy]

Originally Posted by 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!

Steve,
Over the weekend I brought my RPi home and updated OpenCPN to 5.6.2 and updated the SignalK to the latest version as well. Yesterday, I took it back to the boat and ran some additional tests that I think are somewhat helpful. Signal K has a "Data Browser" that shows you what data is being received by the SK server. It also has a SK to NMEA 2000 converter plugin so you can send SK info back across a connection to the NMEA 2000 backbone where all my instruments and SIMRAD AC12 autopilot are connected.

I have two ways of connecting my NMEA 2000 backbone to the RPi. The first is my newly acquired Yacht Devices YDNU-02 and I have it connected straight to the RPi through a Serial Connection through /dev/ttyACMO. All of my instruments are NMEA 2000 and the YDNU-02 appears to convert everything to NMEA 0183 because in OpenCPN I do get the boat location, speed, wind, satellites, temperature, etc. and when I put a waypoint ahead of my boat, which is tied to the dock, and a bit off to the side and give the command "Navigate to Here", the OpenCPN debug window shows in blue that it's sending RMB, APB, and XTE sentences and yesterday I included RMC in the output filter just so I could see what was actually being sent. I added a connection UDP, localhost, port 2000 to send data to SK with those same filters and in SK made a connection to receive them.

When I went to the SK Data Browser window I could see the data in the attached excel spreadsheet. I had forgotten to take my phone to the boat so couldn't take a picture. There are many other pieces of data shown in the data browser, but the ones in the attached table are the relevant ones for what is being transmitted in the RMB, RMC, APB, and XTE sentences. I converted the angles that are listed in radians to degrees and measured the distance to the waypoint I told it to navigate to and those numbers are all correct. Some of them were changing as I was copying them down so those that should have been identical may differ by a tiny amount. Of particular interest is the last entry "steering.autopilot.target.headingMagnetic". Clearly OpenCPN on the RPi is sending that piece of information.

While I had the NMEA 2000 backbone connected to the RPi via the YDNU-02 through the /dev/ttyACM0 port and had the connection from OpenCPN to SK every time it sent out RMB, RMC, APB, and XTE sentences it showed in the debug window that it was sending them to both SK and back to the YDNU-02 so both of them were getting the same thing. This kind of confirms what you said in your previous post that, for some reason, it looks like the "steering.autopilot.target.headingMagnetic" part of the APB sentence isn't making it across the YDNU-02 and being translated to the appropriate PGN.

The 2nd method of attaching the NMEA 2000 backbone to the RPi is through my Actisense NGT-1 USB device which is an NMEA 2000 only device. It is connected to the RPi using the Open Plotter CANBUS program and clearly the SK server is getting all of the same information that it got from the YDNU-02 because when I go to the Data Browser, it's all there including how many satellites, etc. and when I put the same waypoint in the same location and command "Navigate to Here" the debug window shows it's sending out the RMB, RMC, APB, and XTE sentences and I can see in the SK Data Browser the same information. I was hoping that I could follow the advice of Wholybee and Bram and use the SK to NMEA 2000 converter to send PGNs 129283 and 129284 back across the NGT-1 to the NMEA 2000 backbone so they could be seen by the AP. These two PGNs are included in the latest update to SK but were not in my previous version. PGN 129285 is not yet included in the SK to NMEA 2000 converter in the latest version of SK. Unfortunately, I was not able to get that SK to NMEA 2000 connection to actually hook up to the NGT-1. I must not have something defined correctly, but I couldn't figure out what. The NGT-1 is connected to the /dev/ttyUSB0 port and I tried that as well as the alias, but neither worked.

I was able to get the SK to NMEA 2000 plugin to connect to the YDNU-02 through the /dev/ttyACM0 port but it didn't make the AP work when I gave the command "Navigate to Here" and pressed the NAV mode button on the AP controller. It still gave me the error, AP data missing error.

[pa391as]

Hello all, I've read this entire thread with interest, not only because I'm an avid O fan, but I too have been dealing with an AP control issue. I’m also an avid fan of the SteveA TwoCan and Engine Dashboard plugins.

My setup is as follows:

Sailboat: 1985 Hunter 34

NMEA2000 network:
Raymarine p70 Autopilot control head
Raymarine i70s Multi-Function Display
Raymarine ACU-200 Actuator Control Unit with Linear Drive
Raymarine EV-1 Course Computer Unit
Raymarine ITC5 Converter – sends Wind, Temp, Depth, Speed (traducer) data
Raymarine RS130 GPS
Noland Engineering RS11 Engine gateway (voltage, current, temp, pressure, RPM)
Fusion Marine AM/FM/XM
TouCAN Marine USB-to-CAN converter
Cantact – USB-to-CAN converter

Multiplexer: ShipModul Miniplex 3Wi-N2k

NMEA0183 network:
Standard Horizon CPF300i (Chart plotter with Fish finder) – transmits GNSS and NAV data, receives AIVDM data
Standard Horizon Matrix GX2200 VHF/AIS Receiver – receives GNSS data, transmits AIVDM data

Chart plotter: OpenCPN 5.6.2 running on Surface Pro tablet. Also use TimeZERO TZ Navigator on iPad
Wireless network: Verizon Mi-Fi, which serves as a hotspot for Internet connectivity, and a WiFi hub which connects the iPad, Miniplex, and Surface tablet running OpenCPN

For some time, I’ve wanted to control the Autopilot via wireless, i.e., sit in the cockpit or nav table, wirelessly send active routes to “Ray”. This never worked, but I’ve recently found some time to investigate. I was first able to get the CPF300i to “command Track mode” on the Raymarine AP. This works by configuring the CPF300i to send RMB and APB sentences output via Port3. Port3 is connected to Input 2 on the Miniplex. The Miniplex will take the inbound NMEA0183 RMB and APB sentences, convert them to the appropriate PGNs, and transmit on the NMEA2000 network. I found this to work quite well and consistently, with one problem. The CPF300i is hard mounted to the nav station and the screen with “nipple” mouse quite difficult to maneuver. The screen has low resolution and using the nipple navigate probably sounded like a fancy idea but fails in practice.

Anyway, with the knowledge that properly formatted NMEA0183 messages sent from a chart plotter, through the Miniplex, transmitted on the N2K network, would be accepted by the Raymarine AP and successfully command it into Track Mode, I figured doing the same from OpenCPN would be easy. Boy, that could not have been further from the truth.

Weeks of troubleshooting, along with excellent and prompt support from Meindert Sprang at ShipModul, finally resulted in success! Along the way, I upgrade the very old firmware code on all the Raymarine devices. This is not possible without a Raymarine chart plotter running Lighthouse software. The Axiom also came in handy to log NMEA2000 messages which can be accessed via a SD card. However, like all “easy software upgrades”, this was a challenge too. The engineers over at Raymarine long ago identified a bug that causes a “timeout” when upgrading the firmware, via proprietary N2K PGNs, on the EV-1, leaving it in a bricked state. This requires removing all devices from the n2k network, powering it directly instead of via the ACU-200, then placing only the Axiom and EV-1 on the wire. You also must make a quick trip to Walmart to fetch a SD card, because this procedure only works when the .iso file is on the SD card, won’t work with “online upgrade”. Once that was fixed (thanks to Joel @ Raymarine Tech Support), all Raymarine devices had the latest version of software.

Since I had a working chart plotter and knew that Track worked, it was a matter of comparing the n2k data stream when the route was coming from the CPF300i to that of OpenCPN. This is where SteveA’s TwoCan plug-in helped. I was able to use it to capture a raw NMEA2000 data stream so I could see what the Raymarine AP was seeing. Oh, one big detail I left out. Whenever I configured an active route on OpenCPN, then went to the AP control head and hit “Track”, it responded with “No Navigation Data”. What would have been nice if it had a verbose mode that explained exactly which piece of navigation data was missing. Oddly enough, I knew the AP was receiving some good navigation data because it displayed the DTW and BTW data on the i70s.

So, the question was “what information was the AP receiving that was insufficient to command Track mode”. Well, it turned out that it had nothing to do with the actual navigation data. I won’t hold you in suspense. The solution is that the Raymarine Autopilot examines the Class and Function information in the ISO Claim PGNs when each device registers on the network or updates its claim. Because the navigation data was sent, via Wi-Fi, from OpenCPN to the Miniplex, it was translated and sent to the n2k from an n2k interface called “Main”, as opposed to the “In2” (Input2) n2k interface. From the diagram below, you can see how Main is treated differently than In2 in the Device Type. Based on this selection, the Miniplex registers the interface differently on the n2k network, using a difference Class and Function designation, which – apparently – the Raymarine AP does not like. Simply setting Main = NMEA 0183 Gateway solved the issue completely!

There was nothing wrong with the data being sent, it was a constraint that Raymarine imposes on the identification of the sender of the navigation information.

So, if you’re seeing issues with commanding Track mode on your AP, check Address Claim Message PGN 60928, and make sure the Class and Function are set to whatever your AP will accept. For what it’s worth, NMEA0183 Gateway uses Class 25 and Function 135. It’s not clear to me why Raymarine even filters for this, and why they would accept from Function 135, but not from 130 (PC Gateway).

All these codes are listed in the ShipModul Miniplex documentation on page 107:

https://www.shipmodul.com/downloads/...x-3_3.9_EN.pdf

[hoolie]

Thanks for that! I'm about to set up my Raymarine AP with a similar system configuration. I second your appreciation of Meindert Sprang - he's very helpful!

[pa391as]

Conducted more testing this weekend, and confirmed that a known bug in OpenCPN 5.6.2 causes "No Navigation Data" when attempting Track mode from an active OpenCPN route on Raymarine AP. I learned that the NMEA2000 Claim Class/Function issue was a red herring, Raymarine confirmed they do not filter on this.

The bug and tested workaround is documented in this thread:

https://www.cruisersforum.com/forums...ml#post3641304

When the NMEAConverter workaround is used, Track mode works just fine.

I have a OpenCPN VDR file including wind, engine, and nav data if anyone is interested.

[SirChaunchy]

pa391as, As you saw in my original post, I had exactly the same problem as you but with a slightly different setup. I have a SIMRAD AC-12 autopilot and I get the same "no navigation data" error when I try to go to what you call the Track mode. I went to your link showing the switches that you made in the parameters, but exactly how do I get to those lines so I can make the changes to see if that change will work for me too? How do I get to the NMEAConvertor to make that change?

[pa391as]

hi SirChaunchy
following the data from source to target you’ll start by installing the NMEAConverter plugin and configuring the IIRMB sentence to reorder the waypoints as in the post. then goto the Connections tab and setup the outbound reject filter for ECRMB sentences. this assumes you have the default set for outbound sentences. if you are using a custom outbound prefix filter that xxRMB out. this will filter out the RMB sentence with misordered waypoints and allow the IIRMB through. then goto the NMEA output window and filter on RMB. you should see the ECRMB as red and the IIRMB as, I think, green or grey showing that’s it’s being output. next goto whatever system is converting your NMEA 0183 to N2K and try to observe that you’re seeing the inbound NMEA0183 IIRMB sentences. if everything is working properly your converter should be converting the incoming NMEAO183 messages to the appropriate NMEA 2000 PGN which are consumed by your AP.

most AP need only a properly formatted 129283 and 129284 PGN to enter track mode.

from your post it seems you’re having trouble configuring the NMEA Converter plugin correct ?

[pa391as]

why is SK in the picture? i’m not too familiar with the Actisense gateway but it appears to translate between n2k and nmea0183 via the serial USb interface correct
if that is the case take SK out of the picture and just create a Serial connection to the COM port exposed by the Actisense when plugged in.

make sure your Actisense is running the latest software and make sure it converts APB and RMB to 129283/84 n2k PGN

the satellites are populated by GSV and GSA sentences to make sure your Actisense converts those

[pa391as]

https://actisense.com/wp-content/upl...ease-notes.txt

looks like the NGT-1 supports conversion of all the sentences you need as long as you’re running the latest software.

[SirChaunchy]

Originally Posted by pa391as

hi SirChaunchy
following the data from source to target you’ll start by installing the NMEAConverter plugin and configuring the IIRMB sentence to reorder the waypoints as in the post. then goto the Connections tab and setup the outbound reject filter for ECRMB sentences. this assumes you have the default set for outbound sentences. if you are using a custom outbound prefix filter that xxRMB out. this will filter out the RMB sentence with misordered waypoints and allow the IIRMB through. then goto the NMEA output window and filter on RMB. you should see the ECRMB as red and the IIRMB as, I think, green or grey showing that’s it’s being output. next goto whatever system is converting your NMEA 0183 to N2K and try to observe that you’re seeing the inbound NMEA0183 IIRMB sentences. if everything is working properly your converter should be converting the incoming NMEAO183 messages to the appropriate NMEA 2000 PGN which are consumed by your AP.

most AP need only a properly formatted 129283 and 129284 PGN to enter track mode.

from your post it seems you’re having trouble configuring the NMEA Converter plugin correct ?

I was able to install the NMEA Converter plugin, but when I checked the "enable" box and hit the apply button etc., that plugin did not show up in the drop down menu where all of my other plugins show up. Do I have to open the NMEA Converter some other way, or should it automatically show up in my drop down?