Resolution in Scatterplot poor?!

[karlranseierausrom]

Hi. I am a new user and want to use my second GPS device as a base station for the openmower project. I recognized, that in the scatterplot the resolution is poor (see attachment) or there happens some rounding.
Is this just a problem of the graphics or ist there a digit or so lost? I assume that for cm resolution it should not look like that.

Best regards
karl.ranseier
edit: in the status bar is the last digit of lon and lat always 0. That may be the same problem.
I am using a simpleRTK2B – Basic Starter Kit of ardusimple.
edit2: in u-center I do not have this issue.

[semuadmin]

Hi @karlranseierausrom

Can you send me the full screen print of PyGPSClient (the image you've provided is cropped) and the corresponding raw binary log from your receiver?

You're at the extreme end of the scale here - what resolution were you looking to achieve? The scatterplot widget uses a haversine formula to calculate the great-circle distance between sets of coordinates, but this will only give very approximate results at sub-meter resolution. For distances of 10m or less, simple flat plane geometry would be more appropriate and the widget doesn't currently implement this (edit - it will as of v1.3.7 - see comment below). Having said that, I'm not clear why you would be getting decimal truncation. Here, for example, is a quick capture from my own receiver at a similar scale and - as you can see - the least significant digits are not zero:

[karlranseierausrom]

Here it comes...
I recognized two things:
Values in status and scatterplot differ. 1. they are mixed up (lat=lon and lon=lat). 2. the ones in the plot have more digits and not the rounding to a 0.
I want to achieve cm resolution with one antenna giving correction data, the other antenna is mounted on my mower-robot.

[karlranseierausrom]

Why are you using a calculation? This scatterplot is a x-y-plot, but for clearance one shows rings of the distance. There is no need of sin/cos calculation?! Or do I understand someting wrong?
If I would calculate this graph I would simply use an x-y-plot and set the origin to the average value of x and y. Than add the polar scale with right scaling.
Sure, one can calculate the distance and the angle, but why? ;-) Should give the same result.

[semuadmin]

Ok so few observations:

1. The scatterplot widget plots the relative distance and bearing between successive lat/lon coordinates with the x/y plot centered on the cumulative average lat/lon. It is not a 'map' representation. In order to calculate the great-circle distance between two sets of lat/lon coordinates which are separated by more than, say, 50m, you need to use the haversine formula (or something like it). For very small separations (less than around 50m) a planar approximation may suffice, but you still need to do the math. (edit - addressed in semuconsulting/pynmeagps@e343036 and 4a2a7e2)

2. I see that the lat/lon labels are transposed on the scatterplot widget - this is clearly a typo error on my part which I'll fix in the next version (surprised no one has pointed that out before!). (edit - fixed in 3f8dd69)

3. The lat/lon in the scatterplot widget represents the cumulative AVERAGE lat/lon over the capture period - it will not necessarily be the same as the lat/lon shown in the top banner, which represents the instantaneous coordinates from the receiver.

4. The scatterplot image you've given above looks normal enough - would you be able to send me the raw datalog so I can compare results at the maximum scale?

5. For the fixed/rover receiver configuration you describe, you may be better using the Rover Plot widget which uses RELPOSNED data from the receiver to plot the distance between the fixed and roving antennae.

[karlranseierausrom]

May you help me to find the raw datalog? Sorry that I forgot to send it.

I don't really need that plot, I just wanted to be sure, that the correction data is send with full resolution.

[karlranseierausrom]

About 1.: If I do have a twodimensional graph. For example some coordinates on a simple sheet of paper, than one could give kartesian coordinates or polar coordinates, both would give exactly the same positions. In one case you add x/y scale, in the other r / theta.
Assuming that the original date is twodimensional, one does not need to calculate the polar coordinates, one simply has to add circles with certain radius.
Sure, the original data is from a baal called earth and we are doing a projection. But in the range of some hundret meters one should not see any difference if you correct the values or simply plot lat/lon as x/y-coordinates.

This is just a thought to eventualy make the graph easier with less calculation and less problems on that.

[semuadmin]

