About the AutoTrackRaymarine Plugin

[wholybee]

Originally Posted by stevead

I'm sure Douwe will correct me if I am mistaken.

My understanding is that the plugin does not use the Raymarine Track Mode.

When OpenCPN is navigating to a waypoint or following a route, the plugin engages Auto mode, performs its own steering calculations based on bearing and xte values from OpenCPN and adjusts the heading accordingly.

It does not generate PGN's 129283 (XTE) or 129284 (Navigation) messages, which is why selecting Track mode on the autopilot control head generates the "No Navigation Data" error.

Ahh, that makes sense. I will have to test it while underway instead of at the dock then.

However, I still can't do that with OCPN crashing every 5 minutes. Tested on 3 different Laptops. No issues until the AutoTrackRaymarine plugin is enabled.

[Douwe Fokkema]

Originally Posted by wholybee

Ahh, that makes sense. I will have to test it while underway instead of at the dock then.

However, I still can't do that with OCPN crashing every 5 minutes. Tested on 3 different Laptops. No issues until the AutoTrackRaymarine plugin is enabled.

I have tested and used the AutoTrackRaymarine plugin on O5.9.1 using the Actisense NGT-1 controller for nmea2000 access on O. No problems, all works fine.

An easy way to test the AutoTrackRaymarine plugin at the dock is to just use the remote control function. Click "Auto" on the plugin screen, pilot should switch to auto, then "Standby" to switch to standby again. If this functions, communication with the pilot works. Your problem could be in the YD interface.

Regarding the crash, can you get me an opencpn.log file?

[Douwe Fokkema]

Besides this, to activate "Tracking" mode a route in OpenCPN must be active. The plugin will then steer to the active waypoint.
Do you also experience the crash of O with version 5.8.4? Or does it work fine there?

[wholybee]

Originally Posted by Douwe Fokkema

Besides this, to activate "Tracking" mode a route in OpenCPN must be active. The plugin will then steer to the active waypoint.
Do you also experience the crash of O with version 5.8.4? Or does it work fine there?

I am using the beta 5.9.1 that includes N2k via Ethernet. I suspect the issue is actually in the OCPN code relating to the Ethernet communication.

I am able to put the Autopilot in Auto or Standby with the plugin, so it probably works. I am just used to using the pilot with NMEA0183 where the head would go into track mode.

I can get the logs the next time I am at the boat.

[DukeOfAnkh]

Hi Douwe, Rick,

I tried to reproduce the issue, but all worked fine. However, i may have found a clue to what happened.
Please take a look at the attached picture. This is what happened:
Running in tracking mode to point A i activated the next waypoint B. Instead of getting a BTW to port and point B, i got a sharp turn to starboard to point X from where the BTW to B was picked up again.
So the BTW to next waypoint is calculated from the previous WP, resulting in an unexpected XTE, where i would expect the BTW to be calculated from the current position.

[Douwe Fokkema]

Originally Posted by DukeOfAnkh

Hi Douwe, Rick,

I tried to reproduce the issue, but all worked fine. However, i may have found a clue to what happened.
Please take a look at the attached picture. This is what happened:
Running in tracking mode to point A i activated the next waypoint B. Instead of getting a BTW to port and point B, i got a sharp turn to starboard to point X from where the BTW to B was picked up again.
So the BTW to next waypoint is calculated from the previous WP, resulting in an unexpected XTE, where i would expect the BTW to be calculated from the current position.

Very clever, this could indeed be the issue. However, this would mean the BTW is calculated from the previous WP to the active WP. But when I look at the calculations in O this is not the case, the BTW is always calculated from the current ship's position. But when a next WP is activated, the XTE may suddenly increase. This is because the XTE will be calculated relative to the new route segment, which may extend before the WP that was just passed. I have made a diagnostic version of the plugin with a lot of logging, Rick is now using this version and so will I coming days when sailing. Hopefully I can pinpoint the issue from this logging and verify Duke's idea.

Douwe

[Rick Welin]

Very clever observation Duke. And Douwe's analysis makes sense too. From memory, the side to which she wanted to turn was consistent with the extension line that Duke draws on his diagram.

I was supposed to cast off tomorrow but our buddy boat has issues, so I'm delayed by a few days waiting for them. But, I will be getting out this week for sure and have the logging version installed and ready to do some playing around. I'll keep an eye out for Duke's specific behavior too. I'll probably have logs for Douwe by the weekend.

