Cao, Dan,

Today we have been working on locking the internal FPGA clock to an external reference from LIGO. The short version of this story is using the 91 MHz provides the best lock and images from the phase camera. We are currently running the 91 MHz from the CER to ISC-R1 using one of the spare ports. We still need to properly route the cable going to ISCT1, at the moment it is just running along the floor for testing. 

Slightly longer version: our phase camera demodulates at a constant 25 MHz. To image each sideband the reference must be locked with an offset of 25MHz from the sideband of interest, e.g. to image the -9 MHz the reference is offset to +16MHz. The FPGA controls the frequency locking of the reference field, to lock the frequency/phase it internally demodulates at a value like -9+25 MHz so we always lock the phase to the carrier (or another field with the large amplitude). If the FPGA's clock doesn't agree with the clock generating the 9.1MHz then they will drift and the phase will vary image to image. If so, we can't average images over a long period of time and we loose significant amounts of dynamic range in the camera. An FPGA also has a discrete number of frequencies it can pick, clock_frequency/ 2**32. For the FPGA to get *exactly* 9.100230MHz and 45.501150MHz the clock frequency has to be chosen carefully, 72MHz(8x) or 144MHz(16x) should work in theory.

We tried both 72 and 144 but the ADC max frequency is 125MHz and 72MHz seemed to slow for it to work properly. In the end 118MHz or 91MHz seemed good compromises, both resulted in very slow DC drifts in phase when imaging the 9 and 45. Over a few seconds though we did not find this was an issue. The DC phase in the phase camera image isn't that interesting anyway, it just has to stay stable enough over the averaging period. The 91MHz has the benefit that the 45 is a factor of two exactly so it locks very well, 9 drifts a bit but it is manageable.

Ideally I wanted to just be able to feed the RF from the racks straight into the FPGA for locking, however it did not like the signal and the internal PLL would not lock on to it, I'm not sure why. To get this working we had to go through a convoluted process of locking a separate dual channel signal generator to the 91 MHz, one channel for IQ mixing and the other feeding straight into the FPGA. The IQ then fed into a servo and then into the signal generators modulator port to shift the frequency of both outputs for lcoking. Our best guess is that there are some reflections when connecting the 91MHz signal straight into the FPGA which distort the signal. Driving it directly from the sig gen works fine though with the same frequency and amplitude.

Marc also asked me to mention that I am using the balun in the CER with serial number 44.