DGPS stuck on N/A, RTK barely making a difference

[ErikParkerrr]

Hi All,

To give some context: I'm using two ZED F9Ps; one on a robot and one as a base station. I want cm level accuracy using RTK.
The end solution will probably only involve PyGPSClient (or something even less) as an NTRIP server, but for now I'm using it for debugging. The system has to perform without internet access, hence the need for my own server.

I'm using RTK2GO as my ntrip server. I'm receiving messages in the console, all looks good there. My fix status goes between RTK and RTK float, only getting RTK fix once in a while. DGPS is stuck on N/A and never shows "yes". The accuracy is pretty bad, around 0.5m. I had the same result using my other F9P on another PC with that PC as the caster.

Any help on how to diagnose this? I've been playing with this for hours and I'm all out of ideas.

Thank you,

Erik

[gdt]

You didn't explain what kind of antenna you are using and if both units are truly outside while you are testing.
Which messages are you receiving? Are you sure you configured the right ones? MSM4? MSM7?

[ErikParkerrr]

If you couldn't tell, I'm a bit out of my element with this stuff. I'm using the u-blox ANN-MB-00-00 . I'm also using the this board. I apologize for not including that before.

I am outside with the antenna having a completely clear view of the sky with very nice weather.

I'm not sure I have configured the right messages, I'm still running nearly default settings. I will look into that configuration.

Thank you

[semuadmin]

Hi @ErikParkerrr,

To manage expectations, without knowing the details of your specific F9P configuration, your antenna type and location, your satellite signal levels (carrier-to-noise ratio or CN₀), your unrestricted field of view (DOP), the relative proximity of your NTRIP mountpoint, the local atmospheric conditions, etc. etc. I can only offer the same general advice that you can find on the u-blox community forum, where these kind of questions get asked A LOT!

Some general tips and observations (see RTK-TIPS):

