I discovered a bug in the QGNSS v.2.2 program - decoding the SBAS satellite identifiers (PRN) incorrectly. However, the identifiers (PRN) in the NMEA messages are correct. I’m also attaching a screenshot of the Teseo Suite program, where the identifiers (PRN) are decoded correctly.
Hi @dabaz,
Could you kindly provide the following details so we can assist you:
- Module in use:
- Firmware version:
- Design type: Is it your own design or our Evaluation Board (EVB)?
I will also send you another version of QGNSS to see if this issue occurs via email
Hear from you soon
Best regards,
Hi, YongHuang!
1 - L26T-S89
2 - L26TNR01A06V02
3 - my own design
Also I see same problem with SBAS satellite identifiers (PRN) on QGNSS v.1.10…
Hi @dabaz
Here is the answer to your question.
In PSTM, the private sentence PSTMSBAS displays PRN as 136. However, in the standard NMEA protocol, there is no PRN 136. The actual PRN in NMEA is 49. The private sentence applies an offset of 87 to the raw PRN value.
- The NMEA PRN can be seen in the GSV NMEA message, which follows the standard format.
- The PSTMSBAS PRN shown in the private sentence is the raw PRN from the satellite, before any offset to NMEA standards.
The tool being used is a general NMEA parser, designed for modules that support the standard NMEA format. Therefore, this behavior is not a bug in the tool.
For interoperability and consistency, always reference the NMEA PRN (e.g., 49) when working with standard NMEA messages. Which falls between 37 - 64
Also, are we sure that max dBHz rating is correct?
When I did the comparison with the same antenna, it reported 4dB better than competitor’s flagship
• LC76G devkit max 51dBHz
• Ublox MIA-M10Q devkit max 47dBHz
I have never seen ublox reaching 50dB, so I doubt it’s possible.