Pragotron Slave Clock

Whenever I am really busy it seems I get distracted, maybe a failing, I guess, but it always makes life interesting.  Recently I came across a number of articles on electrically driven clocks, slave clocks, which are mechanical devices that are driven from a central point by periodic electric pulses.  These clocks previously found in schools, factories, railway stations etc. are obsolete now, or at least the original electric ones are, and appear every now again on EBAY.

I first bid on a couple of large old clocks made by English manufactures of the past but always got outbid since these seem to be highly collectable despite many of the examples being in very poor shape.  But eventually I found a listing for a large Pragotron (https://pl.wikipedia.org/wiki/Pragotron) clock.

What a beauty!  It has only an hour and minute hand but that works well for my room as I do not want noise from a continuously moving second hand. The wire for the timing input enters from the bottom.

It’s large!  Roughly 47cm in diameter on the front and a bit bigger on the back with flat glass pane above a concave shaped face which has raised detail for the hour and minute markers.  (There are also smaller versions which are more common, those being around 33cm diameter)

On the back is a plaque showing it to be a PV42 requiring a 60 volt pulse once per minute. I think it’s made of Bakelite, not sure of date.

A little research reveals that the slave clock mechanism inside can have two settings: 60V or 24V.  I clearly wanted to use 24V as this was easier for me to generate so I tested the clock by applying +24V and the hands moved on one minute so I guess this modification had already been made by the previous owner (thanks!).  The mechanism requires that the polarity of the applied pulse should reverse for each pulse so I reversed the wires and it moved on again with a satisfying station clock clunk noise.  Awesome! We have a project!

I would like this clock to keep accurate time (i.e. must be radio, GPS or NTP controlled), be self-setting, automatically adjust for daylight savings and to be tolerant of power outages, fixing itself when power is restored.

It seems many of these clocks have been retro-fitted with new quartz movements some with radio clock receivers however I want to keep the clock as original as possible and in particular I want to retain the satisfying clunk sound that probably was heard across the platform in some East German train station counting down the minutes to  whisk the agent away from the Stasi…

Now this is will be interesting….

 

 

MSF Clock Synchronisation for Microcontrollers – Part 6 – Decoding the signal

Decoding the signal

The specification for the NPL time signal (previously Rugby Time signal) is described at http://www.npl.co.uk/science-technology/time-frequency/products-and-services/time/msf-radio-time-signal with each second of transmission encoding two bits (A&B) except for the minute marker which encodes zero bits but instead marks the epoch.

Time information when transmitted normally comprises 59 sets of two bits except for minutes that include an extra leap second (60 sets of 2 bits) or a absent leap second (58 sets of 2 bits).   My interpretation is that during an additional leap second minute the Year code starts in the 18th second and an extra second is inserted after the DUT code; during a negative leap second minute the 16th second (containing 16B of the DUT code) is omitted and the year code starts in the 16th second.  Detection of the length of each minute is not-obvious but can be detected by inspecting the 01111110 pattern that occurs in the last eight seconds of each minute.

Below is an example of a decoding of the sample captured at the end of previous post.

the protocol includes parity bits for the year, month/day, day of week and hour portions but is only resilient to a single bit error; in this example it indicates that all is intact.

The decoded time is 00:10 on Friday 19th June 2015 with BST in effect, no DST change imminent and DUT -700mS.  The message pertains to the following minute so the following minute marker indicates the epoch.

MSF Clock Synchronisation for Microcontrollers – Part 5 – A closer look at the noise

Comparing samples from clean and noisy environment

I have a highly accurate time source in the form of a Motorola VP Oncore GPS which emits a short pulse every second which is within microseconds of UTC and hence can use this pulse as a reliable indicator of phase.

I set up a small program that synchronises to the GPS 1PPS pulse and then records samples every 1mS for the following second.  Each sample is then placed in a bucket of 11mS and the majority high or low is used to produce a 1 or a 0.  (11 is a good number as it is odd, i.e. there is never any doubt about whether high or low is in the majority, and it divides the second into a good number of samples).

Below is a sample shown for just the initial second, the minute marker, for several minutes in a ‘medium’ real-world noisy environment on the edge of my desk (where I would like my clock to reside) and then lastly two samples from a ‘quieter’ environment near the window.

The numbers of the right hand side are, total samples, number of hi in first 50 buckets (555 samples), number of hi in last 50 buckets (555 samples), and three numbers indicating the population of 3 buckets in each of the estimated mid-points for the 0-100mS, 100-200mS and 200-300mS pulses.

It is noteworthy that at the start of each sample is a quiet period of around 17mS.  My distance from the transmitter translates into only a couple of mS so this delay must be due to the lock-up time on the phase locked loop of the receiver.  I think it is fair to say that observations so far suggest the PLL takes around 20mS to lock and around 50mS to unlock.

Analysis of the mean and deviation of the sample suggests that the minute mark may be recoverable with very limited confidence level.

A closer look at second 59

Continuing on our investigation with the second that precedes the minute marker which we always know will be A=0,B=0

Here we really see the effect of the noise with the external RF interference knocking the PLL out of sync and producing spurious streams of erroneous data.

Statistical analysis here shows that averaging across signals would not produce the correct result, the noise has overwhelmed the receiver.

Final reflections on noise

The receiver module I am using does the majority of the work for us, it receives the 60kHz CW signal and using a tone decoder/phase lock loop of some kind translates this to a logic output (and helpful inverts it).  The receiver works very well in ‘quiet’ environments but in realistic noise environments around my computer (the location I would like my clock) it cannot cope with the PLL losing lock and producing highly spurious outputs.

Once you know the accurate time (slightly against the spirit of trying to decode the signal in the first place) it is possible to generate the local signal prediction (especially if you gloss over the details of leap seconds and day light saving changes) in which case the problem would reduce to one of calculating phase only but even this seems to be challenging in the RFI environments I was considering.

Spectral analysis suggests a noise peak at 144.5Hz so a low pass filter might help but statistically from the samples I have taken it would still not give a good level of confidence with the signal.

Therefore it seems that rather than any further signal processing in the noisy environment I need to relocate my receiver to a quieter location or seek an alternative time source.  It should be noted that even in a quiet location there will be some spurious noise but this should be easily eliminated by averaging… more of that later.

And finally a look at what we get when we do find a quiet spot

It’s a bit disappointing to conclude that signal processing won’t really help us recover a signal in the presence of real-world noise but if you accept that fact and relocate the receiver a metre or so away to a quieter spot the receiver module (here) does a great job on its own.

Next we will look at recovery of the time/date from a relatively noise free sample.

MSF Clock Synchronisation for Microcontrollers – Part 4 – Noise

Comparing signals from two receivers

I have two receivers so thought it would be interesting to put one in a good reception position, approx 2 metres away from any electrical equipment, and another on my lab desk and compare the signals from each.  As has been observed previously receivers near my computer monitor shows rapid flickering and loss of lock whereas the ones near the lab window shows a contented pulsing as it receives the time signal.

Control configuration – Two receivers, both away from noise

By way of a control I first put both receivers away from PC equipment and compare output from each receiver.

Here we see two nicely correlated traces.  The amplitude differs because each has an independent supply, one being powered from the 5v USB supply of the PC and the other by 2 AA-cells but otherwise these signals are clean of noise and illustrate that when well sited the receivers can produce a clean, easily decoded output.

Moving one receiver closer to the computer – Feel the noise!

Here we see the clean signal at the bottom whilst at the top the signal is blown away by the computer induced noise.  No chance of decoding the top receiver!

A closer inspection shows that the two peaks in the lower trace, this is an A=0,B=1 second are not easily visible in the top trace. There is some information in the top trace but recovery looks challenging.

Looking at some other examples and differencing the traces, see middle line, shows that in the upper trace some features have been completely erased by the noise.  No amount of signal processing will recover those!

Again, here we see the top trace showing no sign of the 100mS pulse in the lower, the trace has effectively flat-lined for the first half of the measurement missing the 100mS entirely, we can assume that both A and B bits would be unrecoverable in this scenario.

Moving the roving receiver to a position that is mid-way between the computer and the lab window, i.e. middle noise levels, shows a different situation.  Here we see noise on the top trace but the information is clearly present and some form of integration/low pass filter may be able to recover it.  However the width of the pulses is not consistent, the bottom trace might be A=1, B=0, whereas the top trace looks more like A=0,B=0.  Looks like these pulses really aren’t able to cope with much real-world interference before they become unrecoverable.

Conclusions

When a clear signal is present the receiver does a good job of filtering the input and presenting a precise representation, near sources of significant interference, (computer power supply, computer monitors, computer keyboards?) the noise can be significant enough to make recovery of the signal impossible, implementation of clever digital filtering techniques seems pointless.  However, when the receivers are adjacent but not too close to noise sources creates a mode where the MSF signal may be recoverable with a degree of signal conditioning.

To start with I think I will go for the simple case where noise has been effectively discriminated by the receiver, the aerial having been located in a favourable position, later I may look at averaging to increase reliability in the presence of moderate noise.  Tricky stuff!

MSF Clock Synchronisation for Microcontrollers – Part 3 – MSF Minute Marker

At the start of every minute

Each  minute starts with a minute marker comprising 500mS carrier off and 500mS carrier on with the details of this minute having been encoded in the 58 (negative leap second), 59 (normal), or 60 (positive leap second) seconds preceeding.

The signal is shown below (inverted).

Personally I don’t find the official specification at http://www.npl.co.uk/upload/pdf/MSF_Time_Date_Code.pdf very clear on exactly where the minute transition is relative to the two 500mS sections so I have been doing some investigation and came across an interesting page at  http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond.html which shows a waterfall plot of two time signals during a leap second transition.

And if you zoom in very closely you can see the waterfall for just one second of MSF signal timestamped against a locally NTP synchronized PC clock, my interpretation of this is that the start of carrier off is the minute transition. i.e. the carrier is off for the first 500mS of the new minute and then on for the next 500mS.  (Note: Signal in my oscilloscope screenshot above is inverted).

As an aside it is very interesting to discover http://www.websdr.org/ which allows you to listen to signals around the world over a huge range of frequencies. For my purposes WebSDR in Peterborough, England (IO92VO) at http://cambs-sdr.no-ip.org:8901/ yielded a nice waterfall of the MSF signal although I’m not sure of the latency of these feeds so won’t rely on them for determining the minute transition.

Conclusions

I’m pretty happy to have concluded that the minute starts with the carrier turning off for the minute boundary. i.e. a positive edge for my inverted signal.  However clearly the minute marker is yet to arrive at this point so my software implementation will use the initial transition but combine this with receiving the preceding of A-bits 01111110, once these two conditions are met I will consider a good minute mark.

MSF Clock Synchronisation for Microcontrollers – Part 2

Looking at the MSF received signals…

Having established a receiver away from the computer equipment that was causing all my noise issues it was time to investigate the signals so wired up the trusty Rigol oscilloscope and see what we are getting… The MSF Signal is divided into 1 second long segments with normally 60 segments per minute but where leap seconds are present this may change to 59 or 61 seconds. Each minute has a single minute marker segment. The actual signal is encoded as is described here http://en.wikipedia.org/wiki/Time_from_NPL with the encoding being based on either the presence or absence of the 60kHz carrrier, however presence of carrier is considered to be a 0 and absence of carrier is a 1 (i.e. Negative Polarity Bit Signalling). The receiver module I am using helpfully produces an inverted output so on the traces below a hi signal is a 1 and a lo is 0 which reduces confusion considerably!

The minute marker

Once per minute a special minute marker signal is sent.  This comprises, according to the specification 500mS carrier off (i.e. a one) followed by 500mS carrier on (i.e. a zero).  The actual receiver has to determine when the tone is present or absent and therefore introduces a certain amount of stretching/hysteresis to the received signal.

The observed, by the receiver signal, is presented on its output as a 520mS hi followed by a 480mS lo.

The minute epoch is, I believe, on the initial lo to hi transition although the specification is slightly unclear on that point.

The AB Bits in the other segments

Each second other than the minute marker encodes a pair of bits in the form of a 100mS carrier off and then two bits each of 100mS followed by 700mS of carrier on. Bit A is encoded between 100mS and 200mS and Bit B is encoded between 200mS and 300mS of the initial carrier off (i.e. high output from receiver’s inverted output).

AB=00

The 100mS carrier off has been stretched in the receiver and presents as 136mS of hi.

AB=01

The encoding of A=0, B=1 causes the signal to create a two hump display.  The intial hump is the 100mS initial carrier off, the valley is the A bit and the next hump is the B bit.  

The 300mS transmitted signal presents as a 312mS stretched combination which is worth looking at in detail…

The initial carrier off is approx 124mS being a stretched 100mS.

The A bit is in the next 100mS but the receiver only holds the line low for 90mS at most and in some cases even less…

with the A=0 be encoded in only 76mS of low!  That’s a good deal less than 100mS and we will need to take that into account when decoding the signal.

The B bit follows and is slightly stretched at around 106mS

AB=10

As per each segment the A=1, B=0 encoding fits exactly into 1.00sec

with the leading carrier off and the A=1 (remember it’s an inverted polarity bit encoding) combining to make a long pulse of 200mS but stretched to 224mS by the receiver.

AB=11

Finally the coding of A=1, B=1, which again fits exactly into the 1.00 second interval

Here the initial carrier off and A and B combine to a single pulse of 300mS from the transmitter but stretched to 320mS at the receiver.

Final observations

As we can see from the traces the signals are crystal clear now that I have moved away from my computer monitors, they demonstrate the stretching of the theoretical pulses by the receiver and in particular the compression of the A=0 bit in the A=0,B=1 segments to have only 70mS of low for the A bit in some cases.  Armed with this knowledge we can embark on decoding the signal using a controller and do this in a way that hopes to be resilient to some noise.

MSF Clock Synchronisation for Microcontrollers

I have been far too busy recently with real work to be able to dabble in any hardware design but there has been a project that has been nagging away at the back of my brain for many decades and I thought it about time I started thinking about getting it done. I’ll leave the details of the project itself unsaid for the interim but one component I knew was essential was an accurate time source as the project would not work well if its view of time drifted from official time (OK, it’s a type of clock!)

There are many ways of finding the time with GPS (see my previous dabblings with VP Oncore timing and NTP), NTP to the internet etc all being possibilities but in environments which have no good line of sight to the sky and where network connectivity isn’t immediately available an old fashioned way is to use the long wave time signal from Rugby. In the decades since I first had an interest in this signal it has now moved home from Rugby to Cumbria but the principle remains the same and is described at http://en.wikipedia.org/wiki/Time_from_NPL.

Receiving the signal requires a 60kHz receiver of some kind and the SYMTRIK module sold by PV electronics and described at http://www.pvelectronics.co.uk/rftime/SYM-RFT-XX.pdf is a good starting point and is reasonably priced (although if you have a spare radio clock lying around you could probably just hack that). The signal itself is Carrier Wave (CW) with either 60kHz present or absent indicating a zero or a one respectively. The receiving circuitry comprises a ferrite rod wound with enamelled wire and tuned to 60kHz, the module itself then detects the presence of the carrier or not and then inverts this and sends a logic level output to whatever micro-controller you wish to add.

“Any sufficiently advanced technology is indistinguishable from magic.” Clarke.

Getting the thing to work is another matter! I attached the module to a controller I had lying around (an Espruino) and then started experimenting with decoding the inbound signal but got absolutely no-where. The LED on the receiver module was flickering so I assumed that information was being received but analysis of the bit stream yielded nothing sensible.

After a bid of consideration I decided that the receiver module must be suffering from noise issues due to the hardware I had connected to it, specifically the controller is powered from the USB connection of my PC, which in turn is powered by the PSU within the computer. The Computer PSU is a switching power supply where frequencies akin to the MSF signal are used so it was possible that a 60kHz ripple was coming through my USB lead and disrupting the reception. I tried a few things and did alot of googling which suggested adding a low pass filter and/or ferrite beads/filters to the power supply but rather than embark on that I decided on a process of elimination.

I removed the module from the controller and attached it to my lab power supply which is a linear device so should not have much in the way of switching noise and was flabbergasted to see that the random flickering continued. I then went a stage further and powered the module directly from two AA cells and still the issues continued, the problem was not power supply noise!

Positioning of the device is very important, especially the ferrite rod aerial which is highly directional (a fact that is very useful for radio direction finding e.g. in ARDF/Radio orienteering competitions!) but no amount of rotation solved the problem.

Finally I relocated away from my lab desk toward the window and all the flickering disappeared! I had been at two different desks and had issues at both but now I was away from either suddenly sensible data was coming out of the receiver. It was at this point that it dawned on me! The issue wasn’t power related, not even controller related, it was the fact that on my desks I have a computer monitors that seem to be disrupting the receiver, a bit of research later and it seems the timebase for monitors is often exactly the 60kHz the receiver is trying to discriminate.

I made a little video to show the effect with the hope that others won’t have to go through the pain!

The moral of this story is that MSF receivers and modern computer monitors and possibly computer switched power supplies do not mix. Not such good news for having a clock based project on my desk. The solution seems to be to at least have the receiver reasonably far away from the monitor, perhaps connected by a 2m wire, we shall see.

Once the receiver was away from the computer equipment I put the output into the oscilloscope and started looking at the details which I’ll discuss in my next post but suffice it to say the signal looks reliable with very little noise, it’s looking possible.

(And if you find you have a radio clock that isn’t syncing…. think about moving it further away from your computer screen!)

NTP Server using Raspberry Pi and VP Oncore GPS Module – Part 5

Trouble with NTP Tally/Peer Status

Once I had everything up and running I started to get acceptable numbers for offset and jitter however one thing which stubbornly refused to change was the first character of the peer status line.  The “*” is a one character indication of the role of the peer aka the peer status or tally code.  I knew that the PPS logic was working correctly but the status refused to change.

pi@ntpi ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_ONCORE(0)   .GPS.            0 l    1   16  377    0.000   -0.001   0.003
+ptbtime1.ptb.de .PTB.            1 u   34   64  377   36.019   -1.340   6.205
+stratum2-3.NTP. 129.70.130.70    2 u   12   64  377   34.453   -1.166   1.222
+stratum2-3.NTP. 129.70.130.70    2 u   62   64  377   34.526   -1.193   0.178
-clock2.infonet. .PPS.            1 u   54   64  377   59.021   -4.390   2.726
-ntp.univ-angers 145.238.203.14   2 u   48   64  377   44.575   -7.638   0.406
pi@ntpi ~ $

I followed many red herrings until the only conclusion was that this flag was not being correctly set by ntpd.  After study of the source (I am using /ntp-dev-4.2.7p319) for refclock_oncore.c it seemed that the flag was reset at the top of oncore_get_timestamp and set at the end of the function; this doesn’t work!  Since this guarantees that the flag is always reset when refclock_process is called.  I checked the previous implementation (4.2.6p5) and found a different implementation… looks like a regression.

I modified my local version to set the flag more along the lines of the 4.2.6p5, i.e. to carry over the flag between invocations, setting it if the code reached the end of the happy path in oncore_get_timestamp and resetting it in the case of any failure.

And… Hey Presto!

root@ntpi:/# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_ONCORE(0)   .GPS.            0 l    4   16  377    0.000   -0.001   0.002
*ptbtime1.ptb.de .PTB.            1 u    2   64  377   38.102   -0.148   0.147
-frankfurt1.firs 161.62.157.173   3 u   17   64  377   31.474   -1.970   2.257
-diane.ensma.fr  193.79.237.14    2 u   15   64  377   44.064   -3.768   0.453
+iris.wf-hosting 105.240.56.33    2 u   15   64  377   17.128   -0.196   1.980
+login-vlan87.bu 165.94.197.40    2 u   60   64  377   49.098   -0.547   0.303
root@ntpi:/#

Mission accomplished!

NTP Server using Raspberry Pi and VP Oncore GPS Module – Part 4

Devices and Device Links

As we shall see later the Reference Clock driver in NTP needs to see the Oncore Serial I/O and Oncore PPS signals on specific device names and these are not yet configured by the kernel we downloaded.  In particular the device /dev/ttyAMA0 is currently bound to the UART and the /dev/pps0 device is bound to a rising edge on GPIO Pin 18. (And the Rasberry console I/O has been inhibited so the UART is free for our exclusive use).

Creating symbolic links in /dev will work but they do not survive a reboot so the best approach is to create a udev rule file as follows…

root@ntpi:/# cat /etc/udev/rules.d/50-oncore.rules
KERNEL=="ttyAMA0",SYMLINK+="oncore.serial.0"
KERNEL=="pps0",OWNER="root",GROUP="tty",MODE="0777",SYMLINK+="oncore.pps.0"
root@ntpi:/#

And then restart the Raspberry PI with a reboot command. (Resist the temptation to cycle the power on the PI as this often ends in SD card corruption; use reboot and shutdown -h now where appropriate to avoid disaster).

Finally we should have…

root@ntpi:/# ls -1 /dev | grep oncore
oncore.pps.0
oncore.serial.0

Configure NTPd

The NTPd supplied with the kernel we downloaded from openchaos.org has been built including the Oncore reference clock so configuration is pretty easy now.

Configure the server in /etc/ntpd.conf to include the reference clock driver. (Note that the 127.127.x.y addresses are magic numbers to tell NTPd to use a reference clock… see the NTP documentation for details)

# VP Oncore
server 127.127.30.0 prefer

server ntp1.ptb.de prefer  # another stable preferred peer

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

Create a ONCORE specific configuration file /etc/ntp.oncore

root@ntpi:/# cat /etc/ntp.oncore
MODE 1

LAT 51.0
LONG -0.3
HTGPS 10.0 M

SHMEM /var/adm/ntpstats/ONCORE

(Create the directory /var/adm/ntpstats and make it world writable by ntp if using SHMEM status)

Get NTP running again by /etc/init.d/ntp restart

Wait for everything to settle (may take hours if the receiver has no Almanac), ensure good visibility for the GPS antenna to get a good timing solution and then check that all is working…

root@ntpi:/# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_ONCORE(0)   .GPS.            0 l    -   16    0    0.000    0.000   0.000
 ptbtime1.ptb.de .PTB.            1 u   30   64    3   36.530   -0.707   0.691
+stratum2-3.NTP. 129.70.130.71    2 u   25   64    3   35.616   -0.969   4.477
+stratum2-3.NTP. 129.70.130.70    2 u   26   64    3   34.654   -1.434   2.231
*clock2.infonet. .PPS.            1 u   23   64    3   58.767   -4.061   4.464
-ntp.univ-angers 145.238.203.14   2 u   26   64    3   46.173   -3.868   3.988
root@ntpi:/#

… you can track progress by watching /var/log/daemon.log (which is where the NTP log info ends up) and after a while….

pi@ntpi ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_ONCORE(0)   .GPS.            0 l    1   16  377    0.000   -0.001   0.003
+ptbtime1.ptb.de .PTB.            1 u   34   64  377   36.019   -1.340   6.205
+stratum2-3.NTP. 129.70.130.70    2 u   12   64  377   34.453   -1.166   1.222
+stratum2-3.NTP. 129.70.130.70    2 u   62   64  377   34.526   -1.193   0.178
-clock2.infonet. .PPS.            1 u   54   64  377   59.021   -4.390   2.726
-ntp.univ-angers 145.238.203.14   2 u   48   64  377   44.575   -7.638   0.406
pi@ntpi ~ $

We have a GPS Accurate NTP Server!

Part 5

NTP Server using Raspberry Pi and VP Oncore GPS Module – Part 3

Pulse Per Second (at RS232 Level)

Attached the scope to verify the PPS signal.  This is a slightly confusing waveform as the signal is inverted on the wire (it is inverted back to the original when is passes through the MAX3232). Essentially the PPS signal is a the rising edge (falling edge here) and is a pulse of approx 200ms duration.  (This 200ms ON, 800ms OFF makes the LED on the receiver box flash in a friendly way).

Once inverted and converted to 3.3V the PPS signal presents itself at GPIO 18 as a rising edge.

A Raspberry PI Kernel with PPS Support

For precision timing you want the latency from the rising edge on the PPS signal to its processing to be as small as possible.  There are inevitably some delays (in the wires and gates) but ideally you would like a hardware level interrupt and then a kernel mode event rather than polling or a switch into user space.  Fortunately the hard work has already been done and kernels are available with PPS support built-in.  A kernel with PPS bound to GPIO 18 is available here  http://ntpi.openchaos.org/downloads/. (Detailed instructions on how to recompile with PPS support are given but the kernel can be used as-is to get going).

Download the Kernel, Format an SD card, copy kernel onto card, Plug in serial card, attach to GPS receiver via a Serial Modem Cable (Straight through cable) and power on the GPS and Pi.

Powering On and Testing PPS

The kernel provided by openchaos.org is almost perfect for my needs but needs a couple of tweaks, specifically on start-up it runs gpsd which connects to the serial device (/dev/ttyAMA0).  To disable gpsd remove the links in /etc/rc[0-9].d and reboot

Once restarted ensure that the Pi is attached to a network and then configure the ethernet interface.  The eth0 interface defaults to DHCP but I prefer static for my LAN so changed the entries in /etc/interfaces to be…

iface eth0 inet static
address 192.168.1.7
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1

(and then restarted).

Once restarted, download ppstest tool…

apt-get install pps-tools

And then look for a PPS signal on the /dev/pps0 device using ppstest.  (It should be noted that for the PPS signal to be present the VP Oncore must have locked and be solving for time; the LED on the receiver should be flashing contentedly).

(Incidentally the default login for the kernel is pi/raspberry; then sudo su – to become root)

root@ntpi:/etc/network# 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 1388358515.999999495, sequence: 14437 - clear  0.000000000, sequence: 0
source 0 - assert 1388358516.999999285, sequence: 14438 - clear  0.000000000, sequence: 0
source 0 - assert 1388358517.999999074, sequence: 14439 - clear  0.000000000, sequence: 0
source 0 - assert 1388358518.999999866, sequence: 14440 - clear  0.000000000, sequence: 0
^C

As can be seen we are receiving data at regular 1 second intervals. All looking good!

Part 4