40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 85 of 337  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  3530   Tue Sep 7 08:56:00 2010 AlbertoUpdateElectronicsFrequency Generation Box Assembly - Phase Noise 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.

2010-09-03_FreqBoxPhaseNoise_AllOutputsComparison_smooth.png

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.

Attachment 2: 2010-09-03_FreqBoxPhaseNoise_AllOutputsComparison_smooth.pdf
2010-09-03_FreqBoxPhaseNoise_AllOutputsComparison_smooth.pdf
  3450   Fri Aug 20 16:41:43 2010 AlbertoUpdateElectronicsFrequency Generation Box Assembly Completed

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.

 

Attachment 1: RFplan_6_measured_powers.png
RFplan_6_measured_powers.png
Attachment 2: DSC_2409.JPG
DSC_2409.JPG
Attachment 3: DSC_2413.JPG
DSC_2413.JPG
Attachment 4: DSC_2414.JPG
DSC_2414.JPG
Attachment 5: DSC_2415.JPG
DSC_2415.JPG
Attachment 6: DSC_2417.JPG
DSC_2417.JPG
Attachment 7: DSC_2419.JPG
DSC_2419.JPG
  468   Thu May 8 01:07:24 2008 ranaSummaryLSCFrequency Noise test: MC Trans Backscatter
There is a wandering hump in the MC_F spectrum. It can move around on the time
scale of seconds between 40 and 200 Hz. It has an amplitude ~5-50x above the background spectrum. This seems new; I don't remember it
from a year ago. It is there in the IFO unlocked as well as the IFO locked as well as the locked + CM mode.

Tapping the AS table and/or the PSL table enclosures produces a broadband increase in the MC_F spectrum but doesn't
selectively effect the hump.

We thought it might be backscatter from the MC TRANS path and so we stuck in one of Steve's cool black glass V's into
this space. No effect. We should design a black glass V dump which we can replicate in large quantities for us and for
the sites. Something like the one on the LSC PDs, but with a 1 sq. inch opening area and a 2 inch depth.


We have also done this on the MC2 - TRANS beam before. No noise reduced there either.

The noise hump is appearing in MC_F but not in CARM_IN1 (after the CM handoff) so it seems like the MC has enough gain
to squash it. This also exonerates the MC REFL path since anything there would not be effected by the MC servo gain and
so would be visible in CARM.

My best guess is that there is something really, really scattery on the PSL table. But for now it looks like this is not a
big factor in the locking
issues.
  10760   Sun Dec 7 13:11:57 2014 manasaSummaryGeneralFrequency Offset Locking - To Do List

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

Attachment 1: FOLtodolist.pdf
FOLtodolist.pdf
  10791   Fri Dec 12 14:38:39 2014 manasaSummaryGeneralFrequency Offset Locking - To Do List (Revised)

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.

Attachment 1: FOLtodolist.pdf
FOLtodolist.pdf
  10779   Thu Dec 11 12:39:31 2014 diegoUpdateComputer Scripts / ProgramsFrequency Offset Locking scripts status

 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:

  • the Raspberry Pi operates locally: everything is in its /opt/FOL directory, which is a mirror of /opt/rtcds/caltech/c1/scripts/FOL/ ; some backup/sync scripts should be set up, tell me what kind (sync direction, place to call the script from, etc..) is recommended and I'll set it up;

 

  • the /opt/FOL directory contains:
    • ADC_interface                 : Akhil's ADC interface software and dependencies;
    • akhilTestCodes                : Akhil's work directory with his programs and data;
    • backup                             : two zip files with a full backup of the FOL stuff for both chiara and domenica at 2014/12/08, before my work on the directory;
    • fcreadoutApp                   : the EPICS app compiled on domenica. I didn't modify anything in particular here, as I don't know much about EPICS Apps; I'm not even sure if it is used by now, as I launch EPICS manually by just giving him a .db file (see below).
    • armFC*                        : it is the single program that constantly fetches data for the channels: it takes as arguments the RPi device (/dev/hidraw0 for the X arm, and /dev/hidraw1 for the Y arm) and the value to write into the frequency counter (0x3 for initialization and 0x2 for actual use); hence, there is no more need for recompilation!
    • epics_channels.py :  this is the new version of the old codetorun.py script; it handles the initialization and the availability of the two beatnote channels;
    • fcreadout / freqCountIOC : these are the binaries of the EPICS apps that I found on chiara/domenica; they are not used as of now, but could be useful;
    • fcreadout.db           : it is the database file that is loaded by EPICS to handle the channels;
    • FOLPID.pl              : the Perl PID controller; it is still the old version, we will work on this one later on (see Manasa's schedule at elog 10760 for info)

 

  • Domenica's environment:
    • as I said, everything runs locally from /opt/FOL;
    • in particular, I added in /etc/inittab two lines that launch EPICS and the python script for the channels; respawn is supported so these processes should always be available. For this to happen, DO NOT MOVE armFC, epics_channels.py and fcreadout.db from the /opt/FOL directory on domenica!
    • I added a udev rule in /etc/udev/rules.d/98-hidraw-permissions.rules to let the controls user access the /dev/hidraw* devices without having to sudo all the time;
    • I updated the ~/.bashrc and /opt/epics/epics-user-env.sh files to fix syntax errors and add some aliases we usually use.
  1744   Tue Jul 14 16:31:46 2009 ClaraUpdatePEMFrequency Response of Microphone (Bonnie)

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.

Attachment 1: Bonnie_fres_regplot.pdf
Bonnie_fres_regplot.pdf
Attachment 2: Bonnie_fres_logplot.pdf
Bonnie_fres_logplot.pdf
  79   Wed Nov 7 14:01:31 2007 waldmanOmnistructureOMCFrequency and Intensity noise
One of the biggest problems I had using the PZT to lock was excessive noise. I did a little noise hunting and found that the problem was the cable running from the rack to the laser fast input. As a reminder, the laser has a 4 MHz / volt fast input. We require about 300 MHz to go one FSR, so there is a Thorlabs HV box between at the NPRO fast input which takes 0-10 V -> 0-150 V. The 150 V HV range is worth about 600 MHz of NPRO frequency.

OLD SETUP: Single side of DAC differential (10 Vpp) -> 9V in series with 10 kOhm -> 10 kOhm input impedance of Thorlabs HV -> NPRO

We used the single side of the DAC differential because we didn't have a differential receiver. This turned out to be a bad idea because the cable picks up every 60 Hz harmonic known to man kind.

NEW SETUP: Digital conditioning -> DAC differential (digitally limited to 0 - 1 V) -> SR560 in A-B mode gain 10 (0 - 10 V output)-> Thorlabs HV -> NPRO.

This has almost no 60 Hz noise and works much, much better. Moral of the story, ALWAYS USE DIFFERENTIAL SIGNALS DIFFERENTIALLY !

Note that I may be saturating the SR560 with 10 V output, Its spec'd for 10 Vpp output with 1 VDC max input. I don't know whether or not it can push 10 V out....
  9200   Fri Oct 4 01:09:33 2013 ManasaUpdateGreen LockingFrequency counter for ALS

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. 

  11736   Thu Nov 5 03:04:13 2015 gautamUpdateCDSFrequency counting - systematics and further changes

I've made a few more changes to the frequency counting code - these are mostly details and the algorithm is essentially unchanged.

  • The C-code block in the simulink model now outputs the number of clock cycles (=1/16384 seconds) rather than the frequency itself. I've kept converting this period to frequency step by taking the reciprocal as the last step of the signal chain, i.e. after the LP filter.
  • In the current version of the FC library block, I've disabled the moving average in the custom C code - I've left the functionality in the code, but the window length at the moment is set to 1, which in effect means that there is no moving average. I found that comparable jitters in the output are obtained by using no moving average, and having two 2-pole IIR low-pass filters in series (at 4Hz and 2Hz) as by doing a moving average over 4096 clock cycles and then passing that through a 2Hz IIR lowpass filter (as is to be expected).

Systematic error

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. 

Attachment 1: Systematic_error.pdf
Systematic_error.pdf
Attachment 2: systematics_origin.pdf
systematics_origin.pdf
  11709   Fri Oct 23 18:36:48 2015 gautamUpdateCDSFrequency counting - workable setup prepared

I've made quite a few changes in the software as well as the hardware of the digital frequency counting setup.

  • The main change on the software side is that the custom C code that counts intervals between successive zero crossings and updates the frequency output now has a moving average capability - the window size is readily changable (by a macro in the first line of the code, which resides at /opt/rtcds/userapps/release/cds/c1/src/countZeroCrossingWindowed.c - however, changing the window size requires that the model be recompiled and restarted), and is currently set to 4096 because based on some empirical trials I did, this seemed to give me the frequency output with the least jitter, and also smaller systematic errors than in my earlier trials described here.
  • The filter modules for both the X and Y channels now have 2 pole butterworth low pass filters with poles at 64Hz, 32Hz, 16Hz, 8Hz, 4Hz, 2Hz and 1Hz loaded. Again, based on my empirical trials, a combination of a moving average filter in the C code and the IIR filters after that worked best in terms of reducing the jitter in the frequency readout. I think the fact that the moving average 'spreads' the impulse caused by a glitch in the counting algorithm improves the response of the combination as compared to having only the IIR filters in place. 
  • The Frequency Counting SIMULINK block has been cleaned up a little - I have removed unnecessary test points I had set up for debugging, and is now a library part called "FC".
  • After the experience of having C1ALS crash as noted here, I was doing all my testing in the C1TST model. Having made all the changes above, I reverted to the C1ALS model, which compiled and ran successfully this time.
  • On the hardware side, I interchanged the couplers mentioned here - so the 20dB coupler now sits on the X green beat PD, while the 10dB coupler sits on the Y green beat PD. This change was motivated by wanting to test out the digital frequency counting setup by performing an arm scan through an IR resonance using ALS, and we found that the PSL+Y green beat frequency was better behaved than the X+PSL combination.

Arm scan

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

 

 

 

 

Attachment 1: Yscan.pdf
Yscan.pdf
  11710   Fri Oct 23 19:27:19 2015 KojiUpdateCDSFrequency counting - workable setup prepared

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.

Anyways:

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?
http://nodus.ligo.caltech.edu:8080/40m/11111
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...)

  11712   Sat Oct 24 12:34:43 2015 gautamUpdateCDSFrequency counting - workable setup prepared

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.)

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

 

