Dual RTK implementaion

[amirt23]

I was thinking of trying to implement a dual RTK configuration using pygnssutils. Before starting to work on this I was hoping to get some feedback if this is even possible or what problems should I expect.

Given that there are two f9p or a set of f9p and f9h receivers on your machine, does reading the location data (lat, lon) from each receiver in parallel using some synchronization mechanism between the two processes will allow to also calculate the angle in between the two antennas with respect to the true north?

[semuadmin]

Hi @amirt23,

I'm guessing by 'dual RTK' we're talking about a conventional fixed or moving base / rover here. Assuming you have one F9P configured as the (fixed or moving) base station emitting RTCM3 correction messages (1005, 1077, 1087, etc.), and the other F9P/F9H configured as a rover with some means to receive those RTCM3 messages remotely, you can obtain the relative position of the rover with respect to the base by simply enabling and monitoring the UBX NAV-RELPOSNED message. You wouldn't necessarily need to use any pygnssutils functionality.

You would of course need to implement some means by which the rover can receive RTK (RTCM3) correction data from the base. There are a number of options here, e.g.:

1. If the base and rover are co-located, a cable between their respective UART or I2C ports.
2. Via wireless serial telemetry using a LoRa (long-range radio) transmitter at the base and a LoRa receiver at the rover, both connected to an F9* serial port. This is generally the recommended configuration.
3. Via an NTRIP caster/client configuration over the public internet. In this case you could, if you so choose, use pygnssutils's gnssserver utility (in ntrip mode) at the base and pygnssutils's gnssntripclient at the rover, but this assumes you have internet connectivity and can run Python apps at both ends (e.g. via Raspberry Pi or similar device). This may be an interesting option from an educational standpoint but I wouldn't recommend it for practical applications.

For ultimate accuracy, the base station can itself receive RTCM3 corrections from a calibrated fixed source (e.g. NTRIP caster).

Refer to the ublox community forum for general advice on appropriate ublox base/rover device configuration.

Refer to the F9P Interface Specification for further details on the UBX NAV-RELPOSNED message. Note that older versions of this message provide position data in NED (North East Down) format - you would need to apply a conversion to get a position vector in degrees/meters.

If you can provide more specific details on your intended use case and operating platform, I may be able to advise further on appropriate Python implementation using one or more of the SEMU Python GNSS utilities, if indeed any are applicable.

See also this recent Discussion #77 for an illustration of how this has been applied in practice in the PyGPSClient GUI application's Rover widget.

Hope this helps.

(PS. the Sparkfun link above is purely for illustration - I'm not sponsored by Sparkfun in any way whatsoever and there are many other options available)

[amirt23]

First of all, thank you for the quick and comprehensive response. I would also like to point out that pygnssutils is incredibly useful for those of us who are not able to use ublox's official API.

Regarding the "dual RTK" project, Yes, you are correct my intention is to implement a moving base/rover. The setup I'm hoping to test will be achieved by co-locating the two units (2xzed f9p or zed f9h+f9p) respective UART or I2C ports using a cable. The base will receive corrections from an NTRIP caster service.

Please allow me to carefully review all the information you detailed and referenced before writing back. Although I haven't had a chance yet to properly look into the "PyGPSClient GUI application's Rover widget" you suggested it seems to me using a similar implementation with UBX-NAV-RELPOSNED message is the way to go.

Thank you again for you response and assistance.