Hi Andrew
Thanks for the pointers - its all coming back now :-))
This driver, as with most MSF clock drivers, expects to see a 300 baud
data stream. The driver I've done takes the raw data (ie. the actual
carrier transitions) into any IO port - not via an async tty.
Very much like the original MSF TSR for DOS does which provides an
interface for a 15 quid clock rather than the 75 quid for the one with
the serial interface.
The original question was not about NTP - I looked at that (now I recall)
back in September and dismissed it as being totally over the top for the
average ham running a 486dx66 & 8M as his interface to IP over radio .
Robin. G8ECJ - currently seeing the BST bit set in the MSF data stream
and subtracting 3600 seconds from the decoded time to get back to
GMT/UTC (yes I know the difference) because mktime() appears to be
broken.
----- Original Message -----
From: Andrew Benham <[EMAIL PROTECTED]>
To: Colin Bradford <[EMAIL PROTECTED]>
Cc: Robin Gilks <[EMAIL PROTECTED]>; Richard Stearn
<[EMAIL PROTECTED]>; linux-hams list
<[EMAIL PROTECTED]>
Sent: 29 March 1999 14:22
Subject: Re: Time bug
> On Mon, 29 Mar 1999, Colin Bradford wrote:
>
> > As I recall, the xntpd daemon for Unix supports many standard clock
sources,
> > as well as ntp.
> > So, you can use the code from xntpd, and modify it to suit your clock.
>
> The type 27 reference clock is "Arcron MSF Receiver (ARCRON_MSF)", so it
> might be worth looking at that driver.
>
> See xntp docs, or
>
>
http://www.bl.physik.tu-muenchen.de/index_english/rechner/netzwerk/xntp/refc
lock.html
>
> --
> Andrew Benham [EMAIL PROTECTED]
