GNURadio XMLRPC hints

If you are like me with a Windows computer using GNURadio in a VMware virtual machine, here's what you need to know to XMLRPC from a remote computer into your VMware instance on your local machine.

First, you need to make sure your VMWare instance is using a bridged connection. A bridged connection will present your VMware instance as a separate computer to your router giving it a unique IP address on the LAN (note: it is possible to use NAT, where the VMware instance appears on a private LAN to your PC, but the configuration gets messy for port forwarding)

Now, you should be able to use XMLRPC on your LAN. Download the example scripts from the GNURadio repository. In your virtual machine open up 'xmlrpc_server.grc' in grc. Open up the XMLRPC server block and change the IP address from 'localhost' to '0.0.0.0' and the port to whatever port you want to use.

If you use 'localhost' you will default to the local loopback device and will not be able to reach it from outside the VM instance. Execute the diagram and start the server - you should see a window pop up with a scope and FFT. 

You will need to get your VMware instances' IP address using ifconfig or some other tool. In my case it is 192.168.1.10.

On your client machine, download the example scripts and open up 'xmlrpc_client.grc' and edit the XMLRPC client blocks to use the IP address of your VMware instance and the same port

Execute the diagram and move the slider - you should see it update on the server.

Now, if you want remote access from outside your LAN we need to configure the router. First off for convenience' sake give the VMware instance a static or reserved IP address so that the MAC address of the VMware instance will always get the same IP address on the local network. Now, we can configure port forwarding, in which your router will take incoming traffic on a certain port and forward it to your virtual machine. My configuration looks like this:

Now you need to determine your routers' IP address or - better yet - set up a dynamic DNS address so that you can use a URL to always hit your router. I'm not telling you mine :) but I use a free one from freedns.afraid.org. Now go to your off-the-lan computer and update the XMLRPC client as above, but with your router IP address or dynamic DNS. If you did everything right it will work!

Paul Breed Rocket Test Flight Data #3: MOAR RESULTS!

I got a little help on Reddit. Thanks to PE1NUT for identify a way to visualize the crystal drift in the data and jddes for doing some sleuthing: he identified some On Off Keying (OOK) right at ignition. Sure enough; I loadded the data up in Inspectrum (which I should have done in the first place!):

Turns out Paul is using a 900 MHz wireless transmitter to ignite the rocket which sends OOK for about 1.5 seconds, which leave its mark at 1.5 GHz! There are peaks at ~ -300kHz and ~ +650kHz.

So I played around with filtering the data with mixed success initially. When you look at the data, the intermediate frequency (IF) is 110 Hz, or damn near zero, so half the spectrum is negative in frequency and the other half is positive. In order to filter just one half of the spectrum you need to have complex taps on your FIR filter. Now, the problem is most of the GNURadio filter blocks don't expose complex taps! The generic FIR filter and the band pass filter do but you have to provide the taps. Fair enough... but the gui to firdes (Finite Impulse Response Design tool) doesn't expose complex taps either! Ideally we'd want two band reject or notch filter. But since the band pass filter does work with complex taps we can add (n+1) band pass filters together to do the same thing - we just band pass two chunks instead of band rejecting one. Ultimately the flowgraph looks like this:

I also put in an automatic gain control block to try and deal with the jumps in the spectrum (horizontal lines). You can download the flowgraph if you like.

The easiest way to just filter a chunk of time is to split up the data file into three - the first part, the noisy part, and the last part. A combination of "split -b" and "head -c" are used on the command line, then the files are re-merged with CAT.

Here's the cleaned-up spectrum. There's still some jumps in the spectrum but the peaks are nulled out. We lose data, but the hope is that the data lost is outweighed by the interference removed.

I still don't get a valid fix during engine firing but I do reacquire satellites a bit quicker... meaning more data in flight!  Updated trendline in black. Tracking from ~ 3500m to 5000m, covering 12 seconds of flight. 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. Of course, not losing it during the motor firing would be ideal!

Money shot

Paul Breed Rocket Flight Test Data #2: PROGRESS!

I GOT A gnss-sdr PVT SOLUTION IN FLIGHT!

Success kid is successful.

So I managed to get a valid navigation solution for ~ 7 seconds in flight close to what I presume is apogee, absent additional information. Paul flew an IMU but lost the SD card and a Big Red Bee GPS tracker which is, of course, subject to CoCom limits. Below I plotted both the RTLSDR (in red) and the Big Red Bee (in yellow... in retrospect this should have been red!)

