Hardware

To have a really good really good, satellite-powered reference clock, I have to have access to a 1-pulse-per-second (1PPS) signal from the receiver. The pure USB-connected receivers don’t really seem to do that yet (looks like plenty of opportunities there!), instead I have to use separate hardware for it.

The Navspark module has a 1PPS pin (GPO3 below), and the only other pin I’ll really need is a serial pin to receive the NMEA stream of the satellite lock data (TXD1 below).

These pins have to be connected to a Raspberry Pi 2’s GPIO pins.

Based on the pinout above, and some digging around, the connections I needed to make between the Pi (left) and Navspark (right) were:

• 5V  BATTERY
• Ground GND
• GPIO15 (UART0_RX) TXD1
• GPIO8 P1PPS (GPO3)

Some things to remember here, that on serial connections one side’s RX line is connected to the other’s TX  and vice versa. Also, as much as I gather any other GPIO pins on the Pi could be used to receive the 1PPS signal, I used GPIO8 because it’s been used by other projects and playing it safe…

The adapter board was easy enough to put together (though single-side pads are a pain when the components are on both sides, as it is the case here).

The adapter works well enough, though I’m sure that it could be done nicer.

Software

I found a lot of examples and help from other people’s similar projects but there were still some differences to be figured along the way. The overall setup was to be as follows:

• ArchLinux ARM for base platform
• gpsd for interpreting the Navspark NMEA messages
• LinuxPPS for 1PPS signal passing from GPIO to the userspace
• chrony as time server (as opposed to the usual ntpd)

Installing the system was straightforward enough (well, because I’ve done it so many times, but I digress), and added a few required basic packages: gpsd, chrony, git, the base-devel group, avahi (for easier network discovery).

GPSD

UART0 serial communication is done through the /dev/ttyAMA0 device in Pi, though the default settings needed some change for gpsd to be able to receive the data from Navspark.

Most of the changes our outline in a blogpost where I have learned from as well. First remove all config settings from /boot/cmdline.txt, basically these parts:

console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

Next disable the automatic serial console on that device with removing relevant systemd unit with

sudo systemctl disable serial-getty@ttyAMA0.service

Then have to set up the serial channel’s baud rate to enable communication, and here I’ve done that with udev: create a new rule file at /etc/udev/rules.d/AMA0_serial.rules with the content of

KERNEL=="ttyAMA0", RUN+="/bin/stty -F /dev/ttyAMA0 115200 raw -echo"

which will set the 115200 baud rate used by Navspark when the ttyAMA0 device comes up.

Finally have to add gpsd’s default settings in the /etc/gpsd file:

# Default settings for gpsd.
START_DAEMON="true"
GPSD_OPTIONS="-b -n"
DEVICES="/dev/ttyAMA0"
USBAUTO="true"

Now it’s ready, and should be able to run gpsd and see some communication.

sudo systemctl start gpsd

and if want to start it on boot, then run the same command with “enable” instead “start”. Use gpsmon to see what NMEA data Navspark sends, and hopefully it will lock on soon too (mind the sky visibility!). Can also use cgps to monitor which satellites the system is locked onto.

1PPS

For 1PPS I had to add an item to /boot/config.txt:

dttoverlay=pps-gpio,gpiopin=8

This adds the relevant device tree overlay to enable the pps-gpio driver on GPIO8. Upon boot there was a /dev/pps0 device that can be poked at e.g. with ppstest from pps-tools. Since pps-tools did not have a package on ArchLinux, I made one, and the PKGBUILD is available on Github. That package also adds the timepps.h header file which is required for the chrony PPS driver to work.

The pps signal can be checked by running ppstest:

$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1448436177.999366423, sequence: 199 - clear  0.000000000, sequence: 0
source 0 - assert 1448436178.999373610, sequence: 200 - clear  0.000000000, sequence: 0
...

but it needs a 3D fix for the signal to show up.

Chrony

Next up is the time server itself. The satellite time will be pulled in using two “reference clock”: the GPS timestamps provided by gpsd through a memory interface, and the PPS data that locks those timestamps. Unfortunately the PPS driver is not built in by default because it needs the timepps.h header. This means after installing pps-tools chrony needs to be recompiled.

Update the chrony configuration by editing the /etc/chrony.conf file. I usually leave the defaults alone, and add my modifications to the end of the file for clarity. Here’s my current setup:

lock_all

logdir /var/log/chrony
log measurements statistics tracking refclocks

# being a server
allow 192.168/16

server 2.tw.pool.ntp.org iburst
server 3.asia.pool.ntp.org iburst
server 2.asia.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst

# on-boot time setup, from https://news.ycombinator.com/item?id=9796885
makestep 0.1 1

# from https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=1970&start=275
refclock PPS /dev/pps0 lock GPS prefer refid PPS0
# If Beidou, there is a day offset somehow
refclock SHM 0 offset -86400 delay 0.1 refid GPS noselect

leapsectz right/Asia/Taipei

It uses NTP pool servers for initial time setup and a quick on-boot step (as we don’t want to be stuck at 1970, do we?). The time service related settings are the “refclock” parts. The first line sets the 1PPS lock-on and I tell chrony to prefer that over other sources so we’ll switch over to that when there’s good-enough data. The second refclock section uses gpsd’s NMEA data. The large offset there is due to some issues where the reference time shows up with 24h offset. That I still need to investigate. The delay time set needs some fine-tuning too (I think), though from comments 0.1-0.3 (that is seconds) seems to be suitable? I also tell chrony not to use that for reference.

