We look at the DuoTone signal to assess the delays in the new OMC front-end. To facilitate this there are 2 signal paths from the 512K OMC IOP model into the 16K OMC dedicated to the DuoTone signal:
- Fiter module FPGA_DTONE reads the last ADC channel from the 16K model.
- Filter module IPC_DTONE reads the last ADC channel from the IOP model, sends it through an IOP filter module OMC0_ADC_DT that implements the same decimation filter as the DCPD chains, and finally sends it to the 16K model through an IPC transceiver.
As a comparison we also looked at the
- LSC model, which has an 512K IOP but reads the first ADC at 64K and which implements the 16K LSC model,
- ISC EX and EY models that run the IOP at 64K and the CAL model at 16K.
The DuoTone signal itself as generated by the timing interface board is delayed by 7.1 μs. This is a "feature" of the timing board and could be fixed with a firmware upgrade.
There are various expcliti and hidden decimation filters that are applied to the DuoTone signal, when it is transferred to a slower model. We list the various delays they add to the DuoTone signal:
| Filter Description | Delay | Unit | Reference |
|---|---|---|---|
| Standard 4x decimation (used 64K → 16K) | 43.5 | μs | T1600066 |
| 64K/16K decimation filter used in the 512K IOP | 40.0 | μs | Double poles @5.2/6.7kHz (53°/85°) Double zeros @8.2/16.384kHz (89°/87°) |
| Old 8x decimation filter (used 512K → 64K) | 19,7 | μs | Double poles @27/25.5kHz (82°/62°) Double zero @32.768/65.536kHz (89.2°/89.3°) Single pole @ 22kHz |
| New 8x decimation filter (used 512K → 64K) | 14.5 | μs | G2202011 |
| Combined old 8x and standard 4x (used 512K → 16K) | 63.2 | μs | |
| Combined new 8x and standard 4x (used 512K → 16K) | 58.0 | μs | |
| Combined new 8x and 64K/16K decimation (used 512K → 16K) | 54.4 | μs |
The old 8x decimation filter will be retired with the next RCG update.
To analyze the Duotone signal we grab 2 sec of data aligned with the 1 PPS and shift the time axis so it starts at −1.000000 s. We then fit the following function
A Sin[2 π 960 (t − B)] + A Sin[2 π 961 ( t − B)] + C
with C describing the time delay. The results are:
| Channel | Rate | Delay | Expect | Unit | Comment |
|---|---|---|---|---|---|
| H1:IOP-OMC0_MADC0_TP_CH31 | 512K | 14.8 | 14.7 | μs | DT delay + 4 cycles |
| H1:IOP-OMC0_ADC_DT_OUT | 512K | 69.2 | 69.1 | μs | DT delay + 4 cycles + New 8x & 64K/16K |
| H1:OMC-FPGA_DTONE_IN1_DQ | 16K | 64.7 | 64.6 | μs | DT delay − 3 cycles + Old 8x & Std 4x |
| 59.4 | μs | DT delay − 3 cycles + New 8x & Std 4x | |||
| H1:OMC-IPC_DTONE_IN1 | 16K | 84.5 | 71.1 | μs | DT delay − 3 cycles + New 8x & 64K/16K + IPC delay |
| 84.4 | μs | DT delay + 4 cycles + New 8x & 64K/16K + IPC delay | |||
| H1:IOP-LSC0_MADC0_TP_CH31 | 512K | 7.06 | 7.1 | μs | DT delay |
| H1:LSC-FPGA_DTONE_IN1 | 16K | 50.6 | 50.6 | μs | DT delay + Std 4x |
| H1:IOP-ISC_EX_MADC0_TP_CH31 | 64K | 7.09 | 7.1 | μs | DT delay |
| H1:CAL-PCALX_FPGA_DTONE_ADC | 16K | 50.6 | 50.6 | μs | DT delay + Std 4x |
| H1:IOP-ISC_EY_MADC0_TP_CH31 | 64K | 7.05 | 7.1 | μs | DT delay |
| H1:CAL-PCALY_FPGA_DTONE_ADC | 16K | 50.6 | 50.6 | μs | DT delay + Std 4x |
The 8 samples of the 512K data stream that are recorder together within one 64K IOP cycle, are not aligned to 1 PPS, but start 4 cycles earlier. This is to make sure that the IOP has enough time to finish its processing. So, these 8 sampels will be recorded in the 512K data stream with a 7.6 μs delay. Consequently, the last of the 8 sample is 3 cycles later than the 1 PPS. Since after decimation to 64K it will be recorded with a time stamp aligned to 1 PPS, the 64K data stream will effectively be recorded with a 5.7 μs advance. This apparent advance will then propagate to the 16K user models.
Looking at the measured DuoTone delays we generally have good agreement with our expectations, except for IPC_DTONE. There, we seemingly acquire an additional delay of 13.4 μs. I suspect this is because the IPC channel is written after the first sample of the 512K data stream, rather than after the last.