I removed spurious readings from the GPS tracker: these are easy to identify because the GPS time is out of sync. The long red and yellow lines connect the dots from the last good reading on the pad to the first good reading in flight, and are not representative paths per see. If we assume data to be correct it appears the RTLSDR acquires a navigation solution at a higher altitude than the BRB, which based on the speed and drift is operating under chutes. Next up I extracted the the lat/lon/alt from the PVT solution generated by GNSS-SDR (again, the blue line is just connecting the last good fix on the pad with  the first good fix in flight). The data is aligned with the last good fixes for both the RTLSDR and BRB. 

Now we get confirmation that the RTLSDR does indeed acquire before the BRB, and a little mental extrapolation can connect the dots between the last RTLSDR sample and the first BRB sample post-launch if we presume the rocket is drifting steadily under a drogue parachute. (The inflection in the BRB is likely going from drogues to main chute - awaiting confirmation.)

The rocket pops the nosecone at apogee to deploy a drogue chute, at which time the nosecone is swinging in the breeze and we don't anticipate getting any data from the RTLSDR because the directional antenna is no longer pointed up. However the BRB is expected to get a fix under chutes, when within the CoCom limits. My thesis is that we get a valid GPS solution about 7 seconds before popping the nosecone and deploying the drogue, which then causes us to lose track on most of the satellites and thus lose our navigation solution. Indeed, the rest of the flight is filled with messages of acquiring and subsequently losing acquisition of satellites.

Here's an excerpt of the output from just before liftoff to just after apogee:

Current input signal time = 145 [s]

NAV Message: received subframe 3 from satellite GPS PRN 22 (Block IIR)

NAV Message: received subframe 3 from satellite GPS PRN 31 (Block IIR-M)

NAV Message: received subframe 3 from satellite GPS PRN 1 (Block IIF)

NAV Message: received subframe 3 from satellite GPS PRN 14 (Block IIR)

NAV Message: received subframe 3 from satellite GPS PRN 3 (Block IIF)

NAV Message: received subframe 3 from satellite GPS PRN 10 (Block IIA)

NAV Message: received subframe 3 from satellite GPS PRN 25 (Block IIF)

Position at 2016-Feb-06 18:45:47 UTC is Lat = 35.34828164793844 [deg], Long = -117.8089714500355 [deg], Height= 646.4366382388398 [m]

Current input signal time = 146 [s]

Position at 2016-Feb-06 18:45:48 UTC is Lat = 35.34792485975112 [deg], Long = -117.8090110485498 [deg], Height= 653.1580742103979 [m]

Current input signal time = 147 [s]

Position at 2016-Feb-06 18:45:49 UTC is Lat = 35.34836233536886 [deg], Long = -117.8087743892498 [deg], Height= 622.0710280425847 [m]

Current input signal time = 148 [s]

Position at 2016-Feb-06 18:45:50 UTC is Lat = 35.34776621261069 [deg], Long = -117.8090573844694 [deg], Height= 649.063727453351 [m]

Current input signal time = 149 [s]

Position at 2016-Feb-06 18:45:51 UTC is Lat = 35.34842555835016 [deg], Long = -117.8087875236563 [deg], Height= 634.0006730658934 [m]

Current input signal time = 150 [s]

Position at 2016-Feb-06 18:45:52 UTC is Lat = 35.34802741910629 [deg], Long = -117.808877076439 [deg], Height= 641.1753705441952 [m]

Current input signal time = 151 [s]

NAV Message: received subframe 4 from satellite GPS PRN 22 (Block IIR)

NAV Message: received subframe 4 from satellite GPS PRN 10 (Block IIA)

Loss of lock in channel 5!

Tracking start on channel 5 for satellite GPS PRN 11 (Block IIR)

Current input signal time = 152 [s]

Loss of lock in channel 6!

Loss of lock in channel 3!

Tracking start on channel 6 for satellite GPS PRN 31 (Block IIR-M)

Tracking start on channel 3 for satellite GPS PRN 14 (Block IIR)

Loss of lock in channel 0!

Tracking start on channel 0 for satellite GPS PRN 1 (Block IIF)

Loss of lock in channel 4!

Tracking start on channel 4 for satellite GPS PRN 22 (Block IIR)

Current input signal time = 153 [s]

Loss of lock in channel 5!

Tracking start on channel 5 for satellite GPS PRN 11 (Block IIR)

Loss of lock in channel 6!

Tracking start on channel 6 for satellite GPS PRN 31 (Block IIR-M)

Loss of lock in channel 3!

Tracking start on channel 3 for satellite GPS PRN 14 (Block IIR)

Loss of lock in channel 0!

Tracking start on channel 0 for satellite GPS PRN 1 (Block IIF)

