N2K -> ethernet gateway TX capability added

[bdbcat]

All...
Github master branch now contains ethernet-> N2k output (TX) capability.

Notes:
1. Officially supported gateways:
Yacht Devices YDEN-02
Actisense W2K-1
There may be additional code compatible gateways supported, but these two have been live-tested.

2. TX function is supported in NMEA2000 (N2K) mode only, and specifically not supported on N2K->N0183 conversion modes.

3. The gateways must be configured for interface data format using their internal Web interfaces (outside of OpenCPN) as follows:


Yacht Devices YDEN-02:
RX: NMEA2000 (RAW)
TX: NMEA2000 (RAW)


Actisense W2K-1
RX: any of ASCII RAW, ACTISENSE RAW, ASCII N2K, ACTISENSE N2K
OpenCPN autodetects the RX format configured, and adjusts the RX decoder appropriately.
TX: ASCII N2K only.


As you can see, the suggested data format for Actisense is ASCII N2K, and is recommended by Actisense. Indeed, the two "RAW" formats listed for Actisense formats are not publically documented by Actisense, and seem to be incompatible with Yacht Devices (RAW) format for TX operations, by actual test.

tl;dr; Use "ASCII N2K" format for Actisense.

4. For plugin devs, note:
The OpenCPN v18 API N2K TX interface has not been changed.
Existing plugins using this interface should "just work" with N2K<->Ethernet gateways, without need to consider the details of data format after configuration.

We will work closely with plugin devs to adapt to these devices as required.

Good Luck
Dave

[wholybee]

Originally Posted by bdbcat

All...
Github master branch now contains ethernet-> N2k output (TX) capability.

Notes:
1. Officially supported gateways:
Yacht Devices YDEN-02
Actisense W2K-1
There may be additional code compatible gateways supported, but these two have been live-tested.

2. TX function is supported in NMEA2000 (N2K) mode only, and specifically not supported on N2K->N0183 conversion modes.

3. The gateways must be configured for interface data format using their internal Web interfaces (outside of OpenCPN) as follows:


Yacht Devices YDEN-02:
RX: NMEA2000 (RAW)
TX: NMEA2000 (RAW)


Actisense W2K-1
RX: any of ASCII RAW, ACTISENSE RAW, ASCII N2K, ACTISENSE N2K
OpenCPN autodetects the RX format configured, and adjusts the RX decoder appropriately.
TX: ASCII N2K only.


As you can see, the suggested data format for Actisense is ASCII N2K, and is recommended by Actisense. Indeed, the two "RAW" formats listed for Actisense formats are not publically documented by Actisense, and seem to be incompatible with Yacht Devices (RAW) format for TX operations, by actual test.

tl;dr; Use "ASCII N2K" format for Actisense.

4. For plugin devs, note:
The OpenCPN v18 API N2K TX interface has not been changed.
Existing plugins using this interface should "just work" with N2K<->Ethernet gateways, without need to consider the details of data format after configuration.

We will work closely with plugin devs to adapt to these devices as required.

Good Luck
Dave

Thank you. This is huge. I will be testing soon.

[Hakan]

Dave.. All..
Is there a thought to implement general PGNs for AP, Auto Pilot, automatically sent by "Routeman::UpdateAutopilot() " as we do today for N0183 messages?
PGN:
129283 XTE
129284 Nav info
129285 WP info ?
I've no experience with N2k to AP but these three would hold necessary info?

Or are "all" N2k APs dependent on proprietary PGNs only?

[bdbcat]

Hakan...
PGNs for autopilot control:
A very good question. I am researching this now. I sent email to YD, etc.


Anyone with knowledge or experience in this question is encouraged to comment here.


Thanks
Dave

[stevead]

Some terminology.

Autopilot Control Unit (ACU). The device that electrically controls the tiller pilot/linear drive/hydraulic ram that turns the rudder.

Autopilot Control Head (CH). The Human Interface Device (HID) that sends commands to the ACU. In the past these used to be separate devices but now most modern MFD's also perform this function. Obviously this is a role for OpenCPN.

Each manufacturer uses proprietary PGN's sent by the CH to engage the ACU and set its mode of operation (eg. Standby, Compass Heading, GPS, Track, Wind Angle, No Drift) or to alter the heading, wind angle etc. These include PGN's 65359, 65360, 65379 (and use of 126208) for Raymarine, PGN's 65431, 65305, 130850 for Simrad/B&G, 126720 for Garmin, etc.

This is what Douwe's plugin & unreleased bits of TwoCan perform.

