We looked into the /frames situation a bit tonight. Here is a summary:
Plan of action:
BTW - the last chiara (shared drive) backup was October 16 6 am. dmesg showed a bunch of errors, Koji is now running fsck in a tmux session on chiara, let's see if that repairs the errors. We missed the opportunity to swap in the 4TB backup disk, so we will do this at the next opportunity.
DTT stopped working for recent data. An 'ls' in the frames/full/ directory reveals:
drwxr-xr-x 2 controls controls 258048 Feb 3 12:26 9807
drwxr-xr-x 2 controls controls 258048 Feb 4 16:13 9808
drwxr-xr-x 2 controls controls 262144 Feb 5 19:59 9809
drwxr-xr-x 2 controls controls 258048 Feb 6 23:46 9810
drwxr-xr-x 2 controls controls 258048 Feb 8 03:33 9811
drwxr-xr-x 2 controls controls 262144 Feb 9 07:19 9812
drwxr-xr-x 2 controls controls 253952 Feb 10 11:06 9813
drwxr-xr-x 2 controls controls 266240 Feb 11 14:53 9814
drwxr-xr-x 2 controls controls 266240 Feb 12 18:39 9815
drwxr-xr-x 2 controls controls 266240 Feb 13 22:26 9816
drwxr-xr-x 2 controls controls 262144 Feb 15 02:13 9817
drwxr-xr-x 2 controls controls 253952 Feb 16 05:59 9818
drwxr-xr-x 2 controls controls 241664 Feb 17 09:46 9819
drwxr-xr-x 2 controls controls 28672 Feb 17 12:22 9820
drwxr-xr-x 2 controls controls 32768 Feb 17 15:06 6663
drwxr-xr-x 2 controls controls 73728 Feb 17 23:39 6664
controls@fb /frames/full $ date
Thu Feb 17 23:39:27 PST 2011
There are at least 5 free DAC channels (4 if you discount the one channel from these that I am hijacking) available in the 1Y2 electronics rack.
Jamie's nice wiring diagram shows the topology - the actual DAC card sits in 1Y3 inside the c1lsc expansion chassis (while the c1lsc frontend itself is in 1X4). The output of the DAC goes via SCSI to an interface box (D080303) and then to some dewhitening/AI boards (D000316). There are a total of 16 DAC channels available, out of which 8 are used for the TTs, 2 are used for the DAFI model, and one is labeleld "From c1ioo 1X2" (I don't know what this one is for). So I'm going to use some of these channels for measuring the coupling of oscillator noise and intensity noise to MICH in the DRMI lock.
The de-whitening/AI board seems to be old - it has 2x 800Hz Butterworth LPFs and no notch for the clock frequency, but maybe this doesn't matter for the tests I have in mind. The AI board available on 1X2 is more modern but routing the DAC channels from 1Y2 to it is going to be some work.
I'm going to add my testpoint to c1daf given that it seems to be the least critical model on c1lsc.
EDIT: testpoints added to c1daf don't show up in the list of available channels - there was some issue with this model while we were getting the new RTCDS going. So I'm moving my temporary testpoint to c1cal instead.
its an acquired taste, but its a must since we're sending an interferometer to India
Free swing of ITMY started at
Tue Sep 6 17:41:43 PDT 2011
I think Kiwamu accidentally restarted this kick at 17:48:02 PDT.
The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured last night in order to make sure that nothing wrong have happened by the wiping.
I think there are nothing wrong with ITMs, ETMs, BS, PRM and SRM successfully.
For the comparison, Yoichi's figure in his elog entry of Aug.7 2008 is good, but in his figure somehow PRM spectrum doesn't look correct.
Anyway, compared with his past data, there are no significant changes in the spectra. For PRM which has no counterpart to compare with, its shape of spectra looks similar to any other spectra. So I think PRM is also OK. The measured spectra are attached below.
Motivated by the strange pitch/yaw coupling behavior we ran into while doing diagonalization, we looked at the oplev pitch and yaw free swing spectra for all 4 test masses (see attachment 1). We saw the same behavior there: At the peak frequencies for the angular degress of freedom, the oplevs saw significant contributions from both pitch and yaw. We also examined the phase between pitch and yaw at these peaks and found that consistently, pitch and yaw were in phase at one of the resonance frequencies and out of phase at the other (ignoring the pos and side peaks).
This corresponds physically to angular motion about some axis that is diagonal, ie not perfectly vertical or horizontal. If we trust the oplev calibration, and Eric says that we do, then the angle of this axis of rotation with the horizontal (pitch axis) is
Where Y and P are yaw and pitch ASD values. This will always give an angle between 0 and 90 degrees; which quadrant the axis of rotation occupies can be dermined by looking at the phase between pitch and yaw at the same frequencies. 0 phase means that the axis of rotation lies somewhere less than 90 degrees counterclockwise from the horizontal as viewed from the AR face of the optic, and a phase of 180 degrees means the axis is clockwise from horizontal (see attachment 2). Qualitatively, these features show up the same way for segments of data taken at different times. In order to get some quantitative sense of the error in these angles, we found them using spectrogram values with a bandwidth of 0.02 Hz averaged over 4000 seconds.
Results (all numbers in degrees unless otherwise specified):
peak 1 ( 0.692 Hz):
ptich/yaw phase: -179.181
peak 2 ( 0.736 Hz):
pitch/yaw phase: 0.0123677
peak 1 ( 0.502 Hz):
ptich/yaw phase: -179.471
peak 2 ( 0.688 Hz):
pitch/yaw phase: -0.43991
peak 1 ( 0.73 Hz):
ptich/yaw phase: -0.227034
peak 2 ( 0.85 Hz):
pitch/yaw phase: -179.856
peak 1 ( 0.724 Hz):
ptich/yaw phase: 6.03312
peak 2 ( 0.844 Hz):
pitch/yaw phase: -176.838
ETMY and ITMX both show a more significant (~4x) contribution from pitch on one peak, and from yaw on the other. This is reflected in the fact that they each have one angle somewhat close to 0 (below 30 degrees) and one close to 90 (above 60 degrees). The other two test masses don't follow this rule, meaning that the 2 angular frequency peaks do not correspond to pitch and yaw straightforwardly.
Also, besides ITMX, the axes of rotation are at least several degrees away from being perpendicular to each other.
I have the DRMI free swinging right now, since it's not really locking. Looking at these time series in the attached pdf, particularly around time=1.15, it would be super handy to trigger the SRCL degree of freedom on AS110 after the PRMI is triggered on POP22.
In this night, I checked the free swinging spectra of ETMX to make sure nothing wrong with ETMX by the wiping.
Compared with the past (Aug.6 2008), the spectra of ETMX doesn't show significant change.
Successfully the wiping activity didn't change its configuration so much and didn't bring bad situations.
(bad situation means for example, the suspended components hit some others).
The spectra of ETMX by DTT are attached. Also you can see the past spectra in Yoichi's entry.
Yoichi's data was taken during the air-pressure condition, so it's good for comparing.
Actually I compared those data by my eyes, because I could not get the past raw data somehow.
The resonant frequencies and their typical height changed a little bit, but I think those are not significant.
NOTE: In the figure, pitch and yaw modes (~0.57Hz and ~0.58Hz) look like having a smaller Q-factor than the past.
To take the free swinging Michelson measurements for the interferometer calibration Jamie aligned the beam splitter with ITMX and ITMY. I recorded the GPS time (1027827100 and for several hundred seconds later) when the Michelson was aligned in order to look at the correct data. I then copied the python script nds-test.py from Jamie, and modified it to take and plot data from C1:LSC-AS55_Q_ERR_DQ offline. I used dataviewer to verify that C1:LSC-AS55_Q_ERR_DQ and C1:LSC-AS55_Q_ERR were recording the same signal, and to check that I was taking the correct data with NDS. Taking data online worked as well, but it was easier to use a time when the Michelson was known to be free-swinging and take data offline. Attached is some sample data while free-swinging, with time in GPS time.
I ran "freeswing all" at Fri Aug 19 01:09:28 PDT 2011 (997776583) and "opticshutdown" as well.
I noticed that Chiara's backup HD (which has a capacity of 1.8TB, vs the main drives 2TB) was near to getting full, meaning that we would soon be without a local backup.
I freed up ~200GB of space by compressing the autoburt snapshots from 2012, 2013, 2014. Nothing is deleted, I've just compressed text files into archives, so we can still dig out the data whenever we want.
I just started a freeswing all, as a final check before we pump:
Wed Sep 7 00:43:21 PDT 2011
Wed Sep 7 00:43:32 PDT 2011
WATCHDOGS WILL BE RESET 5 HOURS AFTER THIS TIME
sleeping for 5 hours...
Jamie: Please do a quickie analysis (at least for the ITMs) before helping Steve with the heavy doors.
I closed the PSL shutter.
Both ITM chambers were checked for tools, so there should be nothing left to do but put the heavy doors on, and begin pumping.
This work is now complete. The box was characterized and re-installed in 1X2. I am able to (briefly) lock the IMC and see PDH fringes in POX and POY so the lowest order checks pass.
Even though I did not deliberately change anything in the 29.5 MHz path, and I confirmed that the level at the output is the expected 13 dBm, I had to lower then IN1 gain of the IMC servo by 2dB to have a stable lock - should confirm if this is indeed due to higher optical gain at the IMC error point, or some electrical funkiness. I'm not delving into a detailed loop characterization today - but since my work involved all elements in the RF modulation chain, some detailed characterization of all the locking loops should be done - I will do this in the coming week.
After tweaking the servo gains for the POX/POY loops, I am able to realize the single arm locks as well (though I haven't dont the characterization of the loops yet).
I'm leaving the PSL shutter open, and allowing the IMC autolocker to run. The WFS loops remain disabled for now until I have a chance to check the RF path as well.
Unrelated to this work: Koji's swapping back of the backplane cards seems to have fixed the WFS2 issue - I now see the expected DC readbacks. I didn't check the RF readbacks tonight.
Update 7 Dec 2020 1 pm: A ZHL-2 with heat sink attached and a 11.06 MHz Wenzel source were removed from the box as part of this work (the former was no longer required and the latter wasn't being used at all). They have been stored in the RF electronics cabinet along the east arm.
This turned out to be a much more involved project than I expected. The layout is complete now, but I found several potentially damaged sections of cabling (the stiff cables don't have proper strain relief near the connectors). I will make fresh cables tomorrow before re-installing the unit in the rack. Several changes have been made to the layout so I will post more complete details after characterization and testing.
I was poring over minicircuits datasheets today, and I learned that the minicircuits bandpass filters (SBP10.7 and SBP60) are not bi-directional! The datasheet clearly indicates that the Male SMA connector is the input and the Female SMA connector is the output. Almost all the filters were installed the other way around 😱 . I'll install them the right way around now.
The freq fluctuation of the beat note has been measured with the following condition
- The output of the freq divider is already calibrated to have the unit of MHz.
- The transfer function between the analog PFD channel and the digital PFD output was measured to be -23dB = 0.7.
The gain of the XARM-FINE channel was changed to 0.7 such that the output is calibrated in MHz.
- I have not checked the analog noise level of the analog PFD path. We may need more whitening gain (by icreasing the gain of SR560).
- The analog PFD is always better than the digital PFD above 20Hz.
- Both the digital and analog PFD showed good agreement below 20Hz.
Note the measurement was not simultaneous.
- When the arm is locked with the ETMX being actuated , the fluctuation of the arm length must be stabilized by a huge factor
(~10^5 according to Kiwamu's entry) However, we only could see the stabilization factor of 30.
As this residual is the difference of the freq noise felt by the IR and the green,
this is a real issue to be tackled.
- The RMS fluctuations of the arm with and without the IR beam being locked are 2MHz and 0.1MHz,
which correcponds to the arm length motion of 250nm and 13nm, respectively.
Ed: I had to use 532nm in stead of 1064nm. The correct numbers are 130nm and 7nm.
- Without the IR locked, The typical peak-to-peak fluctuation of the beat freq was 10MHz.
I found that some flakiness of the beat signals comes from the RF components for the beat detection.
They are touching the racks in an indefinite way. If we move the components the output of the analog PFD
Once Kiwamu is back I will ask him to clean up all of the green setting in an appropriate way.
I uploaded all the material about the RF frequency Generation Box into the SVN under the path:
I structured the directory as shown in this tree:
I'm quickly describing in a section of the Rf system upgrade document with LIGO # T1000461.
I completed a LIGO document describing design, construction and characterization of the RF System for the 40m upgrade.
It is available on the SVN under https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/RFsystem/RFsystemDocument/
It can also be found on the 40m wiki (http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/RF_System#preview), and DCC under the number T1000461.
I measured the amplitude noise of the source outputs and the EOM outputs of the Frequency Generation box.
the setup I used is shown in this diagram:
(NB It's important that the cables from the splitter to the RF and LO inputs of the mixers are the same length).
The results of the measurements are shown in the following plot:
1) both Crystals (29.5MHz and 11MHz) have the same noise
2) the 55MHz source's noise is bigger than the 11 MHz (~2x): the frequency multiplication and amplification that happen before it, add extra noise
3) the noise at EOM outputs is ~2x bigger than that of the relative sources
When I have the chance, I'll plot the results of my calculations of expected noise and compare them with the measurements.
Here are the results of my phase noise measurements on the 7 outputs of the Frequency Generation Box. (BIN=95L applied by DTT). See attached pdf for a higher definition picture.
The plot shows that the phase noise of the 11 MHz outputs (Source, EOM modulation signal, Demodulation signal) is as low as that of the Marconi. The Marconi is limiting my measurement's resolution.
The mode cleaner signal's oscillator (29.5 MHz output, blue trace) is higher than the 11MHz above 1KHz.
The 55MHz signals have all the same phase noise (traces overlapped), and that is higher than the 11 MHz ones from about 100Hz up. i don't know what's going on.
I need to use the spare 11MHz Wenzel crsytal to have a better reference source for the measurement.
I finished assembling the frequency generation unit for the upgrade. I tested it through to check that the power levels are as expected at the various connection (see attached png, showing in black the design power values, and in red the measured ones).
Because of some modifications made on the design along the construction, I have to recalculate the SNR along the lines.
I can now start to measure phase noise and distortion harmonics.
A document with a description of the design and the results of the characterization measurements will be available in the end.
Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.
Unfortunately the order placed for beam samplers last week did not go through. These will be used at the X and Y end tables to dump the unwanted light appropriately. Since they will not be here until Tuesday, I revised the timeline for FOL related activities accordingly.
I finished the polishing in the scripts/FOL directory, this is the current status and this post replaces my two previous posts on the subject:
So, I actually took these measurements last week, but I didn't get around to making nice plots and things until now. I figured the time while I wait for the spectrum analyzer to do its thing was a good time.
Having been unable to locate the SR785 and also unsure how to connect it to a computer speaker (and also unable to find a free one), I downloaded a demo of a function generator onto my computer and just used that. (Same thing I used to do the swept sine that created the frequency power response plots I posted last week.) I set the program to a number of different frequencies and had the other end of the cable hooked into the oscilloscope to see a) if I could pick out the frequency and b) see how the magnitude of the microphone output varied with the frequency.
The first set of measurements I took, I didn't realize that I could increase the output power of the function generator. Because the generated sound at the default setting was relatively quiet, the oscilloscope traces were pretty chaotic, so I usually froze the trace so that I could look at it better. I ended up with a lot of weird jumps in the magnitude, but I later realized that there was a lot of beating going on at some frequencies, and the amplitude changes were probably much more drastic for the -20 dB sounds than the 6 dB sounds, since it was closer in amplitude to the surrounding noises. So, I've included that data set in my plots for the sake of completeness, but I'm pretty sure that it is useless.
Once I realized I could increase the power output for the signal generator, I took a set of data with and without the voltage divider at 6 dB. There was a cluster of frequencies that showed significant beating around 1700-3000 Hz in the data WITH the voltage divider, but I did not see any clear beating in the data WITHOUT. In the plots, I simply plotted up the highest and lowest amplitudes I measured for the frequencies with significant beating, since it was obviously hard to tell what the amplitude would have been without any background noise. In the w/o volt. div. set, although I didn't see any obvious beat patterns, the measured amplitudes did jump slightly at the frequencies that showed beats with the voltage divider. So, perhaps I was just not seeing them, but they influenced my amplitude measurements? I'm not sure if it would be possible for the voltage divider itself to cause beat frequencies.
(Note: the amplitudes measured were from zero to peak, as the oscilloscope I was using wouldn't show a big enough vertical range to easily measure the peak-to-peak voltage difference.)
I've attached two plots of my measurements. One has a regular x-scale and includes all the measurements. The second has a logarithmic x-scale and omits the 20 Hz points. I had some troubles being able to pick out the 20 Hz signal on the oscilloscope... I don't know if my computer speakers just don't work well at that frequency or what, but either way, those points seemed highly suspect, and omitting them from the log plot allowed me to spread things out more.
One thing I'm not sure about is the 3000 Hz point. It was one of the ones with a beat frequency (~130 Hz), and the amplitudes were pretty low. The corresponding point from the non-voltage-divider data set is also low. So, I'm not sure what's happening there.
The one thing that I do think is quite clear is that the 1000 Hz drop-off in power when the microphone is connected to the ADC has nothing to do with the voltage divider. Beat issues aside, the shapes are very similar (pay no attention to the absolute scale... obviously, the voltage responses with and without the voltage divider were very different, and I just scaled them to fit in the same plot).
Update: Jenne pointed out that I was not absolutely clear about the voltage scale in my plots. The GREEN and BLUE points are on a mV scale, and the RED points are on a 10mV scale. I should probably redo the plots in Matlab in eventuality, since Excel is hard to use if you want to do anything that is not extremely basic with your plots, but this was my solution for the time being. So, the fact that the RED points, which are the data taken WITHOUT the voltage divider, are lower than the GREEN ones does not in any way indicate that I measured lower voltages when the voltage divider was not used.
Also, a to do list:
- Many of the beat frequencies I picked out were veeeeery slow, indicating that something is going at a frequency that is very close to the arbitrary frequencies I chose to sample, which is a little strange. That, combined with the fact that I saw clear beats with the voltage divider but not without leads me to believe that it may be worth investigating the frequency response of the voltage divider itself.
- Redo the measurements near the anomalous 3000 Hz point with a higher density of sampled frequencies to try to see what the heck is going on there.
I checked the BK precision 1856D manual. I found that although this frequency counter can measure upto 3.5GHz, it has 2 separate input channels to measure two range of frequencies.
One input to measure between 0.1Hz to 100 MHz and the other to measure between 80MHz to 3.5GHz. Our beat frequency desirable range is <100MHz for stable ALS. Also, the beat PD response falls off beyond ~150MHz . Should we be happy with this frequency counter and use it in the 0.1Hz-100MHz range or look for one with a better measuring range?
P.S. Right now we are using the spectrum analyzer in the control room set to frequency range from 10MHz - 140 MHz for beat note search.
I've made a few more changes to the frequency counting code - these are mostly details and the algorithm is essentially unchanged.
The other thing that came up in the meeting last week was this issue of the systematic errors in the measured frequency, and how it was always over-estimating the 'actual' frequency. I've been investigating the origin of this over the last few days, and think I've found an explanation. But first, Attachment #1 shows why there is a systematic error in the first place - because we are counting the period of the input signal in terms of clock cycles, which can only take on discrete, integer values, we expect this number to fluctuate between the two integers bounding the 'true value'. So, if I'm trying to measure an input signal of 3000Hz, I would measure its period as either 5 or 6 clock cycles, while the "true" value should be 5.4613 clock cycles. In attachment #1, I've plotted the actual measured frequency and the measured frequency if we always undercounted/overcounted to the nearest integer clock cycles, as functions of the requested frequency. So the observed systematic error is consistent with what is to be expected.
The reason why this doesn't average out to zero is shown in Attachment #2. In order to investigate this further, I recorded some additional diagnostic variables. If I were to average the period (in terms of clock cycles - i.e. I look for the peaks in the blue cuve, add them up, and divide by the number of peaks), I find that I can recover the expected period in terms of clock cycles pretty accurately. However, the way the code is set up at the moment, the c code block outputs a value every 1/16384 seconds (red curve) - but this is only updated each time I detect a zero crossing - and as a result, if I average this, I am in effect performing some sort of weighted average that distorts the true ratio of the number of times each integer clock-cycle-period is observed. This is the origin on the systematic error, and is a function of the relative frequency each of the two integer values of the clock-cycle-period occurs, which explains why the systematic error was a function of the requested frequency as seen in Attachment #1, and not a constant offset.
At the frequencies I investigated (10-70MHz in 5MHz steps), the maximum systematic error was ~1%.
Is there a fix?
I've been reading up a bit on the two approaches to frequency counting - direct and reciprocal. My algorithm is the latter, which is generally regarded as the more precise of the two. However, in both these approaches, there is a parameter known as the 'gate-time': this is effectively how long a frequency counter measures for before outputting a value. In the current approach, the gate time is effectively 1/16384 seconds. I would think that it is perhaps possible to eliminate the systematic error by setting the gate time to something like 0.25 seconds, and within the gate time, do an average of the total number of periods measured. Something like 0.25 seconds should be long enough that if, within the window, we do the averaging, and between windows, we hold the averaged value, the systematic error could be eliminated. I will give this a try tomorrow. This would be different from the moving average approach already explored in that within the gate-time, I would perform the average only using those datapoints where the 'running counter variable' shown in Attachment #2 is reset to zero - this way, I avoid the artificial weighting that is an artefact of spitting out a value every clock cycle.
I've made quite a few changes in the software as well as the hardware of the digital frequency counting setup.
Eric helped me test the new setup by doing an arm scan through an IR resonance by ramping the ALS offset from -3 to +3 with a ramp time of 45 seconds. The data was acquired with the window size of the moving average set to 4096 clock cycles, and a 2 Hz low pass IIR filter before the frequency readout. Attachment 1 shows a plot of the data, and a fit with a function of the form trans = a/(1+((x-b)/c)^2), where a = normalization, b = center of lorentzian, and c = linewidth (FWHM) of the peak (the fitted parameter values, along with 95% confidence bounds are also quoted on the plot). In terms of the data acquisition, comparing this dataset to one from an earlier scan Eric did (elog11111) suggests that the frequency counting setup is working reasonably well - at any rate, I think the data is a lot cleaner than before implementing the moving average and having a 20Hz lowpass IIR filter. In any case, we plan to repeat this measurement sometime next week during a nighttime locking session. It remains to calculate the arm loss from these numbers analogous to what was done earlier for the X arm.
Calculation of loss:
Fitted linewidth = 10.884 kHz +/- 11Hz (95% C.I.)
FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz
=> Y arm Finesse = FSR/fitted linewidth = 362.6 +/- 0.5
Total round trip loss = 2*pi/Finesse = 0.0173
It is a nice scan. I'm still thinking about the equivalence of the moving average and the FIR low pass that I have mentioned in the meeting.
I'm confused by the plot. The bottom axis says "green beat frequency".
If you scan the IR laser frequency by df, you get 2*df shift of the green beatnote. You need to have this factor of two somewhere.
If you are looking at the IR beat freq, just the label is not correct. (I believe this is the case.)
Accepting the rather-too-low finesse of 363 (nominally 450), the total round trip loss is said to be 0.0173.
If we subtract the front transmission of 1.38% (and ignoring the transmission loss from the ETM),
the round trip loss is 3500ppm. Is this compatible with the following elog?
In fact, I'm afraid that the loss number in the above elog 11111 was not correct by a factor of 10.
Then, if so, can we believe this high loss number? (Nominally we expect ~100ppm loss per round trip...)
Sorry for the confusion - I did mean Green beat frequency, and I had neglected the factor of 2 in my earlier calculations. However, the fit parameter "c" in my fit was actually the half-width at half maximum and not the full width at half maximum. After correcting for both these errors (new fit is Attachment #1, where I have now accounted for the factor of 2, and the X axis is the IR beat frequency), I don't think the numbers change too much. It could be that the frequency counter wasn't reading out the frequency correctly, but looking at a time series plot of the frequency counter readout (Attachment #2), and my earlier trials, I don't think this is the case (38 MHz is a frequency at which I don't expect much systematic error - also, the offset was stepped from -3 to 3 over 45 seconds).
The revised numbers:
Fitted linewidth = 2*c = 10.884 kHz +/- 2 Hz (95% C.I.)
I made some changes to the c1tst model running on c1iscey in order to test my algorithm for frequency counting. I followed the steps listed in elog 8909 to make, install and start the model.
I need to debug a few things and run some more diagnostics so I am leaving the model in its edited version (Eric had committed it to the svn before I made any changes).
I have been working on setting up a frequency counting module that can give us a readout of the beat frequency, divided by a factor of 2^14 using the Wenzel frequency dividers as described here. This is a summary of what I have thus far.
The algorithm, and simulink model
The basic idea is to pass the digitized signal through a Schmitt trigger (existing RCG module), which provides some noise immunity, and should in theory output a clean square wave with the same frequency as the input. The output of the Schmitt trigger module is either 0 (for input < lower threshold value) and 1 (for input greater than the high threshold value). By differencing this between successive samples, we can detect a "zero-crossing", and by measuring the time interval between successive zero crossings, we can take the reciprocal to get the frequency. The last bit of this operation (i.e. measuring the interval) is done using a piece of custom C code. Initially, I was trying to use the part "GPS" from CDS_PARTS to get the current GPS time and hence measure intervals between successive zero-crossings, but this didn't work out because the output of GPS is in seconds, and that doesn't give me the required precision to count frequency. I tried implementing some more precision timing using the clock_gettime() function, which is capable of giving nanosecond precision, but this didn't work for me. So I am now using a more crude way of measuring the interval, by using a counter variable that is incremented each time a zero-crossing is NOT detected, and then converting this to time using the FE_RATE macro (=16384). In any case, the ADC sampling rate limits the resolution of frequency counting using zero-crossing detection (more on this later). Attachment 1 shows the SIMULINK block diagram for this entire procedure.
Testing the model
I implemented all of this on c1tst, and followed the steps listed here to get the model up and running. I then used one of the DB37 breakout boards to send a signal to the ADC using the DS345 function generator. Attachment 2 shows some diagnostic plots - input signal was a 2.5Vpp (chosen to match the output from the Wenzel dividers) square wave at 2kHz:
The right column pointed me to the limitations of frequency counting using this method - even though the input frequency was constant (2kHz), the counter variable, and hence the frequency readout, was neither accurate nor precise. But this was to be expected given the limitations imposed by ADC sampling? We only get information of the state of the input signal once within each sampling interval, and hence, we cannot know if a zero crossing has occurred until the next sampling interval. Moreover, we can only count frequency in discrete steps. In attachments 3 and 4, I've plotted these discrete frequencies which can be measured - the error bars indicate the error in the frequency readout if the counter variable is 1 more or less than the "true" value - this can (and does) happen if the high and low times of the Schmitt trigger are not equal over time (see top left plot in Attachment 2, its not very obvious, but all the "low" times are not equal, and so, the interval between detected zero crossings is not equal). This becomes a problem for small values of the counter variable, i.e. at high input frequencies. I was having a look at the elogs Aidan wrote some years ago for a different digital frequency counting approach, and I guess the conclusion there was similar - for high input frequencies, the error is large.
I further did two frequency sweeps using the DS345, to see if I could recover this in the frequency readout. Attachments 5 and 6 show the results of these sweeps. For low frequencies, i.e. 100-500 Hz, the jitter in the readout is small (though this will be multiplied by a factor of 2^14), but by the time the input frequency gets up to 2kHz, the jitter in the readout is pretty bad (and gets worse for even higher frequencies.
Some refinements can be made to the algorithm, perhaps by introducing some averaging (i.e. not reading out frequency for every pair of zero crossings, but every 5) which may improve the jitter in the readout, but I would think that the current approach is not very useful above 2kHz (corresponding to ~30MHz of pre-divider frequency), because of the limitations shown in attachments 3 and 4.
I definitely think lowpassing the output is the way to go. Since this frequency readback will be used for slow control of the beatnote frequency via auxillary laser temperature, even lowpassing at tens of Hz is fine. The jitter doesn't mean its useless, though.
If we lowpass at 16Hz, we're effectively averaging over 1024 samples, bringing, for example, a +-2kHz jitter of a 6kHz signal as you post down to 2kHz/sqrt(1024) ~ 60Hz, which is 1% of the carrier. This seems ok to me.
I was going to suggest using a software PLL, but perhaps averaging gives the same result. The same ADC signal can be fed to multiple blocks with different averaging times and we can just use whichever ones seems the most useful.
I'm working on setting up a moving-average in the custom C code block that counts the zero crossings to see if this approach is able to mitigate the glitchy frequency readout due to mis-counting by one clock cycle between successive zero crossings. I'm storing an array the size of the moving average window of frequency readouts at each clock cycle, and then taking the arithmetic mean over the window. By keeping a summing variable that updates itself each clock cycle, the actual moving average process isnt very intensive in terms of computational time. The array does take up some memory, but even if I perform the moving average over 1 second with 16384 double precision numbers stored in the array, its still only 130 kB so I don't think it is a concern. Some tests I've been doing while tuning the code suggest that with a moving average over 16384 samples (i.e. 1 second), I can eliminate glitches at the 1Hz level in the frequency readout for frequencies up to 5 kHz (generated digitally using an oscillator block). Some tuning still needs to be done, and the window could possibly be shortened. I also need to take a look at the systematic errors in this revised counting scheme, preferably with an analog source, but this is overall, I think, an improvement.
On a side note, I noticed some strange behaviour while running the cds average command - even though my signal had zero fluctuations, using z avg 10 -s C1:TST-FC_FREQUENCY_OUT gave me a standard deviation of ~1 kHz. I'm not sure what the problem is here, but all the calibration data I took in earlier trials were obtained using this so it would be useful to perform the calibration again.
Earlier today, the front panels for the 1U chassis I obtained to house the Wenzel dividers + RF amplifiers arrived, which meant that finally I had everything needed to complete the assembly. Pictures of the finished arrangement attached.
Summary of the arrangement:
Once I figure out the problem with this amplifier/replace it, the box is ready to be installed.
I carried out some more tests on the digital frequency counting system today, mainly to see if the actual performance mirrors the expected systematic errors I had calculated here.
Setup and measurement details:
I used the Fluke 6061A RF signal generator to output an RF signal at various frequencies, one at a time, between 10 and 70 MHz. I split the signal (at -15 dBm) into two parts, one for the X-channel and one for the Y-channel using a mini-circuits splitter. I then looked at the input signal using testpoints I had set up within the model, to decide what thresholds to set for the Scmitt trigger. Finally, I averaged the outputs of the X and Y channels using z avg -s 10 C1:ALS-FC_X_FREQUENCY_OUT and also looked at the standard deviation as a measure of the fluctuations in the output (these averages were taken after a low-pass filter stage with two poles at 20Hz, chosen arbitrarily).
I carried out some further diagnostics and found some ways in which I could optimize the zero-crossing-counting algorithm, such that the error in the measured frequency is now entirely within the expected range (due to a +-1 clock cycle error in the counting). We can now determine frequencies up to ~60 MHz with less than 1 MHz systematic error and <10 kHz statistical error (fluctuations after the 20 Hz lowpass). This should be sufficient for slow control of the end-laser temperatures.
The conclusion from my earleir tests was that there was possibly an improvement that could be made to setting the thresholds for the Schmitt trigger stage in the model. In order to investigate this, I wanted to have a look at the 64K sampled raw input to the ADCs. Yesterday Eric helped me edit the appropriate .par file for viewing these channels for c1x03, and for an input frequency of 70MHz (after division, ~4.3 kHz square wave), the signal looked as expected (top left plot, attachment #1). This prompted me to check the counting algorithm again with the help of various test points I had setup within the model. I found that there was a tendency to under-count the number of clock-cycles between zero-crossings by more than 1 clock cycle, due to the way my code was organized. I fixed this and found that the performance improved dramatically, compared to my previous trials. With the revised counting algortihm, there was at most a +-1 clock cycle error in the counting, and the systematic error between the measured and requested RF frequencies is now completely accounted for taking this consideration into account. The origin of this residual error can be understood by looking at the top right plot in Attachment #1 - presumably because of the effects of some downsampling filter, the input signal to the Schmitt trigger isnt a clean square wave (even at 4kHz) - specifically, the time spent in the LOW and HIGH states of the Schmitt trigger can vary between successive zero crossings because of the shape of the input waveform. As a result, there can be a +-1 clock cycle error in the counting process. Attachment #2 shows this - the red and blue lines envelope the measured frequency for the whole range investigated: 10-70MHz. Attachment #3 shows the systematic error as a function of the requested frequency.
If there was some way to bypass the downsampling filter, perhaps the high-frequency performance could be improved a little.
The new ZKL-1R5 RF amplifier that Steve ordered arrived yesterday. I installed this in the frequency divider box and did a quick check using the Fluke RF signal generator and an oscilloscope to verify that both the X and Y paths were working.
I've now installed the box in the 1X2 rack where the olf "RF amplifiers for ALS and FOL" box used to sit (I swapped that out as I needed the L brackets on that chassis to mount mine, see Attachment #1 for the new layout). The power cable that used to power the old chassis was available, but the connector was of the wrong gender, so I had to switch this out. After verifying that I was getting the correct voltage (+15V), I connected it to the chassis.
I then did a quick check with the Fluke generator to make sure that all was working as expected - Eric had set up some ADC channels for me earlier today in the C1ALS model, and I copied over my frequency counting module from C1TST into C1ALS, and recompiled the model. The RF generator was set to generate a 25MHz signal at -20dBm, which I then split using an RF power splitter between the X and Y arms. I then checked the output using dataviewer - I recovered an output frequency of ~27.64 MHz with a jitter of ~0.02 MHz with a 20Hz low-pass filter in place (see Attachment #2), which looks consistent with the systematic error inherent in the zero-crossing counting algorithm and random fluctuations I had observed in my earlier trials, discussed here. But a more systematic investigation needs to be carried out in this regard. The interfacing between the hardware and software seems to be working alright though. I've left the RF generator near the 1x2 rack for now, though its powered off.
The mode cleaner unlocked quite a few times while I was working but looks stable now.
One of the main draw backs of the measurement was the polarisation was not aligned properly in the setup. So, then the next step was to identify the polarisation at different locations in the beam path and to maximise the polarisation to either S or P component.
So, we introduced HWP at the input beam path after isolator as shown in attachment #1. Also, the polarisation was tested at positions P1, P2, P3, and P4 shown in attachment #1 by placing a polarisation beam splitter at these locations and then by observing the transmitted (P component) and reflected light (S component) using power meter.
The observations at different locations are as the follows
These observations show that the P and S components are almost equal, and this is not a good polarisation arrangement. At this point, we also had to check whether the incoming beam is linearly polarised or not.
To test the same, the PBS was placed at position P1 and the P and S components were observed with power meter as the HWP is rotated.Attachment # 2 shows the results of the same, that is the variation in P and S component as the HWP is rotated.
This result clearly shows that the input beam is linearly polarised. The HWP was then adjusted such that the P component is maximum and coupled to the MZI. With this orientation of HWP, the polarisation observed at different positions P1, P2, P3, and P4 are as follows.
This shows that the polarisation is linearly polarised as well as it is oriented along the P direction (parallel to the optical table).
We have the polarisation maintaining fiber (PM 980) as the delay fiber. The polarisation of the light as it propagates through a PM fiber depends on how well the input beam is coupled to the axis (slow or fast) of the fiber. So, the next task was to couple the light to one of the axes of the fiber.
The alignment key on the fiber is a good indication of the axis of the fiber. In our case, the alignment key lines up with the slow axis of the fiber. We decided to couple the light to the fast axis of the fiber. Since the incoming beam is P polarised, the output fiber coupler was aligned such that the fast axis is parallel to optical table as possible.
A PBS was then introduced after the fiber output collimator . There is a HWP (marked as HWP2 in attachment 1) in front of the input coupler of the fiber as well. This HWP was then rotated and observed the P and S component from the PBS that is now placed after the output coupler with a power meter.The idea was , when the light is coupled to the fast axis of the fiber, we will see the maximum at the P componet at the output
Attachment # 3 shows the observation.
In this way I tried to find the orientation of the HWP2 such that the P component is maximum at the output. But I was not succeeded in this method and observed that the output was fluctuating when the fiber was disturbed. One doubt we had was whether the fiber is PM or not . Thus we checked the fiber end with fiber microscope and confirmed that it is PM fiber.
Thus, we modifed the setup as shown in attachement # 4.The photodetector (PDA55) was monitoring the S component and the output of the detector was observed on an oscilloscope. We rotated the HWP2 such that the S component is almost minimum. At the same time, we were disturbing the fiber and was observing whether the output is fluctuating. The HWP2 angle was tweaked around the minimum of S component and observed the output with disturbing the fiber. This way we found the orientation of HWP2 such that the light is coupled to the fast axis of the fiber and the output was not fluctuating while we disturb the fiber. We tested it by heating the fiber with a heat gun as well and confirmed that the output is not fluctuating and thus the light is coupled to the fast axis of the fiber.