AIVDM, AIVDO and Own Ship GPS data

[rgleason]

Originally Posted by Tehani

There is already enough confusion with redundancy of position data, COG / SOG and satellites in NMEA2000 when simultaneously connecting GNSS and AIS receivers with position output, or when connecting multiple GPS to OpenCPN. This problem has already been discussed: "The ship jumps across the screen".
We add display issues for our boat if we process AIVDO.

My advice is that those users who have an old GPS receiver, it is better to retire it and directly use the output of that data from their AIS transponder.
Normally, AIS transponders have two NMEA0183 output channels, one of high speed 38400baud, and another standard 4800 through which GPS data compatible with the AP and plotter can be output.

This is just an idea, but maybe we should propose for OpenCPN to have a Settings > Connections option under

(Checkbox) "Use magnetic bearings in output ECAPB"
(Checkbox) "Include AIS own ship AIVDO sentence if available (default=no check)"

Which would allow everyone to configure it the way they would like, and have to default to have it off so there is no check?

Improvements and clarifications would be welcome. Then we'll make a Tracker to vote.

[Tehani]

Of course there are solutions, and several.
But I am wondering if it is not better to make things easier for the average user. And even guide him so that the configuration of his installation is the best possible ...

[Dsanduril]

These problems seem to crop up the most with position information, and that is understandable. We frequently have multiple position information sources feeding into OpenCPN. The "priority" function (IME, which is not extensive) does not seem to deal with them well. I could see two options:

a)Improve the priority function so that it is based on the contained data. Ignore duplicate data while passing through related data from the secondary source of it is not available from the primary (for example, primary provides position but not SOG/COG - not sure there's even a sentence that does that, but...).

b)Have OpenCPN, at least for position, make the selection automatically based on accuracy. Select the highest accuracy position report and use that. If things change, make sure they stay changed (15 seconds? 30 seconds? 60 seconds?) before failing over to a new, more accurate position. Maybe there are too many position reports that don't contain accuracy information and this wouldn't work?

[wingssail]

Originally Posted by Dsanduril

These problems seem to crop up the most with position information, and that is understandable. We frequently have multiple position information sources feeding into OpenCPN. The "priority" function (IME, which is not extensive) does not seem to deal with them well. I could see two options:

a)Improve the priority function so that it is based on the contained data. Ignore duplicate data while passing through related data from the secondary source of it is not available from the primary (for example, primary provides position but not SOG/COG - not sure there's even a sentence that does that, but...).

b)Have OpenCPN, at least for position, make the selection automatically based on accuracy. Select the highest accuracy position report and use that. If things change, make sure they stay changed (15 seconds? 30 seconds? 60 seconds?) before failing over to a new, more accurate position. Maybe there are too many position reports that don't contain accuracy information and this wouldn't work?

I'm just wondering why this is a problem, (two GPS sources causing position to jump around.) I've been watching mine do this since 2010 when I installed the AIS. It is slightly aggravating and if I was annoyed I'd turn one of them off on OpenCPN (they are not multiplexed, they are on separate com ports). But the difference is minor and I ignore it.

[Hakan]

Further discussion:

OCPN's connection priority is working fine BUT it's between the same NMEA sentences only.
A GNSS receiver can serve position info by different NMEA sentences like: RMA, RMC, GLL, GLC, GGA, GNS and also transformed by a AIS transponder to be included in AIVDO.
If I like to use the AIS device as the prime gadget for position I can set the priority to e.g. 2. My old GPS receiver is working so I want this as an automatic backup so the priority is set to a lower number, e.g. 1.
Now to get this automatic priority to work we need to receive the same sentences from both devises only.

So, if both the AIS and the GPS are sending GLL and GGA the priority will work just fine. But if the GPS device solely send RMC there will be no prioritization for that sentence and it will be used by OCPN. Possibly leading to a "jumping" position.
To solve this I've to filter out RMC from the GPS connection.

For the situation the AIS device is not serving GNSS sentences but only AIVDO there is no way OCPN can prioritize between the two devices. Instead I'd filter out AIVDO from the AIS connection and trust the GPS device for own ship position and then also receive satellite status information what's not included in the AIVDO sentence.

[wingssail]

Originally Posted by Hakan

Further discussion:

OCPN's connection priority is working fine BUT it's between the same NMEA sentences only.
A GNSS receiver can serve position info by different NMEA sentences like: RMA, RMC, GLL, GLC, GGA, GNS and also transformed by a AIS transponder to be included in AIVDO.
If I like to use the AIS device as the prime gadget for position I can set the priority to e.g. 2. My old GPS receiver is working so I want this as an automatic backup so the priority is set to a lower number, e.g. 1.
Now to get this automatic priority to work we need to receive the same sentences from both devises only.

So, if both the AIS and the GPS are sending GLL and GGA the priority will work just fine. But if the GPS device solely send RMC there will be no prioritization for that sentence and it will be used by OCPN. Possibly leading to a "jumping" position.
To solve this I've to filter out RMC from the GPS connection.

