40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 32 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  1239   Tue Jan 11 11:07:41 2011 AlastairElectronicsGYROPD board design

 I've added pads for the 1mm Perkin-Elmer photodiode.  I've just done this manually rather than adding a new part footprint.  The PD mounting point now looks like this screenshot.

For info I've attached the pdf for the Perkin-Elmer photodiodes from their website and also another pdf that I found that shows the footprints.

Attachment 1: Screen_shot_2011-01-11_at_11.02.04_AM.png
Screen_shot_2011-01-11_at_11.02.04_AM.png
Attachment 2: Perkin_Elmer.pdf
Perkin_Elmer.pdf Perkin_Elmer.pdf
Attachment 3: Perkin_Elmer_PDs.pdf
Perkin_Elmer_PDs.pdf Perkin_Elmer_PDs.pdf Perkin_Elmer_PDs.pdf Perkin_Elmer_PDs.pdf Perkin_Elmer_PDs.pdf
  1238   Mon Jan 10 16:08:04 2011 AlastairElectronicsGYROPD board design

Quote:

Quote:

 Here is the latest schematic for the PDs along with the board layout.  I'm going to check over the routing one last time but it will probably require checking by someone with more RF experience too.  The pcb drawing doesn't show all the features in the pdf.  It uses split internal planes to distribute the power for the diode bias and also the +/-5v for the opamp.  I've kept a full ground plane as the first one down, so there is a continuous ground plane directly underneath the tracks on the surface.

 There are quite a few rule violations that I've just noticed when running the design rule checker.  They're mostly clearance issues between the silk screen layer and various pads, but I want to get rid of them all at this stage.

The PD design is on the svn under gyro_electronics.

 Okay, so most of these violations seem trivial. I've gone into the rule manager and set it up to use the same rules as Rich had on the other RFPD board and all the trivial violations have now gone.  I've fixed all of them except one, which is a maximum hole size.  We are using 195mil for the holes for the stand-offs.  I'll need to check if there is a reason for that  being there (ie is there some limit from the manufacturer) before I remove the rule or change the hole size.

  1237   Mon Jan 10 15:18:24 2011 AlastairElectronicsGYROPD board design

Quote:

 Here is the latest schematic for the PDs along with the board layout.  I'm going to check over the routing one last time but it will probably require checking by someone with more RF experience too.  The pcb drawing doesn't show all the features in the pdf.  It uses split internal planes to distribute the power for the diode bias and also the +/-5v for the opamp.  I've kept a full ground plane as the first one down, so there is a continuous ground plane directly underneath the tracks on the surface.

 There are quite a few rule violations that I've just noticed when running the design rule checker.  They're mostly clearance issues between the silk screen layer and various pads, but I want to get rid of them all at this stage.

The PD design is on the svn under gyro_electronics.

  1236   Mon Jan 10 09:25:50 2011 AlastairMiscGeneralMichelson's interferometer
Attachment 1: michelson.jpg
michelson.jpg
  1235   Sat Jan 8 19:52:24 2011 AlastairElectronicsGYROPD board design

 Here is the latest schematic for the PDs along with the board layout.  I'm going to check over the routing one last time but it will probably require checking by someone with more RF experience too.  The pcb drawing doesn't show all the features in the pdf.  It uses split internal planes to distribute the power for the diode bias and also the +/-5v for the opamp.  I've kept a full ground plane as the first one down, so there is a continuous ground plane directly underneath the tracks on the surface.

Attachment 1: PCB_drawing_RFPD.pdf
PCB_drawing_RFPD.pdf
Attachment 2: RFPD_schematic.pdf
RFPD_schematic.pdf
  1234   Wed Jan 5 21:20:01 2011 ZachLaserMOPAChiller is crying

Done.

Quote:

simply press OK a couple of times. The warning means "check the DI cartridge". The chiller does not measure the resistivity of the water so an internal timer reminds the user every 1000h or so to "check" the water quality. The user can't disable this feature so we have to press the button once a month or so. We don't care how high the resistivity is.

Quote:

The water chiller at ATF is crying with error "Di (or D1)". What should we do? ==> Frank

The water level seems to be higher than the minimum.

It also shows temp of 19.5Cdeg.

 

 

  1233   Wed Jan 5 15:37:18 2011 FrankLaserMOPAChiller is crying

simply press OK a couple of times. The warning means "check the DI cartridge". The chiller does not measure the resistivity of the water so an internal timer reminds the user every 1000h or so to "check" the water quality. The user can't disable this feature so we have to press the button once a month or so. We don't care how high the resistivity is.

Quote:

The water chiller at ATF is crying with error "Di (or D1)". What should we do? ==> Frank

The water level seems to be higher than the minimum.

It also shows temp of 19.5Cdeg.

 

  1232   Wed Jan 5 14:45:53 2011 KojiLaserMOPAChiller is crying

The water chiller at ATF is crying with error "Di (or D1)". What should we do? ==> Frank

The water level seems to be higher than the minimum.

It also shows temp of 19.5Cdeg.

  1231   Tue Jan 4 11:42:19 2011 AlastairMiscGYROVacuum system

We are still waiting on the bottom flanges being machined.  I went to the physics machine shop this morning and they have only just got them on to a machine, which is a bit annoying since they've been there for quite a while now.  They should be ready in one week.  

I'm going to speak to Bob about getting them cleaned and baked.  I know that we're not aiming for some super-high-vacuum system but we probably also don't want machining fluid ending up on the optics when we pump this thing down.

  1230   Tue Dec 28 14:22:03 2010 ZachMiscGYROMurphy's Law verified, science rejoices

I agree that this is a much better idea. How do we go about doing this?

Quote:

I would be hesitant to use any second trend for making a noise budget. The trend generation stuff is not been vetted for low noise;

it may have any number of issues, like timing glitches, extra noise in the moving average, window bleeding, etc.

I feel like the path of least pain will be to just set up the mDV-nds2 system to grab data in chunks and downsample as necessary.

Also, we can ask JZ to implement server side decimation.

 

  1229   Mon Dec 20 00:49:55 2010 ranaMiscstuff happenstrivia

KEvsMOMENTUM.png

from the Wikipedia article on Dispersion.

  1228   Fri Dec 17 22:07:00 2010 AlastairElectronicsGeneralRFPD design: comments

Do we need to add extra caps to both the input and output sides of the regulators, or just the output side?

RA: Both. There are multiple schools of thought on what gives the best performance, so its best to have both possibilities. The large electrolytic caps give good filtering of the low frequency stuff but also have a big inrush current when the supply is first activated. Even so, it would be good to have a pad available so that we can have a large-ish cap on the input and output with a 35V or higher rating. Its not necessary that it be surface mount - could also use tantalum. There's no need to make it larger than 100 uF.

  1227   Fri Dec 17 03:34:55 2010 ranaMiscGYROMurphy's Law verified, science rejoices

I would be hesitant to use any second trend for making a noise budget. The trend generation stuff is not been vetted for low noise;

it may have any number of issues, like timing glitches, extra noise in the moving average, window bleeding, etc.

I feel like the path of least pain will be to just set up the mDV-nds2 system to grab data in chunks and downsample as necessary.

Also, we can ask JZ to implement server side decimation.

  1226   Thu Dec 16 19:46:39 2010 ZachElectronicsGYROEOM circuit

As I mentioned in my previous sad post, I took your advice and it seemed to work, but then it didn't (hooray!). I chose door #3, namely to revert the first transformer to pull from the half-tap point and then add a resistor of R ~ 75 Ohms to ground at the input of the circuit in order to make the total impedance 50 Ohms. I was not exactly sure of the impedance I measured when using the half-tap point before (I quoted 150 Ohms, but this was a rough memory), so I decided to empirically optimize the coupling by varying the resistance.

Since Frank was using the impedance test kit and I couldn't find him, I decided to do this by measuring the signal reflected from the circuit: I put a directional coupler between the RF source and then took the transfer function from "IN" to "CPL OUT", with "OUT" connected to the circuit and "CPL IN" terminated (50 Ohms). Between "OUT" and the circuit itself I had a T-connector with the third port containing the resistor under test using a BNC-to-clip adaptor. To my surprise, I found that the attenuation was maximum with R = 39 Ohms, which doesn't make sense since the maximum overall impedance of this configuration is 39 Ohms (i.e. R should have been something greater than 50 Ohms). Below is a plot of the frequency response with and without the resistor to ground at the input.

refl_signal_with_and_without_R.png

 

I found that the frequency of the notch was pretty sensitive ( O(+/- 1 MHz) ) to the resistor value and the amplitude was extremely sensitive ( O(+/- 30 dB) ) to not only the resistor value but also the way in which I clipped the resistor or how I had it resting in 3D space when taking the measurement. I am certain this has to do with some spooky RF rule where you can't use a metal film resistor or you can't use clips or you can't wear green underwear while working with resonant circuits or some mumbo jumbo.

