I’m on a deep dive into NMEA data from the RTK Express. I was seeing some issues where BeiDou PRNs are reported in the GPS range. I updated the uBlox to the latest 151 firmware and now the issue is much worse. I’m wondering if there is an additional update the I need? I’m using the latest 4.1 RTK Surveyor firmware.
I’m writing a Chrome Web App that read the NMEA using WebSerial. Here is the GPS tab in the screenshot.
Thanks!
Ok - I fixed this by not treating GSV message sets as atomic and by indexing my satellites by Constellation, SignalId and PRN. Pretty obscure, but quite a lot of data.
I still cannot tell which satellites are actually in use though, because BieDou is using GPS PRNs.
I don’t have much to offer, but check out Update PRN numbers - include Beidou · Issue #54 · barbeau/gpstest · GitHub and couple of quick notes…
"BeiDou, China’s navigation satellite system, does not directly use GPS PRNs (pseudo-random noise codes); it has its own set of PRNs assigned by the GPS PRN Coordination Office, allowing for compatibility and interoperability with other GNSS systems like GPS, but with distinct identification numbers for its satellites.
Key points about BeiDou and PRNs:
BeiDou satellites transmit their own unique PRN codes, not directly using the codes allocated to GPS satellites.
While BeiDou has its own PRNs, the allocation process can involve coordination with the GPS PRN Coordination Office to avoid conflicts, especially for BeiDou’s Geostationary Earth Orbit (GEO) satellites.
This coordination allows devices capable of receiving both GPS and BeiDou signals to interpret and utilize the data from both systems effectively.
So…it looks like PRNs 201-235 should be Beidou?
I figured this out by finding the uBlox ZED-F9PInterface Description document. It describes all the NMEA messages for various protocol versions. uBlox returns the satellite numbers for GPS, Galileo and BeiDou in the 1-32ish range. Then they add a non-standard systemId field to the end, just before the checksum. I updated the @jbroll/nmea-simple library to add the correct offset and return the proper PRN for each constellation.
Doesn’t NMEA V4.11 fix this issue and make life much easier ?
What NMEA version does the F9P in the Express use ?
In Apendix A and B of the uBlox document, InterfaceDescription-PM-15136.pdf, is a description of Satellite Numbering and UBX and NMEA Signal Identifiers. GPS, Galileo and BeiDou all use numbering from 1 to 32 or 37. They are distinguished in GSA sentences, which on my ZED-F9P, running the latest 1.51 firmware, all have talker id “GN” by the systemId, a final field just before the checksum.
This claims to be compliant with NMEA 4.10+ ??
Here’s a newer Revision to that Document.
With NMEA V4.11, you can get:
$GPGSV indicates GPS and SBAS satellites.
$GLGSV indicates GLONASS satellites.
$GBGSV indicates BeiDou satellites.
$GAGSV indicates Galileo satellites.
$GQGSV indicates QZSS satellites.
NMEA V4.11 is available on F9P’s Firmware 1.50, maybe even prior.
However, I’m not making any claims that SFE Firmware will handle NMEA V4.11 without causing a hiccup or two .
The satellite numbers in the sentences are still running from 1 to 37ish, you need to apply an offset for each constellation to get the constellation unique PRN numbers. Same for GSA sentences and there you need to use the uBlox specific systemId.
