WHT-TDS-3

The WHT
Time-Distribution System:
the Network Protocol

Nick Hall and J.F.Maclean

Issue 2; 18 August 1993

Contents

1. TDS Background 3

1.1. The original TDS concept 3

1.2. The revised TDS concept 3

1.3. This manual 3

2. Introduction 4

3. The Hardware - Briefly 5

4. The Protocol 6

4.1. The Master node 6

4.2. The slave node 7

5. Conclusions 9

Appendix A. Document history 10

1. TDS Background

1.1. The original TDS concept

The TDS was originally designed to use the utility network and two dedicated fibres to distribute time. to a very high accuracy, around the telescope.

As originally conceived, the protocol for updating a particular nodes UTC was as follows -

1.. The system computer tells the TDS, via the utility network, to update a particular node

2.. The TDS tells the node, via the utility network what the time will be when the next 1 pulse per second (1pps) arrives and then sends the 1pps at the correct time. The node can then synchronise on this pulse.

3.. The node tells the TDS, via the utility network, that it has synchronised ok

4.. The TDS tells the system computer, via the utility network the the node has synchronised.

The second fibre carried a continuous 1MHz signal to clock the receiving nodes.

1.2. The revised TDS concept

The synchronising fibres have now been dispensed with. The requirement for very accurate synchronisataion did not justify the additional cost and effort of installing the fibres, and building the custom receiving hardware for the nodes. Therefore time is now distributed via the utility network only. However the TDS does still retain its fibre synchronisataion capability if required at a later date.

The only nodes requiring UTC updates at the present time are CCD controllers. Due to the effort involved in writing a new system computer 'D' task to control the TDS, the CCD controllers have been given the capability of requesting a time update themselves. This gives them the capability of remaining synchronised without the system computer becoming involved. The CCD controllers can also be told to update their UTC by a command received from the system computer. so the system computer can control UTC updates although it does not talk directly to the TDS.

1.3. This manual

The bulk of this manual was written to describe the original system. Where necessary it has been modified to describe the revised system. The references to the fibre parts of system still remain since this is still present within the TDS. Therefore the references to the fibres, 1pps and 1MHz can be ignored for most purposes.

J.F.Maclean

18/8/93

2. Introduction

Since the reader is probably unaware of either the existence or the purpose (or both) of the 4.2m Time Distribution System, the purpose of this document is to give a brief overview of the system and, more importantly, to describe the software interface to it.

Many of the underlying ideas and protocol structure stem from discussions between Alan Popplestone, Russell Watson and N.Hall in February 1989.

IMPORTANT.
Please read the 'Background' Section first.

Note that since this document was written, the system computer and the instrument controller parts of the protocol are now performed by the instrument controller node which will usually be a CCD controller.

3. The Hardware - Briefly

This consists of a standard 4MS which can read in parallel time-of-day (TOD) information from the adjacent Time Service in the 4.2m Control Room. It is also fed with 1MHz and 1pps signals; it was originally intended for the former to be used to drive the real-time-clock hardware within participating instrument controllers, and the the to latter act as a synchronising pulse for TOD data sent over the network.

The 1MHz and 1pps signals were to be distributed around the 4.2m telescope by means of a dedicated fibre-optic network. The details of this are not relevant here.

4. The Protocol

Reference is made to the accompanying diagram. This shows the generalised message exchange between the system computer, the Time Distribution System (TDS) and the instrument controller (CCD Controller in this case).

The instrument controller takes the roles of master node, initiating a UTC update to its self, and the slave node which receives the incoming time. Note that it was originally intended for the system computer to be the master node, instructing the TDS to update nodes as commanded.

4.1. The Master node

The master node engages the TDS with the following message:

TIM101(node-name) TIM200 TIM201

where "node-name" is a four-character identifier, which will usually be its own name. The request for immediate status (TIM200) ensures that the TDS has received the command and is acting on it. The request for delayed status ensures that the final outcome of the exchange between the TDS and the requested node is relayed to the master node.

The TDS response to a TIM200 will be either:

TIM800(ee); ee=00 This will denote that the TDS is not busy. If a TIM101 has just been issued and this ee_code is received, it is likely that an error in the original message was detected by the TDS and the correct action is to issue the command and status requests again.

TIM800(ee); ee=01 This will denote that the TDS rejected the last TIM101 command. The TDS is presently busy servicing another node. The correct action is to wait for the current exchange to complete.

TIM800(ee); ee=80 This will denote that the TDS is currently busy. This is the normal response after a TIM101 has been accepted. TIM200's issued subsequently will cause the above status response until the TDS has finished it's exchange with the requested node. Note that any TIM101's issued whilst the TDS is busy will be ignored.

The (eventual) TDS response to a TIM201 will be either:

TIM801(ee); ee=00 This will denote that the TDS is not busy. At the present time, there is no ongoing exchange with a slave node.

TIM801(ee); ee=08 This will denote that the exchange between the TDS and the requested node has failed. Issued following an error message received from the node currently engaged. The correct action is to reissue the TIM101 command as well as the TIM200 and TIM201 status requests.

TIM801(ee); ee=0A This will denote that the requested node now has UTC. This is the normal response, denoting a successful exchange between the TDS and the requested node. The TDS will now be free to service other nodes.

Note that multiple requests for delayed status (TIM201) are ignored if the TDS is busy servicing a slave node. Only one TIM801 will be returned.

4.2. The slave node

The instrument controller software will usually reside as part of the overall Ethernet application layer software. If the controller has requested time (or has had time requested for it), it will receive:

UTC101(UTC-time+delay) UTC200 UTC201

where delay is a constant added to cope with the transit time over the Ethernet. The default delay without fibre synchronisataion is 0 seconds.

The controllers' response to the UTC200 should be either:

UTC800(ee); ee=80 This denotes that the UTC time received from TDS, is without error and has been loaded into the resident hardware.

UTC800(ee); ee=01 This denotes that an error has occurred in UTC time received from TDS.

On transmission of the UTC800, the instrument controller should initiate a time-out whose period is approximately equal to the delay over the Ethernet. The (eventual) controllers' response to the UTC201 will be either:

UTC801(ee); ee=0 This denotes that UTC is now present within the instrument controller and its RTC has been updated successfully.

UTC801(ee); ee=01 This denotes that the controller could not update its RTC within the 'time window' allowed. UTC is not present within the instrument controller.

5. Conclusions

The above notes have been written to assist in design of code for integrating into the TDS from 'either side'.

The protocol detailed above has been designed to be as simple as possible; as well as permitting error checking and reporting.

This is not a discussion document.

Appendix A. Document history

Issue 1.0 01/07/89 Nick Halls original document. Described system as originally conceived.
Manual in GEM 1st WordPlus file format.