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.
If you want to play with the data:
- Download RF and
- Download gnss-sdr receiver, or
- Download SoftGNSS (change line 62 on initSettings.m to point to the RF file)