By far the worst thing that happened is that even though I got the above beautiful result when half-assedly clipping the resistor in, when I actually soldered it into the Pomona box it did something ENTIRELY different. Unfortunately, I don't have a plot for this and I won't complain if I never see one again.

As I said in the last post, I will try to do the matching using option #1 when I get back (i.e. using a third transformer to match to the true impedance of the LC tank instead of adding parallel resistances to do the job). We'll see how it goes. 

 

  1225   Thu Dec 16 19:25:27 2010 ZachMiscGYROMurphy's Law verified, science rejoices

 Earlier this week I planned to do the following things before I went home:

  1. Finish with EOM resonant circuit and install
  2. Reduce primary PDH box gain in order to increase optical gain without instability
  3. Re-optimize primary loop in light of (1) and (2), take new OLTFs
  4. Finalize low-frequency noise-budget generation using second trend and stitching, observe improvement in noise from the above modifications
  5. Work with Alastair to finalize the RFPD board design

With the exception of (5), for which Alastair deserves the bulk of the credit, all attempts to get the above done have blown up in my face. What's worse, I have finally contracted the cold that has been lingering about. It feels irresponsible to leave for vacation without having gotten anything I wanted done, but I just physically don't have it in me. The gyro is currently in an unlockable state and so I have left everything shut off until my return. Below is a quick recap of what happened, with the numbers corresponding to the individual goals above.

  1. I followed Koji and Kiwamu's advice and put a resistor to ground at the input side of the circuit to better match the impedance. I was not 100% sure of the exact impedance value I had gotten using the second 1:16 transformer at the half-tap point, so I empirically switched resistors in until I got the greatest reduction in reflected power (see post to follow). Confusingly, I found that a 39-Ohm resistor did the best job, which doesn't make any sense since this configuration can have a maximum impedance of 39 Ohms, barring any series resistance I don't know about. Even more befuddling is that while the resistor did the trick when put in parallel externally via T-connector, upon its being soldered in the circuit had a broadly qualitatively different response. What gives?
    • Bright side/solution: When I come back, I will choose option 1 instead, which is to just use an extra transformer to match the true impedance of the LC tank to 50 Ohms. This should circumvent all the nasty problems associated with putting an extra resistor in. 
  2. I decided to reduce the gain by roughly an order of magnitude. The variable gain stage gives 5.0 dB per turn, so this increase corresponds to about 4 extra turns, or half the range. I accomplished this by increasing the value of R14 (the resistor to ground on the inverting amplifier of the input stage) from 25 Ohms to 330 Ohms. The feedback resistor is 1 kOhm, so the gain was reduced from 41 to 4. This seemed to work at first, as I was able to turn the gain knob up to just under 5.0 before the thing became unstable, however, I noticed that this modification brought back to life our favorite gain-setting-dependent DC offset. When turning the gain down to 0.0 to best capitalize on the optical gain, the DC level was sitting so far above zero that the AC signal could not go negative.
    • Bright side/solution: These circuits have been bent beyond their job description. We have modified them to the point that we don't know what the hell is going on. We have been talking about making our own dedicated servos, and now is the time that we should think about starting. Alastair and I are now reasonably comfortable with Altium, and the topology of the filter is straightforward enough that we should be able to build our own without too much hassle. We should build in cool things like multiple-stage switchable boosts for low frequency, preferably switchable remotely via relay. These boxes can live in our NIM crate and we can finally have everything controllable from the computer.
  3. Clearly there was nothing to re-optimize, and therefore no reason to take new OLTFs.
    • Bright side/solution: We now have most of the vacuum equipment, and with any luck we will have RFPDs ready to roll by the time we get everything set back up again. We will need to re-characterize both loops again once this is done, so there's not a whole lot lost on this one.
  4. CDS is in shambles. Trends and full frames are owned by different users, we can't pull data via NDS regardless of which user runs the daemon, and it appears that the only way to get inittab to run daqd and nds is with root. Also, it appears that the installations of the various tools (DataViewer, DTT, MEDM, etc.) are incomplete on different machines in a decidedly random way. For example, DataViewer doesn't run on ws2, nor does Foton, but MEDM runs on ws2 and not on fb1. Also, all the aliases are totally screwed up.
    • Bright side/solution: There really isn't a bright side here. We have fixed the previous issues regarding an incorrect default gateway on fb0 preventing NDS requests from outside, and Alastair has replaced a corrupt hard disk, but everything else is truly, truly a mess. I don't know nearly enough about hardly any of this stuff to feel confident about fixing it on my own, though I am glad to help in any way if someone has ideas!!!
  5. This is the triumph of the week. Alastair has worked hard at figuring out how to get Altium to do things that are often uncannily close to what we actually want. We have taken the suggestions and comments on the initial design posted yesterday, and we just need to work on the physical layout of the PCB.

Merry Christmas!

hanky.png

  1224   Thu Dec 16 15:27:12 2010 AlastairElectronicsGeneralRFPD design: comments

The 4107 replacement that Rich suggests using is the LMH6624MA.  It's pin for pin compatible with the 4107, which is why I hadn't changed the part on the board - I'll do that now though just to avoid confusion.

The AP1053 is a teledyne-cougar RF amp.  Highlights are:

  • Gain doesn't roll off till above 1GHz
  • 50 ohm input and output
  • Power output of 26dBm.  
  • This is the 10dB gain model, but it is pin for pin compatible with a whole load of others in the range so we can swap in whatever gain we want.
  • Rich tells us the input will be internally AC coupled, so we don't need to do this on the board.  Looking at the website and the datasheet this isn't explicitly mentioned though.

 

Quote:
  1. Add pads around all the voltage regulators for diodes to prevent transient spikes (e.g. preventing the 7815 output from spiking higher than its input).
  2. Add pads to allow more capacitors around the voltage regulators; the large caps ought to be bypasses by little ceramic caps.
  3. May want to add an L between the +15V and the power supply pin on the RF amp. This is sometimes done for RF amps to keep the RF out of the supply for the other guys who need +15V.
  4. The 4107 can develop DC offsets. Should AC couple the output going in to the RF amp.
  5. Add a series L-C in parallel with the R8. Sometimes we like to put a notch in the feedback of the 4107 to get extra notch action.
  6. Put a note on the schematic (almost obvious) that all resistors must be metal film. If any resistors require more than a 1/8W power rating, it should be indicated on the schematic.
  7. Since the 4107 is nearly obsolete, you ought to also scope out another amp and list it in the schematic notes as a good replacement choice.
  8. Put a note on there about what the hell a AP1053 is.

Otherwise, looks pretty good to me. Make sure to calculate the input-referred noise of the AD620 with the gain setting that's there to make sure you're happy with the circuit's RIN sensitivity.

 

  1223   Thu Dec 16 13:13:02 2010 KojiElectronicsGYROEOM circuit

I talked with Kiwamu the EOM master.

- The coil craft's indication like "1:16" means the turn ratio n=4.

- You saw 400Ohm with a single 1:16. This means the resonant impedance of 400*16=6.4KOhm.

- When you connected the second 1:16 transformer, the resonant impedance is 23*16^2= 5.9KOhm. This is reasonable if you consider the loss in the transformers.

- When you connected the second 1:16 with the half-tap point of it,  the turn ratio n=2 was added. This means that the transformer worked as 1:4 rather than 1:8
  although we were not sure why the resonant impedance was higher (150*16*4 =9.6KOhm) the other cases.

- Solution1: Ideally what you need is an additional 1:8. That is realized by 1:2 and 1:4 cascaded. This case the total turn ratio is n=Sqrt(2*4*16)~11. That is your gain. We are not yet sure about the loss by the triple cascade of the transformers.

- Solution2: Put the terminator at the primary side while leaving the first 1:16. As your EOM had 400Ohm with the 1:16, the input impedance will be converted to 44Ohm which is not so bad. The gain will be 4 (=n).
  (By the way this is equivalent to put a 800Ohm resister in parallel to the EOM)

- Solution3: Put the 75Ohm resister at the primary side while using the half tap point of the additiional 1:16. As your EOM had 150Ohm with this condition, the input impedance will be 50Ohm. The gain will be 8.
  (This is equivalent to put a 4.8kOhm resister in parallel to the EOM)

Quote:

 I finally asked Frank if I could just borrow the impedance test kit to measure the EOM resonant circuit impedance, as I have been having problems with the voltage transfer function method. I took the measurement and found that the peak impedance was 400 Ω (see first figure below). Pleased by the round number, I figured I could just add another transformer at the input to divide this down to 50 Ω.

