Time keeper and router

For digital modes on a field day you have to assume the worst, no internet, no local Ethernet, and therefore no time information. We need time with some accuracy, so a GPS (more accurately GNSS) hat on  a Raspberry Pi that controls a local NTP server and a travel router should be able to do the job.

IMG_4082
Figure 1: Upper right is the GPS status window, below that is an existing NTP window, and on the left is a (pulse per second) PPS output window
IMG_4083
Figure 2: The Raspberry Pi with the Dragino LORA/GPS hat.

The GPS hat comes from dragino, it also does LORA (the white stick) which I’m probably not going to use, the only hardware modification is a (blue) patch wire between the output of the GPS chip and a free gpio port on the Raspberry Pi. I used gpio 19 for this purpose (earlier I wrote 29 and this was pin 26 which is a software defined gpio pin while 19 is a hardware PWM pin, there is no difference for the RPi)

Setting up your gpsd server 

GPSD is a daemon, a process running in the background doing all the work for you, such as making the GPS information available on a port on the system. Step 1 is that the GPS has to show positions are time, and, PPS data which we need for the NTP server. The dragino board can be handled in the same way as the Adafruit Ultimate GPS hat for the Raspberry Pi, it is described here. The first time you run the dragino board (the LORA/GPS hat) on a Raspberry Pi no GPS data is shown on a serial port (it should be /dev/serial0), reason is that the console already claimed it, the adafruit article explains how to get the gpsd to work. If cgps -s -u m does not show you anything you then this part needs to be fixed. Debugging the gpsd daemon is explained here although it can quickly become rather technical.

Setting up your ntp server

You could in principle get the time directly from the NMEA strings of the GPS chip, but that procedure can introduce 1 second timing errors because of the baud rate at which the NMEA information is displayed. (see also what I described for the DIY GPS tracker, the article is: here) So there are better ways to do it, namely by using a separate pulse per second (PPS) line from the GPS chip which is unfortunately not wired on the dragino board to any Raspberry Pi gpio pin. So this is what you do yourself, good old-fashioned soldering solves this problem. Once ppstest works you can proceed, for the rest I did not have to do a lot, the procedure is described here. The result is that NTP on lorapi mostly listens to the GPS receiver, and that some internet infomation is used, but not too much.

Some clock and frequency offset results on my LAN

There are several things you can do to see how well time and frequency are now defined, ntp comes with various tools to generate loopstats and peerstats. The loopstats refer to the time and frequency definition of your own clock, and likewise, peerstats are the definitions of all other clocks that NTP synchronizes to while running.

NTP is presently running on rwo Raspberry Pi’s and a PC on my LAN. Lorapi is the RPi equipped with the GPS hat and the wired PPS line,  Adsbpi is its neighbor listening all day to aircraft ADSB data, and the PC is a windows 7 system using the Meinberg ntp implementation. Here are some time and frequency offset estimates for all RPi systems:

clockoffset
Figure 3: Red orange line refers to lorapi, and the blue line is adsbpi. The clock offset is shown in milliseconds and the time runs in hours (its offset is not too relevant)
frequencyoffset

Figure 4: modelling results of the clock frequency. This is what NTP extracts for your system. Color coding is the same, red is lorapi and blue is adsbpi.

So what do you learn? Adding a GPS time synchronization improves the definition of time considerably, better than 50 microseconds is easily achieved unless there are a lot of antenna changes and temperature changes of your RPi. Without the GPS time synchronization we see that the time offset can easily reach +/-200 microseconds  in steady state but this depends on the quality of the internet and the availability of stratum 2 NTP servers in your neighborhood. If they are not there then things become rapidly more troublesome, a few milliseconds (up to 10) is what my PC shows, my PC does not listen to any stratum 2 server. The relaxation time to reach steady state can be as much as 1 or 2 hours for the tested systems, except when you carry your own GPS, in that case the steady state is reached in less than 30 minutes. The frequency plots show that we are dealing with non stabilized (no voltage or temperature stabilization) oscillators. So this is what quartz does for you. At night the temperature does not change too much and the oscillator frequency variations are small, during the day this is a different story. For the intended digital modes application any definition of time is good enough (100 milliseconds would already be satisfactory). If there is no internet to synchronize to during a field day then the GPS solution should work. For time of arrival applications the reported 50 microseconds would result in 1.5 km type of ranging errors.

Routing

This is something I tried on lorapi, but it is too complicated, so what I will do is to carry a travel router with me in the field, a travel router is able to create its own LAN and from there you connect to any internet if needed, if you not matter if the internet is not there, if we ran WSJT-x on a field day.

Last update 28-Jul-2019 11:34

Advertisements

4 thoughts on “Time keeper and router

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.