Douwe it occurs to me that I should mention that I'm using the Yacht Devices YDNU-02 USB/SeaTalk Gateway as my interface. It appears to work flawlessly but you're better to determine that than I. (NOTE TO ALL: I'm using the very latest version of this unit which has new firmware to allow it work in this setup. Earlier versions likely do not work). https://www.yachtd.com/products/usb_gateway.html I don't suspect this device is to blame but best to share that information.

Douwe: Also note the YD developers say in their manual/documentation that they are happy and eager to work with third party developers to integrate products, and to offer their advice and input for free. (Hopefully not required and no expectation of you doing so).

[Douwe Fokkema]

The AutoTrackRaymarine plugin requires a magnetic variation. This is because the autopilot requires magnetic headings. Therefor the WMM plugin should always be enabled. Without the WMM plugin active, results may become unpredictable. In the next version of the AutoTrackRaymarine plugin I will build a check and a warning to activate WMM if not active.

It is also better to first activate a route in OpenCPN before setting the AutoTrackRaymarine plugin to tracking. In the other order proper startup may be difficult. In the next version I will disable the Tracking function if no route has been activated.

[Rick Welin]

Yes, Douwe did some troubleshooting from my logs off-list (thank you Douwe) and saw that OpenCPN was sending random variations sometimes 70 or 100 degrees off because I didnt have the WMM plug-in enabled. This could be the cause of my random issues. I will be testing tomorrow, and will follow up here.

With slow speed boats (7 knots here) this is not a big deal, but imagine a high speed craft at 30-50 knots randomly steering 15 degrees of rudder.

Not Douwe's fault. OpenCPN should not be issuing random numbers without a warning. At the very least it should display a warning on boot-up: "WHEN CONTROLLING AN AUTOPILOT THE WMM PLUGIN MUST BE ENABLED"

Douwe, on your next update is it possible to have AutoTrack run a check for WMM as well?

[Rick Welin]

Originally Posted by Rick Welin

Douwe, on your next update is it possible to have AutoTrack run a check for WMM as well?

Oops I misread.. Douwe already said he's planning to this

[Douwe Fokkema]

Originally Posted by Rick Welin

Y

Not Douwe's fault. OpenCPN should not be issuing random numbers without a warning.

Small correction, OpenCPN does not send random numbers for the variation when the variation is not available, it sends a value that is "not a number". There should be a check on that. When you enter a calculation with such a value, the result is undefined.

[Douwe Fokkema]

I checked the code of the AutoTrackRaymarine plugin, it is some years ago I made this. Currently there is a check on the validity of the variation. In case no variation is available the field "Heading" shows "no variation" and the field "Track" shows "nan". That means that in Rick's case there may have been another faulty source of the variation. This could be a chart plotter or any other device on the network transmitting variation data (YD?). Nevertheless activating WMM should cure this, at least I expect WMM to have priority in OpenCPN.

[Rick Welin]

Thanks Douwe, Good information. I'm just about to weigh anchor to return to port so I'll do some more testing today. I'll keep an eye out for No Variation notice as well.

Originally Posted by Douwe Fokkema

I checked the code of the AutoTrackRaymarine plugin, it is some years ago I made this. Currently there is a check on the validity of the variation. In case no variation is available the field "Heading" shows "no variation" and the field "Track" shows "nan". That means that in Rick's case there may have been another faulty source of the variation. This could be a chart plotter or any other device on the network transmitting variation data (YD?). Nevertheless activating WMM should cure this, at least I expect WMM to have priority in OpenCPN.

[Douwe Fokkema]

Originally Posted by Rick Welin

Thanks Douwe, Good information. I'm just about to weigh anchor to return to port so I'll do some more testing today. I'll keep an eye out for No Variation notice as well.

This is more complicated than I thought. I could not find in the manuals how the prioritizing of variation sources functions in O. But from the code it seems that WMM has no priority over nmea0183 or nmea2000 inputs. From your logfile I conclude that something is sending variation data to O. Variation values I saw are -105, 58, and 0 degrees. It is possible to set a default variation value in the opencpn.ini file, but this value is used with lowest priority. In your opencpn.ini file there is a line: PriorityVariation=nmea2000 COM5:204;127250| From this line I tend to conclude that the system is receiving (or has once received) variation data from a nmea2000 pgn 127250. I do not know which devices in your network are transmitting this sentence. But the Raymarine EV-1 does, may be also a plotter. On the P70 control head it is possible to set a variation value. But I do not know if the EV1 transmits this variation value to anyone on the network. And the received variation that I saw is varying, strange. You are using a YachtDevices YDNU-2, in theory also this device could generate errors, you never know.

[Rick Welin]

I've sent Douwe some more logs from my trip yesterday to verify, but I can say that AutoTrack seemed to perform properly on my trip back with the WMM plugin on. But we should wait for Douwe's assessment.