The results weren't as nice as I'd like. First, I forgot that while the voltage ratio is in proportion to the turn ratio, the impedance ratio is in proportion to the turn ratio squared. So, for lack of a 1:8 RF transformer in the kit, I took another 1:16 transformer and only bridged across half of the secondary coil, so as to presumably get a turn ratio of 1:8 (though admittedly I wasn't sure about this). This resulted in a surprising peak impedance of around 150 Ω, though I do not have data for this

Knowing that I needed a larger ratio, I decided to just connect across the full secondary coil (so that I now had two cascaded 1:16 transformers). The resulting peak impedance is now 23 Ω (see second figure---note also that I have adjusted the tunable inductors to make the resonant frequency 33 MHz, instead of the 37 MHz it was in the first plot).

Clearly, I need something in between, but I am not sure how to do this without a THIRD transformer, which seems gratuitous. Perhaps I can measure the reflected power and decide if we can deal with it?

400_ohms.png

 

25_ohms.png 

 

  1222   Thu Dec 16 10:46:36 2010 ZachElectronicsGYROEOM circuit

 I finally asked Frank if I could just borrow the impedance test kit to measure the EOM resonant circuit impedance, as I have been having problems with the voltage transfer function method. I took the measurement and found that the peak impedance was 400 Ω (see first figure below). Pleased by the round number, I figured I could just add another transformer at the input to divide this down to 50 Ω.

The results weren't as nice as I'd like. First, I forgot that while the voltage ratio is in proportion to the turn ratio, the impedance ratio is in proportion to the turn ratio squared. So, for lack of a 1:8 RF transformer in the kit, I took another 1:16 transformer and only bridged across half of the secondary coil, so as to presumably get a turn ratio of 1:8 (though admittedly I wasn't sure about this). This resulted in a surprising peak impedance of around 150 Ω, though I do not have data for this

Knowing that I needed a larger ratio, I decided to just connect across the full secondary coil (so that I now had two cascaded 1:16 transformers). The resulting peak impedance is now 23 Ω (see second figure---note also that I have adjusted the tunable inductors to make the resonant frequency 33 MHz, instead of the 37 MHz it was in the first plot).

Clearly, I need something in between, but I am not sure how to do this without a THIRD transformer, which seems gratuitous. Perhaps I can measure the reflected power and decide if we can deal with it?

400_ohms.png

 

25_ohms.png 

  1221   Thu Dec 16 03:50:33 2010 ranaElectronicsGeneralRFPD design: comments
  1. Add pads around all the voltage regulators for diodes to prevent transient spikes (e.g. preventing the 7815 output from spiking higher than its input).
  2. Add pads to allow more capacitors around the voltage regulators; the large caps ought to be bypasses by little ceramic caps.
  3. May want to add an L between the +15V and the power supply pin on the RF amp. This is sometimes done for RF amps to keep the RF out of the supply for the other guys who need +15V.
  4. The 4107 can develop DC offsets. Should AC couple the output going in to the RF amp.
  5. Add a series L-C in parallel with the R8. Sometimes we like to put a notch in the feedback of the 4107 to get extra notch action.
  6. Put a note on the schematic (almost obvious) that all resistors must be metal film. If any resistors require more than a 1/8W power rating, it should be indicated on the schematic.
  7. Since the 4107 is nearly obsolete, you ought to also scope out another amp and list it in the schematic notes as a good replacement choice.
  8. Put a note on there about what the hell a AP1053 is.

Otherwise, looks pretty good to me. Make sure to calculate the input-referred noise of the AD620 with the gain setting that's there to make sure you're happy with the circuit's RIN sensitivity.

  1220   Wed Dec 15 22:36:05 2010 AlastairElectronicsGeneralRFPD design

You mean we don't want two +/- connectors run from two separate supplies?  I only put them on there because we are planning on running it from the NIM crate.  You're right though that we should make it just one +/- supply because it is meant to be a general design.  I'll alter it so the 5v regulators are powered from the 15v ones.  Thanks.

I do have a question for someone about how we make up the board.  At the moment we're modifying the aLIGO design, and it has all the power planes inside the board.  My question is this - do we want to add in two extra planes to take the +/-15v to the other opamps?  The number of layers is starting to look like a lot.

Quote:

you don't wanna have 4 power supplies to power the detector, way too complicated. I would change it to power the entire thing by +/-24V and regulate that to +/-15V. Then use the already regulated +/-15V to regulate it down to something else in addition.

 

 Here is our layout for the RFPD in Altium.  We are working on routing the board now.

 

 

  1219   Wed Dec 15 22:29:27 2010 FrankElectronicsGeneralRFPD design

you don't wanna have 4 power supplies to power the detector, way too complicated. I would change it to power the entire thing by +/-24V and regulate that to +/-15V. Then use the already regulated +/-15V to regulate it down to something else in addition.

 

 Here is our layout for the RFPD in Altium.  We are working on routing the board now.

 

  1218   Wed Dec 15 20:35:18 2010 AlastairComputingGeneralmore on fb0

I tried commenting out both daqd and nds from inittab, and then running them manually as controls and chown'ing all the data files in /frames.  It still won't let me get the full data in dataviewer.

I can also take a realtime fft in DTT, but can't get data from the past.

Quote:

Separate issue is that Dataviewer on WS2 doesn't work.  Realtime and playback both result in the error :

--> Broken or incomplete installation - read the FAQ!

_____________________________________________________________________________________________________-

Running dataviewer on fb1 will give data for realtime, or from the frames for minute trend and second trend data but not full data.  In the frames folder, the second trend files were owned by root, and the minute trend were owned by controls. The full data files were owned by root also.  The daqd process was being run by root, hence the reason the full data was owned by root.

I manually edited inittab to comment out daqd, then I pkill'ed the process.  I then went to the /frames and chown'ed the directory recursively.  Then I tried running the daqd process as controls by going to the folder /cvs/cds/caltech/target/fb/ and running ./start_daqd.inittab  .  I then checked that the process was runing as controls (it was) and that the new data in /frames was owned by controls (it was also).

I then went back to dataviewer on fb1 again to see if I could pull full data from the frames - I couldn't.

I haven't yet been able to work out how to get inittab to run daqd as controls.  The problems pulling full data from the frames may be something else, I don't know.  It basically just hangs and the terminal window shows:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
T0=10-12-16-03-08-51; Length=60 (s)
10-12-16-03-08-29

One other thing I notice is that nds is running as root, while on fb1 it is running as controls.

  1217   Wed Dec 15 20:16:44 2010 AlastairComputingGeneralmore on fb0

Separate issue is that Dataviewer on WS2 doesn't work.  Realtime and playback both result in the error :

--> Broken or incomplete installation - read the FAQ!

_____________________________________________________________________________________________________-

Running dataviewer on fb1 will give data for realtime, or from the frames for minute trend and second trend data but not full data.  In the frames folder, the second trend files were owned by root, and the minute trend were owned by controls. The full data files were owned by root also.  The daqd process was being run by root, hence the reason the full data was owned by root.

I manually edited inittab to comment out daqd, then I pkill'ed the process.  I then went to the /frames and chown'ed the directory recursively.  Then I tried running the daqd process as controls by going to the folder /cvs/cds/caltech/target/fb/ and running ./start_daqd.inittab  .  I then checked that the process was runing as controls (it was) and that the new data in /frames was owned by controls (it was also).

I then went back to dataviewer on fb1 again to see if I could pull full data from the frames - I couldn't.

I haven't yet been able to work out how to get inittab to run daqd as controls.  The problems pulling full data from the frames may be something else, I don't know.  It basically just hangs and the terminal window shows:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
T0=10-12-16-03-08-51; Length=60 (s)
10-12-16-03-08-29

One other thing I notice is that nds is running as root, while on fb1 it is running as controls.

  1216   Wed Dec 15 15:41:45 2010 Alastair & ZachElectronicsGeneralRFPD design

Here is our layout for the RFPD in Altium. We are working on routing the board now.

Attachment 1: RFPD_1.pdf
RFPD_1.pdf
  1215   Wed Dec 15 01:20:03 2010 FrankComputingDAQcron-job added on fb1 for wiper script to delete old frame files

added an hourly cron-job on fb1 which runs the wiper perl-script to delete old frame files.
Script is the wiper.pl in /target/fb1 directory.

Here the latest status:

Wed Dec 15 01:15:18 PST 2010

Directory disk usage:
/frames/trend/minute_raw 4850240k
/frames/trend/second 115772408k
/frames/full 52519332k
Combined 173141980k or 169083m or 165Gb

/frames size 241263968k at 71.76%
/frames is below keep value of 98.00%
Will not delete any files
df reported usage 71.84%

  1214   Wed Dec 15 00:49:11 2010 FrankComputingDAQfb1 fixed

i fixed the problems on fb1. The system is working now and taking data again. The following things have been changed:

  1. changed group id for user controls from 121 (oldcon) to 1001 (controls)
  2. changed owner for /frames directory to be 1001:1001 (controls:controls) (formerly 1001:121)
  3. changed owner for files changed after Nov8 to 1001:1001

i also deleted parts of the old full data on fb1 as the disk was almost full.

  1213   Tue Dec 14 17:02:56 2010 Alastair, Zach, Frank (and absolutely definitely no help from Joe)ComputingComputingFB0 status update

We started having a look at the prolems with the frame builder in the ATF today.  As Zach had said, the previous attempts ended at the point where FB0 was rebooted and one of the drives kept coming up with some problem.  The main issue before the reboot was that daqd kept restarting.  It seems that the two problems are unrelated.

1) The first issue, with the hard drive has been solved.  The drive that was causing the problem was sdc1.  The machine FB0 has four drives installed, one of which was labelled "full" and a second one "trend".  We removed these two drives, backed up the fstab file and removed them from the listing in fstab.  The computer was able to boot with no problems.  We identified sdc1 as being "full", mounted in position 3 in the computer casing.  I got a temporary replacement that is 1TB from Larry and have installed that in it's place.  After checking the device name in the /dev directory (didn't want to format the wrong one...) I formatted it using fdisk /dev/sdc and created the filesystem using mkfs.ext3 /sdc1

