Navspark: Arduino for GPS, GLONASS, and Beidou

I’m very much into satellite navigation as previous projects might show (my IT travel pack, StartupBus tracking, GPS satellite tracking). Because of this I was very excited to see an Indiegogo project for Navspark, an Arduino compatible GPS, GLONASS, and Beidou receiver. I guess everyone knows GPS, GLONASS is the equivalent Russian satellite network, and Beidou is the same for China.

I have signed up to support it for two main reasons: it’s a Taiwanese project (Skytraq, the company behind Navspark is in in Hsinchu city in Taiwan), and I haven’t seen anything about Beidou before.

They barely made the campaign, but it’s not for the lack of quality. There were a lot of updates during and afterwards as well as the project was developing. Those were good behind the scenes information, got to see what parts of hardware development are more troublesome than others.

The Navspark board

The rewards just shipped this week, and since for this campaign I’m a “local”, I got it pretty early. I got my Navspark GPS/Beidou (BD) version in a big envelope, together with an antenna, some pin and a jumper.

The size of the board is about the same as the Arduino Nano, but not pin-compatible. Navspark’s pins are multiplexed, and multifunctional.

When I first tried to set it up, I’ve run into some issues. The Navspark community site has a lot of information and many tools. I started at the resources page, downloading the User Manual and the customized Arduino IDE made for Navspark. First the IDE didn’t want to run on my 64bit Linux, but they figured it out and posted an update. Then flashing the code to the board failed with a mysterious error message, but they got that one working as well in the next update. This all took about a day, after which I could happily develop with my brand new board, awesome!

Beidou

When I chose my reward during the campaign, I went for the GPS/Beidou version because my HTC Butterfly already has GLONASS reception, and wanted to try something new. Beidou is an interesting because it just wants to be regional, as opposed to GPS, GLONASS, and the European Galileo positioning network that are all going global. Being regional then it can  use geostationary satellites, and fewer than the other networks.

When I was thinking what should be my first project, I thought I use Navspark to take a look at the Beidou satellites, how do they behave.

I’ve tried the antenna, and it worked (naturally) better being outside, I hung it up on the little balcony outside of my window. Compiled the “demo_how_to_extract_gps_info” sketch, and flashed it.

I needed a few tries to start receiving data from the board, but that’s just because my memory was rusty of all the tools needed under Linux to get and to understand GPS/positioning data. Reminded myself how to use gpsd, and gpsmon, but those understood only the GPS part.

Sidetrack: NMEA

When I started to use gpscat, to just split all the “NMEA sentences” (or fragments of data) from the receiver, everything started to make more sense. The NMEA sentences have a 3-letter identifier, what data should be in that sentence. For example the GGA sentence has the location information, while the GSV sentence lists detailed satellite info, or ZDA lists the date and time.

In front of that 3-letter identifier, though there’s 2 more letters, which I didn’t pay attention before, but now it makes sense: those can be used to denote which positioning network the data is coming from. When I looked at the logs, I’ve seen for example “GPGSV”, and “BDGSV” sentences – both are detailed satellite data, but one from the GPS (“GP”) satellites, while  the other from the Beidou (“BD”) satellites. I’ve seen also “GN” as 2-letter identifier, so that’s probably GLONASS. Since this receiver does not have that function, no actual data shows up in those sentences.

There’s a lot of NMEA sentence information online, for more details. As an example, here’s a sentence that lists the first 4 of the Beidou satellites found by the receiver:

$BDGSV,2,1,05,203,59,206,34,208,58,181,42,201,56,140,44,204,00,000,34*6D

Without going into too much detail, here’s what’s inside this line:

“203”, “208”, “201”, and “204” are the pseudo-random number generator  (PRN) code of 4 different satellites, basically a way to identify them. For the GPS network, PRN goes from 1-32, so anything above that is something else. GLONASS has reserved the numbers between 66-85 (will have to check this with my Butterfly). These 200+ numbers are again a different network, the Beidou satellites (though I haven’t found any source yet that spells them out directly).

The 3 numbers after each PRN code is the “elevation” (degree over the horizon), “azimuth” (horizontal direction in degrees), and signal-to-noise ratio (SNR) of the reception. For example satellite 203 has from my location elevation 59°, direction 206° (south-by-south-west), and SNR of 34. The satellite 204 has 0 for elevation and azimuth, meaning it hasn’t been figured out by the system yet.

Recording

