K. Kawabe, J. Kissel

Keita informed me of his worries that the PCAL timing monitor system is vulnerable to corruption. Here's why: The fast channels are captured with filter modules, which have excitation points. Some of the channels stored in the frames are the OUTs, which would contain both the monitor signal and any excitation. Further, we don't monitor the excitation point: because the PCALX system is used for continuous wave hardware injections, we must ignore the CDS STATEWORD bit that says "the user model is requesting an excitation" when we check for this before going into OBSERVATION READY. This bit is also what's typically used by the low-latency pipelines know that there's an unwanted injection, but it has been ignored and nothing else was used in its place. Thus, "vulnerable" to corruption by unwanted excitation.

As such, I propose the following changes:
 (1) Replace the capture of these signals with an EPICs readback and fast TestPoint instead of standard filter module. There's no need for filtration or excitation -- this is a monitor only system.
 (2) Re-organize and rename the channels to be a little more representative of what's going on.**
 (3) Bring the IRIGB monitor into the PCAL library part.

I attach a couple of screenshots that show the before-and-after.

The channel name changes would be as follows: 
$(IFO):CAL-PCAL$(END)_ [...]
   [...] FPGA_DTONE_IN1_DQ           >>   [...] FPGA_DTONE_ADC_DQ
   [...] DAC_NONFILT_DTONE_IN1_DQ    >>   [...] FPGA_DTONE_DAC_DQ
   [...] DAC_FILT_DTONE_IN1_DQ       >>   [...] DAC_DTONE_LOOPBACK_DQ
   [...] IRIGB_OUT_DQ                >>   [...] IRIGB_DQ


These channels will need to be updated in the GDS broadcaster, and any down-stream low-latency code that uses them (for example, the matlab / python scripts that are used to perform timing diagnostics for candidate GW events).

**As a reminder of what all these channels are, and the expected delay in between them, check out Evan Goetz's I/O Chassis Timing Schematic pcal_timing_schematics_LHOaLOG29259.pdf, from G1501170 and LHO aLOG 29259.

I've requested some further approval from interested parties, but otherwise the proposal is ready-to-install during tomorrow's maintenance day. If successful, I'll file the ECR for it to be implemented at LLO.