Tuesday, August 22, 2017

Realtime Tracking on a RPi3 - Update

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

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?