Saturday, July 29, 2017

Realtime GPS tracking with a RPi - Summer Project

Long time no post!

Summer gets busy. Work travel. Kids' sports. Tons of excuses but I am back and have a project in mind: realtime GPS tracking with the Raspberry Pi 3.

It has been done before - Carles and Javier from gnss-sdr coauthored a paper which did some performance testing with the Raspberry Pi 3 (along with other platforms). In this case they only looked at correlating the signal not getting a final lat/lon/alt fix but in a personal communcation Carles verified they were able to track 6-7 satellites in real time.

So I set about to replicate this work. I installed Raspbian and attempted to take the "cheater's way" by installing gnuradio using APT then manually compiling gnss-sdr. It worked, but didn't - lots of overruns. Then with a fresh SD card I tried using Pybombs to compile gnuradio and dependancies for gnss-sdr. This broke partway through compile because gcc in the Raspbian repos is compile --with-arch=armv6 which is apropriate for the RPi1/2 but in order to get the full set of NEON extensions you need a compiler --with-arch=armv7-a. This problem and the solution is documented here. Basically you switch back to the debian repos and proceed. I ran into one dependancy issue libgnutls. When repos are switched the package dependancies break - issue a "apt-get remove libgmp10" before proceeding to install with Pybombs.

I was then able to compile gnuradio overnight, and gnss-sdr in an hour. I could have cross compiled but sleep time is free time.

Unfortunately, I still had overflows. Oddly, I don't have a full core occupied or all of the RAM. Not quire sure where the choke point is.

Talked to Carles - one clue he provided is they used a USRP, not a rtlsdr stick, so it's possible there is a driver overhead issue. I do have a LimeSDR and I plan on trying that.

So here's my burndown list

  • Drop sample rate until overflows go away (much less than 2Msps will likely result in failure to track)
  • Try using LimeSDR 
  • Try using an OrangePi - I have a spare from my robotics projects. The board is smaller and half the price, more powerful than a RPi2 but less powerful than a Raspberry Pi, but its unclear at this point the processor is the issue.


Has anyone successfully tracked satellites on a Raspberry Pi using gnss-sdr?

Tuesday, December 27, 2016

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.

Tuesday, December 20, 2016

GPS Fake-out with the LimeSDR

I've been privileged to receive an early LimeSDR unit to perform some testing and demonstration! Today I'd like to show you the LimeSDR, the 3d printed case I designed for it, and a demonstration of using the LimeSDR to simulate GPS signals.

First, here's the LimeSDR. It was funded via Crowd Supply and features dual TX/RX with operating frequencies of 100kHz to 3.8GHz at 12 bits, full duplex! You can find more information at the Crowd Supply link and at the MyriadRF discourse.


