Error correction of the NPL time signal

There's a project on the back burner at London Hackspace to make a better alarm clock. One of the first things we need for this is a way to figure out the current time, instead of bothering the user to set it.

There are a number of ways to obtain this automatically. Both GPS and GSM could be used, and in most houses, WiFi could be used to connect to a time server. DAB is also a possibility in Europe. None of these are particularly cheap though. It would be difficult to get a receiver working for under 20 pounds with any of these methods.

The National Physical Laboratory transmits a time signal by low frequency radio from Cumbria. This is also known as MSF from its old radio call sign. Similar services exist in Germany and the USA, at least. A receiver can be had for 9 pounds from PV Electronics, however, using it hasn't been particularly easy. The signal coming from the module is TTL level, but in my experience, very noisy in the time domain. The signal I got on the first try looked more like this:

Eurgh. Some of this is due to the power supply; the module needs a very clean power supply and it took me a long time to get any sensible data while running from a mains supply. Giving the Symtrik module its own linear regulator, some big capacitors and a choke seem to have improved it. The orientation and position of the antenna is also important; I've noticed that it will produce garbage if it's too close even to an AVR running at 1MHz. LCD monitors in particular seem to drive it crazy.

We could use analogue means to try and get an average value over the expected length of a pulse, or sample it several times and take the most common value. Those are approaches I might go back to, but for now, I'm sampling it just once in the middle of the pulse.

The MSF Specification is pleasantly simple. The most important thing to recognise is the minute marker, since all the remaining data frames' meaning is dependent on their sequence after it. If you treat all the frames as 4-bit frames, sampled at 150, 250, 350 and 450ms from the first rising edge, then the minute frame is all 1s, while the other frames always look like XX00. By using four samples it's unlikely to detect a false minute marker, and it's better to miss a minute marker than detect one when there wasn't one. Note that the Symtrik module outputs an inverted signal, which is why the diagram above is upside down compared with NPL's diagrams.

Unfortunately the signal only has four parity bits for error detection, and only one of those covers the hour and minute information that's really interesting to us. So the best resort we have is to collect data over several minutes, and compare them until we get a sequence of minutes which give us enough confidence to change our current idea of the time.

This means we now maintain three notions of time:

Display Minutes	Expected Minutes	Radio Minutes
Display Hours	Expected Hours	Radio Hours

Display time is what we currently display and consider the current time to be; this isn't something we want to change lightly and of course increments by itself. With a crystal oscillator we can expect an AVR to keep good time for months.

Expected time is what we'd expect the next radio frame to say; this also needs to be incremented automatically when we don't get a sensible radio time. Radio time is the time read from the radio this minute. At the end of the minute it's compared with the (pre-incremented) expected time and if it matches, we increment a sequence counter. If it doesn't match, that counter is reset and the radio time is incremented and becomes the expected time for the next frame.

Once we get a high enough sequence (at the moment, 3 agreeing minutes) we can use that to set the display time. If we don't have a current display time (just after power-on, for example) then the standards can be lower.

I'll provide some C code for the AVR when I have it working well. Debugging is an annoyingly slow process, being locked to the minute cycles of the NPL signal.

Simple, headphone-controlled phone robot

TL;DR: The headphone socket on some Android phones is a good enough signal generator to control servo motors almost directly.

I had an idea recently that servo motors could be driven directly from the headphone socket on an Android mobile phone. I was probably subconsciously remembering this old this old Hackaday link; anyway, it turns out that it's very easy to do.

Servo motors expect a square pulse of 5V of between 1 and 2 milliseconds, usually once every 20 milliseconds. 1 millisecond is canonically fully left, 2 is fully right, and 1.5ms is in the centre, although there is quite a lot of variation. So, I created a suitable square wave by hand in Audacity, saved it as a .WAV file and played it back on my phone's default media player app, while looking at the headphone levels on an oscilloscope. There are lots of reasons to not expect a square wave to come out of an audio amplifier, but the result was actually a very faithful reproduction of my square wave. The maximum voltage I could get out of it was just under one volt, not enough to drive a servo directly, but enough to turn a transistor on. On both the phones I've tried - a HTC Hero (G2) and Desire C - the voltage out of the headphone port is negative with respect to the value in the wave file, so the wave file needs to be between 0 (off) and -32768 (pulses) for a 16-bit sample. As well as playing back standard audio files, it's pretty easy to generate audio on the fly, so you can control servos direct from your application.

Here's my circuit diagram (I've only done shown one channel - it's identical for both). I'm not suggesting you try this - it might break your phone in some way I haven't thought of. This is just to show what I've done.

I've used two bog standard NPN transistors in my circuit; the second is acting as a second inverter as the first one inverts the signal once. I think it should be possible to do this with one transistor, and an inverted wave file (using 0 as the pulses and -32768 the remainder of the time) but it hasn't worked when I've tried it and I don't have ready access to an oscilloscope to figure out why.

Nonetheless, this is a very cheap way of controlling servos from a mobile phone and I would like to find out whether it works on more Android devices. The transistors cost about £5 for a hundred and there's just another 3 resistors per channel to make it work. It is limited to two servos, so if you want more connectivity, you'll probably be after more powerful devices like the IOIO.

This idea gets more useful when you use continuous rotation servos. Here's a video of my old phone running two such servos with wheels attached. Even old Android phones have cameras, accelerometers and wifi, which makes them great brains for simple robots. Running two servos from the headphone socket gives them very cheap mobility.

PS. I've since become aware of http://www.gluemotor.com/ which is a very similar device. They don't have any transistors; but use a capacitor on each channel to provide AC coupling. I couldn't get this to work when I tried it with my Android phone - maybe with more experimentation. Still, nice work.