Attachment 1: Yscan.pdf
Yscan.pdf
Attachment 2: Frequency_readout.pdf
Frequency_readout.pdf
  11615   Thu Sep 17 19:58:06 2015 gautamSummaryComputer Scripts / ProgramsFrequency counting algorithm

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). 

  11628   Mon Sep 21 18:31:06 2015 gautamSummaryComputer Scripts / ProgramsFrequency counting algorithm

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:

  • Bottom left: digitized version of the input signal - I used this to set the upper and lower thresholds on the Schmitt trigger at +1000 counts and -1000 counts respectively.
  • Top left: Schmitt trigger output (red trace) and the difference between successive samples of the Schmitt trigger output (blue trace - this variable is used to detect a zero crossing)
  • Top right: Counter variable used to measure intervals between successive zero crossings, and hence, the frequency. The frequency output is held until the next zero crossing is detected, at which time counter is reset
  • Bottom right: frequency output in Hz.

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.

Bottom line

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. 

Attachment 1: Simulink_model.pdf
Simulink_model.pdf
Attachment 2: diagnostic_plots.pdf
diagnostic_plots.pdf
Attachment 3: Error_high_frequency.pdf
Error_high_frequency.pdf
Attachment 4: Error_low_frequency.pdf
Error_low_frequency.pdf
Attachment 5: Frequency_sweep_100_500_Hz.pdf
Frequency_sweep_100_500_Hz.pdf
Attachment 6: Frequency_sweep_100_2000_Hz.pdf
Frequency_sweep_100_2000_Hz.pdf
  11629   Mon Sep 21 23:18:55 2015 ericqSummaryComputer Scripts / ProgramsFrequency counting algorithm

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. 

  11631   Tue Sep 22 02:11:17 2015 ranaSummaryComputer Scripts / ProgramsFrequency counting algorithm

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.

  11704   Tue Oct 20 17:36:01 2015 gautamUpdateCDSFrequency counting with moving average

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. 

  11647   Tue Sep 29 03:14:04 2015 gautamUpdateCDSFrequency divider box

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:

  • Two identical channels (RF amplifier + /64 divider + /256 divider), one for each arm
  • The front panels are anodized, and isolated SMA feedthroughs are used 
  • Given the large number of units to be supplied with DC power (2 amplifiers + 4 dividers), I chose to use two D1000217 power regulators (the default configuration takes +-18V as input, and outputs regulated +-15V, which was fine for the dividers, but the ZKL-1R5 requires +12V, so I changed the resistor R2 in the schematic from a 10.7K to 8.451K so as to accommodate this).
  • The amplifiers and dividers are mounted on a steel plate, which is itself mounted on the chassis via insulating posts. 

Testing:

  • I first verified the power regulator circuitry without hooking up the amplifiers/dividers - with a multimeter, I verified I was getting +15V and +12V as expected.
  • I then connected the amplifiers and dividers, and decided to first check the behaviour of each channel using the Fluke 6061 RF function generator and an oscilloscope. One of the channels (X-arm in the current configuration) worked fine - I got a 0-2.5V square wave as the output for input signals as low as -38dBm at 130MHz (consistent with out earlier observations).
  • The Y-arm channel however did not give me any output. In order to debug the problem, I decided to check the output after the amplifier first. The amplifier does not seem to be working for this channel - I get the same amplitude at the output as at the input. I verified that the correct DC power voltage of +12V was being supplied with a multimeter, but I am not sure how to debug this further. The amplifier is basically straight out of the box, and as far as I can tell, I have not done anything to damage it, as this was the first time I am connecting it to anything, and I repeated the same steps on the Y-arm as the X-arm, which seems to work alright.
  • The rest of the Y-arm signal chain was verified to be working by bypassing the amplifier stage (the attached photographs show the box in this configuration. There seems to be no issues with the divider part of the signal chain. 

Once I figure out the problem with this amplifier/replace it, the box is ready to be installed. 

 

Attachment 1: IMG_0014.JPG
IMG_0014.JPG
Attachment 2: IMG_0015.JPG
IMG_0015.JPG
  11684   Mon Oct 12 17:04:02 2015 gautamUpdateCDSFrequency divider box - further tests

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).