I then went back and copied the old version of fstab back to it's original place and put the fourth drive, sdd back in place.  The machine was rebooted and I checked that the new drive was mounting correctly as /frames/full.  I noticed that the ownership of /full was not the same as /trend (the new drive was owned by root) so I used chown controls:controls /frames/full to make controls the owner.  Inside /full there is a directory /lost+found that I also chown'ed to be controls.  Everything seems happy with this now.

I've ordered a new 1.5TB drive and a second one to keep as a backup.  They were only $59.99 from Tiger Direct - Bargain!!!

2a) The issue with daqd restarting may be a bit more involved.  The first thing that was noticed was that fb1 exhibits the same problem of daqd restarting.  Since fb0 was out of commission at this point, we checked on fb1 to see when the last data in /frames/full was written.  The date was Nov 13th.  Also the user name changes on the 8th, corresponding to this elog posting that Rana put up.  He had been trying to change over all the machines to having the same group user id.  It seems that fb1 however is still on controls oldcon as the user and group.  At some point when the front-end was restarted it no longer had write permission.

b) However having checked out fb0 it appears that this is controls controls, and that it should not have the same problems.  I looked in /frames/trend/second and there is data in there since the Nov 13th date.  However the owner of the data is root which I'm guessing is bad.  I wonder whether the permissions on the /frames/full folder may have been set such that it was unable to write to this folder, or perhaps it was just that the old drive was failing.  It seems that the easiest way to check is to start the frontend again and see if it will record full data.

I ran startatf, then opened the frond end medm panel and set the Burt restore entry to 1.  The front-end came back up just fine, and the gyro MEDM screens are working.  I kept checking back on the processes running until daqd started, with a time of 16:52.  I then went into the /frames/full folder on the new disk and checked for new data.  There was a new data folder which, just like the trend data, is owned by root.  I'm going to leave it for ten minutes to see if any data is recorded that I can access.  I'll come back and update this elog entry........

.....23:35 and daqd is still up and running on fb0 since this afternoon.  So replacing the hard drive seems to have fixed that problem.  Need to look at dataviewer again tomorrow because I can't seem to pull any data on dataviewer without it coming up with errors.

  1212   Tue Dec 14 09:30:52 2010 ZachLaserGYROgyro signal noise comparison (AOM FB vs. PLL FB)

I am referring to the CCW loop gain---the transmission beat occurs after the light has interacted with the IO, so in principle the IO noise should be suppressed by the loop gain as measured there vs. as measured in the AOM actuation signal.

If this turns out to be true, we will build a box and/or extend the vacuum system to include the transmission setup. If it is false, we will have to enclose the IO and the transmission, or eschew the transmission readout for the AOM readout if it wins out noise-wise.

Alastair and I hammered out much of the RFPD board last Friday. It should be done this morning.

Quote:

I can't imagine any noise source that would be suppressed by the transmission PLL loop gain. In principle, we could

just use a frequency counter there instead of a loop and get the same information.

Since our incoming vacuum system doesn't suppress any noise in the IO or transmission, you might as well build a sealed

plastic box to encase the transmission to see if there's any effect. Of course, even better would be to

    FINISH THE RFPD ELECTRONICS DESIGN

 

  1211   Tue Dec 14 04:23:03 2010 ranaLaserGYROgyro signal noise comparison (AOM FB vs. PLL FB)

I can't imagine any noise source that would be suppressed by the transmission PLL loop gain. In principle, we could

just use a frequency counter there instead of a loop and get the same information.

Since our incoming vacuum system doesn't suppress any noise in the IO or transmission, you might as well build a sealed

plastic box to encase the transmission to see if there's any effect. Of course, even better would be to

    FINISH THE RFPD ELECTRONICS DESIGN

  1210   Mon Dec 13 23:55:06 2010 ZachLaserGYROgyro signal noise comparison (AOM FB vs. PLL FB)

 I reconfigured the transmission demod and PLL setup today, so that I could compare the gyro noise as measured in the two signal candidates (AOM feedback and PLL feedback). As detailed in the previous post, the DAQ has taken a big stinky poop and will require Alex's wizardry to reemerge from utter chaos. To do today's analysis, I hooked up an SR560 with one pole at 0.1 Hz to use as the slow feedback filter. I used the Pomona-encased voltage divider to get the gain low enough. The gyro seemed to stay locked indefinitely.

To get better low-frequency data, I took spectra down to a 25-Hz span. This doesn't get us that much more information than with 100 Hz given the smooth shape of the spectrum at low frequency, but anything helps. We will be able to get lower-frequency data once CDS is back up.

Below are three traces, all calibrated to angular velocity noise:

  1. Feedback to the AOM VCO
  2. Feedback to the transmission PLL VCO
  3. Feedback to the transmission PLL VCO, but with foil covering the transmission setup

The third trace---which was inspired by Koji and Frank's elegant work last week---I took because I noticed that the low-frequency part of (1) and (2) looked qualitatively the same. Since we hypothesize that noise in the input optics (e.g. from air) will appear in (1) but not in (2), I suspected that covering the transmission optics in foil to reduce air noise would bring the low-frequency junk down, perhaps to or near the level seen by Koji and Frank when they covered the input optics. The foil "enclosure" is seen in the second picture.

gyro_signal_comparison.png

As can be seen in the plot, (2) and (3)---which are all but identical---are noisier in broadband than (1), save for some resonances which suggest that the calibration is about right (the calibration for each is simply the appropriate VCO gain in Hz/V times the common gyro factor lambda*S/4A). What I think is that there is some non-ideality in the transmission setup that is contributing some excess noise somehow. I am not yet ready to abandon the conviction that IO noise should be suppressed by the loop gain in the PLL signal, as the data do not show that definitively.

foiled_again.jpg

  1209   Mon Dec 13 11:28:32 2010 ZachComputingDAQhelp

. . . _ _ _ . . .

 I'm sorry to pass the buck, but this DAQ issue is above my linux pay grade. It seems that we have embarked on an infinite loop: today, I restarted the ATF model to see if the problem would go away, and now the hFE diagnostic reports NO SYNC again, as it did last time Frank and I were looking at this. daqd also still appears to be restarting every minute or two. At this point last time, we rebooted fb0, and when it came back up it forced a many-hours-long disk check. I have literally almost no intuition for what is going on, and I am humbly asking for help.

One extra clue is that when the system first breaks (i.e. when daqd begins to restart all the time while everything else appears to be running normally), a bit named "DAC0 OUT OFC" towards the right of the diagnostic screen goes RED. It now appears GREEN, though everything else is in shambles.

. . . _ _ _ . . .

  1208   Fri Dec 10 13:43:07 2010 KojiLaserGYROupdate

We need some bias to the PZT out.

> 5. I found that if the PZT output goes to negative on the oscilloscope,
> the gyro signal have larger noise than usual. I put an offset to the slow servo
> such that it does not go into the negative side.

Quote:

I noticed that there was a (slow) error signal offset of about 4000 cts. Koji had recently put in a manual offset of the same amount to counteract what was an offset in the other direction before. I turned this off and was able to get the error signal back to around 0 by clearing the servo memory (i.e. just turning the filter block off and on and then reengaging the output).

 

  1207   Fri Dec 10 11:44:05 2010 AlastairComputingDAQbusted again!

Quote:

Quote:

 The DAQ is doing the same thing it was doing a little over a week ago. Namely, it seems to reset itself or otherwise get flustered every minute or so, rendering any useful data requests futile. Let me remind everyone what happened last time:

  1. Found the problem, tried to fix it using DAQ Reload, etc.
  2. Thought that the DAQ Rate might have been the issue, so I opened daqconfig and removed some channels
  3. Restarted daqd
  4. daqd didn't seem to stay alive---problem
  5. Got Frank
  6. Frank observed the issue and saw that I wasn't just drooling on fb0
  7. Rebooted fb0
  8. fb0 complained about something on boot and forced a disk check
  9. A day passed
  10. Followed some instructions for removing the problem (mainly "yes, yes, yes, yes")
  11. I mistakenly allowed it to reboot again without changing some manual settings that I needed to have
  12. fb0 complained about something on boot and forced a disk check
  13. A day passed
  14. Frank did some magic in the recovery menu and then reboots fb0
  15. Everything worked for a week and a half or so
  16. Step 1

