This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
On pypilot-provided heading information
#1
Ever since I translated my boat compass' heading into a nmea0183 message, the 'own boat' image in OpenCPN was flicking between two different adjacent headings, making it look wobbly, even at the berth. This freaked me out, because if my avatar is wobbly, what else is?

Long story short, it turns out that if opencpn cannot prioritize between HDM messages from two different sources, it uses both (typically slightly different) headings as they come in. This phenomenon has been dubbed 'source priority flip-flop'. Obviously, the second source of heading on my boat was pypilot, but how did it get into opencpn? The answer to this question gave me new insight that I'd like to share in a little narritive.

First, the orientation of the boat in opencpn comes from an external source of magnetic or true heading, like nmea HDM messages. I found out that VHW messages are ignored. If an external heading is not provided, instead the COG is used from RMC messages, that come from your typical gps device. These COG-derived headings are quite all right under sail, but extremely erractic at berth or anchor. In opencpn there's also an option to calculate SOG/COG from position changes, under options/ships/own ship, but I leave that one off.

Second, magnetic variation is involved. You could reckon that the 'own boat' is aligned with true heading, and that your compass provides magnetic heading. To calculate true from magnetic, you need to know local variation. If local variation is not provided, opencpn might fall back on the COG-derived heading and your avatar spins like mad again, even though you provided magnetic heading. Local variation might be provided by a nmea message (RMC or GLL), and if not, opencpn falls back on the local variation from its WMM plugin. So I understand now why it's always encouraged to have that plugin enabled.

Third, in the opencpn options/connections window you can set up a priority for each connection. My understanding was that this is primarily to be used to deal with system redundancy: e.g. if your primary gps source is available, use that data, but if it goes down, use the data from the secondary source. The opencpn manual also mentions this priority to be used to prevent data loops.

Now how did the pypilot data get in here? How does opencpn talk to pypilot anyway? The pypilot plugin talks directly to the data layer of your pypilot. This used to be called signalk but that has been renamed. This data layer connection merely provides the functionality of a rich remote user interface. This data layer connection is not used for nmea data between opencpn and pypilot. For that, there were always 2 options, and lately a 3rd option has been added.

Option 1 was the famous connection to port 20220. You had to output to this port, and when you did that right, your pypilot would magically enable the options to follow an opencpn track or wind. Those who decided to filter the output messages on this connection, to protect pypilot from being flooded, found out that pypilot was happy once it received RMC, APB and WMV messages.

Option 2 was the checkbox 'Forward NMEA' in the pypilot plugin configuration screen. If you checked this, the connection to 20220 was not needed. One-stop shop, no need to think.

Lesser known to me was that port 20220 on the pypilot not only accepts, but also provides data. You can see this if you start a telnet session to the port: you will see pitch, roll, and... heading messages. If you use option 1, a connection to port 20220, you can manage this stream of data with an input filter and input priority, or ignore it alltogether. However, the Forward NMEA option silently reads the pypilot provided information and lets OpenCPN use it. You don't see these messages in the nmea incoming messages screen. But they are there. So that was the eye-opener for me: once I had turned this option off, my boat avatar stopped wobbling, and I could finally lean back. To figure this out, the various gauges from the opencpn dashboard plugin were key.

So, knowing this is all you need to deal with it. There's no real case for adding prioritization functionality to the Forward NMEA feature. In the recently added Option 3 to provide operational data to pypilot, the Zeroconf SignalK functionality, the pypilot-provided heading is nicely tagged and visible in SignalK and can be prioritized there. I don't have this operational yet and I'm not sure if the wobbly boat could come back this way, but with this information you're on your way tackling it. Thanks for reading!
Reply
#2
you seem to have found out what is going on

If you have any suggestions to change how pypilot, the pypilot plugin, or opencpn handles this interaction to improve it would be helpful
Reply
#3
(2021-01-12, 12:02 AM)seandepagnier Wrote: you seem to have found out what is going on

If you have any suggestions to change how pypilot, the pypilot plugin, or opencpn handles this interaction to improve it would be helpful

Yeah it took me quite a while to figure it out, so I thought I'd share it. I love the modularity of it all and how it all fits together makes sense to me. If there's any improvements possible it would be documentation and release notes.

Only since you ask for it, I could imagine that the Forward NMEA functionality presents the incoming data in the nmea debug window, like the NmeaConverter plugin does, tagging its lines as '(virtual)'. This way it'd be self-explanatory. Or, in addition, have two check boxes, like ForwardNMEA and ImportNMEA, with one of those help buttons next to it. This all depends on the shift towards signalk, I guess. But I don't think nmea will be obsolete soon.
Reply
#4
the forward nmea was meant as a simple option to avoid making more connections if changing the pypilot or the network to it changes, but as you discovered it does not support filtering.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)