Updates on using an RTL-SDR for GPS on a High Powered Rocket

Back in April we posted about Philip Hahn and Paul Breed’s experiments to use an RTL-SDR for GPS logging on their high powered small rockets. As GPS is owned by the US military, a standard GPS module cannot be used on a rocket like this, as they are designed to fail if the GPS device breaches the COCOM limit, which is when it calculates that it is moving faster than 1,900 kmph/1,200 mph and/or higher than 18,000 m/59,000 ft. The idea is that this makes it harder for GPS to be used in non-USA or home made intercontinental missiles. As SDR GPS decoders are usually programmed in open source software, there is no need for the programmers to add in these artificial limits.

In their last tests they managed to gather lots of GPS data with an RTL-SDR, but were only able to decode a small amount of it with the GNSS-SDR software. In this post Philip discovers a flaw in the way the GNSS-SDR performs acquisition and retracking that GNSS-SDR decodes in such a way that makes it difficult to obtain a location solution with noisy high-acceleration data. By using a different GPS implementation coded in MATLAB, he was able to get decoded GPS data from almost the entire ascent up until the parachutes deploy. Once the parachutes deploy the GPS has a tough time keeping a lock as it sways around. His post clearly explains the differences in the way the code is implemented in GNSS-SDR and in the MATLAB solution and shows why the GNSS-SDR implementation may not be suitable for high powered rockets.

In addition, they write that while the flight was just under the artificial COCOM GPS fail limits for speed and height, the commercial GPS solution they also had on board failed to collect data for most of the flight too. With the raw GPS data from the RTL-SDR + some smart processing of it, they were able to decode GPS data where the commercial solution failed.

GPS data acquired from the RTL-SDR on the rocket.
GPS data acquired from the RTL-SDR on the rocket (blue line shows solution from MATLAB code, yellow shows GNSS-SDR solution, and red shows commercial GPS receiver solution).

3 comments

  1. Philip Hahn

    To be clear, I don’t think it is fair to call it a ‘flaw’ in gnss-sdr. I consciously phrased it softly in my post.

    If you dig into the gnss-sdr documentation you find the passage “In this project, we focus on signal processing, understood as the process between the ADC and the computation of code and phase observables, including the demodulation of the navigation message. We purposely omit data processing, understood as the computation of the navigation solution from the observables and the navigation message, since there are a number of well-established libraries and applications for that.” OpenGNSS is firmly in the second camp as they rely on the calculation of observables from the navigation message and require a valid subframe 1-3 for each satellite or tracking explicitly fails. gnss-sdr focuses on the phase processing of the received signal which is different and can offer a higher precision location however it is likely ill-suited to a noisy, high-acceleration environment.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>