I'm not sure if Frank got an intuitive grasp on what was wrong last time, but it appears to be the same issue. I imagine that going through this list (perhaps with some omissions) will fix the problem again, but that will take a day or so and it may only last a few days after. Suggestion?

 The realtime stuff all seems to be working fine, it's just the frames that aren't getting written.  Running dataviewer on FB1 I can get realtime data for our channels.  If I try to get data from the past you get:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
T0=10-12-10-19-19-05; Length=60 (s)
No data found

Also, the installation of dataviewer on WS2 doesn't seem to work - does anyone know about this?  Last thing I knew was that it wasn't installed at all on WS2.  It opens fine, but when you try to get data it comes up with "incomplete installation" in the terminal window.

 It does seem to have the same symptoms as before.  When I looked at FB0 it was running daqd with a startup time of 11:25.  I looked again just now and the startup time is listed as 11:35, so it seems it is just re-starting all the time.  The weird thing is that it does appear to be running the whole time.  I've not found one instance where I've checked it and found it to not be running.  The daqd log is not so enlightening for me, but it does list a whole pile of errors - I just don't know what it's normal operation log would look like.  Some of them look quite serious to me, like " test point manager on FB may be down".  Log file reproduced below:

startup file interpreter thread tid=1084229952
calling yyparse(3, 4)
[Fri Dec 10 11:40:02 2010] ->3: set allow_tpman_connect_fail
[Fri Dec 10 11:40:02 2010] ->3: set avoid_reconnect
[Fri Dec 10 11:40:02 2010] ->3: #set cit_40m=1
[Fri Dec 10 11:40:02 2010] ->3: set dcu_rate 10=32768
[Fri Dec 10 11:40:02 2010] ->3: set dcu_rate 11=2048
[Fri Dec 10 11:40:02 2010] ->3: set controller_dcu=10
[Fri Dec 10 11:40:02 2010] ->3: set dcu_status_check=1
[Fri Dec 10 11:40:02 2010] ->3: set debug=0
[Fri Dec 10 11:40:02 2010] ->3: set zero_bad_data=0
[Fri Dec 10 11:40:02 2010] ->3: set master_config="/cvs/cds/caltech/target/fb/master"
[Fri Dec 10 11:40:02 2010] finished configuring data channels
[Fri Dec 10 11:40:02 2010] ->3: configure channels begin end
[Fri Dec 10 11:40:02 2010] ->3: set gds_server = "fb" "fb" 0 0
Fri Dec 10 11:40:04 2010 [16362]:Failed to connect to the test point manager node 1
Fri Dec 10 11:40:04 2010 [16362]:Test point manager on fb may be down
Fri Dec 10 11:40:04 2010 [16362]:tpRequest() returned -4
[Fri Dec 10 11:40:04 2010] ->3: set gps_leaps = 820108813
[Fri Dec 10 11:40:04 2010] ->3: set detector_name="CIT"
[Fri Dec 10 11:40:04 2010] ->3: set detector_prefix="C2"
[Fri Dec 10 11:40:04 2010] ->3: set detector_longitude=-90.7742403889
[Fri Dec 10 11:40:04 2010] ->3: set detector_latitude=30.5628943337
[Fri Dec 10 11:40:04 2010] ->3: set detector_elevation=.0
[Fri Dec 10 11:40:04 2010] ->3: set detector_azimuths=1.1,4.7123889804
[Fri Dec 10 11:40:04 2010] ->3: set detector_altitudes=1.0,2.0
[Fri Dec 10 11:40:04 2010] ->3: set detector_midpoints=2000.0, 2000.0
[Fri Dec 10 11:40:04 2010] ->3: #enable frame_wiper
[Fri Dec 10 11:40:04 2010] ->3: set num_dirs = 200
[Fri Dec 10 11:40:04 2010] ->3: set frames_per_dir=225
[Fri Dec 10 11:40:04 2010] ->3: set full_frames_per_file=1
[Fri Dec 10 11:40:04 2010] ->3: set full_frames_blocks_per_frame=32
[Fri Dec 10 11:40:04 2010] ->3: set frame_dir="/frames/full", "C-R-", ".gwf"
[Fri Dec 10 11:40:04 2010] ->3: #scan frames
[Fri Dec 10 11:40:04 2010] Frame file wiper cannot be enabled when gps_time_dirs==1
Write external script to clean up old frame files

[Fri Dec 10 11:40:04 2010] trend frame wiper enabled
[Fri Dec 10 11:40:04 2010] ->3: enable trend_frame_wiper
[Fri Dec 10 11:40:04 2010] ->3: set trend_num_dirs=60
[Fri Dec 10 11:40:04 2010] ->3: set trend_frames_per_dir=1440
[Fri Dec 10 11:40:04 2010] ->3: set trend_frame_dir= "/frames/trend/second", "C-T-", ".gwf"
[Fri Dec 10 11:40:04 2010] ->3: set raw-minute-trend-dir="/frames/trend/minute_raw"
[Fri Dec 10 11:40:04 2010] ->3: set nds-jobs-dir="/cvs/cds/caltech/target/fb"
[Fri Dec 10 11:40:04 2010] Frame file wiper cannot be enabled when gps_time_dirs==1
Write external script to clean up old frame files

[Fri Dec 10 11:40:04 2010] minute trend frame wiper enabled
[Fri Dec 10 11:40:04 2010] ->3: enable minute-trend-frame-wiper
[Fri Dec 10 11:40:04 2010] ->3: set minute-trend-num-dirs=10
[Fri Dec 10 11:40:04 2010] ->3: set minute-trend-frames-per-dir=24
[Fri Dec 10 11:40:04 2010] ->3: set minute-trend-frame-dir="/frames/trend/minute", "C-M-", ".gwf"
[Fri Dec 10 11:40:04 2010] ->3: #scan minute-trend-frames
[Fri Dec 10 11:40:04 2010] ->3: #scan trend-frames
[Fri Dec 10 11:40:04 2010] ->3: #scan frames
[Fri Dec 10 11:40:04 2010] ->3: start main 30
Error ignored because "allow_tpman_connect_failure" is set in daqdrc file
Fri Dec 10 11:40:04 2010 [16362]:Allocated move buffer size 528014 bytes
[Fri Dec 10 11:40:04 2010] main started
[Fri Dec 10 11:40:04 2010] ->3: start profiler
[Fri Dec 10 11:40:04 2010] ->3: # comment out this block to stop saving data
[Fri Dec 10 11:40:04 2010] frame saver started
[Fri Dec 10 11:40:04 2010] ->3: start frame-saver
[Fri Dec 10 11:40:05 2010] ->3: sync frame-saver
[Fri Dec 10 11:40:05 2010] ->3: start trender
[Fri Dec 10 11:40:05 2010] trender started
[Fri Dec 10 11:40:05 2010] trend frame saver started
[Fri Dec 10 11:40:05 2010] ->3: start trend-frame-saver
[Fri Dec 10 11:40:06 2010] ->3: sync trend-frame-saver
[Fri Dec 10 11:40:06 2010] ->3: # dont' need these
[Fri Dec 10 11:40:06 2010] ->3: #start minute-trend-frame-saver
[Fri Dec 10 11:40:06 2010] ->3: #sync minute-trend-frame-saver
[Fri Dec 10 11:40:06 2010] raw minute trend frame saver started
[Fri Dec 10 11:40:06 2010] ->3: start raw-minute-trend-saver
[Fri Dec 10 11:40:06 2010] ->3: #start frame-writer "225.225.225.1" broadcast="131.215.113.0" all
[Fri Dec 10 11:40:06 2010] ->3: #sleep 5
[Fri Dec 10 11:40:06 2010] producer started
[Fri Dec 10 11:40:06 2010] ->3: start producer
[Fri Dec 10 11:40:06 2010] ->3: start epics dcu
[Fri Dec 10 11:40:06 2010] edcu started
[Fri Dec 10 11:40:06 2010] ->3: start epics server "C0:DAQ-FB0_" "C2:DAQ-FB0_"
[Fri Dec 10 11:40:06 2010] epics server started
[Fri Dec 10 11:40:06 2010] ->3: start listener 8087
[Fri Dec 10 11:40:06 2010] ->3: start listener 8088 1
[Fri Dec 10 11:40:06 2010] ->3: sleep 60
[Fri Dec 10 11:40:06 2010] EDCU has 175 channels configured; first=0

[Fri Dec 10 11:40:06 2010] Epics server started
[Fri Dec 10 11:40:06 2010] Opened /rtl_mem_atf_daq
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 49166,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
[Fri Dec 10 11:40:06 2010] Opened /rtl_mem_psl_daq

