ID |
Date |
Author |
Type |
Category |
Subject |
1043
|
Fri Sep 10 16:32:32 2010 |
Dmass | Electronics | stuff happens | Who cares! |
Quote: |
1:40-2:30 HEPA off, AC coupled temperature being written.
2:30 -> HEPA low.
|
4:31-4:47 PM Fri - Noise test on DAQ_GEN4
4:49 - Noise Test on DAQ_GEN3
5:30 or so HEPA on low
9 PM HEPA to off
11 PM HEPA to low
1AM HEPA off |
1042
|
Fri Sep 10 01:24:41 2010 |
Dmass | Electronics | stuff happens | SR560 needed |
One of the SR560's I was using to AC couple my nice new temperature sensors is...broken? It's output goes from tiny to railed with a 50 Ohm on the input when switching to a gain of 50. It takes a while to come down off the rail after reseting it. I don't trust its output.
I nicked what looked like a spare SR560 from the TCS lab. Settings when I turned it on were DC coupled, 3 Hz low pass single pole, gain = 20. |
1041
|
Fri Sep 10 01:03:21 2010 |
Dmass | Electronics | stuff happens | Who cares! |
1:40-2:30 HEPA off, AC coupled temperature being written.
2:30 -> HEPA low.
|
1040
|
Thu Sep 9 23:36:53 2010 |
Zach | Misc | GYRO | gyro noise budget updated in SVN |
I have updated 'noisebud.m' in the gyro SVN to include the MZ noise measured on the gyro table. It has been plugged into the FSR modulation section, where we used to have the noise from the 40m MZ. I have also suppressed the plotting of the following traces:
- Mechanical noise modulating the earth rotation signal --- this will always be weaker than the FSR modulation, unless we switch to a cavity with an FSR of ~30Hz.
- Old Marconi noise trace --- this has since been replaced by a newer, correct measurement, though the old trace was never removed.
- Old Isomet noise trace --- this has not been revisited, but I assume it is also wrong, as it was calculated in the same way as (2).
I have not removed any of the calculations for the above, but only the plotting instructions. We should decide if they need to be kept in any form or discarded for good.
I am working on a detailed analysis of how cavity mirror displacement noise couples into the gyro signal, as I suspect more than just the one pathway. Once we have all agreed on how it works, I will update the GyroDoc itself.
NOTE: The gyro MZ noise spectrum is DC - 10kHz @ 0.01 Hz BW = 1 million pts. This results in a big (33 MB) file which slows the running of noisebud. I'm sure there is an easy way to smooth this down but I don't know it off the top of my head and I fear for my life if I do not update the NB tonight. |
1039
|
Thu Sep 9 22:38:06 2010 |
Zach | Electronics | stuff happens | Router Crashed again? |
I noticed yesterday that although mDV was working again (I could get data by supplying the channel names manually into get_data), ligoDV could not obtain channel lists for C2 as it could before. Not sure if this is related.
Quote: |
looks like you have to work in the lab instead of sitting on the couch
It's working if you try to get data from there... Or try to tunnel port 8088 through ssh, that should work too. That's the way i usually forward any services which are not accessible from outside.
Time to replace the router....
Quote: |
Quote: |
Router crashed? Can't get channel list.
- Had Tara restart router, still can't get channel list. Was fine this afternoon.
|
nds and daqd both seem to be running on fb0.
|
|
|
1038
|
Thu Sep 9 21:57:37 2010 |
Frank | Electronics | stuff happens | Router Crashed again? |
looks like you have to work in the lab instead of sitting on the couch
It's working if you try to get data from there... Or try to tunnel port 8088 through ssh, that should work too. That's the way i usually forward any services which are not accessible from outside.
Time to replace the router....
Quote: |
Quote: |
Router crashed? Can't get channel list.
- Had Tara restart router, still can't get channel list. Was fine this afternoon.
|
nds and daqd both seem to be running on fb0.
|
|
1037
|
Thu Sep 9 21:56:29 2010 |
Dmass | Electronics | stuff happens | Can't get data from 40m network? |
Get_data worked without hitch when I used a vpn caltech connection. I think I am on the 40m ligo network (131.215...). I toggled on and off a couple times to check, and it only worked with the VPN on. |
1036
|
Thu Sep 9 21:45:26 2010 |
Dmass | Electronics | stuff happens | Router Crashed again? |
Quote: |
Router crashed? Can't get channel list.
- Had Tara restart router, still can't get channel list. Was fine this afternoon.
|
nds and daqd both seem to be running on fb0. |
1035
|
Thu Sep 9 21:12:50 2010 |
Dmass | Electronics | stuff happens | Router Crashed again? |
Router crashed? Can't get channel list.
- Had Tara restart router, still can't get channel list. Was fine this afternoon. |
1034
|
Thu Sep 9 20:28:12 2010 |
Koji | Laser | GYRO | PDH box SWEEP -> OUT TF |
Yes, that's another technique.
Make certain the coherence of the measurement is ok. As the signal before the filter is suppressed by the huge loop gain. the SNR easily gets bad.
Quote: |
Thank you for the tips, Koji. Frank also mentioned to me today that it would be easier to do the measurement with the loop closed (i.e. measure output / input while driving somewhere else in the loop). I'm not sure how we will be able to do this for the SWEEP -> OUT measurement, though, and we still need to understand why turning the boost on while locked kicks us out of lock.
|
|
1033
|
Thu Sep 9 18:31:48 2010 |
Dmass | Electronics | stuff happens | Who cares! |
I switched both HEPAs on to "low" and relocked the PMC at 6:40 PM today.
8:07 PM - both HEPAs turned to "med"
NTC Thermistor SR560 Gain set to 10 (was overloading @ 20).
NTC Thermistor mode set to "A-B" on one of the 560s with nothing hooked into B. Unknown if this makes it fluctuate or not. Channel is "daq1-gen4" |
1032
|
Thu Sep 9 17:10:39 2010 |
Zach | Laser | GYRO | PDH box SWEEP -> OUT TF |
Thank you for the tips, Koji. Frank also mentioned to me today that it would be easier to do the measurement with the loop closed (i.e. measure output / input while driving somewhere else in the loop). I'm not sure how we will be able to do this for the SWEEP -> OUT measurement, though, and we still need to understand why turning the boost on while locked kicks us out of lock.
Quote: |
That's the natural desire, but it is often not straightforward.
It depends on the feature of your LF boost, but in general a LF boost yields a huge gain at DC. Every circuits has some small mount of DC offset and it is amplified by the boost.
e.g. Suppose 1mV input-equivalent offset with DC gain of 10^4. This causes the output of 10V.
What you may be able to do is put an offset to the FFT analyzer output such that the output offset of the box is nulled. If you are lucky, this would let you measure the boost TF.
---------
Even if you have some offset in the servo filter, usually it is not the matter as the servo try to squeeze the offset by the feedback.
Usually small input-equivalent offset of the servo filter turned into huge offset at the output of the filter module, if the loop is not closed.
Once the loop is closed, the feedback signal is adjusted such that the error signal cancels this offset.
Of course, the actual situation depends on how much offset you do actually have. So the above mentions are just general comments.
Quote: |
Trying to take a TF with the BOOST on (to emulate the state of the system while running the gyro) proved fruitless, as this causes the output to rail regardless of how low you make the source or whether you go in at SWEEP or INPUT. This is problematic because we would like to do the closed-loop measurements on the actual (BOOST on) running state of the gyro. It is possible that engaging the boost produces an unwanted offset, and this would explain why doing so with the cavity locked sometimes causes it to drop. I will take a look at the schematic to see if something is obviously wrong with the circuit.
|
|
|
1031
|
Thu Sep 9 14:49:01 2010 |
Koji | Laser | GYRO | PDH box SWEEP -> OUT TF |
That's the natural desire, but it is often not straightforward.
It depends on the feature of your LF boost, but in general a LF boost yields a huge gain at DC. Every circuits has some small mount of DC offset and it is amplified by the boost.
e.g. Suppose 1mV input-equivalent offset with DC gain of 10^4. This causes the output of 10V.
What you may be able to do is put an offset to the FFT analyzer output such that the output offset of the box is nulled. If you are lucky, this would let you measure the boost TF.
---------
Even if you have some offset in the servo filter, usually it is not the matter as the servo try to squeeze the offset by the feedback.
Usually small input-equivalent offset of the servo filter turned into huge offset at the output of the filter module, if the loop is not closed.
Once the loop is closed, the feedback signal is adjusted such that the error signal cancels this offset.
Of course, the actual situation depends on how much offset you do actually have. So the above mentions are just general comments.
Quote: |
Trying to take a TF with the BOOST on (to emulate the state of the system while running the gyro) proved fruitless, as this causes the output to rail regardless of how low you make the source or whether you go in at SWEEP or INPUT. This is problematic because we would like to do the closed-loop measurements on the actual (BOOST on) running state of the gyro. It is possible that engaging the boost produces an unwanted offset, and this would explain why doing so with the cavity locked sometimes causes it to drop. I will take a look at the schematic to see if something is obviously wrong with the circuit.
|
|
1030
|
Thu Sep 9 13:12:24 2010 |
Alastair | Computing | General | paths and aliases |
Some of our standard stuff from bash wasn't working in tcsh shell, so I've added some extra paths and aliases. The tcsh path file (.cshrc) now has the following added
setenv PATH ${PATH}:/opt/apps/Linux/medm/bin
setenv PATH ${PATH}:/opt/apps/Linux/dataviewer
setenv PATH ${PATH}:/opt/apps/Linux/grace/bin
setenv PATH ${PATH}:/opt/apps/Linux/tds
setenv PATH ${PATH}:/opt/apps/Linux/gds/binsetenv PATH ${PATH}:/opt/apps/Linux/ZooZ-1.2
setenv PATH ${PATH}:/caltech/scripts
I also added the following aliases
alias dv 'dataviewer'
alias sitemap 'medm -x /cvs/cds/caltech/medm/c2/atf/C2ATF_MASTER.adl &'
The following now work which previously did not work in tcsh
medm
dataviewer
dv (an alias to open dataviewer)
sitemap (opens medm with the top level medm file)
For some reason 'diaggui', 'foton' and 'mainmenu' still won't work. You just get 'Abort'. If you cd into the correct folder for them and run them using ./diaggui, ./foton or ./mainmenu then you get the same thing. Using bash if I cd into the directory and run them in this way they work. Does tcsh need to know of some other paths to get these to work?
|
1029
|
Thu Sep 9 12:23:50 2010 |
Zach | Laser | GYRO | PDH box SWEEP -> OUT TF |
Below is the transfer function of the PDH box from the SWEEP input to the output. This input will be used for the closed-loop measurements of the gyro loops, so we need to know this information. It appears that the TF is flat at 0 dB up to around 10 kHz, where there is some strange behavior. It also appears to be independent of the gain setting, which is a nice feature. The two seemingly arbitrary gain settings chosen to test this are 1) 0.5: the setting at which we took the IN -> OUT TFs, and 2) 7.0: the typical running setting for the gyro.