I’ve used gpscat to record some (so far about 8 hours) of satellite tracking data, all the NMEA sentences coming out of Navspark. When plugged in, the receiver showed up at /dev/ttyUSB0, and the incoming data stream was correctly received and logged with the command:

gpscat -s 115200N1 /dev/ttyUSBx > navspark.log

Here the “-s” command sets a speed (baud rate) for the USB-serial connection to 115200 bits per second. The “N1” part sets No Parity, 1 stop bit, which is usually the case.. Sometime I could communicate without this setting, but often the wrong baud rate was detected, so I guessed that this receiver likes the highest speed that usually occurs (this 115200 baud rate). Finally, all the output is directed into the “navspark.log”file.

The 8 hours of data adds up to about 15Mb text, and I’ve written a Python script to extract the GPS and Beidou satellite location data. Another python script is used to visualize the tracks on the sky above with Matplotlib. The scripts used can be found in the supplementary files section.

First the GPS tracks. This is quite familiar, fast lines across the sky.

On the image 0° is North, 180° is South, and so on. The centre of the image is right above my location, while the edge of the circle is on the horizon. The satellites are filtered to only show the ones with more than 3000 records, but it’s still a big mess. This is definitely not my greatest plot ever, but it more or less does the job.

Then I’ve plotted the Beidou tracks too. Similar filter is applied, except for the satellite with PRN 209, that I included as well with fewer records. The tracks look like this:

The thing that should stand out is not that there are fewer tracks (of course, since there are fewer Beidou satellites), but that there are two very distinct behaviour.

Satellites 201, 203 and 204 stay pretty much at the same place (geostationary orbit), while 206, 207, 208, 209, 210 are tracing out a path.

Now trying to match this information up with the list of satellites on the Beidou Wikipedia page, I get the following conclusions:

PRN 201, 203, and 204 should correspond to Compass-G1, Compass-G3, and Compass-G4 geostationary satellites. I haven’t double-checked where their location should be visible from here, but their East-West ordering in the group is correct according to this hypothesis. If that’s so, there still should be a PRN 205 (Compass-G5 although might not be visible from here), and no PRN 202 (Compass-G2 is not functioning). Not sure what number the latest geostationary Compass-G6 should have, because PRN 206 is already in use.

PRN 206, 207, and 208 seem to be on the same loop (the three colours adding up to a single loop-of-8). Then these could very well be the Compass-IGSO1, -IGSO2, and -IGSO3 satellites which fly a geosynchronous orbit at “118°E with inclination 55°”. Not sure yet how that orbit should look like, but the position of their loop compared to the geostationary satellites looks promising.

PRN 209 and 210 also seem to be of the same loop, so probably Compass-IGSO4, and -IGSO5, on a geosynchronous orbit “95°E with inclination 55°”.

It’s pretty cool that from a mere few hours of recording we can identify all the Beidou satellites.

An extra mystery

If I check the GPS tracks closely, there are two satellites with code 42 and 50 that don’t look GPS, but geostationary. A bit of search into what they might be showed that they are are the pair of Multi-functional Satellite Augmentation System birds from Japan, to supplement the GPS network. 42 and 50 are their NMEA code, which is equal to PRN-87, so I might have been misusing the “PRN code” terminology, but maybe not too much.

There’s one more satellite with PRN 193 that is out of ordinary. That shows up in a document as Quasi-Zenith Satellite System SV 1 bird. That system is for time transfer, and also to further improve GPS over Japan.

It’s interesting that this receiver can find them. And I guess the Japanese space program does worth to take a deeper look at!

What to do next?

This is a good first experiment, because there are a lot of questions answered, while almost as many new questions popped up. Already have more ideas what to do than time to do it.

• Should compare the position accuracy of this receiver and one of the other USB GPS receivers I have. Not totally fair, because they kinda have a more complete antenna, but maybe under open sky it would work.
• Figure out how GPS and Beidou satellites are used together to get a location. Are they? Or separately?
• Try out the other Navspark functions, which there are many! The examples show ADC, timestamping, SPI, two-wire, 400KHz PWM output. It’s also running on higher frequency (100MHz?) and more program memory (1Mb?) than Arduino.
• Try other programs now playing with GPS, for example gpredict (orbital prediction and tracking). If they don’t have support for Beidou, maybe can try add to them?
• Find my Orbital Mechanics for Engineering Students book, and get learning!

What would you like to do with such hard core geo-positioning tool?