Jim and Dave:

Prior to adding the RFM delayed write feature to H1 ALS tomorrow, we have tested the new feature on the DTS system over the past two days. We are using the h1alsex model running on x1iscex at 16kHz as the RFM IPC sender. The first test uses the h1fe3tim16 model running on x1lsc0 as the 16kHz receiver. Jim loaded up the filters on the sender until its CPU was in the 50uS range. With a 4km fiber run between sender and receiver (we go to the midstation and back) the receiver displayed 100% errors. Switching on the rfm_delay option on the sender zeroed the receiver errors.

The second test was to verify that the rfm_delay does no harm even if it is not needed. We installed zero filters on the sender, putting its CPU in the 27uS range. Delaying the signal caused no problems.

The third test was to check the data was not being corrupted (the receiver uses the cycle counter to check for errors). We put the received signal into the DAQ and sent a non-zero value over several hours. Trending the data shows no values received other than that sent.

The fourth test was to check a 16kHz sender and a 2kHz receiver (as is the case on H1 tomorrow with ALS sender and ASC receiver). We added a reciever to the h1fe3tim02 model, added it to the DAQ and trended its value and error channels. No errors were seen.

The rfm_delay has been tested and is ready for install tomorrow on H1.