Bug fixed in the dashboard. How to upload it ?

[pmx]

Hi all,

the GNSS status view (GPS constellation map) of the default dashboard doesn't work with SignalK.
I found that a bit annoying. In fact, apparently this part of the code was never completed.

I installed OpenCPN on RPI 4 for the first time a week ago.
First using the (sightly outdated) Openplotter image, but quickly switched to using a fresh Raspbian image (because it is a real pain to gather the required lib s in the correct and latest versions via the Buster repositories).

As an "execise", I plunged into SignalK concepts and the OpenCPN 5.6 source code to correct the SignalK problem.

I corrected the (slightly) unfinished code : the "talker" field was not extracted from the SignalK stream.

Now, when using a GPS via SignalK, the Status view correctly displays alternatively each GNSS system constellation, in my case GPS then . (I renumbered the Glonass SVs from the 64...96 range to the 1...32 range, but this is optional).

All work is in a separate git branch on my SD card.
What is the process for review, validation, inclusion in the main repo ?

Note that the GNSS status view of the "dashboard_tactics_pi "plugin doesn't work with SignalK, too. I had a look at the code (this is a strip down version of the original dashboard GNSS view).
P.S. How to change the minimum width of the dashboard, I would like to make it as narrow (or less) than the "dashboard tactics" plugin ?



Pierre.

[bdbcat]

pmx....
Sounds like nice work.


"What is the process for review, validation, inclusion in the main repo ?"


Post a Pull Request to the original repo of the plugin. The plugin author/packager/maintainer will review, with comments from others, and thus begin the process of merging and inclusion in Release.


Thanks in advance for the code.


Dave

[Hakan]

pmx..
The talker ID was not parsed and reported by SignalK and thus not used by OCPN Dashboard. A long discussion by the SK team has so far not concluded.

If you used satellite numbers to separate it sounds interesting although some satellite system use the same number. Please do follow Dave's advice.

[pmx]

Hi Hakan,

in fact, in SignalK, the "talker" ID is available in the "source" member of the "update" message, not in the "values" member.

This is as per the (sparse !!!) documentation on the SignalK server.

Originally, only "values" was treated in the code, to extract the actual satellites status data..

The "sources" are also visible on the local SignalK server page at : Yacht Blogs - Create a free yacht or sailing blog
(bottom of the page, "Sources" section).

My first attempt was actually based on the GPS numbers, but it was only a hack.
(NMEA usually translates GLONASS SVN in the 65...96 range, and SBAS SVN above 128)

