19c2daa00SOllivier Robert<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 29c2daa00SOllivier Robert 39c2daa00SOllivier Robert<html> 49c2daa00SOllivier Robert 59c2daa00SOllivier Robert <head> 69c2daa00SOllivier Robert <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> 79c2daa00SOllivier Robert <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> 89c2daa00SOllivier Robert <title>Arcron MSF Receiver</title> 9ea906c41SOllivier Robert <link href="scripts/style.css" type="text/css" rel="stylesheet"> 109c2daa00SOllivier Robert </head> 119c2daa00SOllivier Robert 129c2daa00SOllivier Robert <body> 139c2daa00SOllivier Robert <h3>Arcron MSF Receiver</h3> 14*2b15cb3dSCy Schubert<p>Last update: 15*2b15cb3dSCy Schubert <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> 16*2b15cb3dSCy Schubert UTC</p> 179c2daa00SOllivier Robert <hr> 189c2daa00SOllivier Robert <h4>Synopsis</h4> 199c2daa00SOllivier Robert <p>Address: 127.127.27.<i>u</i><br> 209c2daa00SOllivier Robert Reference ID: <tt>MSFa</tt> / <tt>MSF</tt> / <tt>DCF</tt> / <tt>WWVB</tt><br> 219c2daa00SOllivier Robert Driver ID: <tt>MSF_ARCRON</tt><br> 229c2daa00SOllivier Robert Serial Port: <tt>/dev/arc<i>u</i></tt>; 300 baud, 8-bits, 2-stop, no parity<br> 239c2daa00SOllivier Robert Features: <tt>tty_clk</tt></p> 249c2daa00SOllivier Robert <h4>Description</h4> 25ea906c41SOllivier Robert <p>This driver supports the Arcron MSF, DCF and WWVB receivers. The clock reports its ID as "<tt>MSFa</tt>'', "<tt>MSF</tt>'', "<tt>DCF</tt>'' or "<tt>WWVB</tt>'' to indicate the time source.</p> 269c2daa00SOllivier Robert <p>This documentation describes v1.3 (2003/2/21) of the source and has been tested against ntpd 4.1.0 on linux x86. Changes from v1.1 and v1.2 include patches to work with the new ntp-4 code, clock support for DCF and WWVB configurable via mode flag, an option to ignore resync request (for those of us at the fringes of the WWVB signal, for instance), averaging of the signal quality poll and several bug fixes, code cleanup and standardizations. In all other respects, the driver works as per v1.1 if a mode is not specified.</p> 279c2daa00SOllivier Robert <p>To use the alternate modes, the mode flag must be specified. If the mode flag is 0, or unspecified, the original MSF version is assumed. This should assure backwards compatibility and should not break existing setups.</p> 289c2daa00SOllivier Robert <p>The previous documentation described version V1.1 (1997/06/23) of the source and had been tested (amongst others) against ntpd3-5.90 on Solaris-1 (SunOS 4.1.3_U1 on an SS1 serving as a router and firewall) and against ntpd3-5.90 on Solaris-2.5 (on a SS1+ and TurboSPARC 170MHz). That code will claimed increased stability, reduced jitter and more efficiency (fewer context switches) with the <tt>tty_clk</tt> discipline/STREAMS module installed, but this has not been tested. For a to-do list see the comments at the start of the code.</p> 299c2daa00SOllivier Robert <p>This code has been significantly slimmed down since the V1.0 version, roughly halving the memory footprint of its code and data.</p> 309c2daa00SOllivier Robert <p>This driver is designed to allow the unit to run from batteries as designed, for something approaching the 2.5 years expected in the usual stand-alone mode, but no battery-life measurements have been taken.</p> 319c2daa00SOllivier Robert <p>Much of this code is originally from the other refclock driver files with thanks. The code was originally made to work with the clock by <a href="mailto:derek@toybox.demon.co.uk">Derek Mulcahy</a>, with modifications by <a href="mailto:d@hd.org">Damon Hart-Davis</a>. Thanks also to <a href="mailto:lyndond@sentinet.co.uk">Lyndon David</a> for some of the specifications of the clock. <a href="mailto:palfille@partners.org">Paul Alfille</a> added support for the WWVB clock. <a href="mailto:cprice@cs-home.com">Christopher Price</a> added enhanced support for the MSF, DCF and WWVB clocks.</p> 329c2daa00SOllivier Robert <p>There is support for a Tcl/Tk monitor written by Derek Mulcahy that examines the output stats; see the <a href="http://www2.exnet.com/NTP/ARC/ARC.html">ARC Rugby MSF Receiver</a> page for more details and the code. Information on the WWVB version is available from <a href="http://www.arctime.com">Atomic Time</a> as their <a href="http://www.atomictime.com/Product17.html">Atomic Time PC</a>.</p> 339c2daa00SOllivier Robert <p>Look at the notes at the start of the code for further information; some of the more important details follow.</p> 349c2daa00SOllivier Robert <p>The driver interrogates the clock at each poll (ie every 64s by default) for a timestamp. The clock responds at the start of the next second (with the start bit of the first byte being on-time). In the default or original MSF mode, the time is in `local' format, including the daylight savings adjustment when it is in effect. The driver code converts the time back to UTC. In modes 1-3 the driver can be configured for UTC or local time depending on the setting of flag1.</p> 359c2daa00SOllivier Robert <p>The clock claims to be accurate to within about 20ms of the broadcast time, and given the low data transmission speed from clock to host, and the fact that the clock is not in continuous sync with MSF, it seems sensible to set the `precision' of this clock to -5 or -4, -4 being used in this code, which builds in a reported dispersion of over 63ms (ie says ``This clock is not very good.''). You can improve the reported precision to -4 (and thus reduce the base dispersion to about 31ms) by setting the fudge <tt>flag3</tt> to <tt>1</tt>.</p> 369c2daa00SOllivier Robert <p>Even a busy and slow IP link can yield lower dispersions than this from polls of primary time servers on the Internet, which reinforces the idea that this clock should be used as a backup in case of problems with such an IP link, or in the unfortunate event of failure of more accurate sources such as GPS.</p> 379c2daa00SOllivier Robert <p>By default this clock reports itself to be at stratum 2 rather than the usual stratum 0 for a refclock, because it is not really suited to be used as other than a backup source. The stratum reported can be changed with the <tt>stratum</tt> directive to be whatever you like. After careful monitoring of your clock, and appropriate choice of the <tt>time1</tt> fudge factor to remove systematic errors in the clock's reported time, you might fudge the clock to stratum 1 to allow a stratum-2 secondary server to sync to it.</p> 389c2daa00SOllivier Robert <p>In default mode, the driver code arranges to resync the clock to MSF at intervals of a little less than an hour (deliberately avoiding the same time each hour to avoid any systematic problems with the signal or host). Whilst resyncing, the driver supplements the normal polls for time from the clock with polls for the reception signal quality reported by the clock. If the signal quality is too low (0--2 out of a range of 0--5), we chose not to trust the clock until the next resync (which we bring forward by about half an hour). If we don't catch the resync, and so don't know the signal quality, we do trust the clock (because this would generally be when the signal is very good and a resync happens quickly), but we still bring the next resync forward and reduce the reported precision (and thus increase reported dispersion).</p> 399c2daa00SOllivier Robert <p>If we force resyncs to MSF too often we will needlessly exhaust the batteries the unit runs from. During clock resync this driver tries to take enough time samples to avoid <tt>ntpd</tt> losing sync in case this clock is the current peer. By default the clock would only resync to MSF about once per day, which would almost certainly not be acceptable for NTP purposes.</p> 409c2daa00SOllivier Robert <p>The driver does not force an immediate resync of the clock to MSF when it starts up to avoid excessive battery drain in case <tt>ntpd</tt> is going to be repeatedly restarted for any reason, and also to allow enough samples of the clock to be taken for <tt>ntpd</tt> to sync immediately to this clock (and not remain unsynchronised or to sync briefly to another configured peer, only to hop back in a few poll times, causing unnecessary disturbance). This behaviour should not cause problems because the driver will not accept the timestamps from the clock if the status flag delivered with the time code indicates that the last resync attempt was unsuccessful, so the initial timestamps will be close to reality, even if with up to a day's clock drift in the worst case (the clock by default resyncs to MSF once per day).</p> 419c2daa00SOllivier Robert <p>When alternate modes 1-3 are selected, the driver can be configured to ignore the resync requests by setting <tt>flag2</tt> to 1. This allows clocks at the fringe of the signal to resync at night when signals are stronger.</p> 429c2daa00SOllivier Robert <p>The clock has a peculiar RS232 arrangement where the transmit lines are powered from the receive lines, presumably to minimise battery drain. This arrangement has two consequences:</p> 439c2daa00SOllivier Robert <ul> 449c2daa00SOllivier Robert <li>Your RS232 interface must drive both +ve and -ve 459c2daa00SOllivier Robert <li>You must (in theory) wait for an echo and a further 10ms between characters 469c2daa00SOllivier Robert </ul> 479c2daa00SOllivier Robert <p>This driver, running on standard Sun and x86 hardware, seems to work fine; note the use of the <tt>send_slow()</tt> routine to queue up command characters to be sent once every two seconds.</p> 489c2daa00SOllivier Robert <p>Three commands are sent to the clock by this driver. Each command consists of a single letter (of which only the bottom four bits are significant), followed by a CR (ASCII 13). Each character sent to the clock should be followed by a delay to allow the unit to echo the character, and then by a further 10ms. Following the echo of the command string, there may be a response (ie in the case of the <tt>g</tt> and <tt>o</tt> commands below), which in the case of the <tt>o</tt> command may be delayed by up to 1 second so as the start bit of the first byte of the response can arrive on time. The commands and their responses are:</p> 499c2daa00SOllivier Robert <dl> 509c2daa00SOllivier Robert <dt><tt>g</tt> CR 519c2daa00SOllivier Robert <dd>Request for signal quality. Answer only valid during (late part of) resync to MSF signal. The response consists of two characters as follows: 529c2daa00SOllivier Robert <dl compact> 539c2daa00SOllivier Robert <dt>bit 7 549c2daa00SOllivier Robert <dd>parity 559c2daa00SOllivier Robert <dt>bit 6 569c2daa00SOllivier Robert <dd>always 0 579c2daa00SOllivier Robert <dt>bit 5 589c2daa00SOllivier Robert <dd>always 1 599c2daa00SOllivier Robert <dt>bit 4 609c2daa00SOllivier Robert <dd>always 1 619c2daa00SOllivier Robert <dt>bit 3 629c2daa00SOllivier Robert <dd>always 0 639c2daa00SOllivier Robert <dt>bit 2 649c2daa00SOllivier Robert <dd>always 0 659c2daa00SOllivier Robert <dt>bit 1 669c2daa00SOllivier Robert <dd>always 1 679c2daa00SOllivier Robert <dt>bit 0 689c2daa00SOllivier Robert <dd>= 0 if no reception attempt at the moment, = 1 if reception attempt (ie resync) in progress 699c2daa00SOllivier Robert </dl> 709c2daa00SOllivier Robert <dl compact> 719c2daa00SOllivier Robert <dt>bit 7 729c2daa00SOllivier Robert <dd>parity 739c2daa00SOllivier Robert <dt>bit 6 749c2daa00SOllivier Robert <dd>always 0 759c2daa00SOllivier Robert <dt>bit 5 769c2daa00SOllivier Robert <dd>always 1 779c2daa00SOllivier Robert <dt>bit 4 789c2daa00SOllivier Robert <dd>always 1 799c2daa00SOllivier Robert <dt>bit 3 809c2daa00SOllivier Robert <dd>always 0 819c2daa00SOllivier Robert <dt>bit 2--0 829c2daa00SOllivier Robert <dd>reception signal quality in the range 0--5 (very poor to very good); if in the range 0--2 no successful reception is to be expected. The reported value drops to zero when not resyncing, ie when first returned byte is not `3'. 839c2daa00SOllivier Robert </dl> 849c2daa00SOllivier Robert <dt><tt>h</tt> CR 859c2daa00SOllivier Robert <dd>Request to resync to signal. Can take up from about 30s to 360s. Drains batteries so should not be used excessively. After this the clock time and date should be correct and the phase within 20ms of time as transmitted from the source signal (remember to allow for propagation time). By default the clock resyncs once per day in the late evening/early morning (presumably to catch transitions to/from daylight saving time quickly). This driver code, by default, resyncs at least once per hour to minimise clock wander. 869c2daa00SOllivier Robert <dt><tt>o</tt> CR 879c2daa00SOllivier Robert <dd>Request timestamp. Start bit of first byte of response is on-time, so may be delayed up to 1 second. Note that the driver will convert time to GMT, if required. The response data is as follows: 889c2daa00SOllivier Robert <ol> 899c2daa00SOllivier Robert <li>hours tens (hours range from 00 to 23) 909c2daa00SOllivier Robert <li>hours units 919c2daa00SOllivier Robert <li>minutes tens (minutes range from 00 to 59) 929c2daa00SOllivier Robert <li>minutes units 939c2daa00SOllivier Robert <li>seconds tens (seconds presumed to range from 00 to 60 to allow for leap second) 949c2daa00SOllivier Robert <li>seconds units 959c2daa00SOllivier Robert <li>day of week 1 (Monday) to 7 (Sunday) 969c2daa00SOllivier Robert <li>day of month tens (day ranges from 01 to 31) 979c2daa00SOllivier Robert <li>day of month units 989c2daa00SOllivier Robert <li>month tens (months range from 01 to 12) 999c2daa00SOllivier Robert <li>month units 1009c2daa00SOllivier Robert <li>year tens (years range from 00 to 99) 1019c2daa00SOllivier Robert <li>year units 1029c2daa00SOllivier Robert <li>BST/UTC status (Ignored in WWVB version) 1039c2daa00SOllivier Robert <dl compact> 1049c2daa00SOllivier Robert <dt>bit 7 1059c2daa00SOllivier Robert <dd>parity 1069c2daa00SOllivier Robert <dt>bit 6 1079c2daa00SOllivier Robert <dd>always 0 1089c2daa00SOllivier Robert <dt>bit 5 1099c2daa00SOllivier Robert <dd>always 1 1109c2daa00SOllivier Robert <dt>bit 4 1119c2daa00SOllivier Robert <dd>always 1 1129c2daa00SOllivier Robert <dt>bit 3 1139c2daa00SOllivier Robert <dd>(MSF) always 0<br> 1149c2daa00SOllivier Robert (WWVB) Leap year indicator bit<br> 1159c2daa00SOllivier Robert 0 = non-leap year<br> 1169c2daa00SOllivier Robert 1 = leap year 1179c2daa00SOllivier Robert <dt>bit 2 1189c2daa00SOllivier Robert <dd>= (MSF) 1 if UTC is in effect (reverse of bit 1)<br> 1199c2daa00SOllivier Robert (WWVB) Leap second warning bit 1209c2daa00SOllivier Robert <dt>bit 1 1219c2daa00SOllivier Robert <dd>= (MSF)1 if BST is in effect (reverse of bit 2)<br> 1229c2daa00SOllivier Robert = (WWVB) 0 if ST is in effect, 1 if DST is in effect, 1 if transition from ST with bit 0 is set to 0 1239c2daa00SOllivier Robert <dt>bit 0 1249c2daa00SOllivier Robert <dd>= (MSF)1 if BST/UTC change pending<br> 1259c2daa00SOllivier Robert = (WWVB) 0 if ST is in effect, 1 if DST is in effect, 0 if transition from DST with bit 1 is set to 0 1269c2daa00SOllivier Robert </dl> 1279c2daa00SOllivier Robert <li>clock status 1289c2daa00SOllivier Robert <dl compact> 1299c2daa00SOllivier Robert <dt>bit 7 1309c2daa00SOllivier Robert <dd>parity 1319c2daa00SOllivier Robert <dt>bit 6 1329c2daa00SOllivier Robert <dd>always 0 1339c2daa00SOllivier Robert <dt>bit 5 1349c2daa00SOllivier Robert <dd>always 1 1359c2daa00SOllivier Robert <dt>bit 4 1369c2daa00SOllivier Robert <dd>always 1 1379c2daa00SOllivier Robert <dt>bit 3 1389c2daa00SOllivier Robert <dd>= 1 if low battery is detected 1399c2daa00SOllivier Robert <dt>bit 2 1409c2daa00SOllivier Robert <dd>= 1 if last resync failed (though officially undefined for the MSF clock, officially defined for WWVB) 1419c2daa00SOllivier Robert <dt>bit 1 1429c2daa00SOllivier Robert <dd>= 1 if at least one reception attempt was successful<br> 1439c2daa00SOllivier Robert (MSF) since 0230<br> 1449c2daa00SOllivier Robert (DCF) since 0300<br> 1459c2daa00SOllivier Robert (WWVB) resets if not successful between 0300-0400 1469c2daa00SOllivier Robert <dt>bit 0 1479c2daa00SOllivier Robert <dd>= 1 if the clock has valid time---reset to zero when clock is reset (eg at power-up), and set to 1 after first successful resync attempt. 1489c2daa00SOllivier Robert </dl> 1499c2daa00SOllivier Robert </ol> 1509c2daa00SOllivier Robert <p>The driver only accepts time from the clock if the bottom three bits of the status byte are <tt>011</tt> or <tt>flag2</tt> is set to 1 to ignore resync requests. For the MSF clock, if the UK parliament decides to move us to +0100/+0200 time as opposed to the current +0000/+0100 time, it is not clear what effect that will have on the time broadcast by MSF, and therefore on this driver's usefulness.</p> 1519c2daa00SOllivier Robert </dl> 1529c2daa00SOllivier Robert <p>A typical <tt>ntp.conf</tt> configuration file for this driver might be:</p> 1539c2daa00SOllivier Robert <pre># hostname(n) means we expect (n) to be the stratum at which hostname runs. 1549c2daa00SOllivier Robert 1559c2daa00SOllivier Robert#------------------------------------------------------------------------------ 1569c2daa00SOllivier Robert# SYNCHRONISATION PARTNERS 1579c2daa00SOllivier Robert# ======================== 1589c2daa00SOllivier Robert 1599c2daa00SOllivier Robert# Default configuration (Original MSF mode)s... 1609c2daa00SOllivier Robertserver 127.127.27.0 mode 333 # ARCRON MSF radio clock 1619c2daa00SOllivier Robert# Fudge stratum and other features as required. 1629c2daa00SOllivier Robert# ADJUST time1 VALUE FOR YOUR HOST, CLOCK AND LOCATION! 1639c2daa00SOllivier Robertfudge 127.127.27.0 stratum 1 time1 0.016 flag3 1 1649c2daa00SOllivier Robert# WWVB users should change that line to: 1659c2daa00SOllivier Robertserver 127.127.27.0 mode 3 # ARCRON WWVB radio clock 1669c2daa00SOllivier Robertfudge 127.127.27.0 stratum 1 time1 0.030 flag1 1 flag3 1 1679c2daa00SOllivier Robert 1689c2daa00SOllivier Robertpeer 11.22.33.9 # tick(1--2). 1699c2daa00SOllivier Robertpeer 11.22.33.4 # tock(3), boot/NFS server. 1709c2daa00SOllivier Robert 1719c2daa00SOllivier Robert# This shouldn't get swept away unless left untouched for a long time. 1729c2daa00SOllivier Robertdriftfile /var/tmp/ntp.drift 1739c2daa00SOllivier Robert 1749c2daa00SOllivier Robert#------------------------------------------------------------------------------ 1759c2daa00SOllivier Robert# RESTRICTIONS 1769c2daa00SOllivier Robert# ============ 1779c2daa00SOllivier Robert 1789c2daa00SOllivier Robert# By default, don't trust and don't allow modifications. Ignore in fact. 1799c2daa00SOllivier Robertrestrict default ignore notrust nomodify 1809c2daa00SOllivier Robert 1819c2daa00SOllivier Robert# Allow others in our subnet to check us out... 1829c2daa00SOllivier Robertrestrict 11.22.33.0 mask 255.255.255.0 nomodify notrust 1839c2daa00SOllivier Robert 1849c2daa00SOllivier Robert# Trust our peers for time. Don't trust others in case they are insane. 1859c2daa00SOllivier Robertrestrict 127.127.27.0 nomodify 1869c2daa00SOllivier Robertrestrict 11.22.33.4 nomodify 1879c2daa00SOllivier Robertrestrict 11.22.33.9 nomodify 1889c2daa00SOllivier Robert 1899c2daa00SOllivier Robert# Allow anything from the local host. 1909c2daa00SOllivier Robertrestrict 127.0.0.1</pre> 1919c2daa00SOllivier Robert There are a few <tt>#define</tt>s in the code that you might wish to play with: 1929c2daa00SOllivier Robert <dl> 1939c2daa00SOllivier Robert <dt><tt>ARCRON_KEEN</tt> 1949c2daa00SOllivier Robert <dd>With this defined, the code is relatively trusting of the clock, and assumes that you will have the clock as one of a few time sources, so will bend over backwards to use the time from the clock when available and avoid <tt>ntpd</tt> dropping sync from the clock where possible. You may wish to undefine this, especially if you have better sources of time or your reception is ropey. However, there are many checks built in even with this flag defined. 1959c2daa00SOllivier Robert <dt><tt>ARCRON_MULTIPLE_SAMPLES</tt> 1969c2daa00SOllivier Robert <dd>When is defined, we regard each character in the returned timecode as at a known delay from the start of the second, and use the smallest (most negative) offset implied by any such character, ie with the smallest kernel-induced display, and use that. This helps to reduce jitter and spikes. 1979c2daa00SOllivier Robert <dt><tt>ARCRON_LEAPSECOND_KEEN</tt> 1989c2daa00SOllivier Robert <dd>When is defined, we try to do a resync to MSF as soon as possible in the first hour of the morning of the first day of the first and seventh months, ie just after a leap-second insertion or deletion would happen if it is going to. This should help compensate for the fact that this clock does not continuously sample MSF, which compounds the fact that MSF itself gives no warning of an impending leap-second event. This code did not seem functional at the leap-second insertion of 30th June 1997 so is by default disabled. 1999c2daa00SOllivier Robert <dt><tt>PRECISION</tt> 2009c2daa00SOllivier Robert <dd>Currently set to <tt>-4</tt>, but you may wish to set it to <tt>-5</tt> if you are more conservative, or to <tt>-6</tt> if you have particularly good experience with the clock and you live on the edge. Note that the <tt>flag3</tt> fudge value will improve the reported dispersion one notch if clock signal quality is known good. So maybe just leave this alone. 2019c2daa00SOllivier Robert </dl> 2029c2daa00SOllivier Robert <h4>Monitor Data</h4> 2039c2daa00SOllivier Robert <p>Each timecode is written to the <tt>clockstats</tt> file with a signal quality value appended (`0'--`5' as reported by the clock, or `6' for unknown).</p> 2049c2daa00SOllivier Robert <p>Each resync and result (plus gaining or losing MSF sync) is logged to the system log at level <tt>LOG_NOTICE</tt>; note that each resync drains the unit's batteries, so the syslog entry seems justified.</p> 2059c2daa00SOllivier Robert <p>Syslog entries are of the form:</p> 2069c2daa00SOllivier Robert <pre>May 10 10:15:24 oolong ntpd[615]: ARCRON: unit 0: sending resync command 2079c2daa00SOllivier RobertMay 10 10:17:32 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock 2089c2daa00SOllivier RobertMay 10 11:13:01 oolong ntpd[615]: ARCRON: unit 0: sending resync command 2099c2daa00SOllivier RobertMay 10 11:14:06 oolong ntpd[615]: ARCRON: sync finished, signal quality -1: UNKNOWN, will use clock anyway 2109c2daa00SOllivier RobertMay 10 11:41:49 oolong ntpd[615]: ARCRON: unit 0: sending resync command 2119c2daa00SOllivier RobertMay 10 11:43:57 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock 2129c2daa00SOllivier RobertMay 10 12:39:26 oolong ntpd[615]: ARCRON: unit 0: sending resync command 2139c2daa00SOllivier RobertMay 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, will use clock</pre> 2149c2daa00SOllivier Robert <h4>Fudge Factors</h4> 2159c2daa00SOllivier Robert <p></p> 2169c2daa00SOllivier Robert <dl> 217ea906c41SOllivier Robert <dt><tt>mode 0 | 1 | 2 | 3</tt> 2189c2daa00SOllivier Robert <dd>Specifies the clock hardware model. This parameter is optional, it defaults to the original mode of operation. 2199c2daa00SOllivier Robert <dd>Supported modes of operation: 2209c2daa00SOllivier Robert <dd>0 - Default, Original MSF 2219c2daa00SOllivier Robert <dd>1 - Updated MSF 2229c2daa00SOllivier Robert <dd>2 - New DCF77 2239c2daa00SOllivier Robert <dd>3 - New WWVB 2249c2daa00SOllivier Robert <dt><tt>time1 <i>time</i></tt> 2259c2daa00SOllivier Robert <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. On a Sun SparcStation 1 running SunOS 4.1.3_U1, with the receiver in London, a value of 0.020 (20ms) seems to be appropriate. 2269c2daa00SOllivier Robert <dt><tt>time2 <i>time</i></tt> 2279c2daa00SOllivier Robert <dd>Not currently used by this driver. 2289c2daa00SOllivier Robert <dt><tt>stratum <i>number</i></tt> 2299c2daa00SOllivier Robert <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 2. It is suggested that the clock be not be fudged higher than stratum 1 so that it is used a backup time source rather than a primary when more accurate sources are available. 2309c2daa00SOllivier Robert <dt><tt>refid <i>string</i></tt> 2319c2daa00SOllivier Robert <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>MSFa</tt>. When used in modes 1-3, the driver will report either <tt>MSF</tt>, <tt>DCF</tt>, or <tt>WWVB</tt> respectively. 2329c2daa00SOllivier Robert <dt><tt>flag1 0 | 1</tt> 2339c2daa00SOllivier Robert <dd>(Modes 1-3) If set to 0 (the default), the clock is set to UTC time. If set to 1, the clock is set to localtime. 2349c2daa00SOllivier Robert <dt><tt>flag2 0 | 1</tt> 2359c2daa00SOllivier Robert <dd>(Modes 1-3) If set to 0 (the default), the clock will be forced to resync approximately every hour. If set to 1, the clock will resync per normal operations (approximately midnight). 2369c2daa00SOllivier Robert <dt><tt>flag3 0 | 1</tt> 2379c2daa00SOllivier Robert <dd>If set to 1, better precision is reported (and thus lower dispersion) while clock's received signal quality is known to be good. 2389c2daa00SOllivier Robert <dt><tt>flag4 0 | 1</tt> 2399c2daa00SOllivier Robert <dd>Not used by this driver. 2409c2daa00SOllivier Robert </dl> 2419c2daa00SOllivier Robert <h4>Additional Information</h4> 2429c2daa00SOllivier Robert <p><a href="../refclock.html">Reference Clock Drivers</a><br> 2439c2daa00SOllivier Robert <a href="http://www2.exnet.com/NTP/ARC/ARC.html">ARC Rugby MSF Receiver</a></p> 2449c2daa00SOllivier Robert <hr> 245ea906c41SOllivier Robert <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> 2469c2daa00SOllivier Robert </body> 2479c2daa00SOllivier Robert 2489c2daa00SOllivier Robert</html> 249