May you help me to find the raw datalog? Sorry that I forgot to send it.

Enable the 'DataLogging' facility in default 'Binary' mode in PyGPSClient's settings before you connect to the receiver. You'll get a file in the chosen directory which will be named something like pygpsdata-20240105221207.log.

I don't really need that plot, I just wanted to be sure, that the correction data is send with full resolution.

So I can assure you that PyGPSClient (and its underlying parsing library pyubx2) does not perform any rounding or truncation of lat/lon data - what you see is exactly what comes out of the receiver. Bear in mind that the traditional NMEA protocol only supports lat/lon to 5 decimal places (roughly equivalent to around 1m resolution). You would need to enable 'high resolution' NMEA mode - or use the UBX protocol instead - to get at least 7 decimal places (the maximum usable resolution, equivalent to around 1 cm).

I presume you appreciate that, in a fixed base/rover configuration, the base station has to be outputting RTCM3 data which the rover picks up and uses to 'correct' its navigation solution. As I say, the Rover Plot widget will give you a better indication of the performance of such a configuration.

[semuadmin]

About 1.: If I do have a twodimensional graph. For example some coordinates on a simple sheet of paper, than one could give kartesian coordinates or polar coordinates, both would give exactly the same positions. In one case you add x/y scale, in the other r / theta. Assuming that the original date is twodimensional, one does not need to calculate the polar coordinates, one simply has to add circles with certain radius. Sure, the original data is from a baal called earth and we are doing a projection. But in the range of some hundret meters one should not see any difference if you correct the values or simply plot lat/lon as x/y-coordinates.

This is just a thought to eventualy make the graph easier with less calculation and less problems on that.

I can only recommend that you refer to the two links I provided earlier for an explanation of the possible approaches.

[semuadmin]

Hi @karlranseierausrom

FYI I'm adding an enhancement to the Scatterplot widget in version 1.4.7 to use a planar approximation formula for scales of 50m or less, and the haversine great circle formula for larger scales. This should improve rendering at smaller scales, though distances at these scales will only ever be approximations.

[karlranseierausrom]

Bear in mind that the traditional NMEA protocol only supports lat/lon to 5 decimal places (roughly equivalent to around 1m resolution). You would need to enable 'high resolution' NMEA mode - or use the UBX protocol instead - to get at least 7 decimal places (the maximum usable resolution, equivalent to around 1 cm).

ok, thanks for that hint. I am yet not familiar with those protocols. In my screenshot it used 9 decimal places or 7 after the point. So it seems to be high resolution nmea, but I need more ;-) I went to UBX config, tried a bit and now the last digit is changing. Thanks!

I presume you appreciate that, in a fixed base/rover configuration, the base station has to be outputting RTCM3 data which the rover picks up and uses to 'correct' its navigation solution. As I say, the Rover Plot widget will give you a better indication of the performance of such a configuration.

I want PyGPSClient to send these correctiondata. I assumed that this is done by NTRIPCaster in NTRIPCaster mode on port 2101 on my local ip in my network. I thought this is a standard protocol. Do I have to configure it somewhere? I think now there is the point where I should read some literature about UBX, NTRIPCaster and RTCM3... I will look for it.

[semuadmin]

I want PyGPSClient to send these correctiondata. I assumed that this is done by NTRIPCaster in NTRIPCaster mode on port 2101 on my local ip in my network. I thought this is a standard protocol. Do I have to configure it somewhere? I think now there is the point where I should read some literature about UBX, NTRIPCaster and RTCM3... I will look for it.

Maybe have a read of this first: https://www.semuconsulting.com/gnsswiki/#DGPS

Can I just clarify which of the following configurations most closely represents your intention here?

1. You're using two GNSS receivers, one configured as a fixed base station, the other as a rover?
2. You're using one GNSS receiver configured to receive corrections from a fixed NTRIP source?

[karlranseierausrom]

1. is the right one. I am using your software with an antenna as the fixed base station. The rover is this: https://openmower.de/docs/overview/

Am I right that because of the NMEA / UBX problem, which is solved now, you do not need the binary protocol?

Thanks for the link.