WinTec GRays 2 GPS device feeding to NTP

USB driver

When I got a wintec g-rays2, it didn't work on USB out of the box with whatever laptop I had (probably a macbook), but was OK on Bluetooth, so that's what I stuck with.

Now, eight years later, I plugged it into one of my Raspberry Pis and it appears as /dev/ttyUSB1 by magic!

Getting NMEA sentences in minicom

minicom --device=/dev/ttyUSB1 --baud=4800 gives some garbled stuff every second, so I'm receiving the NMEA sentences but at the wrong serial port settings.

The manual didn't give any help but a bit of fiddling reveals sensible looking output at 57600 baud, 8N1 (here you can see where I live).

$GPRMC,121815.000,A,5130.3697,N,00003.7216,W,0.00,148.43,240717,,,A*72     
$GPGGA,121815.000,5130.3697,N,00003.7216,W,1,05,2.9,46.2,M,47.0,M,,0000*70 
$GPGSA,A,3,21,26,31,27,16,,,,,,,,4.3,2.9,3.2*38                            
$GPGSV,3,1,12,05,03,021,28,10,08,157,19,21,67,086,34,26,69,175,39*7C       
$GPGSV,3,2,12,29,12,083,,07,08,333,,31,06,193,26,20,27,059,24*72           
$GPGSV,3,3,12,49,,,35,27,43,274,31,16,72,283,39,18,26,132,23*4D 

These lines are spewed out once a second without needing to send any start command to the GPS unit.

Getting ntpd to pay attention

$GPRMC and $GPGGA are the relevant sentences for ntpd, according to the manual.

I already have ntpd runnning on this Pi, with an MSF receiver configured already.

This gives a /dev/gps0 (at least until reboot):

cd /dev
sudo ln -s ttyUSB1 gps0

and this line in /etc/ntpd.conf makes ntpd look for NMEA time sentences on /dev/gps0:

server 127.127.20.0 mode 67

The mode, decimal 67, means hexadecimal 0x43: 0x01 listen for GPRMC, 0x02 listen for GPGGA, 0x40 use 57600 baud.

And after a restart, tada! (although apparently a 160ms delay compared to all my other time sources. ick)

pi@faeroe /dev $ ntpq --peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 2001:8b0:1638:9 81.2.122.172     2 u   39   64   17    0.952  157.794   0.783
 ntp2.aa.net.uk  195.66.241.2     2 u   41   64   17   14.923  162.505   0.671
 SHM(2)          .MSF.            0 l    -   64    0    0.000    0.000   0.000
*GPS_NMEA(0)     .GPS.            0 l   55   64    7    0.000   -5.660   0.819
 tyne.cqx.ltd.uk 81.2.122.172     2 u   46   64   17    0.674  157.858   0.759

Fixing up my MSF radio clock

One of the first hardware things I did with a Raspberry Pi (sometime around March 2013) was interface it to a cheap 60kHz radio clock board, and write some driver software to interface it to ntpd. That was in one house, then in another, and then got dismantled, put in a box, and smashed up a bit. Based on the