[Fri Dec 10 11:40:07 2010] Waiting for DCU 10 to show Up
[Fri Dec 10 11:40:07 2010] Detected controller DCU 10

[Fri Dec 10 11:40:08 2010] Minute trender made GPS time correction; gps=976045221; gps%60=21

  1206   Fri Dec 10 11:21:14 2010 AlastairComputingDAQbusted again!

Quote:

 The DAQ is doing the same thing it was doing a little over a week ago. Namely, it seems to reset itself or otherwise get flustered every minute or so, rendering any useful data requests futile. Let me remind everyone what happened last time:

  1. Found the problem, tried to fix it using DAQ Reload, etc.
  2. Thought that the DAQ Rate might have been the issue, so I opened daqconfig and removed some channels
  3. Restarted daqd
  4. daqd didn't seem to stay alive---problem
  5. Got Frank
  6. Frank observed the issue and saw that I wasn't just drooling on fb0
  7. Rebooted fb0
  8. fb0 complained about something on boot and forced a disk check
  9. A day passed
  10. Followed some instructions for removing the problem (mainly "yes, yes, yes, yes")
  11. I mistakenly allowed it to reboot again without changing some manual settings that I needed to have
  12. fb0 complained about something on boot and forced a disk check
  13. A day passed
  14. Frank did some magic in the recovery menu and then reboots fb0
  15. Everything worked for a week and a half or so
  16. Step 1

I'm not sure if Frank got an intuitive grasp on what was wrong last time, but it appears to be the same issue. I imagine that going through this list (perhaps with some omissions) will fix the problem again, but that will take a day or so and it may only last a few days after. Suggestions?

 The realtime stuff all seems to be working fine, it's just the frames that aren't getting written.  Running dataviewer on FB1 I can get realtime data for our channels.  If I try to get data from the past you get:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
T0=10-12-10-19-19-05; Length=60 (s)
No data found

Also, the installation of dataviewer on WS2 doesn't seem to work - does anyone know about this?  Last thing I knew was that it wasn't installed at all on WS2.  It opens fine, but when you try to get data it comes up with "incomplete installation" in the terminal window.

  1205   Fri Dec 10 11:08:41 2010 AlastairComputingGeneralSitemap working again for gyro

I've updated sitemap so it now links to the correct two files for the gyro MEDM screens.

  1204   Fri Dec 10 10:46:11 2010 ZachComputingDAQbusted again!

 The DAQ is doing the same thing it was doing a little over a week ago. Namely, it seems to reset itself or otherwise get flustered every minute or so, rendering any useful data requests futile. Let me remind everyone what happened last time:

  1. Found the problem, tried to fix it using DAQ Reload, etc.
  2. Thought that the DAQ Rate might have been the issue, so I opened daqconfig and removed some channels
  3. Restarted daqd
  4. daqd didn't seem to stay alive---problem
  5. Got Frank
  6. Frank observed the issue and saw that I wasn't just drooling on fb0
  7. Rebooted fb0
  8. fb0 complained about something on boot and forced a disk check
  9. A day passed
  10. Followed some instructions for removing the problem (mainly "yes, yes, yes, yes")
  11. I mistakenly allowed it to reboot again without changing some manual settings that I needed to have
  12. fb0 complained about something on boot and forced a disk check
  13. A day passed
  14. Frank did some magic in the recovery menu and then reboots fb0
  15. Everything worked for a week and a half or so
  16. Step 1

I'm not sure if Frank got an intuitive grasp on what was wrong last time, but it appears to be the same issue. I imagine that going through this list (perhaps with some omissions) will fix the problem again, but that will take a day or so and it may only last a few days after. Suggestions?

  1203   Fri Dec 10 10:33:46 2010 ZachLaserGYROupdate

 In light of Koji's work, I took new OLTFs of both loops last night. They look almost identical to the old ones, as we should expect if the loops are just below the gain instability point. The gain knob settings on the PDH boxes are:

  • GCCW = 0.00
  • GCW = 3.80

Before the measurements, I adjusted the input power to ensure that we had the maximum optical gain with the CCW servo at 0.00.

Also, when turning the slow loop back on after doing the EOM measurements, I noticed that there was a (slow) error signal offset of about 4000 cts. Koji had recently put in a manual offset of the same amount to counteract what was an offset in the other direction before. I turned this off and was able to get the error signal back to around 0 by clearing the servo memory (i.e. just turning the filter block off and on and then reengaging the output).

I am working on the low-frequency part of the noise budget plot, for which the simple code is done, but it appears that the DAQ is busted again (see next entry). For this, the NB code will pull a series of second-trend data over a longer period, and the low-frequency spectrum produced with it will be stitched to the other one we have been generating.

  1202   Thu Dec 9 23:07:46 2010 ZachElectronicsGYROEOM resonant circuit test

I modified the circuit by replacing the inductor with a slightly smaller one (actually, we only had ones that were too small in the EE shop, so I soldered two of them together in series). I tuned the new inductors so that the resonance frequency was 33 MHz. Below is a plot.

EOM_res_circuit_TF_12_9_10.png

Again, this plot has had the -34 dB of (measured) attenuation from the two in-line 20-ohm BNC attenuators that were used between the source and the resonant circuit subtracted out to reflect the true magnitude.

I took the same measurement using a (MiniCircuits) 50-ohm terminator in place of the circuit and EOM and verified that the result was 0 dB in broadband, as it should be given the measurement setup. What I don't understand is that---as is explained in the elog thread between Stephanie and Koji linked below---the magnitude should be given by 2Z/(50+ Z), where Z is the impedance of the device under testing. The impedance should be >> 50 ohm on resonance, so the magnitude of the peak should be something like 6 dB. I get 11.4 dB, which doesn't seem right unless there is a factor of two missing here somehow.

 

I want to be sure of the impedance before I hook everything up, so I have restored the experiment to the standard setup until I am.

 

Quote:

 I built a simple resonant circuit for use with the EOM consisting of:

  1. A 1:16 turn ratio RF transformer
  2. A tunable inductor
  3. That's it

The schematic of the full circuit including the EOM is:

eom_circuit_schematic.png

The principle of operation is that the impedance Z of the LC circuit in parallel with the secondary transformer coil becomes very high on resonance. The transformer makes this impedance look like Z/(162) to an input signal, and the circuit is optimized when this value is 50 Ω so that the impedance is matched and there is maximal power coupling. Meanwhile, the voltage is stepped up by a factor of 16, so the ultimate result is a gain on resonance. The transformer is useful in its own right in the case where the load impedance is not adjustable, in order to match this with the input impedance. In that case, one chooses the appropriate turn ratio to make Z/n2 = 50 Ω (for RF applications). In our case, we make Z as high as possible, and in doing so we need to increase n, which in turn increases the voltage gain---pretty neat!

The measurement setup is the same as here. Below is the measured voltage transfer function, with the effect of the attenuators from the source to the circuit (to avoid power reflection, as detailed in the linked post) subtracted out.

eom_res_circuit_tf.png

 

It seems like either the inductor I am using is not quite what it says it is, or that the capacitance of the EOM is not the roughly 12 pF it is supposed to be. The latter is not very likely as I got roughly the same resonant frequency of ~26 MHz when simulating the EOM with a mica capacitor. In any case, I am going to replace the inductor with a slightly smaller one and try to adjust the frequency to 33 MHz.

I wanted to plot the LISO prediction for this circuit along with the measured transfer function, but I am running into trouble with getting the Q quite right. The resonant frequency and gain come out to about the same, but the shape was much broader. I realized that I had the coupling efficiency of the mutual inductance line set to unity (ideal), and when I changed this to 0.9 the Q magically increased, resulting in a very sharp spike. I am not sure if I am doing something wrong, but I will either figure it out or just use something to model it analytically.

 

  1201   Thu Dec 9 21:10:24 2010 AlastairLaserGYROWind breaker

 Following Koji's post on the wind noise affecting input optics, I've drawn up the bench area to scale to see how the main parts will fit once we have the vacuum system.  In the first drawing I've left the input optics where they are at the moment, and overlaid the vacuum system on top of the current blue box.

In the second version I've moved everything up the table to see if we can use the current blue box to house the input optics.  The answer seems to be that it will fit (just) and the blue box is very close to being the same area as the current input optics, albeit with everything rotated and a few things that will need to be moved around.  The only downside I can see to this is that we'll need to rearrange all the optics rather than building a new box around them.  Also, at least a few of the final mirrors will not fit inside the box, so we'd have to stick and extra small box on to cover the final turning mirrors before the beam goes into the input mirror.

Attachment 1: bench_layout.pdf
bench_layout.pdf
  1200   Thu Dec 9 20:55:50 2010 ZachLab InfrastructureGeneralWhiteboard installation on Monday

I just removed the cables and hangers. The cables were rolled up as neatly as possible and put in the cabinet on the west side of the lab between the tables. The hangers are there too. The screws I put in an empty compartment in the carousel bins next to the doors.

