Why do I get DGNSS with my ublox GNSS receiver

GPS/GNSS
1

We built a measurement system that is operated on cars in Germany. Among other things that measurements system includes a u-blox ZED-F9P GNSS receiver on a Sparkfun board and a Raspberry Pi. The two are connected via UART. The GNSS messages are logged with Python. The measurement system isn’t connected to the phone network - there is no modem or SIM in there.

Roughly half the time we get NMEA messages without differential corrections like this:

1720048649.4872622, "$GNRMC,135904.00,A,5051.85346,N,01026.42880,E,8.269,140.82,230724,,,A,V*04

And half the time we do have differential corrections (this worked out of the box):

$GNRMC,115316.00,A,5051.49037,N,01024.93509,E,0.012,,230724,,,D,V*1A

According to the receiver’s protocol manual (page 9) the letter before the last comma indicates the position fix flag:

  • A means Autonomous GNSS fix (no DGNSS)
  • D means Differential GNSS fix

I would like to know how the DGNSS correction data is transferred to our receiver.

Many Google searches later, I can find that SAPOS provides free DGNSS data via NTRIP (requires internet) and that WSV provides DGNSS via MF radio. The datasheet of the GNSS receiver doesn’t mention anything about internet or a phone connection and afaik MF radio antennas are huge.

So it doesn’t seem to be either of those. How is the data transmitted then? What kind of receiver for differential data is in the ZED-F9P? We also have EGNOS SBAS in Europe that sends some corrections from the geostationary satellites which the ZED-F9P can receive but I’m not sure if that counts as DGNSS (in the data sheet SBAS is a different heading before DGNSS).

Thanks to what infrastructure do we get that Differential GNSS fix half the time?

2

Stand-alone DGPS typically come via SBAS, most of the DGPS Beacons have been decomissioned (RTCM2 not supported by M9/F9), at least on the US coast and water-ways.
The age and station data should be in GGA, 0000 typical for satellite sourced.
Alternately you can get via RTCM3 or SPARTN data
Should be able to attribute sources via UBX-NAV-SAT/SIG
Earlier ZED-F9P firmwares did not support SBAS, but a lot of external pressure caused it to be added as a check-box item. Generally you’re wasting 3 channels on hunting for it.

3

I see. We have GGA turned off but I have a few GGA messages and they do show 0000 for the station. So getting a signal from EGNOS Open Service (SBAS) would cause the D in the data? From reading the datasheet I would have expected an A for Autonomous fix in that case.

The ZED-F9P supports RTCM3. However, we haven’t made any modifications to enable DGNSS. We just hooked up an I²C bus, that was it. The “D” in the RMC sentences appeared out of the box. WSV does provide RTCM3 all across Germany for the inland waterways (I’ve included a link to WSV in my original post). But there’s no way I receive this signal without knowing about it, right? Wouldn’t that require a huge antenna?

And there’s also no way I somehow get correction data from SAPOS without having done any setup to get it?

So that only leaves SBAS (specifically EGNOS OS)? I guess that’s it then. I had ruled that out too since I thought that doesn’t count as DGNSS because they have very few ground reference stations (only 38 across Europe) and because SBAS is presented as distinct from DGNSS in the ZED-9FP’s datasheet.

4

The ground stations create a mesh or surface model to apply corrections over a region, rather than a perspective of the signals from a single location. At best this buys you about 50cm of CEP50 reduction. Mostly these days it is flagging integrity on a close to realtime basis, so unhealthy satellite can be identified quickly via ranging from known/established locations. Basically a loop in more local control than via USAF.

You should be able to see it tracking and using the SBAS satellite in its geostationary orbit covering you.

The use of that data also flagging on a per satellite basis in either UBX-NAV-SAT or SIG

DGNSS can also flag as a precursor to RTK Float or Fixed, and various NMEA Standards and Messages have different methods to flag fix quality and type, and legacy equipment expectations. I’d argue that RTK is more of a geometry problem than a differential one, because its not receiving range error and rate of change.

I’d probably focus on unpacking UBX messages.

1 Like