ARC Rugby MSF Receiver
This page is for information and code for the Galleon Systems' MSF (Rugby, UK, time signal) clock and the ARCRON MSF clock, price GBP100 or less (April 1997), with or without an LCD display. The instructions suggest that the ARCRON unit is made by ``Zeit-Technologie GmbH,'' possibly of Munich, Germany. The Galleon clock appears to be made by ``HKW Elektronik GmbH.'' Both are sold by Galleon in the UK.
Buying a ReceiverIn the UK the ARCRON/Galleon clocks can be ordered (as at 1997/05/05) from:
ARCRON clock (photo lifted from publicity material without permission---buy a clock!)
The ARCRON unit is quite small and pleasing to the eye, suitable for a desk, with a footprint of about 13cm by 11cm, 7cm high, in black plastic. One model has an LCD display with a read-out of time and date, a backlight and the ability to set two alarms. Another model has no display and costs about GBP30 less at GBP70 (April 1997). The unit will need to be placed where it gets a good signal. Internally the unit appears to use a simple quartz oscillator (apparently a watch-style 32768Hz crystal), and resyncs to MSF only once per day by default, so should not be trusted as a very accurate time source by NTP standards. The clock's documentation claims that its internal accuracy is about 20ms. The unit takes two AA (LR6) batteries which should last 2.5 years in normal use, according to the instructions.
Underneath the unit is an RJ45-style RS232 serial socket, which can be used at 300 baud to interrogate the unit for time (and force the unit to resync to MSF), which is why it is of use for XNTP. (The unit requires true RS232 with both positive and negative voltages; partially because the unit powers the RS232 transmit circuitry from the other lines to save battery power.)
Galleon Systems' clock
The Galleon unit with coloured faceplate bearing the Galleon and HKW names is in a somewhat smaller box (12.5cm by 7.5cm by 3cm deep), and takes AAA cells which should last 2 years in normal use. Use of the xntpd driver will probably significantly reduce battery life. The internals seem pretty much the same as the ARCRON clock. This simply seems to be a slightly older design. There is a serial cable running from the side of the box, which ends in a 9-pin PC-style connector.
XNTP CodeThis is code for use with XNTP:
Other CodeHere is some clock-driver code for command-line use from Lyndon David. Compile the C files and see the manpage for details of what it will do. To quote from Lyndon:
At the moment clock.c is very primitive. I was using it as an exercise in improving my C coding and looking at POSIX. Hence the code should be POSIX compliant. All it does at the moment is send the command to get the time and then print it character by character on the terminal.
All this code COMES WITH ABSOLUTELY NO WARRANTY. USE AT YOUR OWN RISK.
Lyndon has effectively put this code in the public domain, but please acknowledge the source if you use his code.
Latest XNTP Code and UseAs of this writing (1997/05/21) I am still testing the latest xntpd refclock code, but it seems now to be reasonably stable. It is now installed on ntp.exnet.com (at stratum 1 rather than 0 to leave ntp.exnet.com as a secondary server). The clock seems a little jittery, but OK. I have installed (hacked) this code in xntp3-5.90, and am just a little hesitant using this revision since I thought it had the outstanding problem of syncing at a whole number of seconds from true. Thanks again to Derek for the original code. See the preliminary HTML documentation for this code for xntpd.
Just in case you need it, here is the xntp3-5.90.tar.gz distribution (1519k).
You may also wish to apply this patch to stop the 3-5.90 code locking an integer number of seconds from the correct time as mentioned above (it only happens under fairly extreme circumstances, though).
This code was built on Solaris-2.5 with gcc 2.7.2 and on SunOS 4.1.3_U1 with gcc 2.5.8 (and is running on a Sun SS1+ and a much faster TurboSPARC); a very slightly earlier version was compiled and run by Derek with xntpd3-5.85 on SunOS 4.1.3. Comments from users of other machines are welcome.
The driver opens device /dev/arcn to talk to the clock for unit n.
To hack the code into xntp3-5.90 without any elegance or grace, do the following:
A test configuration file for this build is as follows:
#------------------------------------------------------------------------------ # SYNCHRONISATION PARTNERS # ======================== # Our betters... server 127.127.27.0 # ARCRON MSF radio clock(1). # Fudge timestamps by about 20ms. fudge 127.127.27.0 time1 0.020 # Covers a multitude of sins. fudge 127.127.27.0 stratum 1 # This is not a stabilised precision clock. fudge 127.127.27.0 flag3 1 # Improve reported precision when possible. fudge 127.127.27.0 flag4 1 # Use large median filter to reduce jitter. peer 188.8.131.52 # lemon(1--2). peer 184.108.40.206 # assam(3). # This shouldn't get swept away unless left untouched for a long time. driftfile /var/tmp/ntp.drift #------------------------------------------------------------------------------ # RESTRICTIONS # ============ # By default, don't trust and don't allow modifications. Ignore in fact. restrict default ignore notrust nomodify # Allow others in our subnet to check us out... restrict 220.127.116.11 mask 255.255.255.0 nomodify notrust # Trust our peers for time. Don't trust others in case they are insane. restrict 127.127.27.0 nomodify restrict 18.104.22.168 nomodify restrict 22.214.171.124 nomodifyNote the fudge factors. I do not recommend using the MSF clock as stratum-0 to drive a stratum-1 server; I think that would imply more than the clock has to offer in stability and accuracy. Also note that you have to tune the time1 fudge factor dependent on your distance from the MSF transmitter, the speed of your machine, and the OS you are using.
Typical output with above test configuration can be seen here.
Let me know of your experiences with this code, one way or the other.