Results:

  • Attachment #1 shows a plot of the measured RF frequency as a function of the frequency set on the Fluke 6061A. The errorbars on this plot are the standard deviations mentioned above. 
  • Attachment #2 shows a plot of the systematic error (mean measured value - expected value) for the two channels. It is consistent with the predictions of Attachments #3 and #4 in elog 11628 (although I need to change the plots there to a frequency-frequency comparison). This error is due to the inherent limitations of frequency counting using zero crossings, I can't think of a way to get around this).
  • I found that a lower threshold of 1800 and an upper threshold of 2200 worked well over this range of frequencies (the output of the Wenzel dividers goes between 0V and 2.5V, and the "zero" level for the digitized signal corresponds to ~2000, as determined by looking at a dataviewer plot of a tetspoint I had set up in my model). Koji suggested taking a look at the raw ADC input signal sampled at 64 kHz but this is not available for c1x03, the machine that c1als runs on. 

 

 

Attachment 1: calibration.pdf
calibration.pdf
Attachment 2: systematics.pdf
systematics.pdf
  11690   Wed Oct 14 17:40:50 2015 gautamUpdateCDSFrequency divider box - further tests

Summary:

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.

Details: 

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. 

Attachment 1: time_series_input_signals.pdf
time_series_input_signals.pdf
Attachment 2: calibration_20151012.pdf
calibration_20151012.pdf
Attachment 3: systematics_20151012.pdf
systematics_20151012.pdf
  11683   Fri Oct 9 19:54:58 2015 gautamUpdateCDSFrequency divider box - installation in 1X2 rack

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. 

 

Attachment 1: IMG_0027.JPG
IMG_0027.JPG
Attachment 2: time_seris_25MHz.pdf
time_seris_25MHz.pdf
  562   Wed Jun 25 01:30:19 2008 JohnSummaryIOOFrequency noise after the MC
I made some (very) rough estimates of the contribution made to the noise after the mode cleaner by three sources.

Seismic noise - how much of the signal is due to the mode cleaner compenstaing for seismic disturbance of CARM.
Actuator noise - coil drivers and DAC noise.
MC_F - estimate of MC_F suppressed by the loop gain.
Attachment 1: MC2noise080623.png
MC2noise080623.png
  14518   Fri Apr 5 11:40:57 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source
  • Attachment #1 shows the present experimental setup. The photodiode is now replaced with PDA255. The farther end of the fiber (output of the delayed arm) is coupled through a collimator and aligned such that the beam from the delayed path fall on the detector along with the undelayed path of MZI. We tried to measure the frequency noise of the laser with this setup, but we didn’t get anything sensible.
  • 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

Position Input power (mW) P component (mW) S component (mW)
P1 279 145 123
P2 255 113 137
P3 129 67 58
P4 124 66 53

 

  • 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.

Position Input (mW) P component (mW) S component (mW)
P1 283 276 5
P2 248 228 7
P3 126 121 2
P4 128 117 1
  • 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.

Attachment 1: Modified_experimental_setup.JPG
Modified_experimental_setup.JPG
Attachment 2: Checking_polarisation.pdf
Checking_polarisation.pdf
Attachment 3: Checking_the_polarisation_alignment_of_the_delay_fiber.pdf
Checking_the_polarisation_alignment_of_the_delay_fiber.pdf
Attachment 4: Setup_to_test_the_polarisation_alignment_of_delay_fiber.JPG
Setup_to_test_the_polarisation_alignment_of_delay_fiber.JPG
  14520   Sat Apr 6 02:07:40 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source
  • The alignment of the output beam from the delayed path of MZI to the photodetector was disturbed when we did the polarisation characterisation yesterday. So, today we tried to align the output beam from the delayed path of MZI to the detector .
  • We then observed the beat output from the detector on oscilloscope.We initialy observed a dc shift . We then applied a frequency modulation on the input laser and observed the output on oscilloscope. We expected to see variation in output frequency in accordance with variation of input frequency modulation. But we didnt observe this and we were not really getting the interference pattern. 
  • We tried to make the alignment better. With a better alignment, we could see the interference pattern. We also observed that the output frequency was varying in accordance with variation in the input frequency modulation. We would expect a better result with proper mode matching of the two beams on the photodetector.
  14529   Wed Apr 10 00:33:09 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source
  • Attachement #1 shows the input (ch4-green) modulation frequency and the photodiode output (ch1-yellow) when the modulation frequency is about 100 Hz
  • Attachement #2 shows the input (ch4-green) modulation frequency and the photodiode output (ch1-yellow) when the modulation frequency is about 30 Hz
  • The output frequency is varying in accordance with variation in modulation frequency. It is observed that, for a given modulation frequency also, the output frequency is fluctuating. There could be multiple reasons for this behaviour. One of the main reasons is the frequency noise of the laser itself. Also, there could be acoustic noise coupled to the system (eg, by change in length of the fiber).
  • The experimental setup is then modified as shown in attachment #3. The thick beam spliiter is replaced with a thinner one. The mount is also changed such that the transmitted beam can be now coupled to an other photodiode (earlier  the transmitted light was blocked by the mount). One more photodiode (PDA55) is introduced .So now the two photodiodes in the setup are PDA520 and PDA 55. 
  • We then applied frequency modulation on the input laser and observed the output of the two photodiodes. But we didn't get the results as we expected and observed earlier (shown in attachment #1 &2). Looks like, the problem is poor mode matching between the two beams. 
Quote:
  • The alignment of the output beam from the delayed path of MZI to the photodetector was disturbed when we did the polarisation characterisation yesterday. So, today we tried to align the output beam from the delayed path of MZI to the detector .
  • We then observed the beat output from the detector on oscilloscope.We initialy observed a dc shift . We then applied a frequency modulation on the input laser and observed the output on oscilloscope. We expected to see variation in output frequency in accordance with variation of input frequency modulation. But we didnt observe this and we were not really getting the interference pattern. 
  • We tried to make the alignment better. With a better alignment, we could see the interference pattern. We also observed that the output frequency was varying in accordance with variation in the input frequency modulation. We would expect a better result with proper mode matching of the two beams on the photodetector.
Attachment 1: Modulation_frequency_100Hz.jpg
Modulation_frequency_100Hz.jpg
Attachment 2: Modulation_frequency_30Hz.jpg
Modulation_frequency_30Hz.jpg
Attachment 3: Modified_setup.JPG
Modified_setup.JPG
  14540   Fri Apr 12 01:22:27 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source

The alignement was disturbed after the replcement of the beam splitter. We tried to get the alignment back . But we are not succeeded yet in getting good interfernce pattern. This is mainly because of poor mode matching of two beams. We will also try with the spooled fiber.