Quote:

The last whiteboard covering the door to the PSL lab will be installed Monday morning 8am. I will be supervising the guy who will install the stuff.
Someone has to remove the cable hangers and cables until Monday.

 

  1199   Thu Dec 9 02:53:22 2010 KojiLaserGYRODouble Hacky? Trio? Even Hacky quartet!

[Koji, Zach, Alastair, Frank]

After our very hacky trials, we found the noise source in the low frequency band:
It is the air current on the input/output optics even though the mechanism is still unknown.

We need:

- to know why the air flow in the I/O optics causes the noise.
- to make firm wind shield for the input/output optics too.


First Zach, Alastair and Koji started the afternoon experiment.

1. The first attempt was to put the Al foil on the table in the box to prevent the air flow from the table holes.
We practically saw no improvement.
Frank later pointed that the holes of the table are individually sealed. Therefore it was reasonable not to see any improvement.

2. The second attempt was to introduce He gas into the box just in order to see any possible change in the noise spectrum.
We went to the biology stock room to get the tubing for the gas introduction. As soon as we introduced the gas into the box,
the optical path length started to show drastic change (doe to reflactive index of He?). At the same time we started to see vertical
misalignment. We no longer could lock the cavity on TEM00. It may be caused by the temperature change in the box as the
introduced He was indeed quite cold due to adiabatic expansion? We also observed our voices got strange as we expected.

The He cyrinder is still in the lab. We may prepare some reservoir to accumulate the gas and let it heat???

At this point Zach and Alastair left the lab.

3. The third attempt was to put the air baffles made by Al foils along the cavity path. It made no change in the noise.

4. I was checking the PDH box. I found that the phase setting of the VCO loop was at the edge (10.00). I added a short BNC in the PD path.
Now the phase for the maximum optical gain is 9.60. The phase was adjusted such that the servo starts oscillation with as lower gain as possible.

I was observing the VCO feedback (the current gyro signal). It has ~100mVpp 40MHz signal coupled. It turned out that this signal comes from the
DAQ. I put a 5MHz LPF between the PDH box out mon and the DAQ cable.

The signal is also sent to SR560 to filter out the high freq fluctuations which makes the observation quite tricky.

5. I found that if the PZT output goes to negative on the oscilloscope, the gyro signal have larger noise than usual.
I put an offset to the slow servo such that it does not go into the negative side.

6. As the noise below 100Hz has non-stationary behavior I tried to find any sign of scatteriing / clipping. No luck.

Then I started the attept of putting Al foils to cover the input/output optics.
It indeed helped to reduce the noise between 0.1-20Hz! The improvement is factor of ~5 between 1~10Hz.
See the plot and the first photo. This was one of the hackiest work I ever had...

7. As I could not believe this improvement by myself, I told the story to Frank who was in the room at this time.
He got excited and proposed several ideas.

7a. First we removed the Al foils in order to confirm the effect is real. Yes it is real.

7b. The imptovement could have been given by settling the air flow or shadowing the ambient light.
Frank pointed out that our PD is sensitive to the visible wavelength. He brought the VIS light blocking
filters from PSL lab. The filters didn't help the noise level.
The noise from the ambient light was rejected at least for now.

7c. We partially put the Al foils on the table. The effect was not quite localized but relatively strong at the downstream side of the input optics.
There is the air conditioning working above those optics. We put the Al foils to block the A.C. air. It improved the noise level by factor of 2-3.
Anyway, we confirmed that the main cause is the air flow.

7d. Frank found the plexiglas plates at the edge of the room. We constructed the temporary wind shield by them. See the second photo.
It improved the noise level as shown in the plot, although the effect was not as good as the Al foil case.

8. We decided to finish the work of the day. We cleaned up our mess (expect for the foil on the table in the box).
The stray Al foils were disposed. The Al reel was returned to the suspension lab.

 

Attachment 1: Gyro_Spectra_101208.pdf
Gyro_Spectra_101208.pdf
Attachment 2: 100_1158.jpg
100_1158.jpg
Attachment 3: 100_1162.jpg
100_1162.jpg
  1198   Wed Dec 8 22:22:51 2010 KojiLaserGYROGyro relocked

Gyro relocked GPS time at around 975910000. I leave the lab while it is kept locked.
Another elog entry is coming later.

  1197   Wed Dec 8 22:16:00 2010 ZachElectronicsGYROEOM resonant circuit test

 I built a simple resonant circuit for use with the EOM consisting of:

  1. A 1:16 turn ratio RF transformer
  2. A tunable inductor
  3. That's it

The schematic of the full circuit including the EOM is:

eom_circuit_schematic.png

The principle of operation is that the impedance Z of the LC circuit in parallel with the secondary transformer coil becomes very high on resonance. The transformer makes this impedance look like Z/(162) to an input signal, and the circuit is optimized when this value is 50 Ω so that the impedance is matched and there is maximal power coupling. Meanwhile, the voltage is stepped up by a factor of 16, so the ultimate result is a gain on resonance. The transformer is useful in its own right in the case where the load impedance is not adjustable, in order to match this with the input impedance. In that case, one chooses the appropriate turn ratio to make Z/n2 = 50 Ω (for RF applications). In our case, we make Z as high as possible, and in doing so we need to increase n, which in turn increases the voltage gain---pretty neat!

The measurement setup is the same as here. Below is the measured voltage transfer function, with the effect of the attenuators from the source to the circuit (to avoid power reflection, as detailed in the linked post) subtracted out.

eom_res_circuit_tf.png

 

It seems like either the inductor I am using is not quite what it says it is, or that the capacitance of the EOM is not the roughly 12 pF it is supposed to be. The latter is not very likely as I got roughly the same resonant frequency of ~26 MHz when simulating the EOM with a mica capacitor. In any case, I am going to replace the inductor with a slightly smaller one and try to adjust the frequency to 33 MHz.

I wanted to plot the LISO prediction for this circuit along with the measured transfer function, but I am running into trouble with getting the Q quite right. The resonant frequency and gain come out to about the same, but the shape was much broader. I realized that I had the coupling efficiency of the mutual inductance line set to unity (ideal), and when I changed this to 0.9 the Q magically increased, resulting in a very sharp spike. I am not sure if I am doing something wrong, but I will either figure it out or just use something to model it analytically.

  1196   Wed Dec 8 17:57:46 2010 FrankLab InfrastructureGeneralWhiteboard installation on Monday

The last whiteboard covering the door to the PSL lab will be installed Monday morning 8am. I will be supervising the guy who will install the stuff.
Someone has to remove the cable hangers and cables until Monday.

  1195   Wed Dec 8 11:37:17 2010 ZachLaserGYROnoise budget-O-matic

At Koji's suggestion, I have added the residual CCW noise (as measured from the error signal) to the NB plot:

NoiseBudget.pdf

This trace is generated in exactly the same way as the gyro noise trace: 32k data is downloaded and then pwelched. 

Quote:

I have verified the self-consistency of the three different methods of obtaining the gyro noise spectrum, which are:

  1. Analog measurement with a standalone spectrum analyzer (Agilent)
  2. DTT
  3. NDS and pwelch() in MATLAB

(NOTE: what I mean is that these are three ways to obtain a noise spectrum with a given gyro signal, in this case the feedback signal to the AOM VCO). Below is a plot showing that the three results overlap quite nicely, with the only difference being a little less smooth a curve at low frequency for the analog measurement.

noise_spect_consistency_check.png

I'm not sure what was giving me trouble yesterday, but I am now clearly able to get a sensible result with option (3), which is integrated in the new noise budget generation scheme. Below is an output I just generated using a current spectrum. I have made the following aesthetic modifications that Koji suggested:

  • Make the measured noise be bolder (higher linewidth) than the individual noise contributions
  • Make the measured noise some stand-out color, like BLACK
  • I have done the same thing to the "requirement" trace, only I have made it GREEN

NoiseBudget.pdf

Quote:

 I have more-or-less finished a rough first draft of the automatic gyro noise budget MATLAB code. The rough architecture is:

  1. An M-file that obtains and saves the current gyro noise, by:
    1. Downloading a recent time series via NDS from the ATF frames
    2. Using pwelch to take the spectrum
    3. Saving the data and frequency vector as ASCII
  2. A "data" directory containing the above spectrum as well as ASCII spectra of all independently measurable noise contributions, such as:
    • PDH box output noises (V)
    • PD dark noises (V)
    • Displacement noise measurements for fundamental mechanical noise coupling estimates
    • Phase noise measurements
    • CCW and CW OLTFs
    • etc (this data library will be updated and amended as we go along)
  3. An M-file that calibrates all the data in (2), plots it along with (1), and generates a PDF. The current date and time are printed in the plot title. This file contains many adjustable parameters such as:
    • PDH box gain settings
    • AOM VCO deviation setting
    • Gyro signal -> ADC preamp gain
    • etc

