OpenCPN General

[rgleason]

Jose Louis,

I think you're point about GPS is very good, and I'm going to put a note about this under options > connections > filters so users can set some GPS filters, as Hakan has suggested.

Here is an idea: Perhaps OpenCpn should have an optional dedicated GPS filter to set a primary GPS satellite constellation and a secondary backup constellation, if there is not a good signal after 30 seconds?

However the implementation of this needs to be robust enough so that users don't get confused.
I think choices need to be based on real choices from the nmea data stream if possible.


Added a paragraph at the beginning.
https://opencpn.org/wiki/dokuwiki/do...nput_filtering

[rgleason]

Maybe the javascript plugin could provide a plugin that filters and sets a primary/backup GPS constellation connection?

[Hakan]

José..
Your observations are clear. My GNSS receiver sees about 40 satellites from five systems and consequently five groups of GSV messages within the same second.

The 4800 baud rate limitations are clear as well but still nothing OCPN can handle or control. O has to empty the serial buffer and process what's coming in. No problem with that. I we choose to not use GSV or GSA in OCPN it will not influence what's in the serial stream We still have to empty the serial buffer.
What's in the output form the GNSS receiver has to be set there. If the device is trying to send so much its serial buffer is choked I'll claim the control system in that device make a mistake. Often you can select at the device what to output to use 4800 or change to another baud rate.

[rgleason]

Originally Posted by rgleason

Maybe the javascript plugin could provide a plugin that filters and sets a primary/backup GPS constellation connection?

If there are additional suggestions and some affirmation following, I can add this as a Feature Request to Tracker.

[Hakan]

What's a "primary/backup GPS constellation connection" ?
Are you talking about the different GP/GA/GB/GI/GL/GQGSV messages? Then we're talking about the Dashboard "GPS Status" graph. I think we're generally interested in to see all used system. That's the system the GNSS receiver has identified. My suggestion is we show all received system in the graph with a 15 seconds view for each of them in a repeated sequence. Then everyone interested can study all satellite reception and make a picture of witch satellites the GNSS receiver has decided to use for the reported fix. I've a PR ready for next O release.

[Tehani]

The information provided by GSA / GSV is totally accessory. Rick, make no mistake, the GNSS receiver takes the best satellites for the solution, regardless of which constellation they belong to, and this has been said before: the user cannot choose. Right now I'm relying on HDOP to automatically switch the best receiving device when multiple receivers are connected to the system (NMEA2000, NMEA0183 on multiple channels + Wi-Fi and Seatalk), and the result is very satisfactory.
Hakan: Although Ocpn filters those statements, the sender has sent them, and therefore has taken time on the channel to send them, possibly delaying other more important data. Recall that unlike NMEA2000, NMEA0183 does not have a system to advance transmissions of the highest priority information.
The TOTAL amount of satellites used for the position calculation is indicated in the GGA and GNS sentences. When these 2 are preceded by GN (GNGGA or GNGNS) it means that the receiver is using more than one constellation, otherwise we will see a GP, GL or other identifier. In the case of GNGNS, we will also see a field 6 with more than one letter, indicating the calculation mode of each system (A: autonomous, D: differential, R: RTK fixed, F: RTK float, E: dead reckoning, N : no fix or limited). I believe that with the HDOP that GGA and GNS also provide, and the number of satellites used is sufficient to know the quality of reception.
Apart from the ID (GN, GL, ...), it is interesting to know the numbering range sent by the GNSS receiver to indicate the constellation within any GSA / GSV message, (Standard For Interfacing Marine Electronic Devices):
Satellite ID numbers. To avoid possible confusion caused by repetition of satellite ID numbers when using multiple satellite systems, the following convention has been adopted:
a) GPS satellites are identified by their PRN numbers, which range from 1 to 32.
b) The numbers 33-64 are reserved for WAAS satellites. The WAAS system PRN numbers are 120-138. The offset from NMEA WAAS SV ID to WAAS PRN number is 87. A WAAS PRN number of 120 minus 87 yields the SV ID of 33. The addition of 87 to the SV ID yields the
WAAS PRN number.
c) The numbers 65-96 are reserved for GLONASS satellites. GLONASS satellites are identified by 64 + satellite slot number. The slot numbers are 1 through 24 for the full GLONASS constellation of 24 satellites, this gives a range of 65 through 88. The numbers 89 through 96 are
available if slot numbers above 24 are allocated to on-orbit spares.

J.L.

[rgleason]

Hakan and Jose Louis,

I now understand there is no control of how much the GPS floods the nmea0183 bus, that control is with the receiver. Therefore I think Hakan suggestion makes some sense, over the primary/secondary filter that I suggested. However Jose Louis says the OcenNav devices are

"relying on HDOP to automatically switch the best receiving device when multiple receivers are connected to the system (NMEA2000, NMEA0183 on multiple channels + Wi-Fi and Seatalk), and the result is very satisfactory."

HDOP – horizontal dilution of precision

When using an OcenNav device I guess the best satellites are used from multiple constellations, and the others are dropped from Nmea2000 or Nmea0183.

In this case OpenCPN would see only the "best" GPS signals and the nmea0183 would not be cluttered.

Does some software selection by HDOP make sense? No, there is no control by Opencpn of the GPS signals coming from the receiver. That has to be done by the receiver!


Thanks.

[Tehani]

Each GPS / GNSS receiver connected to the boat system delivers the HDOP information within its GGA and / or GNS NMEA0183 messages. I have found cases where more than one receiver is connected to the same NMEA2000 bus sending logically redundant position data. (Some AIS send GPS information as well). PGN 129029 also contains the HDOP.