I spent a few hours yesterday fixing it up: resoldering the antenna onto the circuit board, getting rid of the dodgy soldering and putting it on a prototype board, putting a capacitor across the power supply because I heard rumour that might make it receive better (it doesn't seem to), and implementing parity checking in the decoder.

It's still terribly awkward to position: I have it velcroed up on top of a curtain rail to try to get it high and away from all my other electronics and it is still very sensitive to antenna positioning; and it is still estimated by ntpd to be less accurate than getting time off the internet; and even with parity checking it is still fairly common for it to decode a time that is wrong.

But it has a nice flashing red LED.

Software: https://github.com/benclifford/msf

BST

I wired in a rugby MSF clock into my raspberry pi, and wrote my own software to interface it to NTP.

Unfortunately I wrote it in winter when they were transmitting approximately GMT. Now its summer time and so they are transmitting British Summer Time not GMT; this is indicated by a bit in the time message. That I ignored. Oops.

Bed time project today was to add that in. Now I've got my stratum 1 server back.

Previously I wired a radio clock via a gertboard into my raspberry pi.

Since then, I figured out that I didn't need the gertboard there, and so now the clock is connected to my other "production" Pi directly onto the GPIO pins.

I've also put the C code I use to interface the radio into ntpd onto github. I needed to copy it from one Pi to the other, and doing it via github means you can download it too now. (yes, I know there are other implementations of MSF decoding around, but I wanted to write the code myself - this is supposed to be fun!)

radio clock NTP server

I've got a couple of Raspberry Pi(e?)s. One I'm using for real server stuff like DNS. The other is for hacking around on. I got a gertboard for it, but hadn't wired anything else up. Then I saw this MSF radio time receiver (for 9 GBP) which is intended to receive 60kHz time broadcasts from the UK National Physical Laboratory.

When I was a teenager, a radio clock was a cool thing that I never had. Then later I got an internet connection, and with it NTP, and so I got geek-time a different way. So I never got an MSF clock until now.

The receiver plugs into the Gertboard (actually it can maybe plug directly in to the Pi's GPIO pins without a Gertboard in the way - I'm not sure) and presents a 1-bit serial signal that is the demodulated 60kHz signal. This is a slightly strange looking signal mostly consisting of 100ms of no carrier, two bits at 100ms each then 700ms of carrier, with 60 seconds of data being enough to transmit the current time.

There was some fiddling soldering to do to get the pins connected - turns out 10y old crocodile clips don't cut it. My father, being better than me at soldering, put those on for me. I cut two of the Gertboard's jumper cables in half so that I'd have wires which connect straight onto Gertboard pins.

The layer above that needs to run in software, at least in my setup.

The first program was a scope program that output * for 1 and . for 0 to the console 80 times a second or so, with a CR every second, to give a line-by-line view of the time. That showed the signal pretty clearly, like this:

.*******************............................................................
.**********.....................................................................
.*********************..........................................................
.**********.....................................................................
.*********......................................................................
.******************.............................................................
.******************.............................................................
.************...................................................................
.***********....................................................................

The short lines are when there's a sync pulse only, and the long lines are when there's a 1-bit immediately following the sync pulse.

The second program used a minute-long circular buffer as a shift register (thanks to Dave_H from the #a&a for that suggestion), and tries to decode time when one end of the buffer looks like the start-of-minute sync pattern. This was able to pretty accurately decode the time. I didn't implement parity checking or other error checking (for example, checking the sync pattern is exactly right) because of that accuracy, which gave trouble later on when I moved the antenna around. Thats something I could implement, and give out some accuracy metric. This took a few hours to code in C (yes, I wrote something in a language that wasn't Haskell). The code is pretty inefficient because it hard polls the GPIO pin. There is some edge triggering available in the Pi's GPIO implementation so I could investigate that. So that ended up as a program which outputs the current time every minute, to the console.

Next, I wanted to connect this with ntpd, so that I could compare the time with other internet time sources, and share the MSF signal with other hosts on the same LAN. ntpd has a facility for connecting "reference clocks" which are sources of time that are not other ntp servers. One of those, the SHMEM driver, communicates with a separate process using a shared memory buffer. So I got to learn about Linux shared memory (indexed using integer keys, I discover, rather than as nodes the file system). For that protocol, basically you stuff the current system clock time and the current received radio time into two fields in that shared memory, every time you get a clock reading. That was a straightforward addition to my second program.

So here's what the hardware setup looks like. The big board is the gertboard. Under it with the big wires is the Pi. The tiny tiny board held in the air by the jumpers is the MSF receiver board, and the big metal rod at the front is the antenna.

And here's what I see in ntpd:

 $ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+2001:8b0:0:53:: 195.66.241.3     2 u   38   64  177   27.872   -4.596   8.680
-2001:8b0:7c:1:2 61.69.233.69     3 u   39   64  177    0.597   -2.285   8.710
+2001:8b0:7c:1:b 90.155.53.93     3 u   37   64  177    1.000   -3.868   8.395
*127.127.28.2    .MSF.            0 l   44   64   17    0.000  -23.730   6.885

where NTP has recently synced to the MSF driver (with fake IP address 127.127.28.2). Its about 20ms different from the network-connected NTP servers (see the offest column). Its difficult to know how much of that is from NTP over-the-network inaccuracies and how much is from my code, but I suspect the bulk of it is from my MSF code - my polling just isn't accurate enough at the moment, and my parsing has some weird time alignment stuff in it.

All in all, good fun and blinkenlights!

p.s. you're welcome to point your own ntp servers at this for fun. Add server tyne.cqx.ltd.uk to your /etc/ntpd.conf

p.p.s. is it sad that I can decode those octal reachability fields in my head.

pool.ntp.org

I've used pool.ntp.org to give me reasonable NTP servers before. On Christmas day I investigated how I could add my server. It turns out there is a self-service user interface to do so, with a scoring system that dynamically decides if your server is good enough to be published.

So I added by NTP server ntp.hawaga.org.uk (that also does a bunch of other stuff), waited a while for the score to rise, and then sat back and watched the port 123 packets flow.

There is lots of fun stuff about NTP breaking in ways which result in server floods - summarised in Wikipedia's NTP_server_misuse_and_abuse

One accusation that I've seen is that 50% of traffic is well behaved clients, and that the other 50% is a small number of misbehaving hosts which poll and poll and poll and poll. I've seen that behaviour in some of my tcpdump runs, though that is not too bad today:

Over a 15 minute period, I got 282 packets, less that one per second, from 53 different IP addresses, with a very unbalanced distribution: 24 hosts sending one packet, 50 sending less than one per minute (15 packets total), 3 sending more than one per minute, and one host sent 65 packets.

Update (Jan 6th 2011): You can watch the score history for my server in my pool.ntp.org profile, although at time of writing its kinda dull, being a flat top score for the past few days.

Update (Jan 7th 2011): I grabbed packets for about the last 24, and see 2736 distinct IP addresses, 32778 packets total (8 packets avg), noisiest host was 85.248.56.73 with 4628 packets. Anyway that's the most number of users I've ever provided service to, I think!

Update (Jan 17th 2011): I now have MRTG monitoring this server's estimated offset from correct time (similar but different to the profile graph above):