In addition to this, there are two functions named "pdh1437" and "pdh2215" which contain analytical expressions for the two respective filters. They take as arguments 1) a frequency vector and 2) the appropriate box's gain setting and return a vector of the transfer function sampled at these frequencies. These are used wherever a spectrum needs to be multiplied or divided by the PDH gain.

The file in (2) takes the OLTF in each direction and divides by the correctly sampled PDH gain and actuator gain to obtain the optical response in V/Hz. This is used to calibrate voltage spectra into (rad/s)/rHz.

(1) is separate so that we can choose whether to pull the gyro noise from the frames or upload our own (e.g. an analog measurement), and there will be a single file that runs everything in one fell swoop.

Below is a sample output. In this case, I have used our analog measurement of the gyro noise from last week as I am still working out the kinks in the NDS method (for some reason, they don't come out quite the same). Obviously, this is still somewhat barebones and we will need to add in more noise sources as they come to us. The good thing is that---at long last---we will be able to simply press a button every time we want an up-to-date noise budget. If we make a change to the setup, it is simply a matter of dropping the new data into the "data" directory and re-running.

NoiseBudget.pdf

 

 

 

  1194   Wed Dec 8 01:13:31 2010 ZachLaserGYROnoise budget-O-matic

I have verified the self-consistency of the three different methods of obtaining the gyro noise spectrum, which are:

  1. Analog measurement with a standalone spectrum analyzer (Agilent)
  2. DTT
  3. NDS and pwelch() in MATLAB

(NOTE: what I mean is that these are three ways to obtain a noise spectrum with a given gyro signal, in this case the feedback signal to the AOM VCO). Below is a plot showing that the three results overlap quite nicely, with the only difference being a little less smooth a curve at low frequency for the analog measurement.

noise_spect_consistency_check.png

I'm not sure what was giving me trouble yesterday, but I am now clearly able to get a sensible result with option (3), which is integrated in the new noise budget generation scheme. Below is an output I just generated using a current spectrum. I have made the following aesthetic modifications that Koji suggested:

  • Make the measured noise be bolder (higher linewidth) than the individual noise contributions
  • Make the measured noise some stand-out color, like BLACK
  • I have done the same thing to the "requirement" trace, only I have made it GREEN

NoiseBudget.pdf

Quote:

 I have more-or-less finished a rough first draft of the automatic gyro noise budget MATLAB code. The rough architecture is:

  1. An M-file that obtains and saves the current gyro noise, by:
    1. Downloading a recent time series via NDS from the ATF frames
    2. Using pwelch to take the spectrum
    3. Saving the data and frequency vector as ASCII
  2. A "data" directory containing the above spectrum as well as ASCII spectra of all independently measurable noise contributions, such as:
    • PDH box output noises (V)
    • PD dark noises (V)
    • Displacement noise measurements for fundamental mechanical noise coupling estimates
    • Phase noise measurements
    • CCW and CW OLTFs
    • etc (this data library will be updated and amended as we go along)
  3. An M-file that calibrates all the data in (2), plots it along with (1), and generates a PDF. The current date and time are printed in the plot title. This file contains many adjustable parameters such as:
    • PDH box gain settings
    • AOM VCO deviation setting
    • Gyro signal -> ADC preamp gain
    • etc

In addition to this, there are two functions named "pdh1437" and "pdh2215" which contain analytical expressions for the two respective filters. They take as arguments 1) a frequency vector and 2) the appropriate box's gain setting and return a vector of the transfer function sampled at these frequencies. These are used wherever a spectrum needs to be multiplied or divided by the PDH gain.

The file in (2) takes the OLTF in each direction and divides by the correctly sampled PDH gain and actuator gain to obtain the optical response in V/Hz. This is used to calibrate voltage spectra into (rad/s)/rHz.

(1) is separate so that we can choose whether to pull the gyro noise from the frames or upload our own (e.g. an analog measurement), and there will be a single file that runs everything in one fell swoop.

Below is a sample output. In this case, I have used our analog measurement of the gyro noise from last week as I am still working out the kinks in the NDS method (for some reason, they don't come out quite the same). Obviously, this is still somewhat barebones and we will need to add in more noise sources as they come to us. The good thing is that---at long last---we will be able to simply press a button every time we want an up-to-date noise budget. If we make a change to the setup, it is simply a matter of dropping the new data into the "data" directory and re-running.

NoiseBudget.pdf

 

 

  1193   Tue Dec 7 15:05:25 2010 AlastairComputingPurchasesnew router has arrived
  1192   Tue Dec 7 00:19:26 2010 ZachLaserGYROnoise budget-O-matic

 I have more-or-less finished a rough first draft of the automatic gyro noise budget MATLAB code. The rough architecture is:

  1. An M-file that obtains and saves the current gyro noise, by:
    1. Downloading a recent time series via NDS from the ATF frames
    2. Using pwelch to take the spectrum
    3. Saving the data and frequency vector as ASCII
  2. A "data" directory containing the above spectrum as well as ASCII spectra of all independently measurable noise contributions, such as:
    • PDH box output noises (V)
    • PD dark noises (V)
    • Displacement noise measurements for fundamental mechanical noise coupling estimates
    • Phase noise measurements
    • CCW and CW OLTFs
    • etc (this data library will be updated and amended as we go along)
  3. An M-file that calibrates all the data in (2), plots it along with (1), and generates a PDF. The current date and time are printed in the plot title. This file contains many adjustable parameters such as:
    • PDH box gain settings
    • AOM VCO deviation setting
    • Gyro signal -> ADC preamp gain
    • etc

In addition to this, there are two functions named "pdh1437" and "pdh2215" which contain analytical expressions for the two respective filters. They take as arguments 1) a frequency vector and 2) the appropriate box's gain setting and return a vector of the transfer function sampled at these frequencies. These are used wherever a spectrum needs to be multiplied or divided by the PDH gain.

The file in (2) takes the OLTF in each direction and divides by the correctly sampled PDH gain and actuator gain to obtain the optical response in V/Hz. This is used to calibrate voltage spectra into (rad/s)/rHz.

(1) is separate so that we can choose whether to pull the gyro noise from the frames or upload our own (e.g. an analog measurement), and there will be a single file that runs everything in one fell swoop.

Below is a sample output. In this case, I have used our analog measurement of the gyro noise from last week as I am still working out the kinks in the NDS method (for some reason, they don't come out quite the same). Obviously, this is still somewhat barebones and we will need to add in more noise sources as they come to us. The good thing is that---at long last---we will be able to simply press a button every time we want an up-to-date noise budget. If we make a change to the setup, it is simply a matter of dropping the new data into the "data" directory and re-running.

NoiseBudget.pdf

 

  1191   Mon Dec 6 16:31:15 2010 ZachLaserGYROCCW-CW noise spillover analysis

 Attached is a recent analysis of the "noise spillover" from the primary loop to the secondary (rotation sensing) loop. The plot shows the frequency noise as measured in 1) the primary error signal and 2) the secondary actuation signal. The idea here is that whatever noise is not removed by the primary loop (i.e. the error signal) should be attacked by the secondary loop. In the limit of an ideal secondary loop, the correctly calibrated signals should be exactly equal (that is, the rest of the noise is exactly cancelled by the secondary actuator).

The calibrations are:

  • AOM actuation: 6.103 x 10-4 V/ct * 1/42 (INMON gain) * 500,000 kHz/V (VCO gain)
  • CCW error signal: 6.103 x 10-4 V/ct * 1/50 (SR560 preamp gain) * (1 / 3 x 10-7 V/Hz) (CCW optical response)

CCW-CW_spillover_12_6_10.png

It appears as though the gyro noise is in fact dominated by residual common-mode noise above about 30 Hz. Below this, some other source contributes more strongly. The noise here is roughly 300x higher than the expected fundamental gyro noise from displacement, so this suggests that some other non-ideal condition is at fault.

  1190   Fri Dec 3 12:16:10 2010 AlastairComputingPurchasesThe router saga continues

I had word that the router shipped today.  Should be here Monday, or Tuesday at the latest.

 

Quote:

I finally got through to someone at (**insert name of offending company here**) to ask about our router order for the ATF.  It turns out that although it is now out of stock and discontinued they had not bothered to let us know.  So not only is the router used at the 40m not available, but the next model up in the range has also been discontinued.

I have therefore ordered this one instead as it appears to be the last wired router that linksys offer.  I guess we could have substituted a wireless one but I'm not sure that would have gained us anything.

The specification list on the linksys website is pretty vague:

Model: BEFSR41
Standards: IEEE 802.3, IEEE 802.3u, IEEE 802.1p
Ports: Four 10/100 RJ-45 Switched Ports
One 10/100 RJ-45 Port for Broadband Modem
Warranty: 1 year hardware limited warranty
Lifetime award-winning online support tools

I'm assuming it will allow all the port forwarding settings etc that we need.

 

ELOG V3.1.3-