Standard PGN's are sent by a variety of devices/sensors and received by the ACU, calculations performed and used to physically control the rudder. These PGN's include 127250 (Heading), 130306 (Wind), 127245 (Rudder Angle).

In the case of GPS Track mode ie. following a route or steering to a waypoint, my observations of a Simrad AC-12 and B&G NAC-3 show that the CH sends PGN's 129283 (XTE) and 129284 (Navigation) to the ACU.

Note that my understanding of Douwe's plugin, is that it does not engage the ACU into GPS mode, rather it engages Compass Heading mode and the plugin performs the XTE calculations and sends heading adjustments.

Unreleased bits of TwoCan & TwoCanAutopilot construct PGN's 129283 & 129284 by aggregating data from XTE, APB, RMB sentences & SetPositionFixEx and monitors the OCPN_RTE & OCPN_WPT messages.

PGN 129285 (Route & Waypoint data) is usually sent by the CH and displayed on other instrument displays. It is not received by the ACU.

Have fun....

[wholybee]

stevead - Great information to know.

Something I will note. The Raymarine autopilot will not work in Heading Mode if XTE and Navigation data are present. You can engage and disengage the AP from the CH, but it will force into Track Mode. Stupid implementation on Raymarine's part. This has been a problem for me, as I like to have a route active in OpenCPN to monitor TTG etc., but to have the AP on Heading mode. The workaround is that I turn off transmit on the connection tab if I am not following a route.

I am not sure how it would respond with the AP receiving XTE and Navigation data if the plugin is sending heading adjustment data. I think the AP would ignore the heading data and follow the XTE data.

So, I'm not sure if routeman should automatically send autopilot navigation data. If that function is being moved to plugins, maybe that should be removed, or be an option that can be turned on/off? I do think that whatever functionally it has should be as close to the same as possible with 0183 and 2000.

I will try and play with various configurations soon. I am not on the boat presently. But, I am very excited to have n2k via ethernet/wifi now.

[s/v Jedi]

Originally Posted by wholybee

stevead - Great information to know.

Something I will note. The Raymarine autopilot will not work in Heading Mode if XTE and Navigation data are present. You can engage and disengage the AP from the CH, but it will force into Track Mode. Stupid implementation on Raymarine's part. This has been a problem for me, as I like to have a route active in OpenCPN to monitor TTG etc., but to have the AP on Heading mode. The workaround is that I turn off transmit on the connection tab if I am not following a route.

I am not sure how it would respond with the AP receiving XTE and Navigation data if the plugin is sending heading adjustment data. I think the AP would ignore the heading data and follow the XTE data.

So, I'm not sure if routeman should automatically send autopilot navigation data. If that function is being moved to plugins, maybe that should be removed, or be an option that can be turned on/off? I do think that whatever functionally it has should be as close to the same as possible with 0183 and 2000.

I will try and play with various configurations soon. I am not on the boat presently. But, I am very excited to have n2k via ethernet/wifi now.

You can fix this with the Yacht Devices n2k bridge. It allows you to program it.

[wholybee]

Originally Posted by s/v Jedi

You can fix this with the Yacht Devices n2k bridge. It allows you to program it.

I use the Yacht Device bridge (YDWG-02) What exactly will it do?

It will work either as a NMEA0183 to N2k converter, or as a simple n2k bridge which OCPN 5.9.x now supports. But in either case, if there is XTE navigation data present the autopilot will not work in heading mode.

The YDWG-02 does have a couple extra Raymarine specific features. Raymarine also has a stupid "Turn to waypoint" prompt everytime the autopilot reaches a waypoint and needs to turn to the next. The YDWG-02 will intercept that and press "Yes" for you. It can also optionally engage the autopilot automatically as soon as it receives navigation data. I don't use that because OCPN always sends navigation data if a route is active, and I don't want to be unable to turn off my autopilot.

[s/v Jedi]

Originally Posted by wholybee

I use the Yacht Device bridge (YDWG-02) What exactly will it do?

It will work either as a NMEA0183 to N2k converter, or as a simple n2k bridge which OCPN 5.9.x now supports. But in either case, if there is XTE navigation data present the autopilot will not work in heading mode.

The YDWG-02 does have a couple extra Raymarine specific features. Raymarine also has a stupid "Turn to waypoint" prompt everytime the autopilot reaches a waypoint and needs to turn to the next. The YDWG-02 will intercept that and press "Yes" for you. It can also optionally engage the autopilot automatically as soon as it receives navigation data. I don't use that because OCPN always sends navigation data if a route is active, and I don't want to be unable to turn off my autopilot.