1. If you're diagnosing RTK performance using the F9P, you may find it easier to switch your F9P to output UBX rather than NMEA messages, as the former are much more concise and will give you more consistent RTK status information. There's a PyGPSClient preset you can use for this. That being said, UBX is by no means a pre-requisite and you can get perfectly good results using NMEA.
2. I would also recommend enabling UBX RXM-COR messages which will give you further diagnostic information on RTK status. What you're looking for is errStatus=1, msgUsed=2 i.e. an RTCM correction message has been received OK and has been applied to the receiver's navigation solution.
3. To achieve a consistent RTK DGPS status, you need as a bare minimum a decent L-Band antennae and ideally a good ground plane, good signal strength (e.g. at least 15 satellites with CN₀ > 45 dB), good visibility of the sky and reasonably clear weather conditions. You're unlikely to achieve this indoors (though it's by no means impossible).
4. If you're using an NTRIP RTK source, the selected mountpoint ideally needs to be within 15 or 20km of your location (such that the correction data is representative of your local atmospheric conditions).
5. rtk2go.com is a popular free NTRIP service, but (depending on the mountpoint you're using) it may not give you the best results. I would recommend registering a (free) account with one of the more localised NTRIP services such as BKG's EUREF-IP or IGS-IP services - or the equivalent for your geographical region.
6. Assuming all the above is in place, you should be able to obtain a good RTK-FLOAT status within a couple of minutes of connecting to a reliable local NTRIP source - that will typically give you a reported horizontal accuracy (hAcc) of the order of 15-20cm. With an optimised F9P setup, you should be able to achieve RTK-FIXED with an hAcc of less than 2cm.
7. Bear in mind that RTK will not 'correct' a poor GNSS signal.

Hope this helps.

[ErikParkerrr]

Hi @semuadmin

Thank you for your extensive and fast answer.

I've seen a lot of good information on the u-blox forums, but wasn't able to solve my problem based off what I found. I see now I should've done a better job of going through it all.

I'm using the u-blox ANN-MB-00-00 . Seems to support L-Band. I'm also using this board. Its a perfectly clear day out and the antenna has a nearly perfect DOP besides one tree in my yard (but yes, it is completely outside.) The NTRIP mount point (when I wasn't attempting to use my one) was 54 km away. I will see if I can find a closer one.

I'm going to try your suggestions and report back with more information about my given situation (carrier-to-noise ratio, etc). I apologize for not including it in the first place. If you couldn't tell, I'm a bit out of my element with this stuff.

So I know what I'm looking for: the ideal is RTK-FIX, but RTK-FLOAT is acceptable if all I want is 15-20cm accuracy? What does it mean when it just says RTK? In terms of the DGPS value in the UI, does this matter? Or is N/A okay?

Thank you for making such incredible software and for your help with this.

Erik

[semuadmin]

Hi @semuadmin

What does it mean when it just says RTK? In terms of the DGPS value in the UI, does this matter? Or is N/A okay?

So in essence this is an artefact of the NMEA protocol, where different NMEA sentences report RTK status in different ways (in broad terms, the NMEA protocol predates a lot of modern GNSS developments). So, for example, a GLL or VTG NMEA sentence can only report 'RTK', whereas a GGA or RMC NMEA sentence can be more specific i.e. 'RTK-FLOAT' or 'RTK-FIXED'. This is one reason I recommend using the UBX protocol instead e.g. the UBX NAV-PVT carrSoln attribute distinguishes between 'NO-RTK', 'RTK-FLOATandRTK-FIXED`. Refer to the F9P Interface Specification for a detailed description of all the possible message types and their attribute values.

The "N/A", by the way, refers to the reference station ID aka diffStation or correctionID - this is solely for reference and has no bearing on the RTK fix. Many NTRIP sources will broadcast a null or nominal station ID.

It may be worth familiarising yourself with the difference between 'FLOAT' and 'FIXED' in this context as there are subtleties here that may not be immediately apparent.

Also bear in mind the significance of lastCorrectionAge (aka diffAge) - in broad terms the 'best' RTK correction is a recent one (< 5 seconds), with accuracy gradually tailing off as the correction becomes more and more out of date. A receiver like the F9P will (in its default configuration) 'remember' its RTK DGPS status for up to 60 seconds after the last NTRIP correction is received.

There are countless resources on the web which can help you get the best out of an RTK-capable GNSS receiver. For a general overview, check out https://www.semuconsulting.com/gnsswiki/.

Your ANN-MB antenna is capable of good (not perfect) results in good conditions, but it may be worth investing in a cheap ground plane as well - they can make a very worthwhile improvement (at a push, you can use a heavy ferrous saucepan lid or a car roof).

u-blox GNSS Antennas Paper
Ardusimple GNSS Antenna Installation Guide

[gdt]

Some further comments (not to contradict anything semuadmin said - 99% sounds right to me).

• You should be clear on using someone else's RTK reference data, and using an NTRIP server as a way to do plumbing from your own reference data.
• It is crucial that the reference station be close. 1 km is great, 10 km is good, 25 km is sort of ok, 100 km is not ok. (There are also RTK networks that make synthetic reference data.)
• You really need an antenna that is L1 and L2 both. I think the ANN-MB is that.
• I would either put the ANN-MB on car roofs, or get a basic, $100ish type L1/L2 cheap-but-claimed-geodetic antenna like the SparkFun TOP106.
• I do not believe in cm accuracy with RTK FLOAT. Yes, it will show you cm level error estimates from the receiver, but in experimenting the actual errors are huge compared to the claimed errors. If you care about reliably well sub meter, you need to get to FIX. Basically, do not ever really believe claimed errors from receivers.
• You should understand "DGPS", where the reference station sends corrections to pseudoranges and derivatives of those corrections. This is often sent as "RTCM2", and AFAIK it is rare these days.
• RTK is a carrier phase technique, and while everyone calls the data you get "corrections" that is not actually true. They are phase reference data, and your receiver (the computer inside the F9P chip, more precisely) estimates your position and the number of cycles difference between your cycle numbering and the refererence stations's numbering. RTK reference data is almost always RTCM3

[semuadmin]

* I do not believe in cm accuracy with RTK FLOAT.  Yes, it will show you cm level error estimates from the receiver, but in experimenting the actual errors are huge compared to the claimed errors.  If you care about reliably well sub meter, you need to get to FIX.  Basically, do not ever really believe claimed errors from receivers.

Agree to a point, which is why I use the term 'reported` horizontal accuracy. But the 'accuracy' data attributes are still useful in comparative if not absolute terms.

* RTK is a carrier phase technique, and while everyone calls the data you get "corrections" that is not actually true. 

The NTRIP and RTCM3 specifications use the term 'differential correction' and I think the term is generally understood and accepted in this context. Any distinction is largely academic.

[gdt]

Agree to a point, which is why I use the term 'reported` horizontal accuracy. But the 'accuracy' data attributes are still useful in comparative if not absolute terms.

I agree that the reported accuracies are useful, even if they are not accurate.

* RTK is a carrier phase technique, and while everyone calls the data you get "corrections" that is not actually true. 

The NTRIP and RTCM3 specifications use the term 'differential correction' and I think the term is generally understood and accepted in this context. Any distinction is largely academic.

I don't like saying correction when it isn't, even if everyone else does, because it obscures how RTK works. I do see the point that the process results in differential positioning against the reference station, which removes iono, tropo, satellite clock, and orbit errors. But there is an estimation (and fixing integer ambiguities), not applying a correction and solving, as regular DGPS does. But this nomenclature is not part of the OP's problem....

[semuadmin]

@ErikParkerrr

Bottom line - I suspect the main reason you're getting unsatisfactory results is that your NTRIP RTK source is sub-optimal.

By way of comparison, the PyGPSClient screenshot below - which illustrates an RTK-FIXED status with a reported horizontal accuracy (hAcc) of 1.4 cm (to be taken, as @gdt says, with a pinch of salt) - was taken in an nearby vacant car park using a stock SparkFun GPS-RTK-SMA board and a cheap ANN-MB-00-00 antenna (exactly like yours) mounted on the (steel) roof of a car. The location had more or less 360° visibility to the horizon, it was a clear day, and I was using a reliable EUREF-IP.NET NTRIP mountpoint situated some 28km to the west. As you can see from the RF spectrum chart, the antenna has good reception of both L1 and L2 signals (read the wiki to find out why this is beneficial).

There's a slightly closer (≈ 23km) RTK2GO.COM mountpoint available to me, but I would struggle to get better than RTK-FLOAT and hAcc ≈ 20cm using this mountpoint, all other things being equal. I would recommend you investigate a better NTRIP service for your location.

[gdt]

Very cool example! I should clarify: when in FIXED, and things are great, F9P will say 1.4 cm. My experience is that 30s averages on different days cluster with a diamater of 4 cm, with a 30h carrier phase static solution against NGS using old professional equipment (borrowed) falling in that cluster also. I should have been clearer that what I really distrust is when it says FLOAT 5 cm, I expect 10s of cm if not most of a meter.

This is great confirmation that the ANN-MB works well on a ground plane (the situation it is explicitly designed and intended for). I am guessing that EUREF is professional equipment with a great sky view. Random reference stations by individuals would seem likely to range from almost that good to really marginal.

I had the impression the OP had two setups, one to be base and one to be rover. But still, getting a rover working with a remote base is probably best as a first step.

In your screenshot, i see hacc 0.014 and vacc 0.010. But hdop is lower than vdop, in not quite the opposite ratio. In QFIeld, I often see 0.010 horizontal and 0.014 vertical. Do you understand what's going on here? It almost seems like they are flipped.

[semuadmin]

I had the impression the OP had two setups, one to be base and one to be rover. But still, getting a rover working with a remote base is probably best as a first step.

Exactly. Any fixed or moving base/rover configuration is only as good as its weakest link, so to speak.

In your screenshot, i see hacc 0.014 and vacc 0.010. But hdop is lower than vdop, in not quite the opposite ratio. In QFIeld, I often see 0.010 horizontal and 0.014 vertical. Do you understand what's going on here? It almost seems like they are flipped.

Honestly not sure, but from my limited understanding of how DOP and ACC are derived (the former being essentially a vector geometry calculation, the latter - at least for u-blox devices - a statistical treatment around Kalman filtering) I don't think there's any reason to suppose the vertical and horizontal components of each would necessarily be in the same ratio. More than happy to stand corrected on this.

[gdt]

I will see if I can figure anything out, and actually run your code against a receiver that I then flip to QField. I would sort of expect that there are residuals in the estimation of position from the RTK solution and that this is sort of like a UERE which gets multiplied by DOP. I don't have a good technical argument this minute, but vertical accuracy being better than horizontal just doesn't seem possible.

[semuadmin]

You've probably already seen these discussions... https://portal.u-blox.com/s/question/0D52p00008HKCI5CAP/how-is-haccvaccura-calculated-in-the-m8wm8m