OpenCPN General

[Hakan]

So, I got a thought:
If a label changes according to the talkerID at xxGSV message.

Would this make things clearer?

[P_Dub]

I agree, that should be like that. Many thanks.
Regards.

[rgleason]

Originally Posted by Hakan

Rick..
There's no real problem at all. My aim was only to show that different GNSS system works fine with OCPN as expected.
But if you'll like use the satellite status instrument, still named "GPS Status", you may need to filter the data input to avoid flicker.

Position is very stable so no "jumping".

Thanks Hakan, I added that.

[bgytr]

In the opencpn android app, where can I change the depth units to feet instead of meters?

[bcn]

Android the same as in desktop --> Options (the sprocket) from the tool bar
--> Display --> units

[CarCode]

Originally Posted by Hakan

So, I got a thought:
If a label changes according to the talkerID at xxGSV message.
Would this make things clearer?

Hakan
Thank you for your proposal. Finally one at all but will it solve the problem with modern and future GPS devices? I have e.g. a device which sends with 10 Hz and switches between the different GNSS sources within less a second as seen in the OpenCPN NMEA-Window.
u-blox has done some work into this task. See:
https://www.u-blox.com/sites/default...3004360%29.pdf
They call it MDA. Further informations are here:
https://scholar.google.de/scholar?q=...=1&oi=scholart
I have not read them all.
It might be the GNSS device can also be configured how to handle multiple GNSS sources as I have seen by the Juniper Geode device. After all if that should be implemented into OpenCPN a general way should be found.

[Hakan]

Gerhard..
The GNSS unit will send position messages as GNRMC, GNGGA etc. I. e. the talker GN is the specified way for the device to send position data when it's collected and put together from several GNSS sources. If only one source is used the talker would point to that, e.g. GP, GA etc.
If one GNSS device can be set to use one, two or more GNSS sources it's fine but nothing OCPN can control or react on. O will just use the received position reports like usual. Nothing to be changed there. O don't care about the TalkerID for position messages.

For the satellites report message GSV it's different. That can be used to indicate satellites seen from different sources like in my VDR example above. Our Dashboard instrument: "GPS Status" will follow that. So my suggest was to PR a patch to show the instant received GNSS system from the GSV sentence's talker. If sent in that way from the GNSS device. It's up to the manufacturer. Both way are supported in the standard.

[stevead]

Re the different satellite positioning systems, where the NMEA 0183 v4.11 standard has defined TalkerId's or each system and similarly the NMEA 2000 standard has defined an enum for some of the fix types (in brackets below), does anyone know what the corresponding enum values are for the newly defined systems ?

Galileo - GA (8)
BDS - GB
NavIC - GI
GLONASS - GL(1)
GNSS - GN
GPS - GP (0)
QZSS -GQ

Thanks.

BTW, Perhaps one way for OpenCPN to handle different satellite positioning systems, rather than filtering by TalkerId is to allow users to define a priority. It is now quite common for GPS receivers to track multiple satellite systems.

[Hakan]

Originally Posted by stevead

Re t
BTW, Perhaps one way for OpenCPN to handle different satellite positioning systems, rather than filtering by TalkerId is to allow users to define a priority. It is now quite common for GPS receivers to track multiple satellite systems.

Just to clarify..
OCPN can't handle or select how to use positions from different satellite system. It's the GNSS device doing that.


The only thing OCPN can have influence on is how the Dashboard instrument "GPS Status" is shown based on the NMEA message GSV.

[Hakan]

I agree it would be nice if we could select the used system by our self. But there we, OCPN, are in the hands of the GNSS device to react on deviant positions and possible sort that out.
As seen here things can happen everywhere so today's status with different system would be an advantage:
https://spectrum.ieee.org/aerospace/...arys-gps-tests

[CarCode]