No, that is a simple wifi bridge, you can’t program that and it can’t sit between the appliances. This is the n2k bridge: https://www.yachtd.com/products/nmea_bridge.html

[wholybee]

Originally Posted by s/v Jedi

No, that is a simple wifi bridge, you can’t program that and it can’t sit between the appliances. This is the n2k bridge: https://www.yachtd.com/products/nmea_bridge.html

Ah yes. Perhaps a bit complicated but I see how that would work. I do think the YDWG-02 does have some poorly documented filtering capabilities.

But it would be much easier to be able to turn off the transmission of the navigation data in OCPN because I don't want it forever turned off. I only want it turned off while I am not using it.

Actually, it would be best if Raymarine let me put the AP into heading mode when that is the function that I need.

[stevead]

Actually, it would be best if Raymarine let me put the AP into heading mode when that is the function that I need.

I think I can understand Raymarine's perverse logic.

Raymarine: If you've activated a route, surely you want me to follow the route !

Me: No. Don't think you're cleverer than me, just stay in Heading mode and follow the damn compass heading!

Conjures up an image of 2001: A Space Odyssey !

I am not sure how it would respond with the AP receiving XTE and Navigation data if the plugin is sending heading adjustment data.

There needs to be a simple option in OpenCPN to enable/disable sending Navigation Data (for NMEA 0183 XTE/APB/RMB sentences, for NMEA 2000 PGN's 129283 & 129284). If Douwe's plugin is following an Active Route, but calculating its own heading adjustments, then you don't want the Autopilot automatically switching from Compass Heading mode to GPS Track mode just because it detected navigation data.

[s/v Jedi]

Originally Posted by wholybee

Ah yes. Perhaps a bit complicated but I see how that would work. I do think the YDWG-02 does have some poorly documented filtering capabilities.

But it would be much easier to be able to turn off the transmission of the navigation data in OCPN because I don't want it forever turned off. I only want it turned off while I am not using it.

Actually, it would be best if Raymarine let me put the AP into heading mode when that is the function that I need.

Yes there’s many “would be bests” but they aren’t so I simply offered an option that works today. When you program something, you don’t turn it off permanently, you program when it should be off and when not.

[Hakan]

Thoughts:
If I activate a route the aim would be to be able to use my AP to steer the course to next WP. Corrected by XTE where appropriate. The ECxxx N0183 messages would then be TX:ed to output connections. The same would be valid for the two PGN 129283 (XTE) and 129284 (Nav info).
If I want my AP to use them I "tell" the AP to shift to (Nav/Track/ ..) -mode. That AP mode change would be done by a soft- or hard-ware push button on the control unit.
I wouldn't expect any AP to change mode without my interaction?

Any plugin, like Douwe's, controlling a AP would not use Nav/Track-mode but steer to heading and that heading is controlled by the plugin, by "custom sentence", instead of the control unit.
PGN 129283 and/or 129284 TX:ed to the N2k bus wouldn't disturb that process?

[s/v Jedi]

Apparently, Raymarine changes AP mode regardless of the operator choosing a different mode. Doesn’t surprise me with Raytheon being their mother. God knows what backdoors it has…

[wholybee]

Ok, I got a chance to briefly try it. I was only on the boat a few minutes and never left the slip, so unfortunately I don't have much troubleshooting information, but will try to get more this weekend if you need it.

I built and installed version 5.9.0-0+74b7bd2e3, a few days old by now. This was an upgrade over version 5.9.0-0+1095.a1e4818 that you posted earlier, which was itself an upgrade over 5.8.4. I plan a clean install next time I am at the boat.

I installed Douwe Fokkema's AutoTrack Raymarine plugin.

It worked sporadically. It did sometimes activate the autopilot when I pressed the Auto button in the plugin. But not always. In the NMEA debug window, I never saw any transmitted messages, seemingly even when pressing Auto actually worked and activated the AP.

The same behavior with the autopilot being forced into track mode when a route was activated occurred, which I expected. I would love to see a button on the active route window to toggle that on and off. (I might attempt this-no guarantees I'll be able too.)

Seemingly unrelated to the autopilot or the plugin, this version would hang after running for a short time. The longest it ever ran was about 10 minutes. The program would hang with a spinning circle for a minute or so before windows displayed a dialog that the program quit responding and offered to terminate it. Disabling OpenGL in opencpn.ini did not help, and I didn't have time to do further troubleshooting (disabling all plugins, etc.)

I understand 5.9 isn't ready for production, or even beta, so I don't expect it to work, but thought I would share my experience with the hang and offer what I can to troubleshoot it.

Thank you again for adding the Ethernet support.