Update GxGSV NMEA 4.10 - Add Signal averaging - Update gpsinformationwidget

[bettellam]

parse.c
Update GxGSV - NMEA 4.10 signal_id

sentence.h
Add signal_id; //!< NMEA v4.1 - ID of the ranging signal

qgsnmeaconnection.cpp
NMEA RMC - Set qualitydescription only for status: A or V in processRmcSentence
if the value in status is not A or V (e.g. D), for qualitydescription it is set with GGA

NMEA GSV - Add Signal averaging processGsvSentence
QgsSatelliteInfo signal is calculated as the average of the signals present in GxGSV
With future updates using signal_id you may get a result similar to this:

qgsgpsinformationwidget.cpp
Small updates in SkyPlot satellites (added color and different symbol for various constellations)

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit f14154c)

[bettellam]

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[github-actions]

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist.

[bettellam]

@nyalldawson Ciao
Sorry this request was not merged.

The change to GxGSV is a simple adaptation to NMEA 4.10

The change to GxRMC solves a problem with the new Unicore UM98x receivers, low-cost GNSS receivers that are having a considerable success on par with the UBlox F9P.
In particular with UM98x an improper use of the Status flag is performed in the NMEA GxRMC sentence whose standard values ​​are: A=active or V=void.
UM98x repeats the values ​​of the mode flag.

The current procedure in QGIS only checks Status=A to fix from the Mode flag:
mLastGPSInformation.quality
mLastGPSInformation.qualityIndicator

passing to Void any other value of Status and then:
mLastGPSInformation.quality = Invalid ;
mLastGPSInformation.qualityIndicator = Invalid ;
this makes the UM98x receivers unusable when they switch to RTK Fix mode.

It should be noted that
mLastGPSInformation.quality and
mLastGPSInformation.qualityIndicator
are set using NMEA GxGGA and are therefore correctly present.

A next step for NMEA:
update GxGSA to NMEA 4.10
this will allow to resolve the satellite numbering by introducing the standard character used by the RTCM specifications for the various constellations:
GPS: "G"
GLONASS: "R"
GALILEO: "E"
BEIDOU: "C"
QZSS: "J"
IRNSS/NAVIC: "I"
in addition to the satellite number
(this will avoid double numbering between GPS and GALILEO, currently not resolved in QGis),
it must be said that it will be more readable satellitesInView and satellitesInUse (satprn list) and the Skyplot graphs
Ciao

[github-actions]

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 8135f85)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 8135f85)

[bettellam]

@nyalldawson test Windows Qt6 builds
Ublox ZED-F9P

UNICORE UM982

NEW Update qgsgpsinformation.cpp

[bettellam]

@bettellam can i get your thoughts on #59124 ?

very good, test done OK!!

[bettellam]

With ZED-F9P everything is OK!
With UM982 there is a strange behavior in the two graphs:
Signal Plot and SkyView.
The graphs are seen in bursts for very small intervals of time (tenths of a second).
I don't understand the reason ??????

Registrazione.2024-10-21.190744.mp4

[bettellam]

small improvement....

Registrazione.dello.schermo.2024-10-22.010347.mp4

[bettellam]

@nyalldawson Ciao
I think I found the reason for the flickering with UM982.
I tested them simultaneously on the same antenna using an antenna splitter.

Currently the widget is redrawn at every NMEA sentence received with satInfoComplete=true.

This is the NMEA sequence for 1 epoch with ZED-F9P:
GGA (satInfoComplete=true)
GSA (satInfoComplete=true and satellitesInView.clear())
GSV (satInfoComplete=false)
GST (satInfoComplete=true)
ZDA (satInfoComplete=true)
RMC (satInfoComplete=true)
VTG (satInfoComplete=true).

while the NMEA sequence for 1 epoch with UM982 :
GGA (satInfoComplete=true)
ZDA (satInfoComplete=true)
GSA (satInfoComplete=true and satellitesInView.clear() )
RMC (satInfoComplete=true)
GST (satInfoComplete=true)
VTG (satInfoComplete=true)
GSV (satInfoComplete=false).

In ZED-F9P GSA and GSV with contiguous;
in UM982, after GSA has executed satellitesInView.clear() , you have to wait for the next GGA to have data representable in the widget.

The UM982 NMEA GSV sentences are much more numerous, as UM982 has a capacity to receive more frequency signals from satellites (just under double compared to ZED-F9P).

in the reading period of an NMEA epoch:
ZED-F9P satInfoComplete=true 25% , satInfoComplete=false 75%;
UM982 satInfoComplete=true 7% , satInfoComplete=false 93%.

This explains the flickering!

A possible improvement could be to move the widget redrawing ONLY at the completion of an NMEA epoch, i.e. before proceeding with parseGGA, generally coinciding with the various GNSS receivers at "start of new epoch".
This eventuality must be tested in a subsequent pull request.

I consider this pull request complete for the moment.
Ciao

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[DelazJ]

@bettellam sorry to jump in this way, but are there screenshots we could pick here to feed the QGIS docs, please? Or you'd like to provide to QGIS docs? Ours are quite poor as we don't own/play with GPS in the docs team. Thanks in advance.

[bettellam]

Hi @DelazJ , the GPS documentation is actually a bit dated compared to the great update work done by @nyalldawson .
This PR is about to be closed, so some new implementations will not be available.
No problem for me if you want to take images from here.
I remain available if you need anything else.
bye

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[github-actions]

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist.

[bettellam]

Sorry, I don't understand what's wrong!!!
Help...
Thanks!