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.