RTL-SDR to Orbit with LimeSDR!

As promised, I'd like to show you how the LimeSDR can be used as a GPS simulator to fake out a RTL-SDR device using a rocket trajectory and gps-sdr-sim.

First, I need to thank Dr. Takuji Ebinuma - the author of gps-sdr-sim, who provided me with the rocket trajectory. Takuji designed and built the GPS/GLONASS receiver for the satellite TRICOM 1, scheduled to be launched early next year on the Japanese SS-520-4 rocket. The satellite weighs 3kg and will be spin-stabilizied and contains an earth imaging camera. Here's a picture of the satellite, the GPS/GLONASS receiver is the yellow box:

The rocket is pretty cool too - a 3 stage to orbit vehicle just under 32' long and 2' in diameter which can put a few kilograms into orbit. The launch vehicle is tiny compared to conventional launch vehicles like Altas, Delta or Falcon. Its relative size and scale are encouraging to ambitious amateurs who would like to tackle the project of putting something small into orbit.

More information on the satellite and rocket can be found in this article. Takuji also blogged about it on his blog.

On to the simulation. Takuji provided the trajectory file which is included with his bladeGPS real-time simulator. The trajectory is generated using OpenTsiolkovsky, an open-source rocket trajectory simulator. The trajectory goes from T-60 seconds through the first orbital period but I will only be investigating the first 6 minutes of the trajectory. SoftGNSS only acquires satellites once, at the beginning of processing, so by 6 minutes in several satellites are starting to fall out of view and the GPS fix starts to wander and ultimately fail. However the first 6 minutes are sufficiently interesting as the vehicle accelerates from standing still in the ECEF (Earth Centered Earth Fixed) frame to orbital velocity.

Using gps-sdr-sim (with one tweak - in gpssim.h, change USER_MOTION_SIZE to 3600 or higher to allow for 360+ seconds of simulation, then recompile) the baseband RF can be generated by executing the following:

./gps-sdr-sim -e brdc3540.14n -u ss520-4.csv -d 900 -o trajectory_10M.s8 -s 10000000 -b 8

Then I took the flowgraph I used last time, disabled the receive chain and updated the source file on the transmit chain. I connected the output from my LimeSDR directly to the 1PPM RTL-SDR with bias tee I've been using for testing over the past year. I started the transmission in GNU Radio and then captured the RF using rtl_sdr on the command line like so:

Here is the setup. The USB cable sends samples from GNU Radio to the lime colored LimeSDR. The output from transmitter 1 is sent via SMA cable to the RTL-SDR stick plugged directly in the computer. The samples from the RTL-SDR stick are then captured by rtl_sdr on the command line:

Feeding the output from the RTL-SDR into SoftGNSS, we can see the RTL-SDR captures the trajectory of the rocket from launchpad to low earth orbit. Green satellites are sufficiently strong to track, I use the seven strongest satellites in my navigation solution below.

We can clearly see all three motor burns in the velocity profile. These align well with the values given in the input deck.

Finally, a map showing the ascending trajectory of the rocket as it flies from Uchinoura Space Center in Japan. The three red segments are the three stage burns. Yellow denotes coast phases. 

Now, while this is very exciting, there are a few important caveats

1. The signal generated is perfect: there is no thermal noise or other RF interference
2. The trajectory is idealized: acceleration is smooth and there is no jerk
3. There is no occlusion of satellites due to the location and orientation of the antenna on the vehicle
4. There is no structural vibration or other environmental factors

As such there is no guarantee a RTL-SDR would perform as admirably on an actual rocket.

Next: will be focusing my attention on working with the FPGA.

SoftGNSS w/5 Satellites

I fixed a few small bugs and added a few features. In addition, I played around with skipping the initial few milliseconds of sample time and I'm now able to get a fix with five satellites. This gets a better fix and removes the noise we saw in the last post. We now get a pretty clean trajectory without the 'jitter' until after apogee where the nose cone deploys and the radio is dangling under drogue.

Download kml file.

The speed of sound is 343 m/sec at sea level; the flight briefly but clearly passed the speed of sound. 

I posted my fork of the SoftGNSS code on GitHub so you can attempt to reconstruct the flight for yourself and play with the data. You can also look at other data sources. I'm sure there are still improvements to be made, but the code is usable. The code requires Matlab. To use,

1. cd to \SoftGNSS\GNSS_SDR
2. edit initSettings.m, line 60 to point to the data file (you can download it here, 1.3GB)
3. run 'init'

This code is flexible enough to work with a variety of file formats; a close inspection of initSettings will show you the options you can play with. The Matlab documentation for fread will provide insight into which format type to use for different data types. Experiment boldly!

One thing I haven't teased out yet: The number of satellites acquired varies depending on the number of bytes skipped. A small jump in a file will change the number of satellites seen, which shouldn't happen, barring a satellite moving out of the visible horizon, but in this case I can step through the file every couple of milliseconds and see satellites come and go. My first instinct is to suspect this is due to automatic gain control (AGC) and changes in the AGC may influence whether or not you pick up the weaker satellites. I don't know for sure; it may also be the way the satellite search is performed, but it's something I'd like to tease out in the near future.