For the situation the AIS device is not serving GNSS sentences but only AIVDO there is no way OCPN can prioritize between the two devices. Instead I'd filter out AIVDO from the AIS connection and trust the GPS device for own ship position and then also receive satellite status information what's not included in the AIVDO sentence.

Frankly I don't see the problem, but anyhow, maybe it is the content which should be the subject of prioritization, not the NMEA sentence. Prioritze position data from GPS over AIS, not specific sentences.

[Dsanduril]

I suspect this kind of problem really depends on individual setup/configuration. Some people will observe the issue and others won't. For instance, if you have a 7-satellite signal with one GNSS device but only 3 or 4-satellite with the other (antenna placement, different GNSS systems, etc.), then the discrepancies in position may be bigger on your boat than others. For us it wasn't so much position (the boat didn't move around on screen much) it was SOG/COG, so the boat heading would jump around. Enough that it made use difficult.

Easy enough to filter out the duplicate data with the Connection configuration, but it would be nice to have a priority system that worked on the contained data rather than the NMEA sentences so that I could leave the secondary source connected and it would automatically take over in the event of a failure of the primary. Since the information has to get shoved into the ownboat information anyway it might be as simple as putting a timestamp and priority stamp on the information going into ownboat, then looking at new data, and if within a time window and lower priority not passing that to ownboat.

I'd guess that I see this question pop up once or twice a year here, so it does happen, but possibly not with enough frequency to make it a high priority.

[rgleason]

I'd guess that I see this question pop up once or twice a year here, so it does happen, but possibly not with enough frequency to make it a high priority.

There is a lot of experience and knowledge buried in those participating in this thread. Don't underestimate that. The regular user does not and will not have that knowledge. I think it would be better if the program simply worked, with the option that advanced users can adjust things. If that can happen automatically great, but to leave it the explaining to be in the manual or this thread and others is somewhat problematical because the question keeps getting asked.

[Tehani]

OpenCPN has a limited ability to select the best GPS / GNSS receiver.
Currently this limitation does not depend on the program itself, although something could be improved.

With the implementation of N2k in many installations, the gateway is the one who must perform this function, because redundancy can also occur on that bus, to which Ocpn does not have direct access.
The gateway has to associate the ID of each receiver with the quality sent in the PGN "GNSS data", and then filter with that criteria the COG / SOG rapid update, and POSITION rapid upsate sentences, in addition to the satellite information.

[Tehani]

In NMEA0183, GGA and GNS contain data quality information (HDOP). GLL, VTG, RMC, AIVDO don't have it.

[rgleason]

Thanks, I guess it's a maze, not worth addressing.

[stevead]

With the implementation of N2k in many installations, the gateway is the one who must perform this function, because redundancy can also occur on that bus, to which Ocpn does not have direct access.

From a TwoCan perspective, I've the following thoughts.

1. Provide an option to ignore position data generated by an AIS transponder. Simply determine the NMEA 2000 network address of the AIS device and not process PGN's 129025, 129029 etc. from that address.
2. If multiple GPS, or I should say GNSS, devices are present, both with valid data, just automagically select one with say for example the lowest network address.

If on the other hand there were multiple GPS devices, and you wanted to prefer one based on fix quality, such as fields present in PGN 129029, what criteria would be suggested ? Fix Method, Fix Integrity, Number of Satellites, Horizontal Dilution of Precision (HDOP), Position Dilution of Precision (PDOP), Geoidal Separation ?

Thoughts....

[Tehani]

Steve:
I have seen installations with AIS transponders that have their GPS antenna built into the device itself in the cockpit.
In these cases, the quality of GPS data is poor. Selection by high or low ID would not be correct.

Seatalk1, NMEA0183 and NMEA2000 have a common data to indicate the quality: HDOP. That data is what I compare in those 3 protocols (in all N0183 mux channels and inside N2k) to select the best receiver.

In this way, I am saving the HDOP of the active GNSS, and its ID within N2k (I also assign ID's to the other N0183 and Seatalk channels). Thus, I filter all non-active GNSS data by its ID, but I always look at its quality in case it is necessary to switch. I also set a reception timeout in case the active GNSS fails.

[rgleason]

"I have seen installations with AIS transponders that have their GPS antenna built into the device itself in the cockpit."

Vesper when w/o the external antennae?

[rgleason]

This seems like a very rational approach.

Tehani wrote;

"Seatalk1, NMEA0183 and NMEA2000 have a common data to indicate the quality: HDOP. That data is what I compare in those 3 protocols (in all N0183 mux channels and inside N2k) to select the best receiver.

In this way, I am saving the HDOP of the active GNSS, and its ID within N2k (I also assign ID's to the other N0183 and Seatalk channels). Thus, I filter all non-active GNSS data by its ID, but I always look at its quality in case it is necessary to switch. I also set a reception timeout in case the active GNSS fails."