R&D (FilterCavity)
MichaelPage - 20:36, Wednesday 07 February 2024 (3432)
Homodyne recording data in DGS for machine learning project

It was reported by Hsien Yi Hsieh that we do not have fast data (16 kHz sampling) for the homodyne output data taken on December 30. To reiterate, we took 3 traces from the filter cavity DGS:

CC2 eps1 (representing local oscillator phase -> homodyne angle): K1:FDS-FC_GR_CORR
Ramp signal from function generator: K1:FDS-FC_GR_ERR
Homodyne (from SR560 with gain 1000): K1:FDS-ADCspare_1
 
With these signals we would then have a sweep of homodyne output corresponding to squeezing and antisqueezing. The error signal of the local oscillator phase is used to check for glitch noise which has been an issue recently. We took half an hour of swept data at 5 different OPO green pump (i.e. squeezing) levels.
 
Each has fast (16 kHz) and slow (16 Hz) channels in the TAMA DGS that are accessible to plotting software. However, it turns out that only the slow data was saved to the frame file that was given to Taiwan. The .gwf frame file was taken from /frames/full in the file system which is a hidden directory that doesn't show up when you do command ls (linux file list command). I checked the disk usage in the standalone DGS file system for the possibility that we were using the wrong file and there is a larger collection somehwere, however, it seems that /frames/full is the largest directory inside /frames. /frames/trend/second is also of a similar size. Both of these are giving frame files with a data rate of about 4 MB/min, so it seems we do not have fast data. It shouldn't be a problem to take the data again, but we must first figure out how to record the fast data. Since the fast channel is 1000x faster than the slow one, a full frame file would be about 4 GB/min, so for our limited storage space we don't want this running all of the time. It would also be better if we just take 3 channels rather than the full frame file.