When Atomic Clocks Stop Ticking!

Back in December last year I built my GPS governed NTP server and it’s been working perfectly. I never managed to get the clock display to an external TV screen project working simply because I couldn’t get a signal out of the various composite cables I had laying around and shelved the project at the point of having a competent and functioning reference clock for all my other machines.

Everything has been fine and dandy until the other day. The server has been sat on my desk blinking away for months now and I pay little attention to it, but subconsciously I’ve obviously tuned into it as all of a sudden the blue LED on the Edimax WiFi dongle was no longer winking away at me.


Odd! Firing up PuTTY and trying to connect bore no fruit so a quick yank of the power cable and letting it reboot seemed to fix things until it fell over again a few days later. Very Odd.

With an inability to connect to the device there was no option but to hook it to a monitor and plug a keyboard in. Again, nothing. I’ve mentioned before that I’ve had flashcards corrupt when I’ve power cycled Pi’s in an unfriendly manner so put it down to that.

There was little option but to rebuild an image and start from scratch, which is where things started to get interesting.

Now I don’t know what’s going on but when using Jessie distributions of Raspbian, when the Pi boots I’m getting all sorts of weird memory dump errors during the boot sequence which, without having a keyboard attached you’re unable to acknowledge, so the Pi is left hanging expecting a key press, which it’s never going to receive as it’s running in a headless implementation.

A lot of time was spent updating the distribution, working on the assumption of a kernel or driver issue but to no avail.

As such the only solution I’ve got for this so far is to downgrade to Wheezy.

This then causes its own problems as Jessie very nicely accepts MAC bound IP addresses from my router with very little configuration. The GUI default with Jessie means WiFi network keys can be added instantly and are saved in the various config files along with SSID’s.

Wheezy leaves you having to rummage around inside the various config files using nano to set things up which isn’t as nice but so far, touching wood, we have a functioning NTP server.

Now there’s a silver lining to this cloud! I mentioned before that the GPS module used in this project is a motion based unit rather than a static time sensor and with the necessary skills you can force it into that time mode increasing sensitivity. I never worked out how to do that but on following the Ava HAB guide again this time, the necessary code and instructions have been added!

The necessary steps for setting either stationary or portable mode are as follows –

Download the following –

wget https://dl.dropboxusercontent.com/u/63720513/Code/gpsControl.c

Compile +link –

gcc -o gpsControl gpsControl.c

As sudo issue either command for portable or stationary –

./gpsControl -p -d /dev/ttyAMA0 = Portable Mode
./gpsControl -s -d /dev/ttyAMA0 = Stationary Mode

Now the Ava HAB guide says it may take several attempts to set the mode and they’re not kidding. I repeatedly get the following response


M0XXF@Atlas ~/ntp-4.2.8p3 $ sudo ./gpsControl -s -d /dev/ttyAMA0
Set GPS for stationary mode
Configuring device /dev/ttyAMA0
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>

** FAILED to set GPS Mode**

That isn’t the end of the world as the priority was to get the NTP server back up and running.