[Ikeda, YamaT]
 

Abstract

In recent these days, we replaced IO chassis from V1 to V2.
(K1TEST0 in klog#33560, K1IX1 in klog#36572, K1IY1 in klog#36625, K1EX0 in klog#36654, and K1EY0 in klog#36692).
Real-time models on these front-ends seemed to work well.
But they had a problem that a IRIG-B timing took so long time to be stable when the cold boot of the front-end computer was performed.

Last weekend, we realized that this might be caused by a mix-up of different fiber-optic cables.
So we replaced fiber-optic cables of K1TEST0, K1IX1, K1IY1, and K1EX0 to the correct combination.
After then, the issue of the timing synchronization taking too long no longer occurred.

We had no enough time to go to Y-end today, so we will do same thing for K1EY0 tomorrow.
 

Details

The V2 IO chassis uses a new cable connection standard, and some of its specifications are different from those of the V1 IO chassis. The most significant difference is that the data transfer cable between the front-end computers and the IO chassis has been changed from custom-made HIB optical fiber to standard MTP fiber (OM3). Thanks to this change, we are no longer constrained by the limited availability of HIB cables and we can provide additional IO chassis as spare ones and/or for new instruments in future e.g. filter cavity.

In addition to this change, timing fiber cable in the IO chassis was also changed to the OM3 cable. Strictly speaking, the SFP port of the timing slave was directly accessible from the front panel on V1 IO chassis and any SFP module could be attached, so there were no internal cables. In other words, it is more accurate to say that the interface was changed rather than the cable standard.

Until now, OM1 cables have been installed for multimode optical fiber, not just for timing signals. (Since single-mode fiber, OS1, is used for long-distance connections, this is slightly off-topic.) So the most of timing slaves in the V1 IO chassis were connected to the timing fanout with OM1 cable and we had reused them for V2 IO chassis when we had replaced IO chassis from V1 to V2.

Although the real-time models themselves were running well also in this configuration, there remained a mystery as to why it took several hours for the IRIG-B timing to stabilize after a cold boot of the front-end computer. Figures 1 and 2 show the fluctuations in the IRIG-B value following a cold boot on EY0 and IX1, respectively. Both of them shows that it takes o(hours) time to stabilize the IRIG-B value within normal range (5-20us). And also, for EY0 (Fig.1), it's reproduced in 3 times trial.

The IRIG-B value is not the primary source of timing synchronization but merely serve as a cross-check. However, if they fall outside the normal range, RFM and Dolphin communication will fail. As a result, a global control cannot be done. Even if it took so long time to stabilize IRIB-B value, it finally went to normal range. So we was able to resume global control by waiting this fantastic time. But waiting time as o(hours) was serious from the view point of effective downtime of the digital system for keeping commissioning time and also observing time.

At first, we didn’t realize the relation between the IRIG-B issue and fiber cables standard, but we finally noticed that OM1 and OM3 cables have different core diameters (62.5 μm and 50 μm, respectively) and that mixing them can cause speed reductions and instability especially for the long distance connection in Ethernet case. To be honest, I wasn’t sure if the same discussion applied to Timing synchronization, but We decided to try unifying the fiber cable as OM3.

After replacing the fiber cable, we didn't need to wait that IRIG-B timing was stabilized. And it's not reproduced in a few times power-cycle. After replacing the fiber cable, we didn't need to wait that IRIG-B timing was stabilized. And it didn't appear also in a few times power-cycle. So we concluded that the IRIG-B issue was induced by the mismatch of the optical fiber standard. Today, we was able to complete a replacement work for K1TEST0, K1IX1, K1IY1, and K1EX0. Reaming K1EY0 will be processed tomorrow.