[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsd hardware with RTK support?

From: Greg Troxel
Subject: Re: gpsd hardware with RTK support?
Date: Mon, 21 Nov 2022 07:36:33 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

Nick Taylor <> writes:

> How can I find out which gps chipsets support RTK?

I would suggest using a search engine.

Also note RTKLIB, which allows RTK with any GNSS receiver which outputs
raw observables.  However I have the impression this may not work quite
as well as some built-in implementatations and it is definitely the hard

You didn't mention "dual frequency" but if you are trying to do RTK I
would strongly recommend a dual-frequency multi-constellation receiver,
or even triple-frequency.

However, you need to understand where your reference data is coming
from, because only signals in the reference data are going to be used.

> Which would people recommend? UBLOX?

The u-blox F9P definitely works well, given a good antenna, good sky
view, and good reference data.  There is also a Septentrio product
family "Mosaic" but I have not used it.  I am not aware of other
sub-$1000 GNSS receiver chipsets that do RTK.  There are of course
things like the Trimble R12, and while they don't seem to post prices I
am sure they are well over $1000 :-( and I have no reason to think they
work with gpsd, or that anybody using them would be using other than an
expensive proprietary-software data collector.

Beware that the ardusimple "WiFi NTRIP master" does not appear to be
maintained, with a last release in the before times: February of 2020.

The sparkfun ESP32 code is actively maintained.

Of course, you don't need either of those if you are going to use a
module and do your own plumbing.

I believe that gpsd can obtain reference data via NTRIP, but that it
does not yet support sending GGA upstream so that the correction service
can produce a VRS/iMAX solution localized to the receiver.  Both of the
above ESP32 codebases can do this.  Sending GGA is necessary for
e.g. the MaCORS network RTK service (operated by the Massachusetts
Department of Transportation) to provide synthetic localized reference
data, which works better than picking a base.

It should be easy to make gpsd do it, but somebody needs to reverse
engineer the spec from the other code and implement it.  It could be as
simple as just writing NMEA sentences to the socket, sending one GGA
every minutes or so.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]