Calculating Position from Raw GPS Data (2017) | Hacker News Reader

Calculating Position from Raw GPS Data (2017)

telesens.co

101 pointsuserbinator19 comments

If you're interested in running some code, there's [1] which is fairly active, but as I recall is Linux only. There is also [2] which is a Matlab (or Octave) GNSS receiver implementation; quite well documented and informative. It's meant to be a companion to the author's book [3], which itself I found quite concise and approachable.

[1] https://github.com/gnss-sdr/gnss-sdr [2] https://github.com/perrysou/GNSS_SDR [3] http://gfix.dk/matlab-gnss-sdr-book/

GNSS-SDR is a decently usable software. We use it regularly in our lab with low-cost and medium cost SDRs like Pluto, USRP B series boards (modded with .5 ppm TCXOs). Configuring it for a 15 channel GPS + Galieo L1-band receiver, the CPU usage remains at 120% or so.

is it possible to use it to reach centimeter-precision with dual-band RTK like with two (base+rover) integrated dual-band GNSS RTK modules (e.g. ublox F9P or Skytraq PX1122R)? I mean, your first link seems to show a config example for 1575.42 MHz and 1227.6 MHz, so it would theoretically be imaginable?

I don't even need real-time. I'm fine with sampling/recording the data for the required duration and then running a lengthy (e.g. half an hour) calculation process on it, as long as I get centimeter-precision position data in the end.

These integrated centimeter precision dual-band RTK GNSS modules are unfortunately still terribly expensive (for lack of competition), so it would really be great if this was possible with a <= 250 dollar SDR solution (especially given that SDR hardware can be used for lots of other stuff as well instead of being a one-trick pony like a GNSS module).

I have to imagine there's open source RTK codes out there, but I haven't looked into it. Note that depending on your application, you might not need the dual-frequency component -- that's just to reduce ionospheric error, but if you know to high precision where you base receiver is, the RTK solution at the rover should correct ionospheric delay as well.

If you'd ever get the raw data, you can use RTKLIB* for RTK/PPK. Ublox chips stream the raw data, if you configure it to do so.

*https://github.com/tomojitakasu/RTKLIB

Using rtklib like that with ublox modules was actually the common norm for affordable precision enhancement on a single band at the time of the ublox M8 family, before the era of dual band modules (such as the ublox F9 family), because you could still get relatively cheap modules that didn't have integrated RTK but gave you the raw data so that you could do it externally with RTKLIB. But single-band only i.e. not the same precision as dual-band today.

Nowadays, with dual-band modules, it's no longer necessary nor advantageous to use an external RTKLIB, as the sufficiently precise dual band modules all have RTK integrated i.e. you don't even get decent dual-band GNSS receivers that output raw data but don't have integrated RTK like in ublox M8 times, so there's nothing to be saved by using RTKLIB with available dual-band GNSS modules. And it's not practicable to do dual-band with two single-band modules because you wouldn't get their time references synchronized to a sufficient level for dual-band RTK iirc.

The problem is that the dual-band modules (F9 and such) are - for lack of competition and at least for now and the foreseeable future - waaay overpriced, especially since you need two of them (rover + base) to reach centimeter precision… hence the question about the possibility of doing it with a SDR instead.

just to avoid any misunderstanding: by "you don't even get decent dual-band GNSS receivers that output raw data but don't have integrated RTK like in ublox M8 times" I meant… "like in ublox M8 times" for single band.

Tangentially related, here is the opensource gps software used by a lot of phones:

https://gpsd.gitlab.io/gpsd/index.html

Development primarily lead by Eric Raymond:

https://gpsd.gitlab.io/gpsd/gps-hacking.html

http://www.catb.org/~esr/

gpsd is a service daemon that monitors one or more GPSes or AIS receivers attached to a host computer through serial or USB ports, making all data on the location/course/velocity of the sensors available to be queried on TCP port 2947 of the host computer.

It doesn't do much beyond multiplexing/marshalling. The actual calculations are done in the receiver.

gpsd doesn't do the position determination, it's more or less a clearinghouse for the data once it's been calculated.

Actually taking the raw waveforms from the ADCs and turning them into a (position, velocity, time) solution is an entirely different task.

I'd be remiss if I didn't mention RTKLIB, which is an open-source package to do the PVT solving, using a whole bunch of different algorithms. It ALSO happens to include a bunch of plumbing to stick the pieces together, and thus in some ways overlaps functions of gpsd, but its primary function is actually solving the navigation equations.

Wow I am blown away this is high level IQ stuff. Something we take for granted, the amount of calculations and things to consider in order to be precise is very fascinating. Even though its high level science and math, but all of its logical once you read about it.

Such as the process of calculating position using the pseudorange and the almanac data. I would of never thought of this lol. It also discusses the importance of correcting for errors in the GPS measurements, such as atmospheric delays and satellite clock errors. (totally makes sense right!) The emphasis of the need for careful processing of raw GPS data to ensure accurate and reliable positioning, it makes sense:)

See also Laika, a “Simple Python GNSS processing library”: https://github.com/commaai/laika

A good compliment is this interactive walk-through:

https://ciechanow.ski/gps/

I have previously used RTKLIB, but it seems not to be updated any more: https://github.com/tomojitakasu/RTKLIB

Sub cm horizontal precision has been commercially available since at least 1999.

Differential GPS usually implies a fixed base station and a fixed receiver.

RTK implies the receiver can be in motion. It was central to Trimble products.

https://insidegnss.com/generating-carrier-phase-measurements...

https://www.gpsworld.com/innovation-carrier-phase-rf-ranging...

https://www.vectornav.com/resources/inertial-navigation-prim...

Also related (and fascinating) -- a homemade GPS receiver:

http://www.aholme.co.uk/GPS/Main.htm

It has to be mentioned here, this was developed in 1991-92, before everything was available online, so yeah... the guy is a genius.

Triangulation -> trilateration

Reply on news.ycombinator.com