Hacker News Reader

Comment by mNovak | Hacker News Reader

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/

View on HN

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.

Reply on news.ycombinator.com