Software Defined GPS

Pages

Thursday, December 21, 2017

Paul flew again last Saturday, December 16th from the FAR launch site. If you recall this summer I was fiddling with the Raspberry Pi and Intel Compute Sticks to find the best realtime platform for flight. I had troubles with the Pi, but the first-gen compute stick was able to (barely!) run six trackers. Paul wound up buying a more recent compute stick. This one sports a more recent quad core processor and enough on-board storage to record several test flights (in case of scrub etc.). It comes with Windows 10, and spending a half hour playing with it was actually quite snappy, but ultimately reformatted it and installed Ubuntu Server. The Cherry Trail architecture is fully supported which means both wifi and ethernet work out of the box, even on the console with server.

I meant to have a post on the receiver hardware earlier, but time flies. Briefly, the stick is set up to run gnss-sdr on boot, if a RTLSDR device is plugged into the USB port. gnss-sdr will then attempt real-time tracking while simultaneously dumping the RF signal complex samples to file for post-flight reconstruction. One downside to this is that because of the combination of receivers being used the file dump type is gr_complex which is 32 bits/sample instead of the native 8 bits/sample. The tooling lives here along with the receivers for both realtime and post-flight execution but I need to write up some documentation to make it clear what is what. I tried to use rtl_mus (RTL multi-use server). This would allow one service to stream samples to both gnss_sdr and to file (at native 8 bits/sample, giving 4x the sample storage) but alas I could not get this working reliably and so far as I can tell there is no way to guarantee I and Q pairs as opposed to missing the first I and then getting Q-I pairs.

I sent the stick to Paul. Bench testing weeded out a bad amplifier, once that was replaced we were able to get a nav solution. Paul packaged it all up in the nosecone flight configuration and ... nothing! Likely interference from the electronics, I got the "probably not going to fly tomorrow" email. But then the next day I got the "aluminum tape shielding worked, so I flew it" email!

Unfortunately the on-board realtime tracking got a good fix on the pad, but nothing in flight. Disappointing, but having the RF to post-process is valuable. I tried re-running the code through gnss-sdr several times with several tweaks to the receiver to no avail - spotty tracking on the pad and nothing in flight. So I did what I've done in the past and falled back on SoftGNSS, an offline Matlab-based GPS receiver (link is to my github version of it; updated to run in modern Matlab environment). I had to add the capability to read in complex floating point numbers (prior to this we always logged 8 bit integer samples) but it more or less worked out of the box. As mentioned in previous posts, SoftGNSS is somewhat naive but that naivete means it works where gnss-sdr has to date had trouble, that is with noisy signals. gnss-sdr will drop a satellite receiver if it loses track, whereas SoftGNSS will continue to process that satellite blissfully unawares, which comes in useful when the signal is noisy because yes, you get a few bad samples but then you are back in business.

Seven satellites were tracked through the entire flight. Blue satellites had a low S/N (or were occluded). PRN 5, 21 and 32 were excluded as they had a high S/N but invalid doppler ranges. It is unclear if the code is screwing up the doppler calculation or if the S/N calculation is in error. My gut says the latter because gnss-sdr did pick up PRN 5 and PRN 32 at some point during the flight.

They are plotted below by PRN, the line traces the view of the satellite and the circle is where the satellite started. Axes are azimuth, elevation.

Here are line traces of the range up, east and north, in meters. There is a jump in north position prior to apogee and then in all 3 directions around 100 seconds. Culprit is unclear. Drogue deployment should have been shortly after apogee. It is basically using barometric pressure to find apogee by looking for an inflection in the derivative of pressure. It is possible, but unlikely it fired early. It is more likely that the something went awry in the tracking causing a jump in one of the pseudoranges (I need to dig in). Main deployment is at 1000ft which is where I cut off the plot, because at that point the antenna is occluded (dangling up side down near ground level) and the tracking is all over the place.

And here is a view of the launch site - trace is pretty close to the pad.

And here is the trajectory. It is noisier than I would like but after apogee it is dangling under drogue. I still don't have a good explanation for the kink in the trajectory prior to apogee.

Tuesday, August 22, 2017

If you read my last post, my GPS project for this summer was to get gnss-sdr working in realtime on a Raspberry Pi 3 using gnss-sdr. Unfortunately to get right to the punchline, I failed to do so. Using pybombs I built GNURadio and gnss-sdr from scratch along with dependancies that weren't in the apt archive. I tuned the Volk profiles to use the NEON extensions, but my flowgraph suffered from overflows. I tried eliminating the prefiltering and reducing the doppler shift range in the acquisition block and was able to nearly get rid of overflows but by then the doppler range was so small as to not acquire satellites!

I still think I may be doing something wrong. Carles, Javier and others from CTTC in Spain wrote a paper where they document the performance of several platforms including the Raspberry Pi 3. They were able to correlate 6-7 satellites. I was unable to replicate, but there were several confounders. Namely, they used a USRP over network connection whereas I was using a RTLSDR over USB. They are using different source blocks (UHD vs. osmocom) different physical hardware/drivers (Ethernet vs. USB) and it is difficult to tease out the actual culprit.

So, I tried using the first generation Intel Compute Stick we use for the data logging on flight. Like the Raspberry Pi, I had to build GNURadio and gnss-sdr from scratch (it comes loaded with Ubuntu 14.04 and the apt packages don't exist until 16.04) but it only took about 8 hours to complete with two cores. I did disable unit tests when compiling gnss-sdr as gcc would get hung up during unit test compilation (ran out of physical memory and swap, 1GB each). When I first ran it overflowed but just barely. Removing the prefilter and it worked great with four satellites. And five. And six. Seven caused overflows and it couldn't hold a track, so six satellites it is.

The plan is to track a GPS fix in flight sometime in the near future. This platform is acceptable, but barely. Four satellites are the bare minimum to get a fix, but more is better as it improves the quality of the fix (the root-sum-square [RSS] of the satellites minimizes the influence of a 'bad' invidiual satellite fix). Also in flight during long durations/distances the view in the sky will change and you will necessarily lose satellites and gain new satellies. The process of losing multiple satellites (>2) means you completely lose your fix. Losing 1-2 would merely lose precision. Ideally you can track 8-11 satellites with a good view of the sky.

So, do we stick with the Intel Compute stick or try something a little more computationally advanced? Stay tuned...

Saturday, July 29, 2017

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

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.

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:

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.

Tuesday, December 20, 2016

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.

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

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

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.

RTL-SDR GPS

Movember in Memory of Micah Hahn

About

Investigations into using cheap SDR hardware to track GPS satellites. Hardware provided by Paul Breed of Unreasonable Rocket. End goal is to track high power rockets in high acceleration / speed / altitude environments.