Trying to take a TF with the BOOST on (to emulate the state of the system while running the gyro) proved fruitless, as this causes the output to rail regardless of how low you make the source or whether you go in at SWEEP or INPUT. This is problematic because we would like to do the closed-loop measurements on the actual (BOOST on) running state of the gyro. It is possible that engaging the boost produces an unwanted offset, and this would explain why doing so with the cavity locked sometimes causes it to drop. I will take a look at the schematic to see if something is obviously wrong with the circuit.
|
1028
|
Thu Sep 9 05:17:19 2010 |
Dmass | Electronics | stuff happens | Who cares! |
I switched to using one newport to control both ovens (one has no sensor, is just getting the actuation signal from teh other).
I was able to get the Mach Zehnder back and running.
Leaving it running overnight with with its calibration line on and HEPA off...I also have AC coupled thermistors on each oven being recorded by the DAQ now, so this should tell me exactly how "not ok" it is to use one controller for two ovens, which comes down to how correlated the low frequency temperature changes are inside the box.
Next up - HEPA on / off test, and comparison of 1 controller phase noise spectrum with 2 controller phase noise spectrum. |
1027
|
Thu Sep 9 00:22:14 2010 |
Dmass | Electronics | stuff happens | Newport 3040 fukt? |
I spent the better half of the day trying to debug the 3040 - I returned to an old working hardware setup with some extra 100 Ohm platinum RTDs, but I couldn't get one of the 3040's to read it in the right way. Resistance is "err", and nothing I seem to do or plug in seems to change it.
- I checked the cabling to the 3040 - it was fine (no open connections, or mysterious shorts)
- I checked the software limits and tried to make them as large as possible
- I checked the sensor type and its coefficients
- I switched the RTDs between 3040's, the failure followed the 3040
- I did the onboard calibration for the RTD with a 100 Ohm thin film, as per the manuals instructions
- I calibrated out the RTDs leads with a short, as per the manuals instructions.
- I restored the machine to an earlier state (presumably from when it was still @ MIT), and repeated the above - still nothing.
Back story which may or may not be pertinent (guesses at possible damage here).
- I snapped off the lead from my 100 Ohm RTD on my oven a few days ago.
- I tried to use a 1000 kOhm RTD which I already had affixed to the oven as a spare, but the 3040 doesn't seem to know about these -
- I had a 1 kOhm RTD in with the coefficients from a 100 Ohm for a bit (as it wouldn't let me switch them)
- It seems unlikely that the having wrong sensor type could damage your 3040, as you have to cycle through types with the ipod-esque wheel to select the right one.
I then tried to use an NTC thermistor as the sensor, since I had some already wired up.
- The manual quoted +/- ranges for the Steinhart-Hart coefficients for thermistors, which seems to imply that NTC and PTC are O.K to use
- I pulled the NTC Steinhart-Hart coefficients from a quick matlab fit
- When I tried to use them,the 3040 told me they were illegal and forced the coefficients back to their default positive values
I abandoned this and soldered some connectors on some spare 100 Ohm RTDs, of the exact same type which is working on the other 3040. I then experienced the problems from the first list...
I hope there is something stupid that I am somehow missing, otherwise I either have to skip the last couple measurements for the paper, or wait wait wait for a replacement / refurb / homestyle debugging of the 3040 - I will try to recruit a fresh set of eyes tomorrow to look at this.
|
1026
|
Wed Sep 8 18:13:26 2010 |
Alastair & Zach | Laser | GYRO | Windows are in |
Alignment is done and the gyro is taking data now. We will post a new spectrum after a short while.
Quote: |
We installed the four CVI W2 windows on the box this afternoon. We decided that to do the best job we would remove each side of the box so that the lens mounts could be put in place on a flat surface.
The sealant that we used was RTV108 which had very little smell as we were applying it. As you can see from picture 2, it went on pretty smoothly and I'm confident that all windows are sealed nicely. After leaving it to set for ~30mins the windows were installed and the box put back together round the cavity mirrors.
Unfortunately our best efforts at not moving anything have still resulted in the cavity becoming mis-aligned. It is probably as a result of un-dog-clamping the box from the table and then re-clamping it again. Working on realignment right now.
|
|
1025
|
Wed Sep 8 17:51:15 2010 |
Alastair & Zach | Laser | GYRO | Windows are in |
We installed the four CVI W2 windows on the box this afternoon. We decided that to do the best job we would remove each side of the box so that the lens mounts could be put in place on a flat surface.
The sealant that we used was RTV108 which had very little smell as we were applying it. As you can see from picture 2, it went on pretty smoothly and I'm confident that all windows are sealed nicely. After leaving it to set for ~30mins the windows were installed and the box put back together round the cavity mirrors.
Unfortunately our best efforts at not moving anything have still resulted in the cavity becoming mis-aligned. It is probably as a result of un-dog-clamping the box from the table and then re-clamping it again. Working on realignment right now. |
Attachment 1: photo_3.jpg
|
|
Attachment 2: photo_4.jpg
|
|
Attachment 3: photo_2.JPG
|
|
Attachment 4: photo_5.JPG
|
|
1024
|
Wed Sep 8 02:00:36 2010 |
Dmass | Laser | Doubling | Oven Snafu Update |
I had a minor accident with the ovens a couple days ago - the lead of the 100 Ohm platinum RTD broke off at the RTD. I was using this for the loop.
I have a 1 kOhm platinum RTD affixed to the oven, but apparently the newport 3040 doesn't "know about" 1 kOhm RTDs, and forbids setting that as its resistance internally. I am opting to grab another 100 Ohm RTD from my pile at home and tape it on top tomorrow.
I feel the need to say this internal limitation from the 3040 is this months "most ridiculous thing I have encountered from anything which costs more than 2$," as it is totally unneccesary. |
1023
|
Tue Sep 7 23:43:46 2010 |
Dmass | Laser | Doubling | MZ Freq Noise Spectrum / Noise Budget |
Adding in temperature to the noise budget.
From this entry (this sinc^2 phase matching curve), I get a temperature calibration of
- ~(43 - 37.5 C)=pi radians
- 5.5 Kelvin / radian or 0.18 rad / K
From this entry we see the level of temperature noise expected.
Sadly, I only trust this curve for one of my temperature controllers, because the resistors (for temperature sensing) are at very different places on the oven, and (probably related) the loop gains which make it not oscillate seemed to be at different settings.
The lowest upper bound which I can get from my data is made of the following:
- The 300 Fast temperature curve (which reflects the settings on one of my temperature controllers - presumably the one which was used in the measurement)
- The calibration above
- A single pole at 0.1 Hz (details on its estimation below)
Pole Freq Estimation:
- From looking at the step response of the oven to a current, I found a pole at 1/60 Hz.
- This is the response from the bottom of the oven to the top (where the temp. sensor is)
- I assume the pole frequency scales as 1 / thermal mass (Volume)
- The bottom piece of the oven (between the TEC and the PPKTP) is 3-5x as thick as the top (between the PPKTP and the resistor)
- This implies the transfer function between the temp sensor and the PPKTP is a pole @ ~1/60*(4 or 6) which is 1/15 to 1/10 Hz
Note that at 0.1 Hz, my temperature noise is ~4 mK/rtHz ~ 0.5 mrad/rtHz (sqrt(2) added to the obvious calibration). The temperature noise of the other oven could easily differ by a factor of 2-3 and account for this, or the excess noise could still be some air current left over after the HEPA is off.
|
1022
|
Tue Sep 7 13:28:16 2010 |
Dmass | Laser | Doubling | MZ Freq Noise Spectrum / Noise Budget |
Added in dark and shot noise, as well as lower band RMS's |
Attachment 1: MZFreqNoiseBud.pdf
|
|
1021
|
Mon Sep 6 16:37:05 2010 |
Zach | Laser | GYRO | New gyro noise spectrum |
Now that stuff is working again, I took a spectrum of the gyro in the newest configuration (the one detailed here).
The calibration is: 6.103 x 10-4 V/ct * 375 kHz/V * (lambda * S)/(4*A) [rad/s / Hz] = 3.09 x 10-4 rad/s /ct

It is roughly a factor of 10 better than before at and below 10 Hz, though this comes with the grain of salt that the calibration was off by a factor of 2*pi before, and that there exists some ambiguity over whether or not the measurement can be trusted due to our incomplete understanding of the loop. The noise above 10 Hz is pretty much the same.
It appears that someone was futzing with the gyro over the week, as the BOOSTs on both boxes were turned OFF and the CW camera was off center. Please document your futzings. |
1020
|
Mon Sep 6 16:23:19 2010 |
Dmass | Computing | DAQ | SSHD (re?)started |
FB1 was sitting at login so it seems like it hasn't been opened up since its last restart. SSHD was not running (ps -elf |grep sshd returned nothing).
From /etc/init.d I ran:
sudo ./sshd start
sshing now works again, though we are still trying not to do it as per Rana's earlier post.
I also clicked the "DAQ RELOAD" button in the GDS TP medm screen, and the FB0 config light went from red to green. |
1019
|
Sat Sep 4 03:34:42 2010 |
Dmass | Computing | DAQ | Undocumented change? |
I don't know if this was automatically restarted, or some ninja did something, but I can get data now. It seems this should not be possible without SSHing into the ATF network and playing around with the medm buttons (or their corresponding commands).
If no one was touching it, I am confused, as controls@131.215.115.216 is still refusing SSH's |
1018
|
Sat Sep 4 02:21:46 2010 |
Frank | Computing | DAQ | Undocumented change? |
Quote: |
Quote: |
Quote: |
I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.
Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?
|
As of 12:40 am Sat morning, I can no longer get data from offsite (my channel list request fails). It was working this afternoon, and seems to have been working 40 minutes ago when I asked it for 2 hours of 256 Hz, but it may have choked on that.
|
As of 1:48 AM the error is:
C
Warning: Error number -1 while querying for C2:ATF-DAQ1_GEN2_OUT_DAQ
darkness =
name: 'C2:ATF-DAQ1_GEN2_OUT_DAQ'
data: []
rate: 256
start: 967625192
duration: 18
On a get data. Same for other channels.
The only thing I have done to the entire front end set up is add a DAQ channel, and killed the daqdaemon (on fb0).
|
i think you have to reload the daq too, otherwise the channel count and datarate of the daq (rt model running) is different from the one of the daqd expects to find. They use a shared memory to exchange data. If think you don't reload the daq the amount and order of data/channels exchanged is different from what the daqd expects to find in the shared memory (and maybe in which order). We should ask alex if this is true..
You can find that button in the upper left corner of the main medm screen for your subsystem. The last time we had this issue i reloaded the daq, reloaded all filters and coefficients (which both i think are not necessary) and then restarted the daqd by using sudo pkill daqd and everything worked fine. That's how did this all the time with the psl subsystem and i never had problems with getting data from that... |
1017
|
Sat Sep 4 01:49:23 2010 |
Dmass | Computing | DAQ | Undocumented change? |
Quote: |
Quote: |
I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.
Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?
|
As of 12:40 am Sat morning, I can no longer get data from offsite (my channel list request fails). It was working this afternoon, and seems to have been working 40 minutes ago when I asked it for 2 hours of 256 Hz, but it may have choked on that.
|
As of 1:48 AM the error is:
C
Warning: Error number -1 while querying for C2:ATF-DAQ1_GEN2_OUT_DAQ
darkness =
name: 'C2:ATF-DAQ1_GEN2_OUT_DAQ'
data: []
rate: 256
start: 967625192
duration: 18
On a get data. Same for other channels.
The only thing I have done to the entire front end set up is add a DAQ channel, and killed the daqdaemon (on fb0). |
1016
|
Sat Sep 4 00:44:20 2010 |
Dmass | Computing | DAQ | Undocumented change? |
Quote: |
I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.
Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change?
|
As of 12:40 am Sat morning, I can no longer get data from offsite (my channel list request fails). It was working this afternoon, and seems to have been working 40 minutes ago when I asked it for 2 hours of 256 Hz, but it may have choked on that. |
1015
|
Fri Sep 3 14:45:20 2010 |
Dmass | Computing | DAQ | Undocumented change? |
I could not ssh into fb1 from ws2 to run apps (DTT). I checked from the outside world, and same thing. 131. 215.115.216 no longer says hello.
Did someone reconfigure something to disable ssh'ing, or is this a spontaneous change? |
1014
|
Fri Sep 3 10:21:29 2010 |
Koji | Electronics | Doubling | Calibration Line |
Those plots are so beautifull...I was so much impressed
Quote: |
Here is the calibrated spectra generated from about 2 hours of data last night. I included a coherent subtraction of the IR from the green (the black curve). Table resonances nicely decimated.
I have put a script which auto calibrates and generates spectra in the svn under /mDV/extra/C2/dmass/MZSpecGenerator.m
Edit - Added shot noise, and put a plot in terms of frequency noise (Note that the y axis is mislabeled, and should read Hz/rtHz).
NOTE THE RELATIVE FREQUENCY STABILITY. When I look at it like this, chasing the "excess phase noise" leftover from locking the MZ at low frequency seems a lot less important.
|
|
1013
|
Thu Sep 2 19:10:04 2010 |
Dmass | Electronics | Doubling | Calibration Line |
Here is the calibrated spectra generated from about 2 hours of data last night. I included a coherent subtraction of the IR from the green (the black curve). Table resonances nicely decimated.
I have put a script which auto calibrates and generates spectra in the svn under /mDV/extra/C2/dmass/MZSpecGenerator.m
Edit - Added shot noise, and put a plot in terms of frequency noise (Note that the y axis is mislabeled, and should read Hz/rtHz).
NOTE THE RELATIVE FREQUENCY STABILITY. When I look at it like this, chasing the "excess phase noise" leftover from locking the MZ at low frequency seems a lot less important. |
Attachment 1: MZNoiseBud.pdf
|
|
Attachment 2: MZFreqSubRMS.pdf
|
|
1012
|
Wed Sep 1 20:31:26 2010 |
Dmass | Electronics | Doubling | Calibration Line |
I added a calibration line to the MZ PZT - I used the "Dither in" input on the HV PZT Drive Box (D060283)
I am using a function generator (SRDS335) to put a 12Vpp 100 Hz sine wave into this input.
The input goes through a Sallen-Key high pass with a corner of 2.4kHz, so this is around 58 dB down by the time it gets added into the drive signal. I looked at the gain in RMS from this, and it was not dominant in the band of interest.
I took some spectra with a relatively precise (< 5%) calibration of:
2 V/rad for Green diff
4.5 V/rad for IR diff
With a 0.03 Hz BW measurement in DTT, these show up with about an SNR > 10 with peak heights of:
0.00261 for IR
0.00239 for Green
These were spectra taken in Volts/rtHz
|
Attachment 1: MZCalLinePZT.pdf
|
|
1011
|
Wed Sep 1 04:43:45 2010 |
Dmass | Computing | DAQ | some restarts on fb0: too many cooks |
For the record - one of the symptoms was that we couldn't get data through mdv. This was fixed by rebooting the router. The system as built is not very robust - I will need a couple days of stable quiet operation to get all the data I need to wrap up my paper. |
1010
|
Wed Sep 1 02:21:23 2010 |
rana | Computing | DAQ | some restarts on fb0: too many cooks |
Today Frank, me and Dmass all started making changes at the same time and broke everything. Please stop booting and fiddling at random. This means you Frank!
I set the time on fb0 to the correct time by using the command 'date -s'. It still has the issue that the ntp.conf is set to point at the wrong place. We need a NAT router and a gateway...
I also restarted the daqd process by the usual way of killing the running process. Same for nds. I changed the syntax in the start_nds.inittab to have the same error and logging
redirection as what we have at the 40m. This required knowledge of obscure Bourne shell stdout and stderr redirection sadly.
After restarting daqd, we could get data again by running diaggui on fb1 from the /apps directory (not /opt/apps/).
To conduct an experiment in DAQ stability, please stop even ssh'ing in to the router or fb1 until further notice. We want to see if the system dies by itself while taking data even if we stop
doing our 'this won't effect anything' nonsense. |
1009
|
Wed Sep 1 00:33:56 2010 |
Dmass | Computing | DAQ | mDV NDS DTT DV etc |
I looked on fb1, and noticed that:
[controls@fb1 fb1]$ ps -elf |grep nds
4 S root 3745 1 0 78 0 - 11481 wait Aug26 ? 00:00:00 su controls -c env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
4 S controls 3769 3745 0 78 0 - 17209 rt_sig Aug26 ? 00:00:00 tcsh -c env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
0 S controls 3846 3769 0 78 0 - 13161 - Aug26 ? 00:00:00 /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
0 S controls 22459 22333 0 77 0 - 15297 pipe_w 00:29 pts/5 00:00:00 grep nds
I saw a tcsh thing running, and tried to kill it (sudo kill -9 PID), to see if this might be part of the problem
[controls@fb1 fb1]$ ps -elf |grep nds
0 S controls 3846 1 0 78 0 - 13161 - Aug26 ? 00:00:00 /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
4 S root 22506 1 0 77 0 - 11481 wait 00:30 ? 00:00:00 su controls -c env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
4 S controls 22507 22506 0 78 0 - 13161 - 00:30 ? 00:00:00 /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe
0 S controls 22563 22333 0 78 0 - 15297 pipe_w 00:32 pts/5 00:00:00 grep nds
|
1008
|
Wed Sep 1 00:13:32 2010 |
Frank | Computing | DAQ | mDV NDS DTT DV etc |
daqd on fb0 seems to be broken. i can't get any data from the past, hours, days or weeks ago.
I always get:
Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found
even, when using slow epics channels.
But if i telnet into it and pull up the channel status everything is fine and lots of channels are written with the correct data rate.
So i don't know, fb1 is working fine. Getting a channel list from fb0 too.
The error message you get when starting the daqd on fb1 is not new, but Alex doesn't know what it means and it only happened a couple of times so far and everything is working.
ca "CA.Client.Exception" is our network problem in the PSL lab...
|
1007
|
Tue Aug 31 23:02:35 2010 |
Frank | Computing | DAQ | current channel list on fb1 - note to remove dead/unused channels |
241 channels total
0 gds channels
0 gds channels aliases
240 trend channels
1Hz clock
chnum slow |name |rate |trend |group |bps |bytes |offset |type |active
0 0 C2:PEM-SENS1_TEMP 16 1 0 4 64 0 4 1
0 0 C2:PEM-SENS1_HUMIDITY 16 1 0 4 64 64 4 1
0 0 C2:PEM-SENS1_PRESSURE 16 1 0 4 64 128 4 1
0 0 C2:PEM-SENS1_BATTERY 16 1 0 4 64 192 4 1
0 0 C2:PEM-SENS1_UPDATE 16 1 0 4 64 256 4 1
0 0 C2:PEM-SENS1_STRENGTH 16 1 0 4 64 320 4 1
0 0 C2:PEM-SENS1_SUCCESS 16 1 0 4 64 384 4 1
0 0 C2:PEM-SENS1_ACTIVE 16 1 0 4 64 448 4 1
0 0 C3:PEM-SENS1_TEMP 16 1 0 4 64 512 4 1
0 0 C3:PEM-SENS1_HUMIDITY 16 1 0 4 64 576 4 1
0 0 C3:PEM-SENS1_PRESSURE 16 1 0 4 64 640 4 1
0 0 C3:PEM-SENS1_BATTERY 16 1 0 4 64 704 4 1
0 0 C3:PEM-SENS1_UPDATE 16 1 0 4 64 768 4 1
0 0 C3:PEM-SENS1_STRENGTH 16 1 0 4 64 832 4 1
0 0 C3:PEM-SENS1_SUCCESS 16 1 0 4 64 896 4 1
0 0 C3:PEM-SENS1_ACTIVE 16 1 0 4 64 960 4 1
0 0 C4:PEM-SENS1_TEMP 16 1 0 4 64 1024 4 1
0 0 C4:PEM-SENS1_HUMIDITY 16 1 0 4 64 1088 4 1
0 0 C4:PEM-SENS1_PRESSURE 16 1 0 4 64 1152 4 1
0 0 C4:PEM-SENS1_BATTERY 16 1 0 4 64 1216 4 1
0 0 C4:PEM-SENS1_UPDATE 16 1 0 4 64 1280 4 1
0 0 C4:PEM-SENS1_STRENGTH 16 1 0 4 64 1344 4 1
0 0 C4:PEM-SENS1_SUCCESS 16 1 0 4 64 1408 4 1
0 0 C4:PEM-SENS1_ACTIVE 16 1 0 4 64 1472 4 1
0 0 C5:PEM-SENS1_TEMP 16 1 0 4 64 1536 4 1
0 0 C5:PEM-SENS1_HUMIDITY 16 1 0 4 64 1600 4 1
0 0 C5:PEM-SENS1_PRESSURE 16 1 0 4 64 1664 4 1
0 0 C5:PEM-SENS1_BATTERY 16 1 0 4 64 1728 4 1
0 0 C5:PEM-SENS1_UPDATE 16 1 0 4 64 1792 4 1
0 0 C5:PEM-SENS1_STRENGTH 16 1 0 4 64 1856 4 1
0 0 C5:PEM-SENS1_SUCCESS 16 1 0 4 64 1920 4 1
0 0 C5:PEM-SENS1_ACTIVE 16 1 0 4 64 1984 4 1
0 0 C6:PEM-SENS1_TEMP 16 1 0 4 64 2048 4 1
0 0 C6:PEM-SENS1_HUMIDITY 16 1 0 4 64 2112 4 1
0 0 C6:PEM-SENS1_PRESSURE 16 1 0 4 64 2176 4 1
0 0 C6:PEM-SENS1_BATTERY 16 1 0 4 64 2240 4 1
0 0 C6:PEM-SENS1_UPDATE 16 1 0 4 64 2304 4 1
0 0 C6:PEM-SENS1_STRENGTH 16 1 0 4 64 2368 4 1
0 0 C6:PEM-SENS1_SUCCESS 16 1 0 4 64 2432 4 1
0 0 C6:PEM-SENS1_ACTIVE 16 1 0 4 64 2496 4 1
0 0 C2:PSL-AMP_MANUALMODE 16 1 0 4 64 2560 4 1
0 0 C2:PSL-AMP_DBILOCK 16 1 0 4 64 2624 4 1
0 0 C2:PSL-AMP_DCUROK 16 1 0 4 64 2688 4 1
0 0 C2:PSL-AMP_ENABLETEC 16 1 0 4 64 2752 4 1
0 0 C2:PSL-AMP_ERR 16 1 0 4 64 2816 4 1
0 0 C2:PSL-AMP_OFF 16 1 0 4 64 2880 4 1
0 0 C2:PSL-AMP_RESET 16 1 0 4 64 2944 4 1
0 0 C2:PSL-AMP_DTEMPERR 16 1 0 4 64 3008 4 1
0 0 C2:PSL-AMP_ENABLEPWRDOG 16 1 0 4 64 3072 4 1
0 0 C2:PSL-AMP_SYSTEMOK 16 1 0 4 64 3136 4 1
0 0 C2:PSL-AMP_LOWPWR 16 1 0 4 64 3200 4 1
0 0 C2:PSL-AMP_CHILLERR 16 1 0 4 64 3264 4 1
0 0 C2:PSL-AMP_DVOLT1 16 1 0 4 64 3328 4 1
0 0 C2:PSL-AMP_DVOLT2 16 1 0 4 64 3392 4 1
0 0 C2:PSL-AMP_PWR1 16 1 0 4 64 3456 4 1
0 0 C2:PSL-AMP_PWR2 16 1 0 4 64 3520 4 1
0 0 C2:PSL-AMP_PWR3 16 1 0 4 64 3584 4 1
0 0 C2:PSL-AMP_D1TEMP 16 1 0 4 64 3648 4 1
0 0 C2:PSL-AMP_D2TEMP 16 1 0 4 64 3712 4 1
0 0 C2:PSL-AMP_D3TEMP 16 1 0 4 64 3776 4 1
0 0 C2:PSL-AMP_D4TEMP 16 1 0 4 64 3840 4 1
0 0 C2:PSL-AMP_D1PWR 16 1 0 4 64 3904 4 1
0 0 C2:PSL-AMP_D2PWR 16 1 0 4 64 3968 4 1
0 0 C2:PSL-AMP_D3PWR 16 1 0 4 64 4032 4 1
0 0 C2:PSL-AMP_D4PWR 16 1 0 4 64 4096 4 1
0 0 C2:PSL-AMP_DCUR1 16 1 0 4 64 4160 4 1
0 0 C2:PSL-AMP_DCUR2 16 1 0 4 64 4224 4 1
0 0 C2:PSL-AMP_XTALTEMP 16 1 0 4 64 4288 4 1
0 0 C2:PSL-AMP_SECS 16 1 0 4 64 4352 4 1
0 0 C2:PSL-AMP_MINS 16 1 0 4 64 4416 4 1
0 0 C2:PSL-AMP_HRS 16 1 0 4 64 4480 4 1
0 0 C2:PSL-AMP_DAYS 16 1 0 4 64 4544 4 1
0 0 C2:PSL-NPRO_D1PWR 16 1 0 4 64 4608 4 1
0 0 C2:PSL-NPRO_D2PWR 16 1 0 4 64 4672 4 1
0 0 C2:PSL-NPRO_D1TEMPSET 16 1 0 4 64 4736 4 1
0 0 C2:PSL-NPRO_D2TEMPSET 16 1 0 4 64 4800 4 1
0 0 C2:PSL-NPRO_D1TEMP 16 1 0 4 64 4864 4 1
0 0 C2:PSL-NPRO_D2TEMP 16 1 0 4 64 4928 4 1
0 0 C2:PSL-NPRO_D1TEMPERR 16 1 0 4 64 4992 4 1
0 0 C2:PSL-NPRO_D2TEMPERR 16 1 0 4 64 5056 4 1
0 0 C2:PSL-NPRO_TEMPGUARD1 16 1 0 4 64 5120 4 1
0 0 C2:PSL-NPRO_TEMPGUARD2 16 1 0 4 64 5184 4 1
0 0 C2:PSL-NPRO_XTALTEMPSET 16 1 0 4 64 5248 4 1
0 0 C2:PSL-NPRO_XTALTEMP 16 1 0 4 64 5312 4 1
0 0 C2:PSL-NPRO_XTALTEMPERR 16 1 0 4 64 5376 4 1
0 0 C2:PSL-NPRO_CURSET 16 1 0 4 64 5440 4 1
0 0 C2:PSL-NPRO_CUR 16 1 0 4 64 5504 4 1
0 0 C2:PSL-NPRO_NEMON 16 1 0 4 64 5568 4 1
0 0 C3:PSL-GEN_DAQ14 16 1 0 4 64 5632 4 1
0 0 C3:PSL-GEN_DAQ15 16 1 0 4 64 5696 4 1
0 0 C3:PSL-GEN_DAQ16 16 1 0 4 64 5760 4 1
0 0 C3:PSL-GEN_D2A3 16 1 0 4 64 5824 4 1
0 0 C3:PSL-GEN_D2A4 16 1 0 4 64 5888 4 1
0 0 C3:PSL-GEN_D2A5 16 1 0 4 64 5952 4 1
0 0 C3:PSL-GEN_D2A6 16 1 0 4 64 6016 4 1
0 0 C3:PSL-GEN_D2A7 16 1 0 4 64 6080 4 1
0 0 C3:PSL-GEN_D2A8 16 1 0 4 64 6144 4 1
0 0 C3:PSL-ACAV_SENS1 16 1 0 4 64 6208 4 1
0 0 C3:PSL-ACAV_SENS2 16 1 0 4 64 6272 4 1
0 0 C3:PSL-ACAV_SENS3 16 1 0 4 64 6336 4 1
0 0 C3:PSL-ACAV_SENS4 16 1 0 4 64 6400 4 1
0 0 C3:PSL-ACAV_OOL 16 1 0 4 64 6464 4 1
0 0 C3:PSL-ACAV_TEMP 16 1 0 4 64 6528 4 1
0 0 C3:PSL-ACAV_TEMPAVG 16 1 0 4 64 6592 4 1
0 0 C3:PSL-ACAV_HEATER 16 1 0 4 64 6656 4 1
0 0 C3:PSL-ACAV_SETPT 16 1 0 4 64 6720 4 1
0 0 C3:PSL-ACAV_KP 16 1 0 4 64 6784 4 1
0 0 C3:PSL-ACAV_KI 16 1 0 4 64 6848 4 1
0 0 C3:PSL-ACAV_KD 16 1 0 4 64 6912 4 1
0 0 C3:PSL-ACAV_ENABLE 16 1 0 4 64 6976 4 1
0 0 C3:PSL-ACAV_TIMEOUT 16 1 0 4 64 7040 4 1
0 0 C3:PSL-ACAV_SCALE 16 1 0 4 64 7104 4 1
0 0 C3:PSL-ACAV_RFPDDC 16 1 0 4 64 7168 4 1
0 0 C3:PSL-ACAV_RCTRANSPD 16 1 0 4 64 7232 4 1
0 0 C3:PSL-ACAV_LOCKEDLEVEL 16 1 0 4 64 7296 4 1
0 0 C3:PSL-RCAV_SENS1 16 1 0 4 64 7360 4 1
0 0 C3:PSL-RCAV_SENS2 16 1 0 4 64 7424 4 1
0 0 C3:PSL-RCAV_SENS3 16 1 0 4 64 7488 4 1
0 0 C3:PSL-RCAV_SENS4 16 1 0 4 64 7552 4 1
0 0 C3:PSL-RCAV_OOL 16 1 0 4 64 7616 4 1
0 0 C3:PSL-RCAV_TEMP 16 1 0 4 64 7680 4 1
0 0 C3:PSL-RCAV_TEMPAVG 16 1 0 4 64 7744 4 1
0 0 C3:PSL-FSS_HEATER 16 1 0 4 64 7808 4 1
0 0 C3:PSL-RCAV_SETPT 16 1 0 4 64 7872 4 1
0 0 C3:PSL-RCAV_KP 16 1 0 4 64 7936 4 1
0 0 C3:PSL-RCAV_KI 16 1 0 4 64 8000 4 1
0 0 C3:PSL-RCAV_KD 16 1 0 4 64 8064 4 1
0 0 C3:PSL-RCAV_ENABLE 16 1 0 4 64 8128 4 1
0 0 C3:PSL-RCAV_TIMEOUT 16 1 0 4 64 8192 4 1
0 0 C3:PSL-RCAV_SCALE 16 1 0 4 64 8256 4 1
0 0 C3:PSL-RCAV_RFPDDC 16 1 0 4 64 8320 4 1
0 0 C3:PSL-RCAV_RCTRANSPD 16 1 0 4 64 8384 4 1
0 0 C3:PSL-RCAV_LOCKEDLEVEL 16 1 0 4 64 8448 4 1
0 0 C3:PSL-FSS_RFPDDC 16 1 0 4 64 8512 4 1
0 0 C3:PSL-FSS_LODET 16 1 0 4 64 8576 4 1
0 0 C3:PSL-FSS_PCDET 16 1 0 4 64 8640 4 1
0 0 C3:PSL-FSS_FAST 16 1 0 4 64 8704 4 1
0 0 C3:PSL-FSS_PCDRIVE 16 1 0 4 64 8768 4 1
0 0 C3:PSL-FSS_RCTRANSPD 16 1 0 4 64 8832 4 1
0 0 C3:PSL-FSS_RCTLL 16 1 0 4 64 8896 4 1
0 0 C3:PSL-FSS_VCODET 16 1 0 4 64 8960 4 1
0 0 C3:PSL-FSS_TIDALOUT 16 1 0 4 64 9024 4 1
0 0 C3:PSL-FSS_MODET 16 1 0 4 64 9088 4 1
0 0 C3:PSL-FSS_VCODETPWR 16 1 0 4 64 9152 4 1
0 0 C3:PSL-FSS_MIXERM 16 1 0 4 64 9216 4 1
0 0 C3:PSL-FSS_SLOWM 16 1 0 4 64 9280 4 1
0 0 C3:PSL-FSS_VCOM 16 1 0 4 64 9344 4 1
0 0 C3:PSL-FSS_TIDALINPUT 16 1 0 4 64 9408 4 1
0 0 C3:PSL-FSS_SW1 16 1 0 4 64 9472 4 1
0 0 C3:PSL-FSS_SW2 16 1 0 4 64 9536 4 1
0 0 C3:PSL-FSS_PHFLIP 16 1 0 4 64 9600 4 1
0 0 C3:PSL-FSS_VCOTESTSW 16 1 0 4 64 9664 4 1
0 0 C3:PSL-FSS_VCOWIDESW 16 1 0 4 64 9728 4 1
0 0 C3:PSL-FSS_INOFFSET 16 1 0 4 64 9792 4 1
0 0 C3:PSL-FSS_MGAIN 16 1 0 4 64 9856 4 1
0 0 C3:PSL-FSS_FASTGAIN 16 1 0 4 64 9920 4 1
0 0 C3:PSL-FSS_PHCON 16 1 0 4 64 9984 4 1
0 0 C3:PSL-FSS_RFADJ 16 1 0 4 64 10048 4 1
0 0 C3:PSL-FSS_SLOWDC 16 1 0 4 64 10112 4 1
0 0 C3:PSL-FSS_VCOPWR 16 1 0 4 64 10176 4 1
0 0 C3:PSL-FSS_VCOMODLEVEL 16 1 0 4 64 10240 4 1
0 0 C3:PSL-FSS_TIDALSET 16 1 0 4 64 10304 4 1
0 0 C3:PSL-FSS_LOCK 16 1 0 4 64 10368 4 1
0 0 C3:PSL-FSS_SLOWLOOP 16 1 0 4 64 10432 4 1
0 0 C3:PSL-PMC_PMCTLL 16 1 0 4 64 10496 4 1
0 0 C3:PSL-PMC_RFPDDC 16 1 0 4 64 10560 4 1
0 0 C3:PSL-PMC_LODET 16 1 0 4 64 10624 4 1
0 0 C3:PSL-PMC_PMCTRANSPD 16 1 0 4 64 10688 4 1
0 0 C3:PSL-PMC_PCDRIVE 16 1 0 4 64 10752 4 1
0 0 C3:PSL-PMC_PZT 16 1 0 4 64 10816 4 1
0 0 C3:PSL-PMC_MODET 16 1 0 4 64 10880 4 1
0 0 C3:PSL-PMC_PMCERR 16 1 0 4 64 10944 4 1
0 0 C3:PSL-PMC_SW1 16 1 0 4 64 11008 4 1
0 0 C3:PSL-PMC_SW2 16 1 0 4 64 11072 4 1
0 0 C3:PSL-PMC_PHFLIP 16 1 0 4 64 11136 4 1
0 0 C3:PSL-PMC_BLANK 16 1 0 4 64 11200 4 1
0 0 C3:PSL-PMC_GAIN 16 1 0 4 64 11264 4 1
0 0 C3:PSL-PMC_INOFFSET 16 1 0 4 64 11328 4 1
0 0 C3:PSL-PMC_PHCON 16 1 0 4 64 11392 4 1
0 0 C3:PSL-PMC_RFADJ 16 1 0 4 64 11456 4 1
0 0 C3:PSL-PMC_RAMP 16 1 0 4 64 11520 4 1
0 0 C3:PSL-PMC_LOCK 16 1 0 4 64 11584 4 1
0 0 C3:PSL-PEM_RMTEMP 16 1 0 4 64 11648 4 1
0 0 C3:PSL-PEM_BOXTEMP 16 1 0 4 64 11712 4 1
0 0 C4:TCS-HWS_TEMP_SENSOR 16 1 0 4 64 11776 4 1
0 0 C4:TCS-HWS_TEMP_DIGITIZER 16 1 0 4 64 11840 4 1
0 0 C4:TCS-HWS_TAP1GAIN 16 1 0 4 64 11904 4 1
0 0 C4:TCS-HWS_TAP2GAIN 16 1 0 4 64 11968 4 1
0 0 C4:TCS-HWS_PRETRIGGER 16 1 0 4 64 12032 4 1
0 0 C4:TCS-HWS_DATA_MODE 16 1 0 4 64 12096 4 1
0 0 C4:TCS-HWS_BINNING_MODE 16 1 0 4 64 12160 4 1
0 0 C4:TCS-HWS_GAIN_MODE 16 1 0 4 64 12224 4 1
0 0 C4:TCS-HWS_OUTPUT_CONFIG 16 1 0 4 64 12288 4 1
0 0 C4:TCS-HWS_EXPOSURE_MODE 16 1 0 4 64 12352 4 1
0 0 C4:TCS-HWS_SYNC_FREQ 16 1 0 4 64 12416 4 1
0 0 C4:TCS-HWS_EXPOSURE_TIME 16 1 0 4 64 12480 4 1
0 0 C4:TCS-HWS_SERIAL_COMMS_STATUS 16 1 0 4 64 12544 4 1
0 0 C4:TCS-HWS_DEFOCUS 16 1 0 4 64 12608 4 1
0 0 C4:TCS-HWS_CENTROID_RMS 16 1 0 4 64 12672 4 1
0 0 C4:TCS-HWS_SINGLE_FRAME_BKGD 16 1 0 4 64 12736 4 1
0 0 C4:TCS-HWS_AVERAGE_INTENSITY 16 1 0 4 64 12800 4 1
0 0 C4:TCS-HWS_N_CENTROID_CALC 16 1 0 4 64 12864 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-1+1 16 1 0 4 64 12928 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_+1-1 16 1 0 4 64 12992 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-2+2 16 1 0 4 64 13056 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-0+2 16 1 0 4 64 13120 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_+2+2 16 1 0 4 64 13184 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-3+3 16 1 0 4 64 13248 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-1+3 16 1 0 4 64 13312 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_+1+3 16 1 0 4 64 13376 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_+3+3 16 1 0 4 64 13440 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-4+4 16 1 0 4 64 13504 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-2+4 16 1 0 4 64 13568 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_-0+4 16 1 0 4 64 13632 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_+2+4 16 1 0 4 64 13696 4 1
0 0 C4:TCS-HWS_ZERNIKE_P_+4+4 16 1 0 4 64 13760 4 1
0 0 C4:TCS-ATHENA_ADC0 16 1 0 4 64 13824 4 1
0 0 C4:TCS-ATHENA_ADC1 16 1 0 4 64 13888 4 1
0 0 C4:TCS-ATHENA_ADC2 16 1 0 4 64 13952 4 1
0 0 C4:TCS-ATHENA_ADC3 16 1 0 4 64 14016 4 1
0 0 C4:TCS-ATHENA_ADC4 16 1 0 4 64 14080 4 1
0 0 C4:TCS-ATHENA_ADC5 16 1 0 4 64 14144 4 1
0 0 C4:TCS-ATHENA_ADC6 16 1 0 4 64 14208 4 1
0 0 C4:TCS-ATHENA_ADC7 16 1 0 4 64 14272 4 1
0 0 C4:TCS-ATHENA_ADC8 16 1 0 4 64 14336 4 1
0 0 C4:TCS-ATHENA_ADC9 16 1 0 4 64 14400 4 1
0 0 C4:TCS-ATHENA_ADC10 16 1 0 4 64 14464 4 1
0 0 C4:TCS-ATHENA_ADC11 16 1 0 4 64 14528 4 1
0 0 C4:TCS-ATHENA_ADC12 16 1 0 4 64 14592 4 1
0 0 C4:TCS-ATHENA_ADC13 16 1 0 4 64 14656 4 1
0 0 C4:TCS-ATHENA_ADC14 16 1 0 4 64 14720 4 1
0 0 C4:TCS-ATHENA_ADC15 16 1 0 4 64 14784 4 1
0 0 C4:TCS-ATHENA_DAC0 16 1 0 4 64 14848 4 1
0 0 C4:TCS-ATHENA_DAC1 16 1 0 4 64 14912 4 1
0 0 C4:TCS-ATHENA_PD_VOLTAGE 16 1 0 4 64 14976 4 1
0 0 C4:TCS-ATHENA_TEMP_SENS_V 16 1 0 4 64 15040 4 1
0 0 C4:TCS-ATHENA_I_SET_VOLTS 16 1 0 4 64 15104 4 1
0 0 C4:TCS-ATHENA_I_ACTUAL_VOLTS 16 1 0 4 64 15168 4 1
0 0 C4:TCS-ATHENA_I_LIM_VOLTS 16 1 0 4 64 15232 4 1
0 0 C4:TCS-ATHENA_PD_EXTERNAL_V 16 1 0 4 64 15296 4 1
10001 0 C2:FB1-FB_DUMMY 16384 0 0 4 65536 15360 4 0 |
1006
|
Tue Aug 31 22:07:03 2010 |
Dmass | Computing | DAQ | mDV NDS DTT DV etc |
I can't get data. mDV and DV showed the same failed behavior. (They did nothing when you request data).
I looked in the daqd log files:
/cvs/cds/caltech/target/fb/daqd.log had:
[Tue Aug 31 22:01:37 2010] ->19: version
[Tue Aug 31 22:01:37 2010] ->19: revision
[Tue Aug 31 22:01:37 2010] no_average=1
Tue Aug 31 22:01:37 2010 [16601]:decimation flag=1
[Tue Aug 31 22:01:37 2010] ->19: start net-writer 967351844 20 {"C2:ATF-CTRL_ISS_1_OUT_DAQ" 256}
[Tue Aug 31 22:01:37 2010] UNIX connect(); errno=111
[Tue Aug 31 22:01:37 2010] connection closed on fd=20
The channel I requested is shown as being written in the C2ATF.ini file.
/cvs/cds/caltech/target/fb1/daqd.log had:
[Tue Aug 31 21:42:30 2010] ->8: revision
[Tue Aug 31 21:42:30 2010] ->8: status channels 3
[Tue Aug 31 21:42:30 2010] connection on fd 10 closed
[Tue Aug 31 21:42:31 2010] connection on port 38943 from 10.0.1.11; fd=17
[Tue Aug 31 21:42:32 2010] ->8: version
[Tue Aug 31 21:42:32 2010] ->8: revision
[Tue Aug 31 21:42:32 2010] ->8: gps
[Tue Aug 31 21:42:32 2010] connection on fd 17 closed
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.3:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:43:43.255113000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.2:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:44:20.907151000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.3:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:45:43.759006000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.2:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:47:12.898705000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.3:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:49:51.762671000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.2:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:53:36.383864000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.3:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:53:58.267296000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.2:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:55:14.367285000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit unresponsive"
Context: "10.0.0.2:5064"
Source File: ../tcpiiu.cpp line 921
Current Time: Tue Aug 31 2010 21:56:37.363180000
.................................................................
I then restarted the daq daemon on fb1 (sudo pkill daqd), and the logfile poopped this out:
A call to "assert (pE == &entry)" failed in ../../cds/project/daq/fb2/exServer.h line 346.
EPICS Release EPICS R3.14.10- $R3-14-10-RC2$ $2008/10/10 15:01:51$.
Current time Tue Aug 31 2010 22:02:42.341179000.
Please E-mail this message to the author or to tech-talk@aps.anl.gov
Calling epicsThreadSuspendSelf()
[Tue Aug 31 22:02:43 2010] Minute trender made GPS time correction; gps=967352577; gps%60=57\
Dataviewers error was:
Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found
read(); errno=9
read(); errno=9
T0=10-09-01-05-13-55; Length=10 (s)
No data output.
|
1005
|
Tue Aug 31 21:46:21 2010 |
Dmass | Computing | DAQ | changed default shell on fb1 back to bash |
Is there a reason for this (on ssh into fb from ws2):
RSA host key for fb has changed and you have requested strict checking.
Host key verification failed.
|
1004
|
Tue Aug 31 21:06:02 2010 |
Dmass | Computing | DAQ | FB1 SOFTWARE FREEZE |
I am running some stuff on FB1 (awg for a Cal line mainly) on which my data depends. Please restart/reboot/rebuild nothing on fb1 or fb(0). WS1 and 2 are meat as soon as I get everything set. |
1003
|
Tue Aug 31 13:12:14 2010 |
Frank | Computing | DAQ | changed default shell on fb1 back to bash |
changed default shell on fb1 back to bash temporarily, until the problems with tcsh are solved. The change to tcsh also causes that no sftp-service is running on fb1 and one can't use putty/winscp or other sftp tools for file transfer from/to fb1. changing back to bash fixes all the problems, including that all tools are working now.
Once we fixed those problems we can change to tcsh permanently
Quote: |
or switch back to bash shell in the meantime. That's working too. Simply open a shell, type in bash and then run them from the command line.
All computers have problems finding stuff since rana changed the shell.. This includes fb1 where the path doesn't contain the right directories anymore and you can't run dataviewer, diaggui, foton, ezcaread, ezcawrite etc...
Also fb1 isn't running sftp services anymore and i can't copy anything via sftp on that machine...
Quote: |
probably my fault. It looks like the working DTT is on fb1 in the /apps directory, but not in the /opt/apps directory. Something has gotten pointed to the wrong DTT during my path/shell cleanup.
Just use the fb1 version of diaggui and foton for now. I'll figure out which binaries are bad and then delete them tomorrow.
|
|
|
1002
|
Tue Aug 31 12:30:40 2010 |
Frank | Computing | DAQ | Foton and DTT brokeded |
or switch back to bash shell in the meantime. That's working too. Simply open a shell, type in bash and then run them from the command line.
All computers have problems finding stuff since rana changed the shell.. This includes fb1 where the path doesn't contain the right directories anymore and you can't run dataviewer, diaggui, foton, ezcaread, ezcawrite etc...
Also fb1 isn't running sftp services anymore and i can't copy anything via sftp on that machine...
Quote: |
probably my fault. It looks like the working DTT is on fb1 in the /apps directory, but not in the /opt/apps directory. Something has gotten pointed to the wrong DTT during my path/shell cleanup.
Just use the fb1 version of diaggui and foton for now. I'll figure out which binaries are bad and then delete them tomorrow.
|
|
1001
|
Tue Aug 31 02:37:53 2010 |
rana | Computing | DAQ | Foton and DTT brokeded |
probably my fault. It looks like the working DTT is on fb1 in the /apps directory, but not in the /opt/apps directory. Something has gotten pointed to the wrong DTT during my path/shell cleanup.
Just use the fb1 version of diaggui and foton for now. I'll figure out which binaries are bad and then delete them tomorrow.
|
1000
|
Tue Aug 31 01:19:12 2010 |
Dmass | Computing | DAQ | Foton and DTT brokeded |
The Foton button didn't work on WS1.
- The button does: sh -c 'cd /cvs/cds/caltech/chans; /opt/apps/Linux/gds/bin/foton'
- I looked in /opt/apps/Linux/gds/bin and foton was there.
- I tried to manually execute the command and got the error: sh: line 1: 2793 Aborted /opt/apps/Linux/gds/bin/foton
- DTT is similarly broken, and says "abort" when I try to run it in a terminal.
- Same problem on ws2
- The DV button (/opt/apps/Linux/dataviewer/dataviewer) works.
Have we started changing things?
I also restarted WS1 - no change. Not sure if there's some reason to not restart the frontend (via startatf then reboot) - there were silly reasons not to do other things.
|
999
|
Sun Aug 29 23:04:17 2010 |
rana | Lab Infrastructure | stuff happens | lab cleanup |
The lab has turned into a pit again. Please clean up your stuff. There cannot be tools lying around or drinks or water bottles or used booties or scraps of paper.
Empty the trashes, change the sticky mats, etc.
I also power cycled the router. This router was just a bad choice - I suggest we just get the 24-port router which the 40m is using. I'll ask Joe if it will work. |
998
|
Fri Aug 27 16:55:55 2010 |
Frank | Computing | DAQ | working mDV example |
i've tested it again and it's still working. You can find a simple, working example for mDV getting some trend data for two of my channels a couple of days ago attached here: 
you have to change the mdv_config file to point to 131.215.115.216:8088 instead of the 40m framebuilder
Quote: |
Still having issues, but now more stuff is not working. Yesterday evening before I left, I noticed that I could load realtime data in DV, but not trended playback (didn't try raw). Still the same issue from here in FL: I get "NO DATA FOUND". I have verified that my channels are active and acquired.
As far as mDV is concerned, I don't get an error anymore when trying to get C2 data with get_data, but instead it just freezes at "C...". Now ligoDV doesn't work, either; it just spits out errors.
I want to try DTT, but without any time series data I don't know of a good time to try taking a spectrum. Is anything working for anyone?
Quote: |
Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot.
|
|
|
997
|
Fri Aug 27 11:51:41 2010 |
Zach | Laser | GYRO | gyro back to gyro configuration |
I got the PLL back up and running yesterday before I left. I spent a disproportionate amount of time not knowing that the loop was not closed because "external source" was not on, despite that FM modulation was on and the source was set to external. I'm surprised there is no "modulation source to modulation ON/OFF" or "Displayed instrument settings to actual instrument settings ON/OFF" toggle on top of this.
The gyro is now in a state where it auto-acquires lock in both directions (though it sometimes catches on the TEM10), and the beat frequency is well within the PLL's lock range, so we get a gyro signal automatically. This signal (external voltage on the VCO) is acquired at GENERIC_DOF6_OUT, while TRANS DC is picked up at GENERIC_DOF7_OUT. I think DOF8_OUT has the actuation signal to the AOM VCO, but I don't remember for sure.
I made changes to various settings along the way. Here are the current ones:
- CW PDH (AOM): G = 7, inv ON, boost ON, phi = 5. There is now a 20 dB attenuator at the output to the VCO. This seemed to help with keeping the gain at a reasonable value while not limiting our range on the VCO in lowering the deviation.
- CCW PDH: G = 7, inv OFF, boost ON, phi = 4
- AOM VCO: fnom = 47.451 MHz, dev = 100 kHz
- PDH LO: fmod = 18 MHz. I tried using 33 MHz but the signal out of the (low-bandwidth) CW PD was puny and this generated noise downstream. This frequency appears devoid of other-modely interference.
- PLL: fnom = 94.895719 MHz, dev = 375 kHz, SR560 G = 1 with no filtering (i.e. doing nothing)
I was not able to take a spectrum with DTT as the FB was dead, but I dumped the gyro signal into the SR785 as I was monkeying in the parameter space, and I was able to get the gyro noise at and slightly below 10 Hz to be on par with or ~ a factor of 2 or 3 better than it was before. This is taking into account that the previous calibration was off by a factor of 2*pi (lambdaP/4A takes optical Hz to rad/s, not RPS), so the noise can be made roughly 10-20 times lower than it used to be.
That said, it bothers me that we have no way of knowing at present if we are increasing our SNR or just reducing both noise AND signal whenever we make a change to a setting. I could have "made the noise much lower" by simply reducing the gain in the CW path, but this is not what would really be happening.
My issues with the PLL and settings-tweaking, along with Pinkesh's defense, precluded me from taking the transfer functions I wanted to take. These are the first step in characterizing our loops and ultimately in improving our SNR. They must be done before anything else.
Quote: |
I put the gyro back into the normal configuration today. It is now locking in both directions again. The bandwidth seems slightly improved, as I didn't have to be quite as careful when working on the table to keep it from dropping, but it is far from good, and the 200kHz+ oscillation still shows up with enough gain. I had set up the PLL but was having problems locking it when I had to leave.
A couple changes:
- I kept the high-speed PDA10A that I used for the linear cavity in place as the CCW REFL PD, instead of the old PDA36A. We eventually want to have the same two PDs for both REFLs, but this doesn't really matter at the moment, and we might as well maximize our optical gain in the main locking loop while using the design modulation frequency of 33 MHz. The CW loop is still a 17-MHz diode, but this loop seems to like the lowest gain setting anyway, and we may end up wanting to reduce lower gain limit of the CW PDH box.
- The BS1 in the TRANS readout was a 45P, but we are using S, so I changed it to a 45S.
I took some time to label nearly all of the cables we work with at the controls interface. The REFL PD signals, the CW & CCW error signals, the PZT and AOM VCO control signals, the TRANS DC signal, the SWEEP drive from the function generator, and two cables going to dedicated DAQ channels have all been labeled. This way we don't have to tug on cables or follow them across the table to figure out what is what. We should be prudent that we don't change them around without relabeling them appropriately
 
Tomorrow morning I'm going to figure out what's wrong with the PLL, then lock it and take a spectrum to see if things have gotten better with the new PD, new modulation frequency, and fresh realignment. Then I plan to take a bunch of transfer functions to try and diagnose our loop problem. Specifically:
- The closed-loop TF of each direction
- The OLTF from the SWEEP input of each PDH box to its output
(2) is necessary to obtain the OLTF of the loops from (1), as we will be using the SWEEP input for the excitation, and the TF from SWEEP to OUT is not the same as that from IN to OUT.
|
|
996
|
Fri Aug 27 11:20:54 2010 |
Zach | Computing | DAQ | fb1 down? |
Still having issues, but now more stuff is not working. Yesterday evening before I left, I noticed that I could load realtime data in DV, but not trended playback (didn't try raw). Still the same issue from here in FL: I get "NO DATA FOUND". I have verified that my channels are active and acquired.
As far as mDV is concerned, I don't get an error anymore when trying to get C2 data with get_data, but instead it just freezes at "C...". Now ligoDV doesn't work, either; it just spits out errors.
I want to try DTT, but without any time series data I don't know of a good time to try taking a spectrum. Is anything working for anyone?
Quote: |
Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot.
|
|
995
|
Thu Aug 26 21:59:32 2010 |
Dmass | Computing | DAQ | fb1 down? |
Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot. |
994
|
Thu Aug 26 19:52:15 2010 |
Frank | Computing | DAQ | fb1 down? |
Quote: |
It was (unintentionally?) rebooted when Koji and I were working down here a couple months ago. mDV update incoming
|
i used mDV to get temp data about an hour ago and it was working... |