Loss of lock in channel 4!

Tracking start on channel 4 for satellite GPS PRN 22 (Block IIR)

Current input signal time = 154 [s]

Current input signal time = 155 [s]

Loss of lock in channel 4!

Tracking start on channel 4 for satellite GPS PRN 22 (Block IIR)

Current input signal time = 156 [s]

Current input signal time = 157 [s]

Loss of lock in channel 4!

Tracking start on channel 4 for satellite GPS PRN 22 (Block IIR)

Current input signal time = 158 [s]

Current input signal time = 159 [s]

Current input signal time = 160 [s]

Current input signal time = 161 [s]

Current input signal time = 162 [s]

Current input signal time = 163 [s]

NAV Message: received subframe 1 from satellite GPS PRN 11 (Block IIR)

NAV Message: received subframe 1 from satellite GPS PRN 14 (Block IIR)

Current input signal time = 164 [s]

Current input signal time = 165 [s]

Current input signal time = 166 [s]

Current input signal time = 167 [s]

Current input signal time = 168 [s]

Current input signal time = 169 [s]

NAV Message: received subframe 2 from satellite GPS PRN 11 (Block IIR)

Current input signal time = 170 [s]

Current input signal time = 171 [s]

Current input signal time = 172 [s]

Current input signal time = 173 [s]

Current input signal time = 174 [s]

Current input signal time = 175 [s]

NAV Message: received subframe 3 from satellite GPS PRN 1 (Block IIF)

NAV Message: received subframe 3 from satellite GPS PRN 11 (Block IIR)

NAV Message: received subframe 3 from satellite GPS PRN 14 (Block IIR)

NAV Message: received subframe 3 from satellite GPS PRN 3 (Block IIF)

Current input signal time = 176 [s]

Position at 2016-Feb-06 18:46:18 UTC is Lat = 35.3536423978743 [deg], Long = -117.8154004936006 [deg], Height= 4891.649443297647 [m]

Current input signal time = 177 [s]

Position at 2016-Feb-06 18:46:19 UTC is Lat = 35.35313826705141 [deg], Long = -117.8151172574466 [deg], Height= 4786.770911485888 [m]

Current input signal time = 178 [s]

Position at 2016-Feb-06 18:46:20 UTC is Lat = 35.35361800624526 [deg], Long = -117.8156283909009 [deg], Height= 4907.156536793336 [m]

Current input signal time = 179 [s]

Position at 2016-Feb-06 18:46:21 UTC is Lat = 35.35351364315449 [deg], Long = -117.815566988265 [deg], Height= 4801.439769400284 [m]

Current input signal time = 180 [s]

Position at 2016-Feb-06 18:46:22 UTC is Lat = 35.35325156470748 [deg], Long = -117.8156706709576 [deg], Height= 4741.917847431265 [m]

Current input signal time = 181 [s]

NAV Message: received subframe 4 from satellite GPS PRN 22 (Block IIR)

NAV Message: received subframe 4 from satellite GPS PRN 1 (Block IIF)

NAV Message: received subframe 4 from satellite GPS PRN 31 (Block IIR-M)

NAV Message: received subframe 4 from satellite GPS PRN 11 (Block IIR)

NAV Message: received subframe 4 from satellite GPS PRN 3 (Block IIF)

Loss of lock in channel 7!

Current input signal time = 182 [s]

Tracking start on channel 7 for satellite GPS PRN 23 (Block IIR)

Loss of lock in channel 3!

Tracking start on channel 3 for satellite GPS PRN 26 (Block IIF)

Current input signal time = 183 [s]

Therefore, based on the output and plots, I believe liftoff takes place at 151 seconds, engine burns for ~ 5-6 seconds (highlighted in yellow), with apogee occurring at 182 seconds, or roughly 30 seconds on ascent. Apogee of ~ 4850 meters ASL.

The numerous subframes from 163-182 seconds show we are still getting some meaningful data which could be interpreted by a fft-based approach like fastpgs.

So what did you change?

I lowered the bandwidth of all 3 tracking loops by roughly half. Previously I had increased the bandwidth on the loops figuring more bandwidth = ability to deal with rapid shifts in phase/frequency but my intuition was incorrect. I'm still a DSP newbie but I am learning.

To Do

1. Continue playing with tracking loops 
2. Investigate fastgps fft-based solutions

Files

1. BRB.kml - Big Red Bee GPS Logger
2. RTLSDR.kml - RTLSDR tracking

Paul Breed Rocket Flight Test Data!

This post is long overdue as I've been quite busy with my day job that I've been remiss in updating the blog with the progress happening with the rocket GPS.