But GALLILEO would not be differentiated from GPS (AFAIK).
(Can't check this, as I don't seem to receive GALLILEO, although my tiny uBlox GPS receiver is supposed to (????)
Also, my GPS is on my balcony, in a city surrounded by the snowy French Alps mountains.

[bcn]

In the GSV (and other GNSS messages) the talker ID should indicate the constellation
GP - GPS
GL - GLONASS
GA - Galileo
The corresponding valid satellite IDs are
GP --> 1-32 Sats, 33-64 SBAS
GL --> 33-64 SBAS, 65-96 Sats
GA --> 1-36 Sats, 37-64 SBAS
If there is no TalkerID or none corresponding to the constellations, then you will have a mix up in the cases of GPS and Galileo. Quite messy...

[Hakan]

[QUOTE=pmx;3574961]Hi Hakan,

You're correct! It's actually there. We and the SK team may have talked around each others.
So we just need to catch the "source" in the update stream. We may not need to check the "sources" stream it's in the "vessels" (updates) as well. Although not direct but as the $source":"blueconv.GP" See the raw data extract below for the GSV values.


So the member "$source" would be includet in "value" so easy to catch.
Then we just have to extract the talker, here "GP" from e.g. "blueconv.GP"
Would be worth a test. I could try in the coming days. Or did you already tested something?

Dave.. thoughts


Raw data stream:
"gnss":{"satellitesInView":{"meta":{},"value":{"co unt":11,"satellites":[{"id":2,"elevation":0.6632251159092791,"azimuth":1 .0297442589117756,"SNR":34},{"id":26,"elevation":0 .38397243552642474,"azimuth":4.991641661843522,"SN R":35},{"id":6,"elevation":0.087266462619642,"azim uth":0.4537856056221383,"SNR":33},{"id":20,"elevat ion":0.24434609533499757,"azimuth":1.4660765720099 855,"SNR":34},{"id":25,"elevation":1.0821041364835 606,"azimuth":2.1293016879192646,"SNR":41},{"id":1 8,"elevation":0.087266462619642,"azimuth":3.141592 6543071118,"SNR":0},{"id":4,"elevation":0.17453292 5239284,"azimuth":6.003932628231369,"SNR":30},{"id ":12,"elevation":0.43633231309820997,"azimuth":1.8 84955592584267,"SNR":36},{"id":29,"elevation":1.25 66370617228446,"azimuth":3.4906585047856797,"SNR": 43},{"id":31,"elevation":0.9424777962921335,"azimu th":4.694935688936739,"SNR":39},{"id":22,"elevatio n":0.24434609533499757,"azimuth":4.328416545934242 5,"SNR":31}]},"$source":"blueconv.GP","timestamp":"2022-02-15T15:14:47.633Z","sentence":"GSV"}}

[pmx]

Hi,

the raw data show exactly what I said : "source" is sent along the "value" member, not into it.

@bn
the SVN renumbering seems to be manufacturer dependent ? (apparently, SBAS renumbering is different in uBlox - can't test it, thought).

[bcn]

That was citing from IEC 61162-1:2016.
Manufacturers wrangling how to get this straight or in line with previous versions of their software is obviously a hard or impossible task.

[pmx]

@Dave,
The "source" member in your exemple is "$blueconv.GP", while I have a separate "talker" sub-member (in this cas, it would be set to "GP").
is it an unparsed raw data ?

I use SignalK version 1.4.2., installed via the Openplotter tool (over a clean Raspbian bullseye 32 bits).

BTW, what is "blueconv" ?

[pmx]

@bcn,

thanks for the clarification !

Pierre.

[Hakan]

pmx..
re: "source" is sent along the "value"
Yes correct. But still along the self (path) data and not in the list "sources" further down.
The item "$source" is within the path "navigation.gnss.satellitesInView" where GSV values are so that must be connected and the right time.

Now I'm trying to catch the value in $source but no luck so far. I may need some help. So far testing different ways like: source = item["$source"].AsString();

My programming skills are limited so it can take some time.

re: blueconv is the "Serials" nickname for the RS232-USB converter where the GNSS receiver is connected. So the $source value says: this data is from the serial connection "blueconv" and the Talker is "GP" (blueconv.GP)

It may be the path is different when originating from SK and not NMEA0183-SK parser?
How is the raw data from your server if you've SK(Nk2?) data for "navigation.gnss.satellitesInView"?

[pmx]

Originally Posted by Hakan

pmx..
Now I'm trying to catch the value in $source but no luck so far. I may need some help. So far testing different ways like: source = item["$source"].AsString();

What is your version of SgnalK ?
I suspect that in the past the "talker" part was not decoded, hence the missing feature in the dashboard. (There a is a comment in the original code that I didn't really understood, at first, but which would make sense if this is the case).

I'm using a very recent 1.4.2 version (latest version is 1.4.3).
Version can be found in the footer of the SignalK Server pages.

Version is displayed in the footer og the SignalK server page.

Originally Posted by Hakan

It may be the path is different when originating from SK and not NMEA0183-SK parser?
How is the raw data from your server if you've SK(Nk2?) data for "navigation.gnss.satellitesInView"?

I tested both with the GPS souce connected directly (serial), as you do, and via gpsd.
Same resut (works).

Here is the code snipet I added in dashboard_pi.cpp to get the talker ID.
This function is called on all UPDATE messages, before analyze of the path (i.e. not just on navigation.gnss.satellitesInView).

void dashboard_pi::handleSKUpdate(wxJSONValue &update) {
  wxString sfixtime = "";

  if (update.HasMember("timestamp")) {
    sfixtime = update["timestamp"].AsString();
  }

  if (update.HasMember("values") && update["values"].IsArray() ) {
        wxString talker = "";
        if (update.HasMember("source")) {
            if (update["source"].HasMember("talker")) {
                if (update["source"]["talker"].IsString()) {
                    talker = update["source"]["talker"].AsString();
                }
            }
        }

    for (int j = 0; j < update["values"].Size(); ++j) {
      wxJSONValue &item = update["values"][j];
      updateSKItem(item, talker, sfixtime);
    }
  }
}

I modified the updateSKItem(item, talker, sfixtime); function to transmit the talker ID along the data ("value[i]") and the timestamp.
Then, in fact, every instrument / client code will receive the talker ID associated with the data block, but here, only the GPS status instrument will use it.

I knew nothing about SignalK and very little about Json, but there are no difficulties here.

NOW : NMEA2000 "talker" seem to have a different meaning, so... ?? I don't have any NMEA2000 instrument.

Anyways, I will upload the code soon, but as I've not cloned the source code in my github (cloned directly via git), so I will have to switch to github and reconfigure my local git repo before I can issue a pull request.

[emilecantin]

Originally Posted by pmx

Anyways, I will upload the code soon, but as I've not cloned the source code in my github (cloned directly via git), so I will have to switch to github and reconfigure my local git repo before I can issue a pull request.

git remote set-url origin <your forked repo's URL>

In case you need to look it up

[Hakan]

Pierre..
Very good. I was on the same place on got the first talker data as well.
I'll test more tomorrow.
Thanks
Håkan

[stevead]

For NMEA 2000, GNSS satellite information is obtained from several messages; PGN's 129029 and 129540

129540 provides information about the satellites used for the position fix (sort of equivalent to the NMEA 183 GSV sentence) and 129029 contains information regarding the quality of fix, including the GNSS type (sort of equivalent to the NMEA 183 GSA sentence). Off the top of my head, GNSS Type Values are: 0 = GPS, 1 = Glonass, 8 = Galileo

BTW, In addition to Dave's list of NMEA 183 talker id's indicating GNSS types there are also:
GB: BeiDou (China)
GQ: QZSS (Japan)
GI: NavIC (India)