ZED-F9P RTK system takes too long to find distance between Moving Base and Rover

[rubo]

We are developing an RTK system that uses two SparkFun GPS-RTK2 Board - ZED-F9P (Qwiic). The first one is used as a moving base and the other one as rover. The base recieves correction data from Thingstream via NTRIP. We have followed ZED-F9P moving base applications Application note from U-Blox. Our goal is to obtain precise heading and absolue position (latitude, longitude) from the RTK system.

We are using the length we obtain form the messeage UBX-NAV-RELPOSNED to know if we can trust the heading, latitude and longitude given by the Rover via I2C. We compare RELPOSNED length to the kwown distance between the rover antenna and the base antenna, which is 50cm. If our system takes 10 consecutive samples of RELPOSNED length between 49.5cm and 50.5cm, we allow our device to continue working, but if RELPOSNED lenght doesn’t fall into those margins, we wait untill it does. We call that process calibration.

The problem is that sometimes our device takes up to 7 minutes or more to establish 10 consecutive samples of RELPOSNED lenght inside our bracket, when it normally takes under a minute. This happens both when the device is started in a location where its has recieved GPS/GNSS signal before (warm start) and when it is started at a new location where it has never been before (cold start). But this can also happen at other times different from start, meaning we perform a first successful calibration under a minute, and then, after a while, a second calibration, third or fourth can take a lot of time, or our device just stays calibrating forever.

We have found some sort of solution to this porblem, but it doesn’t always work. When we notice that a calibration is going to take a very long period of time, we play with the device orientation. For example, we try to calibrate with the Rover antenna pointing to the East, we notice it is taking longer than usual, we rotate ti so that it points South, and 10 consecutive samples of RELPOSNED lenght are received almost instantly after rotating. But, as I previously said, this doesn’t always work.

We would like some help to understand this issue, and to know if there is something we can do, firmware or hardware, to prevent our device from it. We would also like to know if there is a better way of obtaining the heading than the one we are currently using, which is from the RELPOSNED message when the obtained lenght matches our known lenght.

The antennas we are using for both Base and Rover are AECC0502GB.

Thank you in advance

[PaulZC]

Hi @rubo ,

Just some quick comments:

50cm is a very short baseline and +/-0.5cm is a very tight tolerance. Can you extend the baseline and/or relax the tolerance?

Is this system mounted on a drone? Could the drone motors or structure be interfering with the GNSS reception?

I hope this helps,
Paul

[rubo]

Hello @PaulZC ,

Thak you for your reply. We are aware it is a short distance and a tight margin. Extending the baseline is not possible without modifiying the structure of the device. We can increase the tolerance, and it does make it better, but we were hoping to find a solution that allowed us to maintain our margin.

The system is mounted on a measuring device with some other sensors and a screen. There is some metal structure that could be interfering with GNSS reception. However, we believe this is not the main source of the problem since the strucure is always there but the issue doesn’t always happen

[PaulZC]

OK - thank you.

It may be due to the position and orientation of the satellites in the sky, on that particular day at that particular time. Please see the post below for more information. +/-0.5cm is very close to what is possible with RTK. If a tolerance of +/-1cm works better, I would suggest using that.

Best wishes,
Paul

Altitude Stability Question

X, Y, and Z accuracies are in that order typically. Your X component is generally the best, Z is the worst. There are many reasons for this, but most stem from the fact that Positioning relies on the principle of trilateration. When you think about the orientation of satellites (birds) flying around overhead, the Z component is the most sensitive to errors in the trilateration calculations. The best birds for calculating a single distance are directly overhead, and the worst are low on the horizon. Geometry would point us to adding the birds low on the horizon to better “fix” a point in 3D space - but those signals must travel through more atmosphere than the rest. Low angles are also much more susceptible to Multi-Path interference at the receiver. Now consider that the bird has traveled a couple hundred miles [Correction: meters] through space during the time it takes the RF signal to reach Earth. Plus the Earth is spinning and the Y coordinate has moved ~100’ during that ti…

[PaulZC]

Hi @rubo ,

Also, could the accLength and/or accHeading fields be a better way to evaluate your ‘calibration’? Have you tried monitoring those as the calibration progresses?

I hope this helps,
Paul

[rftop]

I agree with @PaulZC suggestions.

The requirement for both GNSS receivers to reproduce the baseline to 1cm or less could be considered similar to requiring Each receiver to be within (+/-) 0.5cm. That’s possible in certain settings, but out of spec.

Your results of “less accuracy” in the East/West orientation makes sense. The East coordinate is generally the worst in GNSS horizontal positioning.

@rubo

Our goal is to obtain precise heading and absolute position (latitude, longitude) from the RTK system. We are using the length we obtain from the message UBX-NAV-RELPOSNED to know if we can trust the heading, latitude and longitude given by the Rover via I2C.

Your goal of absolute position is driven by the moving Base receiving an external correction (which you confirmed). The Rover is only performing the orientation duty.

@rubo

There is some metal structure that could be interfering with GNSS reception. However, we believe this is not the main source of the problem since the structure is always there but the issue doesn’t always happen

A precision requirement of 0.5cm will require the elimination of all multi-path signals reaching the antennas. This is something that you might be able to improve.

It sounds like you are doing everything correctly, but are just experiencing the limitations of RTK, including the variable HDOP over time of the constellations (which you can’t control).

[Theory only]: The design decision to require 10 consecutive samples as verification could be reconsidered, especially at the current 0.5cm precision requirement. Statistically speaking, 10 consecutive pairs of RTK samples wouldn’t give me (personally) much “extra” confidence in the performance of the System in this type of application. That’s too short of a period of time to reduce random errors, so it’s better to lean towards the real-time aspect in this case. I’d think more along the lines of Epoch to Epoch.

You could run a static test with your baseline. With your rig still, collect all bearing data and use a spreadsheet to later change the proposed design requirements (10 samples, 1cm total, etc) to see how those impact the results for your particular baseline and physical Rig. That’s also an easy way to check if ground planes improve the system performance, etc. Then you will have empirical data to adjust your real-time validation criteria.

It wouldn’t surprise me if you ended up with using each individual Epoch that is qualified via baseline length after testing, but I don’t know how much that short baseline will impact this.

[rubo]

@rftop @PaulZC Thank you so much for your ideas. We will process all the feedback and get back to you once we have new results.