Recommendation for low cost GPS RTK solution (offline corrections) ?

Hi! I’m looking for recommendations for a low cost GPS RTK solution for a project and was hoping that the folks here might have some suggestions that can meet that following requirements:

  1. horizontal accuracy <= 5cm (with RTCM corrections)

  2. vertical accuracy <= 5cm (with RTCM corrections)

  3. =10Hz navigation update rate (higher is desirable)

  4. raw logging support (to facilitate offline RTCM correction with RTKLIB)

  5. did I mention low cost? :slight_smile:

The NEO-M8T appears to meet the requirements (1)-(4) but is pricey (for my BOM budget anyway).

Does know of GNSS modules that meet the requirements and are cheaper?

Any creative solution suggestions?

Thanks in advance.

ZeroMho

I don’t think the M8T will realistically get you to 5cm.

And the “T” Variant appears to be built specific to help with Timing.

Take a look at pages 3 & 4 of the Product Overview Doc :

https://content.u-blox.com/sites/defaul … 000426.pdf

For <5cm, you are looking for Multi-Band and High Precision - which appears that the ZED-F9P (or R variant) would be the best available from U-Blox to meet your requirements.

Post-Processing M8T generated measurements can get convergences below a cm, the containment of the carrier signal in the correlators is less than a mm. The same exact HW design is use in the NEO-M8P, and the NEO-M8N for that matter…

To get to “low cost” is to find the cheapest module/chip which you can recover raw measurements from, and process yourself with RTKLIB, or something equivalent. The trade here is your ability to do the work externally vs getting firmware to do it on the module. There’s a premium there because it’s a non-trivial exercise.

There are sub-$20 modules that can recover raw-measurements for dual-band GNSS, the costs then move to your software and a platform that can run sufficiently fast for the computational work load. Figure perhaps a RPi running at a few GHz

I’m not sure there are any uBlox modules that can do multi constellation RTK at 10 Hz, the spec value on the F9P keeps dropping, perhaps 7 Hz now, and the F9R/F9K have always been much slower, with the high/priority navigation rates in the 30-50 Hz type range coming from the sensor fusion, and gate-posted by much slower RTK solutions.

Post Processing and RTK are obviously 2 entirely different paths.

There appears to be some ambiguity (pun intended) in the OP’s intentions. :smiley:

Yes, would appear the underlying question is for low cost modules which can support “Raw Measurements”, and technically for uBlox’s parts that’s ALL of them.

Hi. First, thank you all for answering so quickly with great information.

I think I might have confused the issue by using the term “RTK”. I’ll do my best to clarify what I’m trying to do.

The use case I have does not require “real time” processing where the correction stream is received by the rover and applied in real time to yield the high precision position estimate. I do want to achieve high precision positional estimates, but I can do the processing offline after the rover has returned from its journey. Think “GPS data logger” not “GPS real time navigation”.

Modules that do RTK tend to be quite expensive since they have to do a lot of work (receive both satellite and a correction data stream and do the computation in real time to yield position estimates). Since I don’t need correction processing to happen on the rover (I’ll do it offline later), I should be able to get away with a cheaper GNSS module that doesn’t have RTK capability on board. As I understand things, not just any GNSS module will do. The module must provide “raw” satellite data if one wants to post-process the rover data with an RTCM correction stream (with RTKLIB).

One more thing… The use case I have doesn’t require high position accuracy (meters is fine), but it does require high precision (<10cm). It’s relative position I care most about, not absolute position. I don’t think this should matter too much to the choice of module, but I wanted to mention this for completeness.

I hope this clarifies the use case.

So it comes down to the following question:

What low-cost GNSS modules support “raw” data logging, that, combined with a corrections stream (offline) can achieve better than 5cm positioning precision and >10Hz update rate?

Thank you all again for your helpful comments.

clive1:
Yes, would appear the underlying question is for low cost modules which can support “Raw Measurements”, and technically for uBlox’s parts that’s ALL of them.

Thanks @clive1. I’ll take a look through the uBlox product line.

clive1:
Post-Processing M8T generated measurements can get convergences below a cm, the containment of the carrier signal in the correlators is less than a mm. The same exact HW design is use in the NEO-M8P, and the NEO-M8N for that matter…

That's incredibly impressive. Way better than I need.

To get to “low cost” is to find the cheapest module/chip which you can recover raw measurements from, and process yourself with RTKLIB, or something equivalent. The trade here is your ability to do the work externally vs getting firmware to do it on the module. There’s a premium there because it’s a non-trivial exercise.

Yup, this is exactly what I'm hoping to do. I'm looking to reduce BOM cost at the expense of "owning" the offline corrections computations. AFAICT RTKLIB has done the hardest work. It should be more of an integration effort rather than having to implement an estimator from scratch.

There are sub-$20 modules that can recover raw-measurements for dual-band GNSS, the costs then move to your software and a platform that can run sufficiently fast for the computational work load. Figure perhaps a RPi running at a few GHz

Please can you list some that you know of? This is what I'm looking for.

I’m not sure there are any uBlox modules that can do multi constellation RTK at 10 Hz, the spec value on the F9P keeps dropping, perhaps 7 Hz now, and the F9R/F9K have always been much slower, with the high/priority navigation rates in the 30-50 Hz type range coming from the sensor fusion, and gate-posted by much slower RTK solutions.

Good to know. Thanks.

Thanks for the excellent info here.