On February 6th, 2016 Paul Breed flew an RTL-SDR on a high power rocket to capture GPS RF data for post-processing. This was the second test flight and the first one to get good data.

Hardware Configuration

Paul shows off the payload. The blue box outlines a 6DOF IMU, the orange box is a LNA4ALL low noise amplifier. On the reverse the orange box outlines a 2S LiPo battery, the green box a Nooelec 0.5PPM TXCO in aluminum case and the blue box an Intel Compute Stick running Ubuntu, and the yellow trapezoid a quadrifilar antenna GPS antenna from antennas.us.

Backside of RF capture unit.

Frontside of RF capture unit.

Hardware Configuration

They payload is packaged inside the nosecone fairing of the rocket. Here, the rocket is mounted on the launch rail in a horizontal configuration. Before launch the rail is elevated to near vertical, but this orientation allows for easy handling of the rocket.

Rocket mounted on the launch rail

At T-2 minutes (2 minutes prior to launch) the rocket begins aquiring data - Paul SSH's over wifi into the Intel Compute Stick to trigger a script which calls rtl_sdr centered on the L1 frequency with a bandwidth of 2048000 Hz. Two minutes is sufficient time to get multiple GPS fixes of the launch site.

And at T-0, smoke and flames!

Liftoff!

Post-flight analysis

I took the output from rtl_sdr and converted it to complex for gnss-sdr. I was able to get a fix on the pad but not much after that. The last fix was at about 145 seconds - liftoff was likely between 145 and 150 seconds. I attempted to make a few tweaks to the tracking loop configuration gnss-sdr file with little success - it changed the results but not the actual character, that is not a whole lot after liftoff. I did find I was able to get a few subframes well after launch - 3 with the final configuration file - but not enough to get a fix. But there are other codes to be investigated which can get an approximate fix without a full 4 satellite solution.

One of the productive changes was decreasing the step size of the doppler search - this performs a more refined search and reveal more post-launch subframes. Initially I had one subframe and through tweaking the search step size (to 100 hz) I was able to get three. It is tempting to increase the doppler window but the max doppler shift of a GPS satellite to a stationary receiver is ~ 5kHz and the default search window is +/- 10 kHz - unless you are going orbital velocity at the satellite while it is coming at you, you are well within 10 kHz.

Here's the KML file in Google Earth. Don't get too excited about the altitude jumps! There are two of them in the file one occurs during the first few fixes and the last ones are of similar magnitude. I've seen the same thing happen with fixes at home. We know for the early jumps the rocket is sitting soundly on the pad and the latter jump is of the same magnitude.

I took the GPS time from gnss-sdr and used an online tool to back out the orientation of the satellite constellation during the rocket flight. The arrows point to the satellites which were used to get position fixes as output in the RINEX files. It is interesting to see some satellites which appear farther away on the map are useful to getting a fix where closer ones are not - however that's only half the story.

If we look at altitude (the earth is crudely pointed so the launch site is oriented up towards the top of your monitor) we see the satellites it uses are largely overhead and the "closer" satellites are on the horizon.

I also looked at the two satellites which gave valid subframes after T-0, they are PRN 3 and PRN 11, shown here.

So why didn't we get a good fix in flight? There are two likely culprits - the vibration / acclereation environment and the loop dynamics. Both vibration and acceleration affect the crystal which effects the frequency being captured. If the tracking loops are off then we'd anticipate losing satellite  directly overhead (in the direction of acceleration) and not laterally where the acceleration of the rocket doesn't effect things much. I tweaked the tracking loops as far as I could without making results worse and they didn't seem to get any better. Based on the fact that one of the satellites is fairly high in the sky my gut suspects the acceleration/vibe environment.

UPDATE: Got a brief in-flight nav solution; see this post!

But there's still work to be done to try fft-based approaches like fastgps, dig into the intermediate outputs and see if some smart people out there have ideas!

Thanks to Paul for providing the data, test hardware and ideas on how to look at and understand the data. Follow his blog or twitter!

Files

1. Feb6.bin - raw RTLSDR binary file (interleaved shorts) you will need to convert to complex.
2. flight.conf - gnss-sdr configuration file
3. output.log - Console output from "gnss-sdr --config_file=flight.conf"
4. PVT.kml - Position fixes in Google Earth format
5. GSDR086x11.16N - Navigation data in RINEX format 
6. GSDR086x11.16O - Observation data in RINEX format

Next Actions

1. Investigate gnss-sdr telemetry and tracking outputs
2. Try running through fastgps code 
3. Get help from smart gps/sdr folk!