Interpreting RMC sentence with "D" for status

[simon3789]

Describe the issue

Using Q-Field with an Unicore UM960 Receiver. Everything is working. As soon as I reach a differential fix (like rtk float or rtk fix), Q-Field drops out.

I made some research, unicore introduced another caracter for the status in the RMC sentence. According to their documentation they only do it in their RMCH sentence, which is the one for the slave antenna, but I found it in the normal RMC sentence as well.
(The UM960 doesnt even have a slve antenna)

QField only expects "A" for active or "V" for void, but unicore also sends a "D" for differential.
As soon as I turn off the RMC sentence, the positioning is working, even with rtk fix.

Expected behavior

Qfield interpreting "D" in RMC senctence same as "A"

Observed behavior

Qfield interpreting "D" in RMC senctence as invalid

Mobile (please complete the following information)

• Device: [Samsung Galxy Tab Active 4 and Samsung Galaxy Tab Active 3]
• OS: [Android 14]
• QField version: [72be17 v3.2.2]

[nirvn]

@simon3789 , good reporting. Is this value unique to this vendor or you've seen it in RMC sentence specs?

[simon3789]

@nirvn I only had expericence with ublox receivers before I bought this Unicore. Have never seen this behavior before.
It isn't contained in any official RMC sentence specs, not even in the unicore documentation.

But is is contained in the specification for the unicore-specific RMCH sentence which they use to report the values of the slave antenna.
So I guess it is a vendor or even firmware-specific mistake that this value is reported in the normal RMC sentence.

[bettellam]

@simon3789 , @nirvn
The NMEA $GNRMC phrase of UNICORE
contains a field <14>,
not foreseen in: QGIS/external/nmea/parse.c

405 int nmea_parse_GPRMC( const char *buff, int buff_sz, nmeaGPRMC *pack )
      {....
448 }

[Pag. 68-69] (https://core-electronics.com.au/attachments/localcontent/Unicore_Reference_Commands_Manual_For_N4_High_Precision_Products_V2_EN_R1_1_189543505cb.pdf)

I also plan to buy a Unicore GNSS receiver (UM980 or UM982)!!!
Ciao

[bettellam]

@nirvn
If I'm not mistaken, the changes to make would be quite simple:
external/nmea/sentence.h line 121
Add to :
121 char navstatus; //!< UNICORE Navigation Status type (S = Safe, C = Caution, U = Unsafe, V = Navigational status not valid)

external/nmea/parse.c line 418
change to:
418 "$G%CRMC,%s,%C,%f,%C,%f,%C,%f,%f,%2d%2d%2d,%f,%C,%C,%C*" ,

external/nmea/parse.c line 423
change to:
423 &( pack->declination ), &( pack->declin_ew ), &( pack->mode ) , &( pack->navstatus ));

external/nmea/parse.c line 425
change to:
425 if ( nsen != 14 && nsen != 15 && nsen != 16 )

Ciao :-)

[nirvn]

@bettellam , good catches. My advise would be for you to open an issue and discussion this issue in upstream QGIS. I'm not sure we'd want to add a vendor-specific parameter to the RMC sentence, however we chould tolerate a 14th parameter that we don't necessarily consume but insures more GNSS devices work.

[bettellam]

@nirvn I have now checked the RMC phrase used by UNICORE and it corresponds to the new NMEA 0183 Version 4.1 : https://gpsd.gitlab.io/gpsd/NMEA.html#_rmc_recommended_minimum_navigation_information
external/nmea/sentence.h line 121
Add to :
121 char navstatus; //!< NMEA v4.1 - Navigation Status type (S = Safe, C = Caution, U = Unsafe, V = Navigational status not valid)

[nirvn]

@bettellam , oh that's good news!

[bettellam]

Solved - qgis/QGIS#57204

[nirvn]

QField now building with a version of QGIS that includes the fix, closing.

@bettellam , thanks for your help fixing upstream.