Bug fixed in the dashboard. How to upload it ?

[Hakan]

Pierre..
I've put in your code and fed "SendSatInfoToAllInstruments" with the new talker. I also validated the talker is like: "Gx"
Works as expected. Nice.. See picture.
Would you push that to Github? (If trouble I can do it?)



Stevead..
Yes that's for sure the PGN's with that info.
Next step is to validate SK is handling path "navigation.gnss.satellitesInView" in the same way for SK data as for NMEA0183 data we have tested.
If you've N2K Signalk GNSS data to test I could pass a Win binary? (If you don't test this from source yourself?)

[Hakan]

All..
A historical view.
Before O 5.6 release the GNSS status instrument was updated to include source satellite system. At the time talker ID was not present as a SK path. Some discussions with the SK team took place but yield no direct result.
As I haven't noticed before the talker ID is now present as a part of the data source path. This is very welcome so thanks to the SK team and not less to Pierre recognizing this and made a proper action. Very good.


What's still to verify is to check the new talker behavior with pure SK data i.e. without a NMEA0183 parse as noticed at my previous post. Apart from running the new O code also a SK Data Browser check would do if anyone has a N2K GNSS receiver connected to SK. Is the talker present in a similar way as of the shot below?
(I'm using SK version 1.41)

[pmx]

Hi,
pull request sent.

Code is in the branch "FIX_Dashboard_SignalK_GPS".
(rebased on the current master tip, will merge without problem).

For those in a hurry, you can access my github here :
https://github.com/pmxy/OpenCPN.git

Pierre.

[pmx]

I don't see any NMEA2000 specific code in the dashboard code.

Is there a conversion from N2K to NMEA0183 in SignalK for the GPS data (including a $GxGSV message ?)
I'm new to SignalK....

Or is it necessary to decode the N2K codes in the source member (is easy to add by duplicating the code for NMEA0183).
A N2K GPS data file dump would be required.


Pierre.

[Hakan]

Originally Posted by pmx

I don't see any NMEA2000 specific code in the dashboard code.

Is there a conversion from N2K to NMEA0183 in SignalK for the GPS data (including a $GxGSV message ?)
I'm new to SignalK....

Or is it necessary to decode the N2K codes in the source member (is easy to add by duplicating the code for NMEA0183).
A N2K GPS data file dump would be required.


Pierre.

No... this is nothing for OCPN. (Hopefully!)
SignalK would use the same JSON path for all similar data. Whatever source they use it would result in the same path e.g. "navigation.gnss.satellitesInView".
My ask for a test of SK N2K data is just to verify the SK "talker" all time does according to our expectations.


Håkan

[pmx]

I had a look at the SignalK server code.

The N2K analyzer decodes the positions (PGN 129029), but not the PGN 129540 "GNSS Sats in View" .

I can't find details of the NMEA2000 messages online. Another non-free standard ?(freedom of access and cost).
Only found the message list
https://www.nmea.org/Assets/july%202...field_list.pdf

IMHO, the rignt way to address all problems,would be :

• Modify the "navigation.gnss.satellitesInView" UPDATE message to add a "gnsstype" member to the "values" data block.
  The schema is slightly modified.
• The NMEA0183 decoder in SignalK must be slightly modified.
• A N2K analyzer must be added to produce the corresponding "navigation.gnss.satellitesInView" message.
• This makes a unified message structure (not NMEA0183 based).

I'm pretty sure this discussion already took place in the past...

Indeed, this would make the current fix obsolete.

Pierre.

[pmx]

P.S. Adding an extra member in the "values" section doesn't disrupt existing codes (important !!!)

Pierre.

[pmx]

Hi,

as a test, I've been able to inset the GNSS type in the update messages.

I add a "gnss" member directly in the "values" section.
I choose to stick to the NMEA-0183 two letters code : GP, GL, etc...

This offers a way to expose the GNSS family independently of the NMEA0138 "talker" flag, which doesn't exist in the SignalK's NMEA2000 "source".

Changed only 3 lines of code in SignalK (no interference with the rest of the code).

This offers a template for compatible messages in a N2K "navigation.gnss.satellitesInView" generator (still to be developped).




Quick test within OpenCPN :





NOTE that another dashboard window ("GNSS in use", see the picture above) don't deal gracefully with multiple GNSS systems. It alternates randomly between the number of GPS or Glonass (in my case) satellite in use.

Pierre.

[Hakan]

Pierre..
SignalK development you've to discuss with the SK team. For example here: https://app.slack.com/client/T02ENM6QA/C02EMP1RF

NOTE that another dashboard window ("GNSS in use", see the picture above) don't deal gracefully with multiple GNSS systems. It alternates randomly between the number of GPS or Glonass (in my case) satellite in use.

Now you're mixing two different things with each other.
"GNSS in use" comes from the GNSS receiver reporting how many satellites they have used for the fix calculation. They don't tell which specific satellites are used for that. We can only hope they have used the "best" in the total mix having access to. In your example it could be 8 of GPS and 4 of Glonass or whatever constellation was the best for the moment. We don't know.
It's reported in e.g. the GGA message. If the fix calculation is based on several satellite system the talker shall be "GN" - GNGGA. The information if one or several satellite system are used for the calculation we don't report in OCPN.

[pmx]

Hi Håkan,

currently, the Dashboard code uses simultaneously (!!!) GGA and GSV to drive the "GNSS in use" instrument.

Here is what happens, every time the GPS receiver sends an update (for example, every second) :

1. The satellites in use number is extracted from GGA, and is sent to the instrument.
2. The satellites in view numbers is extracted from GSV for each GNSS family, i.e. GPS, Glonass, etc... and are sent to the instrument one after the other.

These various numbers are "flashing", one after the other, every second or so.
(Try it !)

As I said, this is a bit weird, even when there is only one GNSS system in use (i.e. old fashioned GPS only receiver).

Note that the GxGSA message is not used by the Dashboard.
GxGSA tells which individual satellites are actually used, and is sent from each GNSS system.

As I said, there is room for improvement here. This is a simple way for me to jump into the OpenCPN development.

Pierre.

[Hakan]

Pierre..
The prioritization should do so only one message is used for the same data.
For satellites in use it's called "mPriSatUsed".

Originally Posted by pmx

1. The satellites in use number is extracted from GGA, and is sent to the instrument.
2. The satellites in view numbers is extracted from GSV for each GNSS family, i.e. GPS, Glonass, etc... and are sent to the instrument one after the other.

GGA is preferred so has mPriSatUsed = 3
GSV, mPriSatUsed = 5, is used of no other are available. It's not good data for this but instead of NULL value if there are a lack of relevant data from connected instruments.
I don't know how you feed your system with GNSS data but for me it seems your receiver lacks GGA so we take what we got and use the (bad) GSV satellite count instead.

[stevead]

The NMEA 2000 stuff is kind of documented in either canboat (used by SignalK) or in the TwoCan plugin. I can't comment on SignalK, however TwoCan converts PGN 129029 & PGN 129540 to NMEA 183 GGA and GSV sentences respectively.

PGN 129540 has enough information to generate the "view of the sky", its fields include an array of satellites with prn, elevation, azimuth, snr and usage (used, tracked etc.) values.

The prn value values are allocated to the different GNSS systems (GPS, Galileleo, Glonass etc) so could be used to differentiate the different GNSS systems. Why not plot all satellites in use and differentiate the satellites from each of the GNSS systems with a different colour?

I don't know (nor have any interest) in whether SignalK does anything useful with PGN 129540.

On the other hand NMEA 183 is kind of limited in how it represents this stuff, it uses different talker id's to identify the GNSS system used for the position fix and the satellite numbers have different ranges of numbers to reflect the different GNSS Systems. (Hakan refer to the NMEA 183 v4.11 document I mentioned previously).

The only suggestion I shall make is if the SignalK schema does not contain a value for identifying the GNSS system in use, perhaps add one. But don't use string values that match the NMEA 183 talker id's (GP, GL etc.) as you have done already, rather use integer or enum values that match the NMEA 2000 PGN 129029 GNSS Type field. (Think of someone writing a program, easier to use a "switch" statement on the GNSS Type value, rather than a heap of "if else" statements using a string comparison operator). It would also allow the SignalK NMEA 193 parser to parse the talker id values to the correct GNSS Type value.

I don't think I have any NMEA 2000 logs where the position fixes used other GNSS Systems such as Glonass, Galileo.

[pmx]

Thanks for both replies.

Well, I have GGA, so.... mybe a bug in the prioritization system ?
This is a pert of the code I've not tried to understand until now.

EDIT : I checked a few things :
when OpenCPN use gpsd as a data source, the "GNSS in use" Dashboard instrument is feed by the following function :

dashboard_pi::SetPositionFix(PlugIn_Position_Fix &pfix)

which is triggered by the top pluging manager (as far as I can see).
No visible bug in this case : the display is OK, the individual GGA and GSV event messages are not used.

When using SignalK as a source, we have the behaviour I described earlier, and a flickering display.
The display is continuously triggered by all 3 competing events :

• dashboard_pi::SetPositionFix(PlugIn_Position_Fix &pfix)
• navigation.gnss.satellites event
• navigation.gnss.satellitesInView event

There is probably a bug in this part of the prioritization code ?

@stevead :

Concerning the usefulness of what I'm doing :
I've to admit that this is not essential functionalities, but this is a relatively easy starting point to plunge into a huge set of APIs and software intricacies.
And, BTW, I found this a bit problem annoying, so, in the pure Open Source philosophy, I tried to fix it.

As we say :

Use the source, Luke !

Pierre.

[pmx]

@tevead,

had a look at the two libs you suggested.
The only names are the fix-type (like: "GPS+SBAS/WAAS+GLONASS").
It is not clear whar SVN bumbering is used by NMEA-2000 to distinguish between GNSS systems.

In the NMEA-0183 seem to be some numbering collisions (was already said before).
Extract from a ublox manual :

[stevead]

The only names are the fix-type (like: "GPS+SBAS/WAAS+GLONASS").
It is not clear whar SVN numbering is used by NMEA-2000 to distinguish between GNSS systems.

Unfortunately I don't think I've any logs where the position fix is derived from other GNSS systems such as Glonass, Galileo etc.

PGN 129029 has a field (field 7) that indicates the GNSS Type. However without some sample data I don't know what values indicate other GNSS Systems. PGN 129540 which contains an array of the satellites in use including PRN may use the same numbering as for NMEA 183, but without sample data, again unable to verify. It might also use a bit map, eg high order 3 bits to define the GNSS Type and low order 5 bits to indicate the satellite id.

From a NMEA 183 perspective, I would expect that a GPS receiver will send multiple blocks of GSV sentences, each prefixed with the corresponding talker id to represent the different GNSS systems. But the fly in the ointment is if the GPS receiver generates a position fix using a combination of constellations, in which case the talker id is "GN". I think you may require a little more logic in the dashboard plugin to render each of the different GNSS satellites.

BTW, if I was to implement a "sky view" of the different GNSS constellations, I would want it to look like this.

Have fun...