I also set leap seconds timezones (with the “right/…”  TAI time zone, see e.g. the NTP support page and a discussion on the Debian mailing list). And I enable the server on the local network so other can connect to it and get the time.

I’ve enabled logging of the tracking data (so there’s offset and other information available) and refclocks (tailing /var/log/chrony/refclocks.log continuously is a handy way to see when the lock is lost).

Start chrony (or enable if you want to start it on boot)

sudo systemctl start chrony

and the results can be monitored with chronyc.

All together now

If everything worked well, gpsmon should show a good locked signal after not too much time, something like this:

From the interface above I can also see that Navspark has a 3D lock (Mode A3) to satellites number 209, 207, and 206, which are Beidou birds. And that the time offset is 86399.96 seconds (~24h), that is what the chrony configuration compensates for.

Checking the results in chrony I the system time it’s locked to PPS0 where the last sample had 410ns offset (pretty good).  Also printed the sourcestats.

And this is pretty much all that is needed in general to have a Stratum-1 (atomic clock-locked) NTP server in general.

Some extra references:

• NavSpark GPS+GLONASS Stratum-1 NTP Time Source with a Raspberry Pi
• Hackspherelab: NTP GPS Time Server
• GPSD Time Service HOWTO

Experience

Navspark has a GNSS Viewer program (available for download from their website) which can also set the module’s parameters, for example forcing it to only listen to the GPS signal or only Beidou signal. There are a lot of settings, and I think most don’t need any change, but there’s still a bit to explore, and it’s definitely a handy tool.

Running the NTP lock and looking at the tracking lock there are immediately a few lessons in the ~1 day I’ve been playing with the system:

Environment matters a lot: having wind blowing over the system and being exposed to temperature changes (e.g. outdoor setting) is quite bad for frequency/time stability. One could say duh! but it’s good to see. Even a curtain and placing it indoors helps too, though having it in a well air conditioned space is even better. Too bad that in that case the sky visibility and thus the signal strength suffers a lot, but as long as there’s enough signal to have a lock it is worth it.

PPS is lost when 3D fix is lost: this took a while to figure out why did I lose lock every now and then, especially because once chrony loses the PPS signal it won’t pick it up again.

Indoor can work: indoor lock with the default antenna can work, but the building structure matters a lot.

GPS vs Beidou

Of course the most interesting part is comparing GPS and Beidou. What follows here is not very well qualified yet, just first impressions and need more work.

One of the biggest advantage of GPS is having a lot more satellites than Beidou. I wouldn’t be surprised if they are transmitting at a higher power too, or some other ways easier to receive. When locked onto GPS I could have rock-solid indoors time lock with 4-9 satellites visible at any one time. The time precision is judged by the offset frequency distribution that chrony reports (and would love to hear if there’s a better way to do that!), and that had a standard deviation of about 1µs by experience (in an air-conditioned office).

When I’ve enabled both GPS and Beidou then Navspark seemed to have generally locked onto the Beidou signal. When i was lucky I got 5-6 satellites, but generally it’s around 3 – just on the threshold of having a 3D fix, and the source of the PPS-unlock mentioned above. The offset stability on the other hand can be really good, I had runs that had about 5x smaller time offset standard deviation than GPS had (~0.2µs), and that’s quite a bit of improvement!

The issue is, that when I set the Navspark module GPS+Beidou then when there was a low Beidou satellite count (2-3), even though it still kept a (fragile) 3D fix, the time offset stability was pretty much the same as GPS on its own, though with some intervals of improved readings….

This below is a ~35minutes run of GPS+Beidou setup in an air-conditioned office with limited sky-view and 3 more stories above, using the default 12dB antenna. Using cpgs I could see that in general the lock was provided by 2-3 Beidou satellites, and in some intervals switched over to GPS without losing PPS signal (until it did). Thus it’s not the best performance that I’ve seen but still pretty good. Offset is plotted with the reported standard deviation as error bars. The central line is the mean value of the offset readings, and the two bars are the standard deviation calculated from the offsets.

Future

The ideal setup would be a well air-conditioned roof-top location (I think it would be possible to reliably see 6-7 satellites that way), and switching to Beidou only measurements to clearly see the difference between the two satellite network.

Improved reception could probably be achieved by a different Navspark antenna, which provides 25±3dB gain (that’s an extra ~13dB above the current antenna), and should help indoor reception a lot. It’s currently on pre-sale and expected by the end of the year, so will keep an eye on it!

For more advanced improvements, the adapter board would be easy enough to redo on PCB (instead of surface mount soldering), add maybe some more voltage stabilization for the module to improve the noise figure, and probably have cleaner 1PPS signal too (compared to flying wires). Will definitely give it a try as it is so easy to get the boards printed these days, e.g. with Seeed Studio.

Finally some more setting adjustments could improve the final result, such as tweaking the 1PPS pulse length, using the surveying profile for higher precision (though have to figure out what does it mean first, but looks promision), and other little tweaks….

It looks to me that if the satellite reception issues are cleaned up, the Navspark + Beidou 1PPS signal should be interesting to try with laboratory frequency references for long term stability (such as a Rubidium Clock). And of course to run the Pi+Navspark as a local time reference and provide a NTP service, e.g. from the Tapei Hackerspace…. Plenty to do. :)

The post Dual Satellite NTP server with Navspark appeared first on ClickedyClick.

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?

The post Navspark: Arduino for GPS, GLONASS, and Beidou appeared first on ClickedyClick.