Using u-blox ZED F9-P for full raw data collection via Pygpsclient

[savioratharv]

can I use a u-blox ZED F9-P module and obtain .ubx files using Pygpsclient? I need it to be a .ubx file containing full raw data, so that I can use this data for PPK and achieve cm level accuracy.
I am very new to this stuff so any help is appreciated.
Thanks in advance.

[semuadmin]

Hi @savioratharv

Yes, you can certainly do that. Just select the 'DataLogging' option in PyGPSClient with a format of 'binary' before you open the serial connection. You will be prompted to select the folder into which the log file will be saved. PyGPSClient will save the raw data from the receiver (NMEA, UBX or RTCM) to a timestamped binary file in that folder e.g. pygpsdata-20240816085025.log. If needs be, you can change the file suffix to *.ubx, but this doesn't affect the content at all.

You can then read back the contents of the file using the FILE input mode of PyGPSClient.

FYI you can also do the same thing with the gnssdump command line utility if you'd prefer not to use a GUI application.

NB: note that the F9P receiver only outputs NMEA data by default. If you specifically need UBX data, you will need to configure the receiver accordingly. PyGPSClient has preset facilties to suppress NMEA data and enable a minimal cohort of UBX messages instead:

[gdt]

Also, you say "accuracy is not cm". Be careful not to confuse actual accuracy with error estimates. Assessing actual accuracy requires a monument that you have an accurate position for. However, another technique I find useful is to repeatedly measure a monument, on different days, and to plot all the measurements, and see show they cluster. There could still be bias, but it is very enlightening.

You said PPK and CORS (do you mean US National CORS Network?), but you didn't explain how you are doing PPK, and what kind of residuals and float/fix indication the PPK solution is giving you. I have done RTK with the F9P's processing, and not PPK, and would expect better performance with PPK compared to RTK since it can propagate fixed integer ambiguitiies backwards in time rather than just forward.

[savioratharv]

I am using the Indian CORS network. As you said about measuring accuracy, we have a reference station within our institution that is not operational but whose exact GPS coordinates are known. I am planning to test out the GPS accuracy properly using that. But as it stands, the results I am getting are not able to trace the path taken by me correctly and when I tested both the native GPS coordinates and the obtained coordinates after PPK, I noticed the native GPS coordinates were more representative of the path than the points after PPK. I tried using both Emlid Studio and RTKLIB for PPK. RTKLIB tells the accuracy of the points after PPK is sub-metre.
query.zip
I am attaching a zip file with both the raw data in ubx format and the correction data from CORS. The area where we tested this has a lot of buildings and a canopy of trees, could that also be a reason for this result? And the fact that the base station we are using for corrections is 25.8km away.

[semuadmin]

Hi @savioratharv,

So, having taken a quick look at your raw ubx data, I can see straight away that your satellite coverage is unlikely to be sufficient for cm accuracy via RTK. Your carrier-to-noise (CNo) ratios are far too low and your sky coverage appears to be concentrated in a roughly 36° vertical arc.

You're seeing this:

... but you should be seeing something more like this, with much broader sky visibility and around 15-20 satellites with CNo > 45 dB:

At a push I'd say you need to elevate your antenna and/or use a more powerful active antenna with a decent LNA. Suggest having another look through RTK-TIPS.

In terms of any PPK results via RTKLIB, you need to be asking those questions in the u-blox or FOSS GPS forums rather than here.

[gdt]

Also, you should understand what datum your national CORS operates in. I have no idea, but I would expect that India has a modern (after the dawn of the satellite era) datum that is plate fixed. which is not WGS84.

[semuadmin]

I'm going to lock this discussion at this point, before we go off on too many tangents.

@savioratharv if you have any further queries in relation to PyGPSClient, don't hesitate to come back to the Discussion Forum.