First thing I did was to design a case to be 3D printed to protect the board. I am always paranoid about using bare circuit board. (Part of the reason I've been negligent in posting the past few months is because I caught the 3D printed bug. My kids and I have been busy building and fighting plastic antweight robots at Robot Roundabout) You can download the STL models of the case from Thingiverse. Here's the case in action:


I used a sharpie to mark the channels and TX/RX. I have a CAD model which has those engraved, but my printer is not quite that precise. I'm pretty happy with the case it has served me well. The only thing I might add is a clip to hang it from my laptop monitor like I did with my HackRF. If you decide to use it and have any feedback I'd be happy to take it! 

So once you get your LimeSDR, it is pretty straightforward to set up. Under Linux, follow the instructions on the wiki, with one minor alteration: during step 2.1 do not apt-get limesuite or limesuite-udev. Instead, continue with the instructions as you will be installing LimeSuite from source in Step 4.1. On my machine, anyways, the presence of the lms7 driver from the ppa and the lms driver installed from source confused SoapySDR. If you are using Windows, download the drivers from here, plug it in to your USB port and tell Windows where the drivers reside. You can then download Pothos to run GNURadio and other supported applications in Windows.

So once I was set up under Linux, I did the canonical SDR test of tuning in the FM band in gqrx. And behold, there was spectrum! Next, to probe the features of the device, use the command "SoapySDR --probe". Study the output closely and you will see there are multiple transmit and receive antennas for each channel. Cross-check the names with the LimeSDR Schematic (page 5/6) and you can see the appropriate frequency ranges for each antenna. You will need to know which antenna port your antenna is connected to so you can tell GNURadio which antenna to tune.

On to GNU Radio. If you have your own installation, make sure that gr-osmosdr is installed with SoapySDR enabled. If you use pybombs, you can uninstall gr-osmosdr and then reinstall gr-osmosdr and it should work since you installed SoapySDR two paragraphs ago. Alternately if you don't have GNU Radio installed you can get them from the MyraidRF GNU Radio PPA.

In order to fake out GPS, I needed to either record and replay acquired GPS signals, or generate the GPS signals from software. I opted for the latter, as eventually I want to simulate high speed and high altitude trajectories to test software receivers on the bench. I used gps-sdr-sim by Takuji Ebinuma. An open-source code, it uses a GPS broadcast ephemeris file (one is provided) to orient the satellite constellation, and then based on a user specified location or path you can generate a baseband signal of the GPS constellation. For this first example, I picked a fixed location, 5 degrees latitude, 10 degrees longitude, 15 feet altitude - nice, round numbers that happen to lie outside Nkongsamba in Cameroon. I used 10Msps and 8 bits of I/Q resolution. The command line is thus:

./gps-sdr-sim -e brdc3540.14n -l 5,10,15 -d 60 -s 10000000 -b 8
Now to build the GNURadio flowgraph. On the transmit chain, we need to read in the file generated by gps-sdr sim, convert it from 8 bit interleaved samples (I,Q,I,Q,I,Q...) into 32 bit Complex values for the osmocom sink. For the file source, grab the full file path and set repeat to false. This is what I consider to be best practice because if you repeat, you won't see a change in the statistics of the transmission, but the satellites jump places in the sky and this will cause errant results on the decoding. If you don't repeat, the void will be filled in with null values and this, statistically, is visible to the naked eye in a waterfall. For the osmocom sink, specify the device string and the antenna. 





On the receive chain, our source is the LimeSDR using the same device arguments but specifying the LNAW output antenna. We use the Complex to IChar block to reduce from 32 bit integer to 8 and interleave the samples, and write to file.



The complete flowgraph looks like this:



If you are having trouble setting up your flowgraph, you can download my grc file

On the hardware side you need to connect the transmit antenna (BAND1) to the receive antennal (LNAW). To do this I used a direct connection via SMA cables and an attenuator. Once connected I ran the flowgraph. I then took the recorded file and ran it through my fork of SoftGNSS.




What's next? I want to fake out the flight RTLSDR stack with a rocket-type trajectory with velocity/altitude which violates the so-called COCOM limits. After that, I am going to play with the FPGA on board the LimeSDR. 

Thursday, October 6, 2016

Blue Origin In-Flight Escape Test

Super proud "dad mode" on.

I work for Blue Origin. I had the honor and privilege of representing the company as one of the co-hosts for the live webcast. The full webcast is here, if the director's cut (below) gets your blood pumping you should definitely watch the entire flight.


I've spent the last four and a half years working on the propulsion modules' aerodynamics and integrated simulation. It's my baby. I'm glad to have her back from space after five successful missions, including a triggered in-flight escape. 

More cool footage: here's a frame-by-frame of the escape event:


While I enjoy playing with SDR in my free time - this is my passion. Gradatim Ferociter! 

Tuesday, September 27, 2016

Navigation bit plot

Inspired by http://kom.aau.dk/project/softgps/galileoSdr.php the following plot shows the bits sent by PRN-31 over the course of one hour, recorded about a month ago. Each row is a single subframe (6 seconds) and a total of 300 columns represents the bits from each subframe.


Thursday, August 25, 2016

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.





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. 

Tuesday, July 5, 2016

Paul Breed Rocket Test Flight Data #4: SoftGNSS

So where we last left off, I had successfully tracked the last 15 seconds of coast before apogee using GNSS-SDR. We discovered thanks to a little help from jddes on reddit that there was a loud burst of RF noise (confirmed by Paul to be due to a 900 MHz wireless igniter) which caused GNSS-SDR to lose lock on the GPS signal. It had to reacquire and could not do so for ~ 15 seconds

To quote myself:
There are 30 seconds from ignition to apogee, gnss-sdr loses lock during motor firing (~6 seconds) assuming that is insurmountable there is a maximum of 18 seconds of valid GPS data. Assuming perfection, you could start tracking on the next subframe and have a maximum of 20 seconds of flight data, (if you miss that subframe, 15 seconds) so we're over halfway there.

The assumption, in bold, is incorrect! There is no need to wait for a valid subframe of data to resume calculating pseudoranges, rather, the only thing required is that we are locked onto the signal, ie, that our DLL and PLL are actively and correctly tracking the signals. I am still investigating, but this appears to be due to the way gnss-sdr performs the acquisition and tracking: re-acquisition occurs shortly after the noise source goes away, but tracking doesn't occur until after the next subframe is acquired. I believe this is an implicit assumption in the code which doesn't perform a tracking check until that subframe comes in but I am still investigating and will update this post when I determine the exact culprit.

Earlier this year I read the book A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach. With the book came an accompanying CD with a Matlab-based GPS receiver (GPLv2 licensed) and there are several updates available online. I was unable to run the example data provided with the book and felt gnss-sdr was a far more mature solution. I cached the code for later. After a few months it was gnawing at me that the code wasn't working and I wanted to try and get Paul's data working in another code. It took a week of evenings to get the code up and running, primarily due to Matlab language changes to legacy functions and several bugs in the code. I will document this in an upcoming post along with a link to my repository of the updated code.

It took another evening or two to get Paul's data fed in, as the data type was different (8 bit I/Q instead of 8 bit real) and there were a number of hardcoded assumptions in the code (including file seek operations and FFT bin sizes) that had to be exposed as parameters to get the data working...





...But work it did! The code tracks through the entire ascent until the nose cone jettisons to deploy drogues at apogee, and a few seconds beyond that although it becomes very noisy as the receiver suffers from multipath and the GPS constellation coming in and out of view as the cone tumbles. You will notice the signal is pretty noisy in the east and up components with up to 200 meters of error - this is due to the GPS constellation orientation (bottom right). All of the satellites are in the east quadrant and thus we get excellent resolution in the north direction but poor (ambiguous, one-sided) resolution in the east and up directions. There is a satellite to the west (PRN13) which gnss-sdr picks up. SoftGNSS will acquire it but not successfully track it - if I can get that tracking, the noise in the E/U channels will go away.

Coplotted with the GNSS-SDR data and the Big Red Bee GPS tracker, things fit nicely.



The BRB, gnss-sdr and SoftGNSS all agree on the location of the launch site. gnss-sdr (yellow) loses it at ignition but reacquires near apogee. SoftGNSS tracks all the way past apogee into reentry when the nose cone is swinging under drogue and the BRB reacquires satellites all the way to the ground. Between SoftGNSS and the BRB tracker we have end-to-end GPS coverage for the flight, with gnss-sdr confirmation at liftoff and apogee. The max speed according to SoftGNSS (with generous filtering) is 350 m/s... right about Mach 1. Still below the CoCOM limit for velocity, but as we see the COTS GPS solution loses lock where we are able to tease out a PVT solution.

So why did this work where gnss-sdr failed? Basically, the naivete of the SoftGNSS program design alowed it happen. SoftGNSS only acquires satellites at the start of file (plus specified offset). It then processes the data, tracking the signals with DLL/PLL for the duration of the file. Once all the file is processed it looks for the first subframe and decodes the next 30 seconds of transmission (five subframes at 6 seconds/subframe) to propagate the ephemeris for each satellite. It then takes the timing information from signal that was tracked to calculate pseudoranges. So long as the DLL/PLL retains a lock we get valid pseudoranges and there's no signal saying "We lost lock, stop calculating pseudoranges." More or less. The figure below shows tracking for PRN22. On the bottom left you see the filtered PLL discriminator which stays tight until liftoff where there's notable jump due to doppler (and likely RTLSDR cystal drift due to acceleration).






    Files
    1. Big Red Bee GPS tracker KML file
    2. GNSS-SDR KML file
    3. SoftGNSS KML file


    Action Item List
    1. Update post on cause of gnss-sdr delay in tracking after losing acquisition
    2. Post on SoftGNSS with links to my github repo