I second the proposal of stevead and it does not help to describe the actual status of OpenCPN. In my opinion OpenCPN should be updated for this. Fortunately we have more GNSS systems available today and european people does not trust the US the same way anymore then 4 years before.
BTW it is not the GNSS device which dictates the GPS system to use, perhaps for a smartphone but not for a standalone multiple GPS receiver.

[Hakan]

Gerhard..
What in OCPN would be updated, apart from the GSV message?
Do you have an example of positions from a GNSS device that is sending position reports from different GNSS without using the talkerID GN?
There would be GNSS devices where you can set what GNSS system to use. But it's still controlled by the GNSS device and not the receiver? BTW is there only one GPS system to use, or?

[bcn]

Take into consideration that the numbers of satellites in sight (total, from different constellations) is possibly not the most important quality factor for positioning anymore.
There are GNSS sensors that will pick just the five or six sats with the best signal to achieve their optimal solution.


Nevertheless the bar graph indicator can help to identify a situation where one has issues with reception. Bad antenna, some broken cable etc. Therefore it shall show all sats in view, not just the G(P)S ones.

[Hakan]

Originally Posted by bcn

Take into consideration that the numbers of satellites in sight (total, from different constellations) is possibly not the most important quality factor for positioning anymore.
There are GNSS sensors that will pick just the five or six sats with the best signal to achieve their optimal solution.

Yes and and according to the NMEA spec they use the talker GN in that case. This is not a problem and we, OCPN, don't need to care what satellites are used as long we get a proper position.

Nevertheless the bar graph indicator can help to identify a situation where one has issues with reception. Bad antenna, some broken cable etc. Therefore it shall show all sats in view, not just the G(P)S ones.

Yes that could sometimes be a help. And we, OCPN, are viewing all kind of satellites the GNSS device reports in the GSV message. The GNSS device transmits one satellite system info per GSV messages in a repetitive sequence. The bar graph, now called "GPS Status" (Would be changed to "GNSS Status"), is reflecting that sequence. (See below link for a VDR record).
A simple code change to reflect that sequence is to show actual GNSS system in the bar graph. Then it will look as of my little video linked below. It's a fast changing process not very clear but still there. See also here: https://www.cruisersforum.com/forums...ml#post3325188
So far I think clarifying the viewed GNSS system in the bar graph, as of the video, will be sufficient for our needs, even though slightly "jumping"?
If we need more than that it's a more elementary code change. For example:
- One status bar graph for each possible satellite system. (Unpractical?)
- Just show the 12 best in terms of SNR, signal to noise ratio. That means we have to construct a data base to collect and sort what's in the different received GSV messages since the last minute or so. Including a time reference to clear out what's old. (more than two minutes?) Then we also have to indicate on each bar what system it belongs to. This may be nice and doable but starts to grow more than the practical use, if you ask me.

The code change for the simple solution showed in the linked video is ready for a PR now.
Thoughts?

Håkan

Links:
A VDR where different satellite system are used: https://www.dropbox.com/s/ilfzsp6uj5...ystem.txt?dl=1
A video of above VDR when sat system designations are used: https://www.dropbox.com/s/pyurmstt2s...tatus.mp4?dl=1

[Tehani]

I want to raise a reflection on the influence on communications performance when using GSA / GSV.
As I have analyzed using UBLOX-M8N, this receiver optionally sends these sentences every second. When there is a significant number of satellites in view, this information occupies a lot of time in communication channels. This is a real example:
GSV (sats in view): GPS: 14, GLONASS: 9, this is 2 GSA sentences (one for each system), 4 GSV sentences (of more than 70 bytes each) for the GPS constellation, and 3 more GSV sentences for the GLONASS constellation. The maximum accepted number of GSV sentences for each constellation is 9 (NMEA association Documentation).
If we think that it can also receive from Galileo and Beydou systems, we can already easily deduce that important navigation data can be delayed or even disappear.
In conclusion, it does not seem reasonable to me to use this information outside the environment of the GPS receiver itself, especially if we are using a standard NMEA0183 speed (4800 baud).

José Luis.