As each NMEA2000 device has an ID within the bus, I use the HDOP to validate the ID of the most precise device, and filter the information related to satellites, DOPs and residuals sent by devices with an ID not validated at all times. This is done simultaneously with the other buses: Seatalk and NMEA0183. The result is that no redundant information is forwarded, and that which is sent to Ocpn (and others) is the best.

Only when there is no GNSS in the system with valid HDOP or less than 50 meters (which is a lot today) for more than 5 seconds, the system triggers the "NO FIX" alarm.

The result greatly improves the cleanliness of communications. I think Ocpn could do something like this if it receives NMEA0183 multi-channel GPS data.

J.L.

[Hakan]

José..
Yes, no objections at all. And N2k I haven'' studied at all for this matter.
What I suggest is to let the GNSS status window, for NMEA 0183, show what we get.
For a "normal" user just connecting a rather new GNSS device to OCPN using NMEA0183 all position fix would be better due to more satellites for the GNSS receiver to choose from to make the position fix. And then use the talkerID "GN". But that info is mostly transparent for a general user. In this matters you're a interested specialist who have found tools to satisfaction. Very good.

For the general users i now suggest this if they are interested in the GNSS system used: https://github.com/OpenCPN/OpenCPN/pull/2159
Håkan

[Hakan]

José..
re: "The result greatly improves the cleanliness of communications. I think Ocpn could do something like this if it receives NMEA0183 multi-channel GPS data."
What do you mean with "multi-channel GPS data."? Is that several GPS only receiver connected to different ports?

[Tehani]

Originally Posted by Hakan

José..
re: "The result greatly improves the cleanliness of communications. I think Ocpn could do something like this if it receives NMEA0183 multi-channel GPS data."
What do you mean with "multi-channel GPS data."? Is that several GPS only receiver connected to different ports?

Yes, I am referring to this situation at all times. I'm sorry I didn't make it clear.
Nobody can choose a constellation of satellites for the calculation of the position. This is done internally by each GNSS receiving device.
What can be done is to select the best GNSS receiving device (of all those connected to the ship's system).
Many people still have Raymarine Raystar mushroom antennas, and at the same time have installed a state-of-the-art plotter and AIS. All three are forwarding the position through gateways to Ocpn.
Currently, the user can establish a static input filter (connections menu) to eliminate position sentences from a particular channel, and others that are not interesting. But I think that's not the best way.

[Hakan]

José..
Ok, now I understand you better.
I agree we so far don't have such a prioritizing system in OCPN. The best we can do is to decide who we trust the best and set a high prioritization flag accordingly in the Connections list. But a GNSS (GNRMC) and GPS only (GPRMC) mix of devices will not be handled in good way by that prioritization. Both will pass through.
Exiting future to develop?
Håkan

[Tehani]

Originally Posted by Hakan

But a GNSS (GNRMC) and GPS only (GPRMC) mix of devices will not be handled in good way by that prioritization. Both will pass through.
Håkan

Of course, that kind of filtering is not optimal.
Nor do I think it is important to pay attention only to the prefix of GGA or GNS: only if it is not Gx we could ignore the information completely.

I will try to explain it with two examples of logs found on this same website: One from the Pacific Regatta from San Francisco, and another from Southampton.
In both cases, the route drawing shows broken line segments, precisely if we use all the position data coming from the same NMEA0183 channel. And because?

a) In the first log (Pacific Cup), a talker appears as "M1" and another as "GP", the sentence sent by this talker with GPS information is $M1RMC, in addition to others referring to heading. In this case, M1 cannot be considered a valid talker, and therefore its information is ignored. What is really curious here is that $M1RMC contains magnetic declination information, and $GPRMC does not. Well, in this case, we can generate the declination using the WMM2020 model and forward a consistent and complete information as $GPRMC.

The GGA or GNS sentences do not appear in this log. Thus, if there is no other GNSS connected, the gateway, as a last resort, will forward RMC as long as this sentence says that it contains valid "A" data in the second data field, after UTC time, and adding the updated declination. (RMC contains the date).

b) Two talkers appear in the Southampton Log: II and GP. They contain redundant information from RMC, GGA, GLL (with 1.6-GP and 2-II HDOP), and then a variety of things that don't add more information: $ GPGBS, $ GPVTG, & GPZDA. It is almost certain that a NMEA GPS and a Seatalk Raystar are being used at the same time, and that the entire ST60 data is passed through a converter sending as talker II. (HDOP is rounded to 2 in Seatalk).

This is a disaster if we compare coordinates, because $ IIGLL contains 3 decimal digits and a 0.02 minute difference in latitude and longitude from $ GPGGA, which has 5 decimal digits. This is what produces the constant jump of the ship's position on the screen. In this log, & GPRMC does not contain declination either.

The solution to gain consistency is the same as for the previous case: Ignore the sentences $ IIRMC, $ IIGGA and $ IIGLL, and adding the updated declination WMM2020.

[Hakan]

José..
Good summery.

Talker.. Yes, so far OCPN take no response to any talkerID. (Next release will for the sentence GSV)
$IIRMC and more: I've a similar experience on my boat. The GPRMC is also connected to a Simrad IS15 system reflecting it back as IIRMC creating a jumping effect if not filtered out in OCPN. So for the Simrad OCPN input connection I filter out all sentences that contains a position.

[James_Armstrong]

Hello,
Does anyone know how to mirror my computer on to my iphone? Thank you.
Jim