NTP Time Services

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 Receiver

In 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.

The original code to drive XNTP from the ARC clock comes from Derek Mulcahy, and I'd like to thank Lyndon David for putting me in contact with him and providing some additional information and code.


This is code for use with XNTP:

Other Code

Here 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.

The clock talks 7 bits even parity and two stop. I failed to get this to work so the code talks 8 bits no parity one stop and set ISTRIP. This works fine.


Lyndon has effectively put this code in the public domain, but please acknowledge the source if you use his code.

Latest XNTP Code and Use

As 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:

  1. Unpack the distribution and run configure as appropriate to your site. Make sure refclock support is left in.
  2. Copy the C file into the xntpd directory as refclock_arc.c.
  3. Add refclock_arc.c and refclock_arc.o to the appropriate macro definitions in xntpd/Makefile.am and xntpd/Makefile.in.
  4. Add the following code to config.h, and to be thorough, to config.h.in:
    #define ARCRON_MSF 1 /* New MSF receiver support. */
  5. In include/ntp.h the following line was added amongst all the other reference clock types:
    #define REFCLK_ARCRON_MSF 27 /* DHD: ARCRON MSF radio clock. */
  6. In xntpd/refclock_conf.c the entry for clock 27 in the struct refclock *refclock_conf[] definition was amended from:
    &refclock_none, /* 27 reserved */
    &refclock_arc, /* 27 REFCLK_ARCRON_MSF */
  7. An extra block of code is inserted before the struct refclock *refclock_conf[] definition, thus:
    #ifdef ARCRON_MSF
    extern struct refclock refclock_arc;
    #define refclock_arc refclock_none
  8. Insert this extra entry just before the last entry for clktypes[] in libntp/clocktypes.c:
    { REFCLK_ARCRON_MSF, "ARCRON MSF (and DCF77) Receiver (27)",
    "ARCRON_MSF" },

A test configuration file for this build is as follows:

# ========================
# Our betters...
server # ARCRON MSF radio clock(1).
# Fudge timestamps by about 20ms.
fudge time1 0.020 # Covers a multitude of sins.
fudge stratum 1 # This is not a stabilised precision clock.
fudge flag3 1 # Improve reported precision when possible.
fudge flag4 1 # Use large median filter to reduce jitter.
peer # lemon(1--2).
peer # assam(3).
# This shouldn't get swept away unless left untouched for a long time.
driftfile /var/tmp/ntp.drift
# ============
# 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 mask nomodify notrust
# Trust our peers for time. Don't trust others in case they are insane.
restrict nomodify
restrict nomodify
restrict nomodify
Note 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.



Last updated 1905/05/03.

Home, About/Contact Search

See our privacy policy.
Contact us or report abuse.
Site content copyright 1993--2020 unless otherwise stated.