Quote:

 

  • The experimental setup is then modified as shown in attachment #3. The thick beam spliiter is replaced with a thinner one. The mount is also changed such that the transmitted beam can be now coupled to an other photodiode (earlier  the transmitted light was blocked by the mount). One more photodiode (PDA55) is introduced .So now the two photodiodes in the setup are PDA520 and PDA 55. 
 
 
  14579   Fri Apr 26 12:10:08 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source

From the earlier results with homodyne measurement,the Vmax and Vmin values observed were comparable with the expected results . So in the time interval between these two points, the MZI is assumed to be in the linear region and I tried to find the frequency noise based  on data available in this region.This results is not significantly different from that we got before when we took the complete time series to calculate the frequency noise. Attachment #1 shows the time domain data considered and attachment #2 shows the frequecy noise extracted from that. 

As discussed, we will be trying the heterodyne method next. Initialy, we will be trying to save the data with two channel ADC with 16 kHz sampling rate. With this setup, we can get the information only upto 8 kHz. 

Attachment 1: Time_domain_data.pdf
Time_domain_data.pdf
Attachment 2: Frequency_noise_from_data_in_linear_region.pdf
Frequency_noise_from_data_in_linear_region.pdf
  14586   Tue Apr 30 17:27:35 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source

We repeated the homodyne measurement to check whether we are measuring the actual frequency noise of the laser. The idea was to repeat the experiment when the laser is not locked and when the laser is locked to IMC.The frequency noise of the laser is expected to be reduced at higher frequency  (the expected value is about 0.1 Hz/rtHz at 100 Hz ) when it is locked to IMC . In this measurement, the fiber beam splitter used is Non PM. Following are the observations

1. Time domain output_laser unlocked.pdf : Time domain output when the laser is not locked. The frequency noise is estimated from data corresponds to the linear regime. Following time intervals are considered to calculate the frequency noise (a) 104-116 s (b) 164-167 s (c) 285-289 s

2. Frequency_noise_laser_unlocked.pdf: Frequency noise when the laser is not locked. The model used has the functional form of 5x104/f as we did before. Compared to our previous results, the closeness of the experimental results to the model is less from this measurement. In both the cases, we have the uncertainty because of the fiber length fluctuation. Moreover, this measurement could have effect of polarisation fluctuation as well.

3.Time domain output_laser locked.pdf :Time domain output when the laser is locked. Following time intervals are considered to calculate the frequency noise (a) 70-73 s (b) 142-145 s (c) 266-269 s. 

4. Frequency_noise_laser_locked.pdf : Frequency noise when the laser is locked

5. Frequency noise_comparison.pdf : Comparison of frequency noise in two cases. The two values are not significantly different above 10 Hz. We would expect reduction in frequency noise at higher frequency once the laser is locked to IMC. But this result may indicate that we are not really measuring the actual frequency noise of the laser.

Attachment 1: Homodyne_repeated_measurement.zip
  11800   Mon Nov 23 20:32:43 2015 KojiUpdateLSCFrequency source fixed, IMC LO level adjusted

The frequency source was fixed. The IMC LO level was adjusted.

IMC is locked => OLTF measured UGF 144kHz PM 30deg.

  11801   Mon Nov 23 21:48:49 2015 KojiUpdateLSCFrequency source fixed, IMC LO level adjusted

The trouble we had: the 29.5 MHz source had an output of 6 dBm instead of 13 dBm.

The cause of the issue: A short cable inside had its shield cut and had no connection of the return.


- The frequency source box was dismantled.
- The power supply voltages of +28 and +18 were provided from bench supplies.
- The 29.5 MHz output of 5~6 dBm was confirmed on the work bench.
- The 11 MHz OCXO out (unused) had an output of 13 dBm.

- Once the lid was opened, it was immediately found that the output cable for the 29.5 MHz source had a sharp cut of the shield (Attachment1).
- OK. This cable was replaced. The output of 13 dBm was recovered.

- But wait. Why is the decoupling capacitor on the 29.5 MHz OCXO bulging? The polarity of the electrolytic capacitor was wrong!
- OK. This capacitor was replaced. It was 100 uF 35 V but now it is 100 uF 50 V.

- I further found some cables which had flaky shields. Some of them were twisted. When the panel cable s connected, the feedthroughs were rotated. This twists internally connected cables. Solder balls were added to the connector to reinforce the cable end.

- When the box was dismantled, it was already noticed that some of the plastic screws to mount the internal copper heat sinks for ZHL-2's were broken.
They seemed to be degraded because of the silicone grease. I didn't try to replace all as it was expected to take too much time, so only the broken screws
were replaced with steel screws with shoulder washers
at the both side of the box.

- After confirming the circuit diagram, the box was returned to the rack. The 29.5 MHz output of 13 dBm there was confirmed.

Attachment 1: IMG_2136.JPG
IMG_2136.JPG
Attachment 2: IMG_2129.JPG
IMG_2129.JPG
Attachment 3: IMG_2133.JPG
IMG_2133.JPG
  14476   Fri Mar 8 08:40:26 2019 AnjaliConfiguration Frequency stabilization of 1 micron source

The schematic of the homodyne configuration is shown below.

Following are the list of components

Item Quantity Availability Part number  Remarks
Laser (NPRO) 1 Yes    
Couplers (50/50) 5 3 No's FOSC-2-64-50-L-1-H64F-2 Fiber type : Hi1060 Flex fiber
Delay fiber  two loops of 80 m Yes PM 980

 

One set of fiber is now kept along the arm of the interferometer

InGaAs PD (BW > 100 MHz) 4 Yes NF1611

Fiber coupled (3 No's)

Free space ( 2 No's)

SR560 3 Yes    
  • The fiber mismatch between the couplers and the delay fiber could affect the coupling efficiency
Attachment 1: Homodyne_setup.png
Homodyne_setup.png
  6195   Fri Jan 13 00:51:40 2012 Leo SingerUpdateStewart platformFrequency-dependent requirements for Stewart platform

Below are revised design parameters for the Stewart platform based on ground motion measurements.

The goal is that the actuators should be able to exceed ground motion by a healthy factor (say, two decades in amplitude) across a range from about .1 Hz to 500 Hz.  I would like to stitch together data from at least two seismometers, an accelerometer, and (if one is available) a microphone, but since today this week I was only able to retrieve data from one of the Guralps, I will use just that for now.

The spectra below, spanning GPS times 1010311450--1010321450, show the x, y, and z axes of one of the Guralps.  Since the Guralp's sensitivity cuts off at 50 Hz or so, I assumed that the ground velocity continues to fall as f-1, but eventually flattens at acoustic frequencies.  The black line shows a very coarse, visual, piecewise linear fit to these spectra.  The corner frequencies are at 0.1, 0.4, 10, 100, and 500 Hz.  From 0.1 to 0.4 Hz, the dependence is f-2, covering the upper edge of what I presume is the microseismic peak.  From 0.4 to 10 Hz, the fit is flat at 2x10-7 m/s/sqrt(Hz).  Then, the fit is f-1 up to 100 Hz.  Finally, the fit remains flat out to 500 Hz.

ground_velocity_spectrum.png

Outside this band of interest, I chose the velocity requirement based on practical considerations.  At high frequencies, the force requirement should go to zero, so the velocity requirement should go as f--2 or faster at high frequencies.  At low frequencies, the displacement requirement should be finite, so the velocity requirement should go as f or faster.

The figure below shows the velocity spectrum extended to DC and infinite frequency using these considerations, and the derived acceleration and displacement requirements.

requirements.png

As a starting point for the design of the platform and the selection of the actuators, let's assume a payload of ~12 kg.  Let's multiply this by 1.5 as a guess for the additional mass of the top platform itself, to make 18 kg.  For the acceleration, let's take the maximum value at any frequency for the acceleration requirement, ~6x10-5 m/s2, which occurs at 500 Hz.  From my previous investigations, I know that for the optimal Stewart platform geometry the actuator force requirement is (2+sqrt(3))/(3 sqrt(2))~0.88 of the net force requirement.  Finally, let's throw in as factor of 100 so that the platform beats ground motion by a factor of 100.  Altogether, the actuator force requirement, which is always of the same order of magnitude as the force requirement, is

(12)(1.5)(6x10-5)(0.88)(100) ~ 10 mN.

Next, the torque requirement.  According to <http://www.iris.edu/hq/instrumentation_meeting/files/pdfs/rotation_iris_igel.pdf>, for a plane shear wave traveling in a medium with phase velocity c, the acceleration a(x, t) is related to the angular rate W'(x, t) through

a(x, t) / W'(x, t) = -2 c.

This implies that |W''(f)| = |a(f)| pi f / c,

where W''(f) is the amplitude spectral density of the angular acceleration and a(f) of the transverse linear acceleration.  I assume that the medium is cement, which according to Wolfram Alpha has a shear modulus of mu = 2.2 GPa and about the density of water: rho ~ 1000 kg/m3.  The shear wave speed in concrete is c = sqrt(mu / rho) ~ 1500 m/s.

The maximum of the acceleration requirement graph is, again, 6x10-5 m/s2 at 500 Hz..  According to Janeen's SolidWorks drawing, the largest principal moment of inertia of the SOS is about 0.26 kg m2.  Including the same fudge factor of (1.5)(100), the net torque requirement is

(0.26) (1.5) (6x10-5) (100) pi (500) / (1500) N m ~ 2.5x10-3 N m.

The quotient of the torque and force requirements is about 0.25 m, so, using some of my previous results, the dimensions of the platform should be as follows:

radius of top plate = 0.25 m,

radius of bottom plate = 2 * 0.25 m = 0.5 m, and

plate separation in home position = sqrt(3) * 0.25 m = 0.43 m.

 

One last thing: perhaps the static load should be taken up directly by the piezos.  If this is the case, then we might rather take the force requirement as being

(10 m/s2)(1.5)(12 kg) = 180 N.

An actuator that can exert a dynamic force of 180 N would easily meet the ground motion requirements by a huge margin.  The dimensions of the platform could also be reduced.  The alternative, I suppose, would be for each piezo to be mechanically in parallel with some sort of passive component to take up some of the static load.

  15061   Mon Dec 2 23:01:47 2019 gautamUpdateCDSFrequent DTT crashes on pianosa

I have been experiencing frequent crashes of DTT on pianosa in the past few weeks. This is pretty annoying to deal with when trying to characterize the interferometer loops. I attach the error log dumped to console. The error has to do with some kind of memory corruption. Recall that we aren't using a GDS version that is packaged with the SL7 lscsoft packages, we are using a pretty ancient (2.15) version that is built from source. I have been unable to build a newer version from source (though I didn't spend much time trying). pianosa is the only usable workstation at the moment, but perhaps someone can make this work on donatella / rossa for general improvement in quality of life.

Attachment 1: DTTerrorLog.tgz
  13734   Fri Apr 6 16:07:18 2018 gautamUpdateCDSFrequent EPICS dropouts

Kira informed me that she was having trouble accessing past data for her PID tuning tests. Looking at the last day of data, it looks like there are frequent EPICS data dropouts, each up to a few hours. Observations (see Attachment #1 for evidence):

  1. Problem seems to be with writing these EPICS channels to frames, as the StripTool traces do not show the same discontinuities.
  2. Problem does not seem local to c1auxex (new Acromag machine). These dropouts are also happening in other EPICS channel records. I have plotted PMC REFL, which is logged by the slow machine c1psl, and you can see the dropouts happen at the same times.
  3. Problem does not seem to happen to the fast channel DQ records (see ETMX Sensor record plotted for 24 hours, there are no discontinuties).

It is difficult to diagnose how long this has been going on for, as once you start pulling longer stretches of data on dataviewer, any "data freezes" are washed out in the extent of data plotted.

Attachment 1: EPICS_dropout.png
EPICS_dropout.png
  14208   Fri Sep 21 19:50:17 2018 KojiUpdateCDSFrequent time out

Multiple realtime processes on c1sus are suffering from frequent time outs. It eventually knocks out c1sus (process).

Obviously this has started since the fiber swap this afternoon.

gautam 10pm: there are no clues as to the origin of this problem on the c1sus frontend dmesg logs. The only clue (see Attachment #3) is that the "ADC" error bit in the CDS status word is red - but opening up the individual ADC error log MEDM screens show no errors or overflows. Not sure what to make of this. The IOP model on this machine (c1x02) reports an error in the "Timing" bit of the CDS status word, but from the previous exchange with Rolf / J Hanks, this is down to a misuse of ADC0 Ch31 which is supposed to be reserved for a DuoTone diagnostic signal, but which we use for some other signal (one of the MC suspension shadow sensors iirc). The response is also not consistent with this CDS manual - which suggests that an "ADC" error should just kill the models. There are no obvious red indicator lights in the c1sus expansion chassis either.

Attachment 1: 33.png
33.png
Attachment 2: 49.png
49.png
Attachment 3: Screenshot_from_2018-09-21_21-52-54.png
Screenshot_from_2018-09-21_21-52-54.png
  14210   Sat Sep 22 00:21:07 2018 KojiUpdateCDSFrequent time out

[Gautam, Koji]

We had another crash of c1sus and Gautam did full power cycling of c1sus. It was a sturggle to recover all the frontends, but this solved the timing issue.

We went through full reset of c1sus, and rebooting all the other RT hosts, as well as daqd and fb1.

Attachment 1: 23.png
23.png
  11926   Tue Jan 12 03:03:55 2016 ericqUpdateLSCFrequently making noise

Gautam will soon follow up with detailed analysis, but here is a brief summary of some of our activities and findings.

  • Two Marconis were beat together in various ways, we figured the noise added by turning on external modulation didn't make us happy. 
  • I locked the AUX X laser to the PSL via PZT. I'm more likely to believe we're seeing real broadband laser noise in this configuration; locking the the PSL laser to the IMC brought the noise down in a reasonable way. The PLL bandwidth was a smidge over 100k.
  • We saw a factor ~6 increase in noise when changing the diode current from 1.8 to 1.96A. We'll be following this up at more temperatures and currents soon. 
  • Gautam will verify the AUX X laser PZT calibration tomorrow, and post calibrated spectra of this increase. 

Please note that there is a long BNC cable still laid out from the IOO rack area to the X end table; watch your step!

  11929   Tue Jan 12 19:38:31 2016 gautamUpdateLSCFrequently making noise

EDITS 15Jan:

  1. Schematic of test setup added (Attachment #5). Note that the UGF measurements were made with the LPF and gain on the 'wrong' SR560, in a way defeating the purpose of having 2 SR560s in the setup. I only realised this after taking the measuements. But having done the loop algebra, I believe we can extract the necessary information, which is what has been done in subsequent plots...
  2. Koji pointed out that UGFs of ~100kHz was probably too high - this is when I took a closer look at the setup and realised the remarks made above in point 1. I realised we were in fact measuring the 'Process' open-loop TF. We can recover the loop TF by measuring the controller TF (which I did, see Attachment #3). The UGF for the PSL+X PLL loop is ~7.5kHz while that for PSL+Y is ~22kHz (both with a 1Hz LP on the SR560 and gain of x200).
  3. During the above investigations, I found that the measured TF for a 1Hz LP on the SR560 is weird - there seems to be a zero around 5kHz which gives some phase lead where one would expect a uniformly decaying gain and phase to be -90 degrees. Eric and I confirmed this behavioud on another SR560. Low-pass at 10kHz and high-pass at 1kHz seem to work fine. I will investigate this further when I get the time. Anyhow I don't think this affects anything as long as we measure the correct OLTF. It is still not clear to me why we even need this to lock the PLL...
  4. All the spectra (Attachment #4 and #5) are now calibrated taking into account the loop TF. I've added another panel with the spectra in V/rtHz as measured on the SR785, along with the SR560 output noise. I don't think any of the conclusions below are affected by these edits.

Summary:

I took several measurements today using the revised PLL scheme of using the Marconi just as an LO, and actuating on the Laser PZT to keep the PLL locked (I will put up a sketch soon). On the evidence of the attached plots (spectra of PLL control signal), I guess we can conclude the following:

  1. The AUX X laser's frequency noise performance is consistent with the levels expected from 'typical' NPRO numbers (and the datasheet), and is more or less consistent across different diode currents/crystal temperatures (? see below...).
  2. The diode current should be set to something less than 2.00 A
  3. Qualitatively, there is a difference in the shape of the spectra between the PSL+X and PSL+Y combinations above a couple of kHz. I don't know why we see this.

Attachment #2: Measured OLG of PLL for the PSL+X and PSL+Y combinations. The UGF in both cases looks to be above 100 kHz, so I didn't do any calibration for the spectra attached. The gain on the SR560 was set to 200 for all measurements.

Attachment #3: Measured spectra of PLL control signal for various diode currents, with one reading from the PSL+Y combination plotted for comparison. When we took some data last night, Eric noted that there was a factor of ~6 increase in the overall frequency spectrum level at higher currents, I will update the plots with last night's data as well shortly. I found it hardest to keep the PLL locked at a diode current of 2.00 A across all measurements.

Attachment #4: Measured spectra of PLL control signal at two different crystal temperatures. There does not seem to be any significant dependance on temperature, although I did only do the measurement at two temperatures.

Attachment #4 Attachment #1All the data used to make these plots (plus some that have yet to be added to the plots, I will update them).

Misc notes:

  • All measurements taken with two free-running lasers (PSL shutter closed)
  • The SR560 noise was measured with the input on the SR560 set to ground. 
  • In order to go from V/rtHz to Hz/rtHz on the plots, I used 1MHz/V for the X-end laser (which I verified by a quick measurement today to be approximately correct) and 4.6 MHz/V for the Y-end laser, based on an earlier measurement. 
  • I re-routed the long BNC cable to the Y-end, have yet to remove it. The BNC from the PDH setup at the X-end has been re-attached to the X-end NPRO.

Unrelated to this work:

When I came in this afternoon, I noticed that the PMC was unlocked. The usual procedure of turning the servo gain to -10dB and playing around with the DC output adjust slider on the MEDM screen did not work. Eric toggled a few buttons on the MEDM screen after which we were able to relock the PMC using the DC output adjust slider.

Attachment 1: 2016_01_AUXLaser.tar.gz
Attachment 2: OLGs.pdf
OLGs.pdf
Attachment 3: variedCurrent.pdf
variedCurrent.pdf
Attachment 4: variedTemp.pdf
variedTemp.pdf
Attachment 5: PLL_setup.pdf
PLL_setup.pdf
  4885   Sun Jun 26 16:02:12 2011 kiwamuUpdateIOOFriday MC activity

[Rana / Kiwamu]

 Last Friday we did several things for MC :

   - aligned the incident beam to MC

   - increased the locking gain by 6 dB and modified the auto-locker script accordingly

   - improved the alignment of the beam on the MC_REFLPD photo diode

 


(Motivation)

 In the beginning of the work, we wanted to know what RF frequency components are prominent in the reflection from MC.

Since the WFS circuits are capable for two RF notches, we wanted to determine which frequencies are appropriate for those notches.

So for the purpose we tried searching for unwanted RF components in the reflection.

However during the work, we found several things that needed to be fixed, so we spent most of the time for improving the MC locking.

 

(Some notes)

 - Alignments of the incident beam

At the beginning, the reflection from MC was about 2.2 in C1:IOO-REFLDC and the lock of MC had been frequently unlocked.

This situation of high reflection seemed to be related to a work done by Suresh (#4880).

Rana went to the PSL table and tweaked two input steering mirrors in the zig-zag path, and finally the reflection went down to ~ 0.8 in C1:IOO-REFLDC.

This work made the lock more robust.

 

 - Change of the locking gain

 After the alignment of the incident beam, we started looking at the time series of the MC_REFLPD signal with an oscilloscope as a start point.

What we found was a significant amount of 30 kHz components. This 30 kHz oscillation was thought be a loop oscillation, and indeed it was so.

We increased the loop gain by 6 dB and then the 30 kHz components disappeared successfully.

So the nominal locking gain of MC is now 11 dB in C1:IOO-MC_REFL_GAIN. The auto locker script was also modified accordingly.

 

- RF components in the MCREFL signal

After those improvements mentioned above, we started looking at the spectrum of the MCREFL PD using the spectrum analyzer HP8590.

The 29.5 MHz component was the biggest components in the spectrum. Ideally this 29.5 MHz signal should be zero when MC is locked.

One possible reason for this big 29.5 MHz signal was because the lock point was off from the resonant point.

We tweaked the offset in the MC lock path using a digital offset, C1:IOO-MC-REFL_OFFSET.

We found an offset point where the 29.5MHz signal went to the minimum, but didn't go to zero.

 

(works to be done)

So it needs some more works to investigate the cause of nonzero 29.5 MHz signal as well as investigation of what RF components should be notched out.

A good start point would be writing a GPIB interface script such that we can get the spectra from HP8590 without any pains.

  9641   Sun Feb 16 17:40:11 2014 KojiUpdateLSCFriday Night ALS

I wanted to try common/differential ALS Friday evening. I tried ALS using the LSC servo but this was not successfull.
The usual ALS servo in the ALS model works without problem. So this might be coming from the shape of the servo filter.
The ALS one has 1:1000 filter but the LSC one has 10:3000. Or is there any problem in the signal transfer between
ALS and LSC???


- MC:
Slow offset -0.302V

- IR:
TRX=1.18 / TRY=1.14, XARM Servo gain = 0.25 / YARM Servo gain = 0.10

- Green Xarm:
GTRX without PSL green 0.562 / with PSL green 0.652 -> improved upto 0.78 by ASX and tweaking of PZTs
Beat note found at SLOW OFFSET +15525
Set the beat note as +SLOW OFFSET gives +BEAT FREQ

- Green Yarm:
GTRY without PSL green 0.717 / with PSL green 1.340
Beat note found at SLOW OFFSET -10415
Set the beat note as +SLOW OFFSET gives -BEAT FREQ

- BEAT X -10dBm on the RF analyzer@42.5MHz / Phase tracker Qout = 2300 => Phase tracking loop gain 80 (Theoretical UGF = 2300/180*Pi*80 = 3.2kHz)
- BEAT Y -22dBm on the RF analyzer@69.0MHz / Phase tracker Qout = 400 => Phase tracking loop gain 300 (Theoretical UGF = 2.1kHz)

Transfer function between ALSX/Y and POX/Y11I @560Hz excitation of ETMX
POX11I/ALSX = 54.7dB (~0deg)
POY11I/ALSY = 64.5dB (~180deg)

POX11I calibration:

ALSX[cnt]*19230[Hz/cnt] = POX11I[cnt]/10^(54.7/20)*19230[Hz/cnt]
= 35.4 [Hz/cnt] POX11I [cnt] (Hz in green frequency)

35.4 [Hz/cnt]/(2.99792458e8/532e-9 [Hz]) * 37.8 [m] = 2.37e-12 [m/cnt] => 4.2e11 [cnt/m] (c.f. Ayaka's number in ELOG #7738 6.7e11 cnt/m)

POY11I calibration:

ALSY[cnt]*19230[Hz/cnt] = POY11I[cnt]/10^(64.5/20)*19230[Hz/cnt]
= 11.5 [Hz/cnt] POX11I [cnt] (Hz in green frequency)

11.5 [Hz/cnt]/(2.99792458e8/532e-9 [Hz]) * 37.8 [m] = 7.71e-13 [m/cnt] => 1.3e12 [cnt/m] (c.f. Ayaka's number in ELOG #7738 9.5e11 cnt/m)

  7334   Tue Sep 4 11:32:58 2012 JenneUpdateLockingFriday in-vac work

Elog re: Friday's work

Adjusted PZT2 so we're hitting the center of PR2. 

Noticed that the beam centering target is too low by a few mm, since the OSEM set screw holes that it mounts to are lower than the center line of the optic.  This meant that while we were hitting the center of PR2, the beam was half clipped by PRM's centering target.  We removed the target to confirm that the beam is really centered on PR2.

Checked the beam on PR3 - it looked fine.  There had been concern last week that PR2 was severely pitched forward, but this turns out to be an effect of the PRM centering target being too low - shoot the beam downward to go through the hole, beam continues downward to hit the bottom of PR2, so beam is falling of the bottom of PR3.  But when we actually centered the beam on PR2, things looked fine on PR3. 

Checked that the beam approximately goes through the beam splitter.  Again, the targets are too low, and these 45 deg targets' holes are smaller than the 0 deg targets, so we don't see any beam going through the target, since the beam is hitting the target higher than the hole.  The beam looked left/right like it was pretty close to the hole, but it was hard to tell since the angle is bad, and I'm not infinitely tall.  We should check again to make sure that the beam is going through properly, and we're not clipping anywhere.  I'll need help from a height-advantaged person for this.

Checked that the beam is hitting the center of the ITMY, as best we can see by using an IR card at the back of the optic.  We didn't try reaching around to put a target on the front side. 

We were debating whether it would be worth it to open ETMY this week, to check that the beam transmitted through the BS hits the center of ETMY.

We also took a quick look around the AS optics, but since that depends on BS/ITMX alignment, we weren't sure how to proceed.  We need a plan for this part.  All suspended optics were restored to their last good alignment, but we haven't tried locking MICH or anything to confirm that the alignment. 

To do list:  Check no clipping on ITMY table of beam between BS and ITMY, clipping on POY optics.  Also, oplev is clipping on cable holder thing on the table - this needs to be moved.  .....other?

  4884   Sat Jun 25 06:09:38 2011 kiwamuUpdateLSCFriday locking

I was able to measure the sensing matrix in the PRMI configuration.

The results will be posted later.

  1909   Sat Aug 15 05:08:55 2009 YoichiUpdateLockingFriday night locking
Summary: DD hand off fails for DRFPMI.

Tonight, I did a lot of house keeping work.

(1) I noticed that the reference cavity (RC) was locked to TEM10.
This was probably the reason why we had to increase the FSS common gain.
I re-locked the RC to TEM00. Now the common gain value is back to the original.

(2) The MC WFS did not engage. I found that c1dcuepics had the /cvs/cds mounting problem.
I rebooted it. Then MC WFS started working.

(3) After checking that the MC WFS QPDs are centered for direct reflection (the MZ half fringe method),
I locked the MC and tweaked the mirror alignment (mainly MC3) to offload the WFS feedback signals.
Now the MC locks to TEM00 robustly.

(4) Since the MC mirror alignment is touchy recently, I did not like the idea of mis-aligning MC2
when you do the LSC PD offset adjustment. So I modified the LSCoffset script so that it will close
the PSL shutter instead of mis-aligning MC2.

(5) I changed the PD11_Q criteria for success in the alignment scripts because PD11_Q is now lower
than before due to the lower laser power.

(6) Since today's bootfest, some epics values were not properly restored. Some of the PD gains were
unmatched between I and Q. I corrected these with the help of conlog.

(7) By checking the open loop TFs, I found that the short DOFs have significantly lower UGFs than before,
probably due to the lower laser power. I increased the gains of MICH, PRCL and SRCL by a factor of 2 for
the full configuration.
For the DRM configuration the changes I made were:

PRC -0.15 -> -0.3
SRC 0.2 -> 0.6
MICH 0.5 -> 0.5

(8) I locked the DRFPMI with arm offsets, then adjusted the demodulation phases of PD6,PD7,PD8 and PD9 (DD PDs)
to minimize the offsets in the error signal, while locked with the single demodulation signals.

Change log:
PD6_PHASE 201 -> 270
PD7_PHASE 120 -> 105
PD8_PHASE 131 -> 145
PD9_PHASE -45 -> -65


(9) I ran senseDRM to get the sensing Matrix for the short DOFs using DD signals in DRM configuration.

(10) Still the DD hand off fails for DRFPMI. It succeeds for DRM.
  61   Sun Nov 4 23:55:24 2007 ranaUpdateIOOFriday's In-Vac work
On Friday morning when closing up we noticed that we could not get the MC to flash any modes.
We tracked this down to a misalignment of MC3. Rob went in and noticed that the stops were
still touching. Even after backing those off the beam from MC3 was hitting the east edge of
the MC tube within 12" of MC3.

This implied a misalignment of MC of ~5 mrad which is quite
large. At the end our best guess is that either I didn't put the indicator blocks in the
right place or that the MC3 tower was not slid all the way back into place. Since there
is such a strong stickiness between the table and the base of the tower its easy to
imagine the tower was misplaced.

So we looked at the beam on MC2 and twisted the MC3 tower. This got the beam back onto the
MC2 cage and required ~1/3 if the MC3 bias range to get the beam onto the center. We used
a good technique of finding that accurately: put an IR card in front of MC2 and then look
in from the south viewport of the MC2 chamber to eyeball the spot relative to the OSEMs.

Hitting MC2 in the middle instantly got us multiple round trips of the beam so we decided
to close up. First thing Monday we will put on the MC1/MC3 access connector and then
pump down.


Its possible that the MC length has changed by ~1-2 mm. So we should remeasure the length
and see if we need to reset frequencies and rephase stuff.
  62   Mon Nov 5 07:29:35 2007 ranaUpdateIOOFriday's In-Vac work
Liyuan recently did some of his pencil beam scatterometer measurements measuring not the
BRDF but instead the total integrated power radiated from each surface point
of some of the spare small optics (e.g. MMT, MC1, etc.).

The results are here on the iLIGO Wiki.

So some of our loss might just be part of the coating.
  4203   Tue Jan 25 22:49:13 2011 KojiUpdateCDSFront End multiple crash

STATUS:

  • Rebooted c1lsc and c1sus. Restarted fb many times.
  • c1sus seems working.
  • All of the suspensions are damped / Xarm is locked by the green
  • Thermal control for the green is working
  • c1lsc is frozen
  • FB status: c1lsc 0x4000, c1scx/c1scy 0x2bad
  • dataviewer not working

1. DataViewer did not work for the LSC channels (liek TRX)

2. Rebooted LSC. There was no instruction for the reboot on Wiki. But somehow the rebooting automatically launched the processes.

3. However, rebooting LSC stopped C1SUS processes working

4. Rebooted C1SUS. Despite the rebooting description on wiki, none of the FE processes coming up.

5. Probably, I was not enough patient to wait for the completion of dorphine_wait? Rebooted C1SUS again.

6. Yes. That was true. This time I wait for everything going up automatically. Now all of c1pemfe,c1rfmfe,c1mcsfe,c1susfe,c1x02fe are running.
FB status for c1sus processes all green.

7. burtrestored c1pemfe,c1rfmfe,c1mcsfe,c1susfe,c1x02fe with the snapshot on Jan 25 12:07, 2010.

8. All of the OSEM filters are off, and the servo switches are incorrectly on. Pushing many buttons to restore the suspensions.

9. I asked Suresh to restore half of the suspensions.

10. The suspensions were restored and damped. However, c1lsc is still freezed.

11. Rebooting c1lsc freezed the frontends on c1sus. We redid the process No. 5 to No.10

12. c1x04 seems working. c1lsc, however, is still frozen. We decided to leave C1LSC in this state.

 

  4206   Wed Jan 26 10:58:48 2011 josephbUpdateCDSFront End multiple crash

Looking at dmesg on c1lsc, it looks like the model is starting, but then eventually times out due to a long ADC wait. 

[  114.778001] c1lsc: cycle 45 time 23368; adcWait 14; write1 0; write2 0; longest write2 0
[  114.779001] c1lsc: ADC TIMEOUT 0 1717 53 181

I'm not sure what caused the time out, although there about 20 messages indicating a failed time stamp read from c1sus (its sending TRX information to c1lsc via the dolphin connection) before the time out.

Not seeing any other obvious error messages, I killed the dead c1lsc model by typing:

sudo rmmod c1lscfe

I then tried starting just the front end model again by going to the /opt/rtcds/caltech/c1/target/c1lsc/bin/ directory and typing:

sudo insmod c1lscfe.ko

This started up just the FE again (I didn't use the restart script because the EPICs processes were running fine since we had non-white channels).  At the moment, c1lsc is now running and I see green lights and 0x0 for FB0 status  on the C1LSC_GDS_TP screen.

At this point I'm not sure what caused the timeout.  I'll be adding some more trouble shooting steps to the wiki though.  Also, c1scx, c1scy are probably in need of restart to get them properly sync'd to the framebuilder.

I did a quick test on dataviewer and can see LSC channels such as C1:LSC-TRX_IN1, as well other channels on C1SUS such as BS sensors channels.

Quote:

STATUS:

  • Rebooted c1lsc and c1sus. Restarted fb many times.
  • c1sus seems working.
  • All of the suspensions are damped / Xarm is locked by the green
  • Thermal control for the green is working
  • c1lsc is frozen
  • FB status: c1lsc 0x4000, c1scx/c1scy 0x2bad
  • dataviewer not working 

 

  4207   Wed Jan 26 12:03:45 2011 KojiUpdateCDSFront End multiple crash

This is definitely a nice magic to know as the rebooting causes too much hustles.

Also, you and I should spend an hour in the afternoon to add the suspension swtches to the burt requests.

Quote:

I killed the dead c1lsc model by typing:

sudo rmmod c1lscfe

I then tried starting just the front end model again by going to the /opt/rtcds/caltech/c1/target/c1lsc/bin/ directory and typing:

sudo insmod c1lscfe.ko

This started up just the FE again

 

  3837   Mon Nov 1 15:35:41 2010 josephbUpdateCDSFront end USR and CPU times now recorded by DAQ

Problem:

We have no record of how long the CPUs are taking to perform a cycle's worth of computation

Solution:

I added the following channels to the various slow DAQ configuration files in /opt/rtcds/caltech/c1/chans/daq/

IOO_SLOW.ini:[C1:FEC-34_USR_TIME]
IOO_SLOW.ini:[C1:FEC-34_CPU_METER]
IOP_SLOW.ini:[C1:FEC-20_USR_TIME]
IOP_SLOW.ini:[C1:FEC-20_CPU_METER]
IOP_SLOW.ini:[C1:FEC-33_USR_TIME]
IOP_SLOW.ini:[C1:FEC-33_CPU_METER]
MCS_SLOW.ini:[C1:FEC-36_USR_TIME]
MCS_SLOW.ini:[C1:FEC-36_CPU_METER]
RMS_SLOW.ini:[C1:FEC-37_USR_TIME]
RMS_SLOW.ini:[C1:FEC-37_CPU_METER]
SUS_SLOW.ini:[C1:FEC-21_USR_TIME]
SUS_SLOW.ini:[C1:FEC-21_CPU_METER]

 

Notes:

To restart the daqd code, simply kill the running process.  It should restart automatically.  If it appears not to have started, check the /opt/rtcds/caltech/c1/target/fb/restart.log file and the /opt/rtcds/caltech/c1/target/fb/logs/daqd.log.xxxx files.  If you made a mistake in the DAQ channels and its complaining, fix the error and then restart init on the fb machine by running "sudo /sbin/init q"

ELOG V3.1.3-