40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL, Page 13 of 52  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  2193   Thu May 31 14:17:42 2018 awadeDailyProgressFSSFixing FSS binary under voltage issue

After switching the laser fast monitor channel from the front panel FASTMON pin to the FASTM_P/FASTM_N pins I found that the PID controllers that use this channel to adjust the laser slow frequency became unstable.  After turning down the gain the oscillations of laser temperature were very difficult to tune out.

It looks like the issue is with the fact that the FSS interface board (LIGO-D040423) low passes the monitor signal with a 0.8 Hz LP filter (200kΩ wt 1 µF cap).   The narrowed bandwidth of this 'sensor' in the PID loop limits the bandwidth of the total OLG.  We could turn down the P and up the I a little bit, but this seems less good than switching out some resistors.  

I replaced four 100 kΩ resistors R99, R100, R116 and R117 with 510 Ω resistors.  This brings the LP filter on the Fast monitor channels and mixer monitor channels up to 156 Hz: the new frequency is well above the ADC 10 Hz sampling rate but should still filter very high frequencies that are not of interest to the slow loop. I'm not sure what the ideal cut off point should be wrt digitizing signal and the loop, but this seems like a good first guess.

These modifications were made to North and South FSS interfaces boards (LIGO-D040423), serial 2010:005 and 2010:00? respectively. These changes are logged in the wiki page and with a label on the box back to this post. 

Quote:

Autolockers were not catching the resonances again. It turns out I had unplugged the excitation to the FSS acromag controller box that engages the binary channels.  It had been plugged back in but often fails to activate the logic because it is still being powered from a 5 V plug pack.

Decided it was time to make the switch to 9V. I installed some voltage dividers to set the excitation out to the FSS interfaces to 4.9 V with a low voltage of 0.66 V maximum (unpowered).  See PSL:2058 for the wiring, I used option D with R1 = 820 Ω  and R2 = 680 Ω.  The new wiring was tested to check the voltages were right, so I don't fry the FSS interface box again.  I also made some changes to the soft binary channels in the acromag IOC: the front medm panel Test1 and Test2 switches are now flipped (NOT operation) so they make sense from the users point of view.  Before the logic was inverted so turning TEST1 off actually activated this path in the circuit.

I also noted down the channels off the ADC card that picks off the monitors from the FSS D25 connector.  This should reduce the number of front panel BNCs as it can all be routed inside the Acromag interface controller box. These have remapped from Aidan's acromag crate into the FSS interface controller box.

 

  1989   Wed Nov 22 20:31:43 2017 awadeDailyProgressFSSFixing resistor values in south FSS main servo board D040105 (2010:007)

Looking around inside the FSS field box I found that some of the resistors had been replaced with the wrong values on the main board .

  • R7 was 470 Ω instead of 100 Ω.
  • R1 and R2 were 470 Ω intead of 453 Ω (knew this, before I didn't have exact values).  
  • R3 is a 100 Ω radial metal film radial packaged resistor on long janky leads instead of a 124 Ω surface mount. Maybe someone in the past wanted to be able to switch this out regularly.

R1 and R2 were ok values, but the solder job I did when I replaced them from 50 Ω resistors was not so great.

I've now switch these values to the ones correct for the schematic.  The R7 is the most liklely to make a difference here.  Its not clear why 470 Ω was used.

 

  1874   Tue Aug 22 19:22:57 2017 awade, CraigDailyProgressTempCtrlFixing some of the lab temperature issues

I removed some of the insulation around the north side of the tank to see beams going in when aligning the cavities.  When Craig and I replaced these, the stirring of air around the tank was enough to change the laser beat note by order 5 MHz over 15 -20 minutes.  

A rough calculation:

the absolute frequency of the laser is\nu = c/\lambda = 2.81 \times 10^{14}  Hz and expansion coefficient of fused silica is 5.5e-7 [1/K].  Frequency and length change are related by \Delta L /L = \Delta \nu/\nu.  So temperature is related to frequency shift by

\Delta T = \frac{\Delta \nu}{\alpha\nu} = \frac{\lambda}{c\alpha }\Delta \nu = 32 mK

This is the differential shift in cavity temperature over the 15-20 minute period.  At this rate of drift it is impossible to keep the PLL loop in range and means that our RefCavs are extremely sensitive to environmental drift

Some changes

- The intake of the hepa filters above the clean tent are directly below the output of the AC. There was some temporary aluminum foil put on the AC output vent to redirect air away from the top of the tent.  This was ripped and had holes about the edges so Craig is making a new one. We can make a more permanent thing out of Plexi glass later maybe. 

- We changed the room temperature from 72 F to 75 F to reduce the work the AC needs to do to maintain lab temperature (Michelson originally performed his experiments in a basement lab with no AC, they deliberately locked the door shut for >10 h stretches at time with no air circulation: they seem to have the right idea).  The real lab temperature measured with a temperature display was 19.9 C. We'll check again in the morning what this settles at. For now the BN has really changed a lot its moved from ~60 MHz down to 16 MHz.  This will take a while to settle.

 

  2058   Wed Jan 24 18:29:13 2018 awadeDailyProgressFSSFixing the Acromag latching issues and adding resistors to match the logic levels to FSS and PMC interface boards.

In troubleshooting binary engage interfacing between acromag XT1541 and the PSL servo board for PMC locking (see context PSL:2056) I think I've located the origin of our latching issues with the acromag cards: we're not using enough excitation voltage for the acromag's internal FET buffers to clear their on-voltage thresholds.

Acromag Binary Chanels REQUIRE 6-32 V Excitation

The XT1541 manual gives a recommended voltage range of 6-32 V for the digital excitation driving voltage.  I had been running it at 5.1V because it actually worked (most of the time) and it is a bad idea to drive a 5V level logic chip at an excess of 5 V. However, often, on a power cycle, the excitation voltage of the binary outputs isn't quite enough to push over the minimum threshold and the binary output of the cards latches off. I tried a few power cycles of the cards at binary excitation voltage at 4V, 5V, 6V etc and found that 5 V was just at the threshold where the binary outputs were responsive to modbus IOC channel changes.  6V> guarantees working.

Dealing with logic with pull up resistors

Most of the inputs for binary engage in LIGO electronics have some kind of pull up resistor on their inputs.  For the FSS it is 4.99 kΩ pull up to +5V.  In the pre-modecleaner servo boards (LIGO-D980352-D) there is a 10 kΩ pull up to +5V.  Aidan had previously come up with a solution for interfacing with the 4.99 kΩ pull up resistors in the FSS boxes input logic (see PSL:1573).  This was to add a ~810 Ω resistor in parallel with the acromag's internal 10 kΩ resistor to bring the off state voltage below the 0.8 V threshold of the HCT157D input chip (see option B in attached). This is satisfactory for ensuring that the off-state of the acromag forms a voltage divider back from the +5V rail to ground through the 810 Ω || 10 kΩ of the acromag + added resistor. It gives a value of 0.66 V at the HCT157D's input. However, as it stands, the on state is whatever the minimum of the acromag is (6V). That value exceeds the acceptable limit for the logic.

If we add one more resistor, it is possible to divide down whatever the acromag binary channels put out to 5V while also ensuring the off state is below 0.8 V.  The attached figure shows the four options for configuring a resistor network to adapt the acromags to driving the pulled-up inputs digital logic switches.

  • Option A connects the acromag directly to the digital logic.  In this case the 10 kΩ pull-down inside the acromag along with the 4.99 kΩ pull up to +5V gives an off state voltage of 3.34V (too high for 0.8V switching threshold) and an on-voltage limited to that of the source.
  • Option B  is what we use now for the FSS. This gives a useable off voltage (0.66 V for R1 = 820 Ω and Rpullup = 4.99 kΩ), but is limited to the on voltage of the source.
  • Option C is not great, you would need a really large value for R2 to bring the voltage divided between the input and +5V pullup rail close to 5 V, R1 would then need to be made very small, greatly increasing the current requirment.
  • Option D best.  In the case of the FSS interface, with a pull up voltage of +5V and Rpullup  = 4.99 kΩ, choice of R1 = 820 Ω and R2 = 164 Ω brings the on state to 5.0V (from a 6.0 excitation) and the off state falls to 0.66 V.

The current requirements for option D are also fine.  In the on state the acromag will need to source about 6.7 mA, which is fine. In the off state 0.8 mA will be sourced via the +5V pull up, which is also ok.

Here are the equations for choosing R1 and R2

R_1 = \frac{R_\textrm{pull up}}{(V_\textrm{pullup}/V_\textrm{off}-1)-R_\textrm{pull up}/R_\textrm{pull down}}

where Vpull up is the voltage of the pull up rail, Voff is the desired off state voltage, Rpull up is the pull up resistance of the input logic and Rpull down is the pull down resistance of the driving circuit. Using this value we can also find that the best series resistance is

R_2 = R_1(\frac{V_\textrm{excitation}}{V_\textrm{on}}-1)

where Vexcitation is the  high value of the driving circuit and Von is the desired on (high) voltage at the input logic.

 

Choice of pull down and series R for PMC boards

The pull ups on the PMC board logic are 10 kΩ. So to interface the acromag a good choice would be 1.79 kΩ parallel to acromag 10 kΩ and 359 Ω for the series resistances (in configuration D)

 

Small correction to above equations

Thu Jan 25 22:00:23 2018: I didn't quite include all the stuff in the above equations.  They will give good values for cases where R1<<Rpull up  and R2<<Rpull down. Here is the full equation in the case that the pull up resistor and/or pull up reistor values are comparible to the choices needed for R1 and R2​.

R_1 = \frac{R_\textrm{pull up}}{(V_\textrm{pull up}/V_\textrm{off}-1)-R_\textrm{pull up}/(R_\textrm{pull down}+R_2)}

where Vpull up is the voltage of the pull up rail, Voff is the desired off state voltage, Rpull up is the pull up resistance of the input logic and Rpull down is the pull down resistance of the driving circuit. Likewise

R_2 = \frac{R_1(V_\textrm{excitation}/V_\textrm{on}-1)}{1+(1-V_\textrm{pull up}/V_\textrm{on})R_1/R_\textrm{pull up}}

where Vexcitation is the  high value of the driving circuit and Von is the desired on (high) voltage at the input logic. As is very likely the case the pull up voltage rail is actually the same as the required on voltage and the above equation for R2 reduces to the value in the previous section.

Its a bit cicular here R1<--> R2. Just try some values, if logic pull up and source pull down are ≥5 kΩ then the equations in the second above are fine. 

 

 

Quote:

When Craig restarted the acromag IOC yesterday the North path FSS loop engage binary channel went into a permanent latch off mode.  This is a recurring problem that can be fixed by plugging the 5 V power in line to the acromag binary channels in with the FSS control boxes unplugged. Sometimes you need to plug and unplug a few times.  

It could be an issue with the way we have used 820 Ω resistors to bring the pull up 10 kΩ down to 758 Ω. It probably should be buffered somehow.  For now its good enough to get it working, once it's powered up its fine.

As an intermediate fix I soldered a 1000 µF electrolitic cap in line with the 5V supply to give it juice when first powered up.  This seems to make the latching go away most of the time (90%) when first powering up the units. So... slight improment.

 

Attachment 1: Acromag-to-pullup-logic_options.pdf
Acromag-to-pullup-logic_options.pdf
  1857   Sun Aug 13 19:58:49 2017 awade, CraigDailyProgressBEATFixing the calibration of North laser Lightwave series 125/126 set point temperature

When Craig and I looked and mapping out good beat notes on Friday it wasn't clear that we had enough range to find more that one pair of temperatures that would work.  The two lasers seemed to have vastly different operating set points for a corresponding frequency match and re centering the slow controls BNC inputs to zero seemed to go in the opposite direction to that expect.  

As noted in the previous post summarizing config of the lasers (PSL:1854) South laser was set at +47.0749 C and North laser was set at +26.4650 C.  We were reluctant to tune the North laser much lower than 24 C, lest we risk condensation of water within the head. This meant that once the slow frequency controls voltage was reset back to zero, there was very little range of the North laser temperature settings left to find a BN within.

After checking in the manual, it turns out two things were not what we expected.  Firstly, the slow tuning has opposite sign to the laser temperature: increasing temperature tunes laser frequency down and increasing slow frequency voltage tunes laser frequency up. Secondly the laser set point temperature is a calculated value and note a true value (the screen value LT gives the true value).  It also doesn't include the offset caused by voltage on the front panel Slow frequency BNC.  So for North laser set point temperature of +26.4650 C the true value measured at the crystal is 44.8 C (with zero voltage on slow freq input).  

The discrepancy was probably caused by a poor calibration on setting up the laser head with the controller box.  The setup procedure when configuring a new laser head is to center the temperature setting in the middle of the range, wait for it to come to equilibrium and then to trigger a recalibration of temperature to this value.  This is done by putting the laser into standby and pressing: Display x2 (will read C +xx.xxxx) -> Set (to recenter real temperature) -> wait for equilibrium -> Set (to recenter the calculated set point temperature). 

It is likely that set was pressed twice in rapid succession and that the calibration was triggered before the laser had time to reach its midpoint temperature.  This hasn't affect operation, but it does mean that the set point looked much lower than it should have been, we might have been worried about selecting temperatures that were too low to safely operate the laser at. 

I have recalibrate the laser 'Center Temperature Calibration' on both lasers (North was too low and south was too high) so that we can have more confidence that the laser ranges are in a safe range.  Calibrated setpoints are now 48.4 ± 15 C for the South laser and 44.8 C ± 15 C for the North laser.

  2088   Mon Feb 12 20:03:53 2018 awade, CraigMiscLab InfrastructureFlipped circuit breaker at around 8 pm

Flipped circuit breaker at around 8 pm.

I looks like we've overloaded the UPS group one circuit.  I was operating a heat gun off some of the table power and flipped the circuit breaker.  

Unfortunately the lasers were running off this circuit. The whole point of the UPS was to avoid the hard shutdowns. We switching the lasers to group 2 on the UPS so that this doesn't happen again.

  2153   Fri Mar 23 18:22:53 2018 CraigDailyProgressBEATFloated vs Landed Table Spectrum

I landed the table today to diagnose our TRANS and REFL power fluctuations and enable easier scattering searches.  (It seems that our TRANS and REFL power fluctuations have ceased, need more time to be sure, but this points to cavity misalignments from slight table motion causing the power fluctuations)

I noticed right away that the spectrum changed, in particular, the scattering shelf extended to even higher frequency.  I made a plot comparing the beatnote from just before landing the table and just after using ~/Git/cit_ctnlab/ctn_labdata/scripts/SeismicAndScatteringStudy.ipynb
Data GPSTimes for Floated Table = 1205884032 to 1205884332
Data GPSTimes for Landed Table = 1205888438 to 1205888738

Attachment 1: CTNLabBeatnoteASD_gpsStart_1205884032.pdf
CTNLabBeatnoteASD_gpsStart_1205884032.pdf
  2024   Thu Dec 21 14:38:17 2017 awadeDailyProgressOtherFloating the table on N2

We recieved a cylinder of gas. The compressor was at the lower end of presure so I decided switch in the new N2 bottle. The used bottle has been moved to the bottle cage in the ATF (QUIL) lab until facilities comes to pick it up.

Initial bottle preasure is 2300 psi.

I've applied 35 psi to the legs.  A presure of 25 psi is about enought to just float the legs, so 35 psi is ample.

Table is back and floating again.

  1798   Tue Jan 3 11:53:39 2017 awadeMiscOtherFlow bench lights are out, need replacing

The PSL lab flow bench fluro lights have died.  Its not obvious how we get to the tubes as the difuser pannel is designed to not be taken out. They may need to be accessed from above or from front.  I will call the company today and see how this is done.

 

Update (Tue Jan 3 16:14:14 2017): called Pure Aire, the lights are replaced from the top.  All the stuff stacked on top will need to be removed and four screws removed to open the top pannel.

  1823   Mon Mar 6 20:49:18 2017 awadeMiscOtherFlow bench lights are out, need replacing

Finally cleared stuff off the top of flow bench.  Need to reorder 2x Phillips F72T12/CW, 56 W.  

These bulbs have a Hg marker, so they may need special disposal for mercury containing waste. 

Quote:

The PSL lab flow bench fluro lights have died.  Its not obvious how we get to the tubes as the difuser pannel is designed to not be taken out. They may need to be accessed from above or from front.  I will call the company today and see how this is done.

 

Update (Tue Jan 3 16:14:14 2017): called Pure Aire, the lights are replaced from the top.  All the stuff stacked on top will need to be removed and four screws removed to open the top pannel.

 

  2332   Tue Apr 30 18:55:06 2019 anchalSummaryElectronics EquipmentFollow up on TTL Trigger generator box

But I used AD620 which is an instrumentation amplifier, not opamp. I thought comparators are made with differential amplifiers (from Horowitz & Hill Sec 4.23) and since AD620 was a nice available instrumentation amplifier, I thought it would work (and it does work).

But this particular circuit that I made seems to be less general than I thought. 100 kOhm potentiometer makes it hard to fine tune the threshold. Also, I think I should have buffered the threshold voltage divider circuit because I see the threshold level changing with the incoming signal when the signal is more than the threshold. It doesn't affect my particular application, but I think that makes this a crappy TTL generator. But since my purpose has been served, I'll push optimizing and generalizing this box to some other day. Maybe my new SMD prototype boards would be handy.

Quote:

not all amps are good for use as a comparator

https://www.analogictips.com/faq-use-op-amp-comparator/

 

  2045   Thu Jan 11 19:15:43 2018 awadeDailyProgressTempCtrlFollow up: Lowing can heater effective resistance

Rewiring and updating channels

I just re configured the heater driver to the configuration C illustrated in the last post. 

When I actually opened up the sub-D15 connector I found the previous configuration was not what I thought it was. The actual wiring was optimally bad, see attached schematic.  The resister network paralleled 38 Ω and 70 Ω heater blocks and then puts those pairs in series.  This meant uneven heating and higher resistance.  

I've rewired to put all heaters in parallel and updated the IOC db file entry for the heater voltage channel to max out at 1.5 V (1.5A at output). We should make a point of putting fuses in the heater driver circuits soon, to prevent a meltdown from mistakes in input voltage: this is now a going concern with the low heater impedance.  And/or implement a zenor diode crimp at the input.

Issue with high current affecting temperature readout

I ramped the drive current all the way up to 1.5 A, this is 27.7 W. This was max 9.7 W max before.  The out-of-loop sensor showed an immediate rise in temperature climbing at 0.16 K/min; the can can get from room temperature to 30 C in 1h20min which is much better than the 4-6 hours before.

However, I noticed when I cycled the current up and down this changed the reported temperature (in the out of loop sensor!). Which is very bad.  The transimpedance temperature sensor box that converts AD590 1µV/K sensor current to voltage runs off the same 24V lines as the heater. However, this voltage is regulated down to 12 V (pretty sure) and should be well bypassed on the board. So I'm not sure what the interaction is here. There should be a wide margin for the sensor board voltage regulators and the AD590 should also be pretty immune to any voltage dip (if there is one).

The temperature sensor board is reporting a full 0.6 degrees below when the heater driver is turned all the way up.  This needs to be debugged pronto in case all our temperature readouts are bogus.

Issue with the PID

Another issue I found was with the PID.  I don't think this is related to the above temperature dip with heater drive current changes.  The PID (settings P = -0.50, I  = 0.00020, D = 0) was actually reducing the current drive to 0.700 A when started from 1.5 A, even 5 K below the set point.  It should slowly wind up to the actuator limit and stay there until the set point is exceeded.  I have two theories:

  1. that the high value of P and the upper current limit have a ratcheting effect: upward movements in current hit an upper bound and the finite difference approximation used by the PID python locker subtracts the previous iteration's value.  This onesidedness effectively creates a negative integration term (in the wrong direction) pulling the process value down; and 
  2. there is an issue with the finite difference approximation of the PID loop itself, due to rounding errors.  We only really need a small integration term to push the temperature to set point.  The chosen value mainly determines how fast the can comes to temperature*. Setting it too high ends up with integrator wind up and oscillating overshoot.  I wonder if implementing a finite difference version of the PID introduces accumulated rounding errors when the P and I terms are very different magnitude.  A different implementation of the loop would keep computation of P, I and D separate until the last step of summing them all together. In that scheme one would only accumulate value on the integration term, avoiding many add subtract operations that may round the last digit off a much smaller integrator compared to other terms.

I turned down the P term and this seemed to solve the problem, but it shouldn't do this in the first place.  I've had a suspicion for a while that adjusting the P value was actually introducing an integration affect (usually in the opposite sign to the integrator term). However, it wasn't this extreme in previous cases.

This python PID script is a direct port of an earlier Perl script used at the 40m.  Its a very Perly way of solving the problem: using a single vector each for the process and error and performing shifting and pop on that vector. A python noob might write a script more like that given on Wikipedia

Changing the script isn't a lot of work, but working out what is wrong and why might be harder.

*it will also effect the bandwidth of the loop I guess.

 

Quote:

For the vacuum can heater, we are limited in the heater driver max power by the positive supply rail voltage and the maximum current permissible through the sense resistor. The 54 Ω of the can heater means that for 0.44 A of drive current, the drop across the heater is 24 V, the maximum voltage available to the circuit.  Thus there is a limit to total heating of 9.77 W, accounting for sense resistor and MOSFET voltage drop.

...For now I will just configure the heaters to all be in parallel (configuration C)...

Attachment 1: HeaterConfigs_badconfig20180111.pdf
HeaterConfigs_badconfig20180111.pdf
  2547   Mon Mar 2 16:48:12 2020 anchalDailyProgressISSFollow-up, porbalem stopped happening, OLTF plot.

The issue isn't visible right now. I'm not sure what changed but with a similar power level, I'm able to increase the gain on North ISS to much higher than before. Currently, I'm taking RIN measurements (still using in-loop detector) to update the noise budget plot which is taking some time as I'm trying to measure the uncertainty in the measurement as well. So, the step response plot would come later.


OLTF

  • Open-loop transfer function of the North ISS loop was measured by exciting at port B in SR560 and using mode A-B.
  • Measurement was taken as Input A / Output which is equivalent to open loop gain divided by the transfer function of SR560.
  • I measured the transfer function of SR560 separately and hence obtained the OLTF.
  • The first measurement is actually product of Actuator TF, Plant and Detector and I have plotted it as well.
  • This plot shows that a pole of 20 kHz is coming through the plant. It can't be detector or actuator as they have very high bandwidths.
  • At the lower end, we couldn't reach to the point where AC coupling sets in. SR560 manual (at page 12) says it is 30 mHz.
  • Lower UGF is roughly 5 Hz, which the gain margin from lower ugf must be more than 20 dB.
  • Since the power level of laser changes somehow  over day, keeping this OLTF is not really fixed and moves up and down. Hopefully, in the present setting, it doesn't hit oscillations.

 


Witness detector?

The beatnote detector SN101's DC output has electronically railed. This might be due to a disconnection inside which may or may not be intentional. I don't think I should meddle around with that detector so close to the result. I will instead replace the other 1611 detector in the blocked port of beam splitter (11,19) with a thorlabs PDA10CS and use that for RIN measurement. But since, the loops were in modd of being stable today, I decided to go ahead and take the measurement with current settings. This will also work as in-loop measurement for comparison later.


Data

Attachment 1: NISS_OLTF.pdf
NISS_OLTF.pdf NISS_OLTF.pdf
  1907   Sat Sep 9 18:20:38 2017 awadeMiscDrawingsFour channel BNC breakout for Acromag front panel and other general use

The BNC keyed holes punched in the front of the Acromag crate (LIGO-D1600135) are all 0.5".  This means that none of the standard insulated panel BNC feed through fit (the in-line types are all 9.7 mm), I seem to only be able to find the 0.5" in the PCB mounted right angle BNC receptacles. Right now all that is holding the current BNCs in from rotating are lock washers and almost INHUMAN TORQUE FORCES.

Johannes had a 4-channel BNC to Sub-D 9 that he had procured from Downs (Old DCC D090415).

However, this part is now obsoleted and they have run out.  I made a quick board layout in Eagle (attached below with all of the Gerbers files).  I added male and female sub d receptacles and included an optional screw terminal breakout.  We often need quick break outs for multiple BNCs and end up making dangly octopus creations.  We might as well have a bunch of properly made breakouts.  

If there are no objections I will order a small batch some time next week.

 

Attachment 3: BNC_Front_Pannel_Connectors.zip
  1915   Wed Sep 13 13:59:04 2017 awadeMiscDrawingsFour channel BNC breakout for Acromag front panel and other general use

I ordered BNC PCB breakout board parts yesterday. Purple.

Expect a 12 day turn around.

Quote:

The BNC keyed holes punched in the front of the Acromag crate (LIGO-D1600135) are all 0.5".  This means that none of the standard insulated panel BNC feed through fit (the in-line types are all 9.7 mm), I seem to only be able to find the 0.5" in the PCB mounted right angle BNC receptacles. Right now all that is holding the current BNCs in from rotating are lock washers and almost INHUMAN TORQUE FORCES.

Johannes had a 4-channel BNC to Sub-D 9 that he had procured from Downs (Old DCC D090415).

However, this part is now obsoleted and they have run out.  I made a quick board layout in Eagle (attached below with all of the Gerbers files).  I added male and female sub d receptacles and included an optional screw terminal breakout.  We often need quick break outs for multiple BNCs and end up making dangly octopus creations.  We might as well have a bunch of properly made breakouts.  

If there are no objections I will order a small batch some time next week.

 

 

  2262   Fri Dec 7 11:26:30 2018 awadeMiscDAQFrame builder back up

Framebuilder has been down for months now.  It looks like I've been able to get it up and going again albeit with the same issues of drifting clock from before.

I restarted the TCS lab framebuild computer (fb4) that is supposed to be recording all our PSL lab channels.  It seems that the daqd process was hung on something. After poking around a bit I found that a large proportion of channels have been renamed, maybe requests to dead channels was overwhelming it.  I used Craig's python channelFramebuilderConfigFileCreator.py script (see PSL:2133) to regenerate all channels into a .ini file used by cds, copied the output to them to /opt/rtcds/caltech/c4/chans/daq/C3CTN.ini and restarted.  

Framebuild is now back and recording all channels (except modecleaner channels) with a UTC time that is 2h 20 m too slow.  Otherwise we are now collecting data that will be useful in assesing goodness of vacuum can temperature control.

To fix the time drift issues we need to get GPS stablized timing waveform into the daq

Todo list:

  • Run 10 MHz backlink from cryo lab to TCS lab
  • Aquire function generator to generate 65kHz (32 KHz?) waveform to feed into framebuilder
  • Electronics hardware to connect into ADC in fb4
  • Configure fb4 to stablize to GPS standard

Someone else needs to do this.  Maybe a secondary project for Gupta.

 

  2396   Tue Aug 20 19:38:36 2019 anchalSummaryComputersFramebuilder re-configured

I updated ctn_scripts\channelFramebuilderConfigFileCreator.py to work with the new format of modbus hosting through docker (and cleaned it a bit). Also, from now on, C3CTN.ini will stay in the ctn_scripts repo to have version control.

I have run this once and followed instructions from CTN:2014 to restart frambuilder daqd process so that all new channels are logged as well.

Quote:

I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.

  1   Thu Nov 5 07:07:40 2009 ranaMiscRC noiseFrank's pictures in other log

http://nodus.ligo.caltech.edu:8080/AdhikariLab/423

  1364   Thu Oct 10 16:59:59 2013 ChloeDailyProgressECDLFree Running Noise Experiment

 Today, I met with Tara and discussed the delay line, which will be used to tune the wavelength of the bare laser diode and measure the free running noise of the ECDL. I will write up notes of what we talked about and how the delay line will work and post these soon, along with a list of items I will need. 

Collecting materials for delay line: I will be using an RF photodiode and the series of lenses from the Gyro setup, which Evan is not using right now. I'm in the process of disassembling and reassembling this setup on the table that I'm using. Evan said the mode matching was already messed up, so I will be working on focusing the beam. I will be using NPRO light from the CTN lab via a fiber cable. 

Tara helped me modify the piece I found last time, which goes under the collimating lens mount to fix the optical height. I learned how to tap a hole in the metal. I moved the ECDL setup and got the current driver back up and running, and was able to focus the beam using the collimating lens we purchased. The setup so far is attached. 

Photo_on_10-10-13_at_4.49_PM.jpg

Tara and I decided on a modification to make to the grating mount which will allow for us to make vertical tilt adjustments (we will have 2 holes with adjustment screws, not one). I am going to draw this in Solidworks so that I can get it machined tomorrow at the Caltech machine shop. 

  1366   Mon Oct 14 17:38:10 2013 ChloeDailyProgressECDLFree Running Noise Experiment

 

I got the modified grating design into the Caltech machine shop; this part should be done by tomorrow. We decided to use 2 vertically placed 1/4-80 holes which will have adjustment screws. This will allow for tilt adjustment. 

I found a mixer and a splitter in the CTN lab plus the appropriate adapters to use. I'm still working out how the cable length difference will affect the sensitivity of our measurement. 

I have the PD removed from the Gyro table along with the lenses that were used to focus the beam to go into the PD. This was more difficult than I expected to remove these pieces since I'm short and didn't want to disturb the other setup. We are still need several things:

  • Tara helped me find a power supply I can use for the PD
  • stable laser light from fiber optic from CTN lab: Tara said the laser in the CTN lab is working but I need to work out the mode matching. I will read up on this/Erica's old elog posts. 

I'll go pick up the modified grating mount from the Caltech machine shop tomorrow so that I can wash it tomorrow afternoon (I don't have much time tomorrow) and do more on Wednesday. 

  1371   Wed Oct 23 15:16:25 2013 ChloeDailyProgressECDLFree Running Noise Experiment

 

Note: last week I picked up the modified diffraction grating mount. I forgot to bring it in today but I'll put it back in the ATF lab on Thursday. 

I've spent the last week reading a few papers Tara sent me about mode matching/old elog entries by various people. I couldn't find Tara around the lab today, so I'll try and talk to him this week to figure out exactly what I'm doing. I'm still a bit confused about how to do the setup, although I've been starting to sketch what I'm planning on doing. I'm also messing around with a few mode matching programs to help me plan my setup. 

I sent up the power supply for the PD and confirmed it works. I'm going to try to talk to Tara tomorrow or Friday so I know what I need to do in the next week. My midterms are starting so I may have a hard time being around the lab much until afterwards. 

  1304   Fri Aug 16 19:43:01 2013 ChloeDailyProgressECDLFree Running Noise of Bare Laser Diode

 Today Tara and I worked on getting a noise measurement for the bare laser diode using a Michelson interferometer with different arm lengths. The setup is attached. However, at a differential arm length of 20 cm we were unable to see interference because it was too difficult to focus the beams. Tara suggested I use a symmetric Michelson interferometer to see if I can get interference, since the noise levels might be too high for such a large arm length. I then tried much smaller differential arm lengths and I was able to get interference at 1 cm and 5 cm.

I took background measurements of the noise from the SR785 (about 20 nV/rtHz) and from the blocked photodiode (electrical noise, about 50 nV/rtHz). Since these were both small, we can be confident that the measurements we took are mostly the noise from the frequency of the laser diode. 

The results from the 1 cm and 5 cm measurements are attached. We seem to have noise levels close to what we predicted (1 MHz/rtHz), which seems odd since there will be extra noise from mechanical components, temperature fluctuations, and a worse current driver than we planned to use. In addition, this doesn't explain why we weren't able to get interference at a differential arm length of 20 cm. The 5 cm measurements have even lower noise levels for some reason. I'm not sure if I'm doing something wrong with factoring in the gain, so I'm going to check my math. Gain still confuses me a little since there's a different gain on each machine I used. Overall, the measurements seem suspiciously low noise. 

I'm going to check these calculations again this weekend to make sure I didn't mess up. I will also revise my presentation so that I will be ready to present on the LLO SURF field trip. 

Attachment 1: michelsonsetup.jpg
michelsonsetup.jpg
Attachment 2: 1cm_and_5cm.png
1cm_and_5cm.png
  2487   Wed Dec 4 18:11:09 2019 anchalDailyProgressFSSFree running laser frequency noise spectrum

I took a spectrum of PMC error signal when the FSS loop is not closed. This should provide a rough estimate of the free running laser noise. We had earlier seen a peak at 435 kHz in the Northside, hence I wanted to take this data with some references. First of all, this peak is very similar in the description of relaxation-oscillation peaks of these NPRO lasers mentioned on page 52 of this manual. The "Noise Eater (NE)" is supposed to suppress this peak significantly. However, in the spectrum of the PMC error signal, there is no difference when noise eater was ON or OFF.

I took a spectrum of Southside as well, just to see if I could see action of Noise eater there. For south laser, the noise eater suppressed noise only till 100 kHz or so and probably this side also has a similar relaxation-oscillation peak problem but is shadowed by a large feature at 30 kHz. Not, the absolute value of the spectrum between North and south are vastly different due to different amount of light, different transimpedances od the PDs and different gain values in the feedback circuit.


However, the noise eater is supposed to reduce relative intensity noise only. And the error signals of PMC should really be telling us noise in the frequency of the laser. So maybe I'm connecting two dots in different Hilbert spaces. But Rana suggested that a busted Noise Eater could be the reason for the 435 kHz peak, I just do not understand how RIN would cause frequency noise so badly. I thought photothermal transfer functions from RIN to frequency noise were very small.

Attachment 1: PMCErrorSignals.pdf
PMCErrorSignals.pdf PMCErrorSignals.pdf
  2488   Thu Dec 5 18:25:11 2019 ranaDailyProgressFSSFree running laser frequency noise spectrum

when the NPRO crystal is oscillatin

          no tellin what is relaxin

  2124   Wed Mar 7 21:07:10 2018 Craig, awade, Johannes, Gautam, oh myDailyProgressDAQFrequency Counter added as Precav Beatnote Monitor

Last night we had an issue where my PLL autolocker lost the lock at some point during the night.  The PLL autolocker (located on acromag1 at ~/Git/labutils/netgpibdata/Marconi2023A_BeatnoteTrack.py) relies on the linearity of the mixing of the Marconi signal and the beatnote, and most of the time this is okay.  However, sometimes FSS ringing and fast temperature slewing can cause the beatnote to move in frequency too fast for the Marconi to keep up, causing the autolocker to fail.
What's worse, sometimes the autolocker fails to realize it has failed, since the mixer error signal goes to zero as the frequencies of the local oscillator and beatnote diverge.  The autolocker sits there thinking it's doing a great job locking the Marconi to the beatnote when it fact it's doing NOTHING.
What's EVEN worse, we use the PLL autolocker calculated beatnote frequency soft channel as the error signal for our North Cavity Shield Temperature PID.  If the PLL autolocker fails, the error signal it sends to the NCST PID is completely wrong, causing the North cavity shield heater to actuate as hard as it can to control the beatnote frequency, but it can't because the PLL autolocker is constantly lying to it.

In order to counter this issue, we scrounged up a frequency counter for use as the error signal for the North Cavity Shield Temp PID.
Gautam gave us a spare 40m UFC-6000 frequency counter.
Johannes kindly lent us his script ufc.py and associated service ufc.service, as well as some instructions for communicating with the frequency counter which I will go over.  What Johannes sent me is attached as ufc-6000.tar.gz.
awade modified the python script ufc.py to be a bit more pythonic, which is attached as ufc2.py, and increased the precav beatnote signal strength so the frequency counter could detect the beatnote.
I made the dang thing work with ws1.


Johannes sent some instructions to allow USB devices to communicate with python directly.  Apparently USBs are often restricted from talking with the rest of the computer directly unless you define some udev rules to allow some specifically identified USB devices through.
To do this, I went to the directory /etc/udev/rules.d/, and created a file 99-usb-serial.rules.  Inside this file I typed:
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="20ce", ATTR{idProduct}=="0010", MODE="0666", GROUP="plugdev"
Then, when I ran python ufc.py, I was able to retrieve the UFC-6000's reported frequency on ws1.

Some commands that were useful for figuring all of this out:
lsusb, which tells you about your usb devices connected to your computer
man udev, which tells you everything you need to know about udev on your particular Linux machine, and how to configure the .rules files.
lsusb -v -d ????x???? (where ????x???? represents the idVendor and idProduct attributes of your USB device), which tells you even more about a single USB device.
groups, which tells you what groups your username is a member of.  Not sure what a group is though.  controls was a member of plugdev, I guess this is enough.


Next steps, create a soft channel for the precav beatnote, and switch out the North Cavity Shield Temp PID error signal in the .ini file.
Also, I can modify the PLL Autolocker Marconi2023A_BeatnoteTrack.py to read in the beatnote soft channel value first to get the PLL into the linear region, then start it's locking process.  It can also use the new soft channel as a constant check to see if the Marconi has gone completely haywire.  Finally, the PLL Autolocker must have ANDChannels added to it to make sure that both North and South RAMP_EN channels are true.


EDIT: Added soft channel C3:PSL-PRECAV_BEATNOTE_FREQ which is monitoring the frequency counter in real time.

Attachment 2: ufc-6000.tar.gz
Attachment 3: ufc2.tar
  469   Thu Feb 3 14:25:18 2011 FrankSummaryBEATFrequency counter time series

2 stretches of data taken at the following UTC times:

11/2/2 23:18:19  duration: ~9min

11/2/2 23:22:50  duration: ~9min

units for data: volts  SCALE: 10kHz/V

 

Here a screenshot for the first stretch from dataviewer:

frequcount_timeseries2.png

 here the data: freqcounter_timeseries.dat

 we didn't take longer timeseries with more range as the resolution is so bad that it couldn't be used to extract a spectrum down to mHz .

RAW data can be accessed via 131.215.114.84:8088 or SSH-login and doing the usual.
Channel name is C3:PSL-FSS_FREQCOUNTER

 

 

  1128   Mon Mar 25 22:56:42 2013 EvanDailyProgressElectronics EquipmentFrequency readout noise of PDH loop

Today I tuned the mode matching into the south cavity by adjusting the two lens translation stages. The 64.4-mm ROC lens is at 15.63 mm, and the 38.6-mm ROC lens is at 4.01 mm. We currently have 80% visibility (see first attachment). One of the lenses is at the end of the range of its stage, so we will have to work to reposition it and continue mode matching.

Tara was able to tame the cavity servo loop. The third attachment is the result of several SR785 measurements of the error signal power spectrum. I converted this to a frequency noise power spectrum (fourth attachment) by extracting the voltage/frequency calibration factor from the error signal as follows.

I smoothed the PDH error signal by convolving with a gaussian and then numerically differentiated (second attachment). The locations of the carrier and the sidebands can then be read off, along with the magnitude of the derivative at zero cavity offset. Sidebands are at −14.5 ms and +14.7 ms, and the carrier is at 0.2 ms. Since the sidebands are 14.75 MHz from the carrier, this gives the time-voltage calibration as 1.01 GHz/s. The zero crossing of the carrier has derivative 16600 V/s, and hence the PDH slope is 61 kHz/V.

Attachment 1: res_and_pdh.pdf
res_and_pdh.pdf
Attachment 2: errsig_smooth_derivative.pdf
errsig_smooth_derivative.pdf
Attachment 3: errsig_voltage_noise.pdf
errsig_voltage_noise.pdf
Attachment 4: errsig_freq_noise.pdf
errsig_freq_noise.pdf
  1129   Tue Mar 26 10:00:19 2013 EvanDailyProgressElectronics EquipmentFrequency readout noise of PDH loop

Quote:

Today I tuned the mode matching into the south cavity by adjusting the two lens translation stages. The 64.4-mm ROC lens is at 15.63 mm, and the 38.6-mm ROC lens is at 4.01 mm. We currently have 80% visibility (see first attachment). One of the lenses is at the end of the range of its stage, so we will have to work to reposition it and continue mode matching.

Tara was able to tame the cavity servo loop. The third attachment is the result of several SR785 measurements of the error signal power spectrum. I converted this to a frequency noise power spectrum (fourth attachment) by extracting the voltage/frequency calibration factor from the error signal as follows.

I smoothed the PDH error signal by convolving with a gaussian and then numerically differentiated (second attachment). The locations of the carrier and the sidebands can then be read off, along with the magnitude of the derivative at zero cavity offset. Sidebands are at −14.5 ms and +14.7 ms, and the carrier is at 0.2 ms. Since the sidebands are 14.75 MHz from the carrier, this gives the time-voltage calibration as 1.01 GHz/s. The zero crossing of the carrier has derivative 16600 V/s, and hence the PDH slope is 61 kHz/V.

 I dialed the 38.6-mm ROC lens back to 1.11 m, twiddled the periscope mirrors, and got only marginal improvement in the visibility.

  1132   Thu Mar 28 12:36:27 2013 ZachDailyProgressElectronics EquipmentFrequency readout noise of PDH loop

Is this really the input noise of the PDH servo (i.e., output noise / servo TF)? If so, it seems pretty high. With the right components, you should to be able to do ~100x better.

Quote:

Tara was able to tame the cavity servo loop. The third attachment is the result of several SR785 measurements of the error signal power spectrum. I converted this to a frequency noise power spectrum (fourth attachment) by extracting the voltage/frequency calibration factor from the error signal as follows.

 

  1133   Sat Mar 30 01:42:16 2013 taraDailyProgressElectronics EquipmentFrequency readout noise of PDH loop

It is indeed really high. We expect something in the order of ten nV/rtHz level (like what we had before, see PSL:781.). We are investigating it.

One of the possible causes is the back reflected beam. When I reduced the power input from 6mW to 1mW (with common/fast gain = 999/720, boost on), the error noise was down to ~ 10nV/rtHz up to 5 kHz, with bumps and peaks around 50kHz up to 100kHz. Our mode matching this time is not very good.

 I replaced the PBS for PDH locking to a bigger one, since the beam spot at that position was quite large. This got rid off some high frequency peaks and bumps. I still have to align the beam to minimize back reflection.

 

Quote:

Is this really the input noise of the PDH servo (i.e., output noise / servo TF)? If so, it seems pretty high. With the right components, you should to be able to do ~100x better.

Quote:

Tara was able to tame the cavity servo loop. The third attachment is the result of several SR785 measurements of the error signal power spectrum. I converted this to a frequency noise power spectrum (fourth attachment) by extracting the voltage/frequency calibration factor from the error signal as follows.

 

 

  1906   Fri Sep 8 23:54:18 2017 awadeDailyProgressFSSFront and rear panels for FSS computer controls

I've made up some panels for a new 1U chassis to house the acromag controls of the two TTFSS boxes.  It makes sense to mount them in a separate 1U chassis. The D25 connectors into the FSS interface boxes have enough binary engage and analog channels to take up all the inputs and outputs of an XT1221 and an XT1541 card. The whole experiment needs to be taken down while someone modifies the main crate, this way we modularize it a bit.

This will neatly package all the computer controls together with the two rack interface boxes and remove some of the clutter from the front panel.  The package will take standard 24 V plug, along with a panel mounted Ethernet and a pair of  Sub D 25s. I've also included some standard 9.7 mm D holes (NOT THE 0.5", PCB STYLE) for general purpose slow monitor channels for the autolocker. These are optionally on the back or front.  

The panels are the only part we need. Everything else is in stock.

---

Aidan had a good way of mounting the Acromags in the standard 1U boxes.  He put a DIN rail vertically, bolted into the sides. From there we can just manually wire everything up.  

We will also need a 5 V source to excite the binary channels. It doesn't need to be clean, its driving a binary comparator.  An LM7805 would maybe work off the 24 V line. There is a 24 mA of current which means 123 mW of power dissipation.  These TSR-1 DC/DC converters look cool, but not sure I want to introduce something with a switching frequency of 500 kHz anywhere near our electronics. 

Attachment 1: D1700425-v1_TTFSS_2ChannelController_rearpanel.pdf
D1700425-v1_TTFSS_2ChannelController_rearpanel.pdf
Attachment 2: D1700425-v1_TTFSS_2ChannelController_frontpanel.pdf
D1700425-v1_TTFSS_2ChannelController_frontpanel.pdf
Attachment 3: TTFSS_digitalcontrols1ubox.zip
Attachment 4: 2017-09-08_23.32.36.jpg
2017-09-08_23.32.36.jpg
Attachment 5: 2017-09-08_23.32.32.jpg
2017-09-08_23.32.32.jpg
  1914   Wed Sep 13 13:55:39 2017 awadeDailyProgressFSSFront and rear panels for FSS computer controls

I ordered FSS controler box front and back panels yesterday.

Can build as soon as they arive.

  2531   Thu Feb 13 15:27:18 2020 anchalDailyProgressBEATFurther iterated back and forth to optimized FSS Gains.

I took beatnote measurements and spanned gain values in the PMC to see if stability issues in PMC loops can be affecting the FSS downstream.


Method

  • I used BNspec.py with default settings (10 kHz bandwidth at 15.625 kSa/s for 60s) while spanning the parameter space of PMC gains.
  • The beatnote frequency was robustly within 2 kHz of 27.34 MHz during this whole measurement.
  • The overall experiment was run by spanParamSpace.py script.
  • First I spanned North gains using the last optimum values found for South Side and tried to span the area towards which we found minima earlier.
  • Next, I used the new minima found for North side and spanned region in South side.
  • This time, I used sum of the ASD of beatnote frequency between 300 to 600 Hz to determine improvement in noise overall.
  • Still, I would say, the improvement is hardly more than 5% over large areas of parameter space, meaning mostly BN noise is independent of these gains.

Final result

  North South
COM Gain (dB) 12 22
FAST Gain (dB) 10 17

Data

 

Attachment 1: FSS_Gain_Span.pdf
FSS_Gain_Span.pdf FSS_Gain_Span.pdf
  1576   Tue Aug 25 19:12:36 2015 Antonio, EricDailyProgressComputersGPIB installed

Today Eric provided his Python scripts (and installed them) needed to connect the SR785 and the AG4395A devices with our lab computer through the GPIB interface. With these scripts we are able to download measurement data that we take by using the two above mentioned devices, plot them and set the measurement settings directly from the computer. Mainly we need to use two of them, i.e. with following commands:

1. AGmeasure: AGmeasure --getdata -i 10.0.0.13

2. SRmeasure: SRmeasure --getdata -i 10.0.0.13

These scripts can run from any folders on the computer. These and some other features will be explained in the TCN wiki page, which I am going to write soon.

We now need to make the lab computer accessible from other computers. The SSH protocol is iinstalled, but the modem need to be configured. Less attaractive but a possible option is to have a svn folder on the lab machine.

 

  1318   Wed Aug 28 21:21:38 2013 taraNotesopticGWINC for TO calculation: recap

Here is a summary for how I verify the codes for TO calculation.

So far, we have been using a set of modified GWINC codes to calculate TO noise, but I have not mentioned how did I make sure that the codes were reliable. So I'll try to explain how I check the codes here.

==What do we compute?==

  For the TO nosie calculation and the optimization, we are interested in:

  • effective dn/dT (TR coefficient) of the coatings
  • effective alpha (TE coefficient) of the coatings
  • total reflectivity of the coatings (including the phase), and transmissivity

==Beta calculation check==

For TR coefficient we can compare GWINC with an analytical result (see Gorodetsky,2008, and Evans 2008) (when # of layers ~ 50 or more), see psl:1181. I tried the solution with nH, 1/4 cap and nL, 1/4 and 1/2 cap. All results agree.

==Alpha calculation check==

 There is no complication in this calculation. The effective alpha is just the sum of all layers. This calculation is quite straight forward.

==reflectivity check==

   This was done by reducing the coating layers to one or two layers and comparing with an analytical solution by hand. I checked this and the results agreed.

 

So I think the calculations for TO noise is valid, the noise estimated from the optimized coatings is done with some error check (previous entry). I think we should be ready to order.

  1582   Sun Sep 13 13:56:04 2015 AntonioDailyProgressElectronics EquipmentGain Knobs calibration on the North side

Summary

========

In order to have a better understanding of the gain associated to the Knobs on the interface PDH box, I took some measurements from TestInput to Out1Fast on the FSS field box

at different gain values for the common and fast knobs and measured the gain of the transfer function at DC. From fitting dB vs Knob counts

we get:

 

North:

Common Knobs dB/100Counts = 2.35dB

Fast Knob: dB/100Counts = 2.49dB

 

I took more measurements than I needed of course, I did it to check while I was taking measurement that some unwanted electronic effect was happening.

 

Data

Data are on the lab control/home/data/20150831_Knobs_calibration/

 

Attachment 1: CommonKnob.pdf
CommonKnob.pdf
Attachment 2: CommonKnob.pdf
CommonKnob.pdf
Attachment 3: FastKnob.pdf
FastKnob.pdf
  2005   Sat Dec 9 20:24:19 2017 awadeMiscPurchasesGas orders

I've ordered a refill for the N2 gas cylinder.   I got the slightly better stuff so we also have the option to use it for venting at a later date. Airgas part number NI UHP200 (Ultlra High Purity 5.0 Grade Nitrogen, Size 200 Cylinder, CGA-580)

For future reference the LIGO use recommendations and order instructions can be found at: https://dcc.ligo.org/LIGO-T1600478

 

  1634   Mon May 30 14:27:48 2016 AidanSummarySafetyGave Andrew Wade a safety walkthrough

I showed Andrew Wade the CTN lab and gave him a safety walkthrough. We also went over the safe operating procedure for turning on the laser.

  1866   Thu Aug 17 16:43:35 2017 awadeHowToComputersGenerating public-private keypairs for ssh sessions

Criag didn't have this configured for gitlab/github or any other computers. Having a public/private ssh key-pair is usefull for accessing machines and services securly without needing a password, plaintext or otherwise.  Here is a recipe for generating a public-private keypair that can be used with gitlab, github etc.  The public key is pasted into the remote service (aka github) and forms the basis for a good secure communication and simplifies pulling and pushing.


TL;DR

cd ~/.ssh/
ssh-keygen -t rsa -b 4096 -C “label”

Where label = is some label to help you remember what service/computer it corresponds to. I use the format "usr:service" or “email@address” to identify which git or computer I’m keypaired with.

When prompted give name “id_rsa_namehere" and password.  Then copy the public part of the key to your clipboard

pbcopy <~/.ssh/id_rsa_namehere.pub
(case using linux)
xclip ~/.ssh/id_rsa_namehere.pub

Pastes clipboard to remote service, i.e. github, gitlab, other computer etc. (You can find a place to paste ssh keys in the settings/security tab of these services)

Now Add private key (the non .pub file) to local Mac keychain

ssh-add -K id_rsa_namehere

Finally test to see if it works with an ssh test

ssh -T git@github.com (or other user@website relevant combination)

 

Detailed instructions/explanation:

Generating a key pair:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com”

-C flag stands for comment, can be used to label what the ssh key is used for. Best to use an email or somthing you will remember.

If you hit enter you get a default name. But is best to give a unique name. Once you have a few different keys it can be  hard to tell what is what. Choose something like ‘id_rsa_github' if it is used for github etc.  File will be saved to .ssh/id_rsa* which is where you want it. [Here an below * indicates wildcard if you have changed the name]

It will also ask for a password, this is a good idea.


You need to add the key to the active ssh-agent service (change id_rsa if you named it something different). To add to your mac’s keychain (so that it can be loaded automatically on terminal session start) do the following:

ssh-add -K ~/.ssh/id_rsa*

where id_rsa*  is the name you gave your key file (note: this is the private part of the key-pair, do not store this in any public location. If you find it any publicly location, purge it and start again)

Add the following to your .bash_profile or .bashrc config files located at ~

cd ~
ssh-add -A

You may need system/user password

Now when you start terminal it will load all the key’s you’ve added.  If keychain is not open it will prompt for your keychain passwords.

IMPORTANT:

There will be two files generated from ssh-keygen, your private key id_rsa* and your public key id_rsa*.pub.  Make sure you only give the public key to the remote machine/service. If you accidentally reveal through ANY plaintext communication then burn it and run ssh-keygen to make a new one.

Setting up remote git/computer:

Copy the public key to clipboard:

pbcopy < ~/.ssh/id_rsa*.pub

and paste to remote computer/website.

Then test it using something like

ssh -T git@github.com

replace server username and address with whatever you are adding your ssh key to

Note: purge clipboard if it stores a history.

You now have a public/private key pair for secure communications.  Use it for github or ssh into machines that you use very frequently.  It is as secure as your local machine.

Some other things

To see what saved keys you have try

ssh-add -l

To delete all cached keys

ssh-add -D

 

  1886   Tue Aug 29 22:44:11 2017 CraigHowToComputersGenerating public-private keypairs for ssh sessions

This was great... thanks a lot "Andrew".

These directions work ONLY if you register your ssh key with your github.com account and not your git.ligo.org account.  You'll have to generate TWO ssh keys on a single compypyie, and put one key on your github.com account and another on your git.ligo.org account. 

I have done this for my git accounts on acromag1 and 2, so now we can git clone via ssh from both git.ligo.org and github.com.  V convenient.

  2112   Wed Feb 28 18:58:01 2018 CraigHowToComputersGetting CTN lab data from framebuilder using python nds2

Jaime and John R have done some work enabling NDS on our framebuilder in the subbasement, fb4.  I have figured out how to get data from fb4 to our CTN lab computer ws3, using python nds2.

1) Log into ws3 from your local machine: $ ssh -Y controls@131.215.115.216 -p 2022

2) Run ipython on ws3: $ ipython

3) Enter the following code into the ipython session:

In [1]: import nds2
In [2]: c = nds2.connection('10.0.1.156', 8088)  # 10.0.1.156 is the fb4 local ip address.  8088 is the fb4 NDS broadcast port number.
In [3]: gpstime = 1201902464  # using old data from Feb 5th, because our lab has been out of commission for a couple of days.
In [4]: chanName = 'C3:PSL-SCAV_FSS_SLOWOUT'  # retrieve the SCAV slow laser control
In [5]: from pylab import *
In [6]: ion()
In [7]: data = c.fetch(gpstime, gpstime+50000, [chanName])
In [8]: plot(data[0].data)

A plot should appear on your computer.  It should be the same as the plot posted below.  It should take about 10 seconds to appear.

Quote:

Steps to getting data from our framebuilder, since many of the steps are pretty hard to remember.  These steps were performed on a Macbook running OSX Sierra 10.12.5.  Dataviewer was opened locally using XQuartz.


1) SSH into PSL Lab computer ws3 through the public port 2022:

$ ssh -Y controls@131.215.115.216 -p 2022   (I often alias this on my PC .bashrc as some command: $ alias ws3="ssh -Y controls@131.215.115.216 -p 2022")

2) SSH into framebuilder4 fb4:

$ fb4 ("fb4" is already aliased on ws3 to be the command $ ssh -Y controls@10.0.1.156)

3) Launch dataviewer:

$ dvlaunch ("dvlaunch" is an alias to $ LIGONDSIP=localhost dataviewer.  This tells dataviewer to look locally for frames.)

4) Dataviewer will launch.  Click the "Signal" tab.  Click the "Slow" button.  Channel options "C3" and "C4" should appear.  The PSL Lab is "C3".  Choose what channels you want to plot.

5) Click the "Playback" tab.  Click "Second Trend" because other modes don't work.  Unclick "Min" and "Max".  Select X Axis Time as "GPS".  Choose your start and stop times you want plotted. Finally select your signals.  Click "Start".

Wait a while.  The terminal you ran dvlaunch from should give a progress report.  After all data is retreived a plots page should automatically appear with the channels and plot start/stop times you requested.


If you want to save the data from your plot:

6) Click on the plot you want to save data from.  It will have little black boxes in the corners of the plot when selected.

7) Click the "Data -> Export -> ASCII" tab.  A window called "Grace: Write sets" should open.

8) Click on the option under "Write set(s)", and change the Format from "%.8g" to "%.10g" to get all the digits of the GPS time.  Change Selection to whatever you want to name your datafile.  Click "OK". 

Your data should be saved.  Make sure it is formatted well.

 

Attachment 1: SCAV_SLOWOUT_examplePlot.png
SCAV_SLOWOUT_examplePlot.png
  2040   Thu Jan 11 11:35:36 2018 CraigHowToComputersGetting data from our frame builder from anywhere

Steps to getting data from our framebuilder, since many of the steps are pretty hard to remember.  These steps were performed on a Macbook running OSX Sierra 10.12.5.  Dataviewer was opened locally using XQuartz.


1) SSH into PSL Lab computer ws3 through the public port 2022:

$ ssh -Y controls@131.215.115.216 -p 2022   (I often alias this on my PC .bashrc as some command: $ alias ws3="ssh -Y controls@131.215.115.216 -p 2022")

2) SSH into framebuilder4 fb4:

$ fb4 ("fb4" is already aliased on ws3 to be the command $ ssh -Y controls@10.0.1.156)

3) Launch dataviewer:

$ dvlaunch ("dvlaunch" is an alias to $ LIGONDSIP=localhost dataviewer.  This tells dataviewer to look locally for frames.)

4) Dataviewer will launch.  Click the "Signal" tab.  Click the "Slow" button.  Channel options "C3" and "C4" should appear.  The PSL Lab is "C3".  Choose what channels you want to plot.

5) Click the "Playback" tab.  Click "Second Trend" because other modes don't work.  Unclick "Min" and "Max".  Select X Axis Time as "GPS".  Choose your start and stop times you want plotted. Finally select your signals.  Click "Start".

Wait a while.  The terminal you ran dvlaunch from should give a progress report.  After all data is retreived a plots page should automatically appear with the channels and plot start/stop times you requested.


If you want to save the data from your plot:

6) Click on the plot you want to save data from.  It will have little black boxes in the corners of the plot when selected.

7) Click the "Data -> Export -> ASCII" tab.  A window called "Grace: Write sets" should open.

8) Click on the option under "Write set(s)", and change the Format from "%.8g" to "%.10g" to get all the digits of the GPS time.  Change Selection to whatever you want to name your datafile.  Click "OK". 

Your data should be saved.  Make sure it is formatted well.

  1993   Wed Nov 29 19:46:48 2017 CraigNotesNoiseBudgetGithub Pages to view the latest noisebudget with no sign-in

I made a github page to host our the latest CTN noisebudget: https://ccahilla.github.io/noise.html.

 

  708   Mon Oct 17 20:26:57 2011 taraDailyProgressFSSGround Loop, RFPD

Today I verified that fss is not gain limited. I also tried to fix the ground loop problem in fss by replacing the power supply, but it did not work.

 

 ==FSS gain limit==

     From psl:706 I mentioned that I did not check the in loop noise level vs gain. So I checked it again.The in-loop noise (MIXER OUT signal when the RCAV is locked) does not change at all when the gain reaches 25 or more. There's a change as the gain was increased from 20 to 25.  This means the noise is probably from the detection point. Modifying/changing RFPD will be the next thing on the list.

 ==Ground Loop==

   From psl:700, I noted that the ground loop might come from the power supply which had ground output same to protective ground. I found a power supply which has float ground and replaced it with the current one. Then I measured MIXER OUT(in loop noise) when the cavity was locked. 

 The results:

  1.  In loop noise look similar from either power supplies I use.  Odd harmonics (3f, 5f, ...) are still present.
  2. There are no even harmonics(2f,4f,...) in rcav loop. I found it to be from acav loop.

 

==beat PD noise level==

 I just realized that I have not checked and thoroughly understood the noise level of the beat PD and how it shows up in the beat noise. This will be the next thing to do as well.

  1419   Mon Mar 31 17:44:52 2014 EvanDailyProgressfiber opticGyro fiber pickoff now on north cavity transmission

I removed the 90% reflector from the north transmission path on the ISS breadboard and then installed the fiber launcher.

The ThorLabs power meter says 440 uW going into the fiber on the CTN side; the ThorLabs fiber power meter says 260 uW coming out on the ATF side.

  2589   Tue Sep 15 15:13:44 2020 AnchalNotesEnvironmentHEPA filters switched on. Measurement stopped.

I have switched on HEPA filters to high, both on top of the main table and on top of the flow bench.


Continuous measurement is stopped hereby. This experiment is finished.

  1157   Tue Apr 23 18:43:39 2013 taraDailyProgressRefCavHOM for new sideband frequencies

35.5 MHz and 38MHz sideband frequencies are chosen for  1.45 " refcav. These frequencies will be suitable for cavities formed by 0.5/0.5m RoC mirrors and 1.0/1.0m RoC mirrors.

 

HOM35.5MHz0.5m.png                           HOM38MHz0.5m.png

  a) For0.5m/0.5m RoC mirrors 1.45" cavity, f1 = 35.5MHz.           b) For0.5m/0.5m RoC mirrors 1.45" cavity, f2 = 38MHz

HOM35.5MHz1m.png                                HOM38MHz1m.png

 c) For 1m/1m RoC mirrors 1.45" cavity, f1 = 35.5MHz                d) For 1m/1m RoC mirrors 1.45" cavity, f2 = 38MHz

 

Since we will use a crystal oscillator to drive the EOMs, I have to check how much power we need for the sideband.

If the crystal oscillator can provide us with enough power, we can use the crystal to drive a broadband EOM directly. Otherwise we will need an EOM driver, or a resonant EOM.

 

==shot noise level vs mod index(Beta)==

shot_vs_beta.png

To see how much should the mod index be, I plot shot noise level vs Beta, with Power intpu = 1mW and 2 mW, and Finesse = 1e5 (for  T=300 ppm mirrors)and 2e5 (For AlAs/GaAs coatings), with mode match = 80%. It seems that for the lowest shot noise level, we need beta = 0.8.

For resonant EOM, mod depth = 0.2 rad/V, for BB EOM, mode depth = 15mrad/V , see psl:745.  These correspond to 4V (25dBm) and 53 V (47dBm) for the resonant and BB EOMs, respectively.

 

  106   Tue Apr 13 15:06:35 2010 Tara ChalermsongsakLaserRefCavHOM, from carrier and both sidebands

HOM frequency shift for RefCav is plotted below. The second one has clearer dots.

Y axis is the frequency shift in MHz

X axis is the (n+m)th order of the Hermite Gauss mode

The waist of the beam inside the cavity is 261 um* (symmetric cavity, R =0.5m, L = 0.2032 m.) 
Thus, the frequency shift between n+m+1 and n+m mode is 219.763 MHz. (see Lasers, p 762 for details)

Blue line represents the 0th order of the carrier's frequency (thus =0) The purple and the brown lines, at y= 35.5 and -35.5 MHz, are the 0th of + and - sidebands respectively.

The color dots represent the frequency shift from Higher order mode which is specified on x-axis, blue for HOM from the carrier's frequency, purple and brown for HOM from +/- sidebands.

 Choosing 35.5 sideband seems to be ok, the 27th order should be small and negligible. 

 

*The number 237 um for waist size is the effective beam waist size of the "emerging beam," not the real waist size in the cavity. The beam passes through the mirror which acts as a negative thin lens and changes the

beam parameter. 

Attachment 1: HOM_df_219.32MHz_02.png
HOM_df_219.32MHz_02.png
Attachment 2: HOM_df_219.32MHz_03.png
HOM_df_219.32MHz_03.png
  604   Thu May 19 23:16:44 2011 Tara ChalermsongsakNotesRefCavHOM, from carrier and both sidebands

 I made a plot for HOM from 24.5 MHz sidebands.  The 17th and 20th order are quite close to the main frequency and its sidebands.

      We were thinking about using 24.5 MHz sidebands, but it seems that 35.5 MHz is safer for the current setup.

 

 RA: plot deleted - put some details into the ELOG to explain your plots to prevent deletion.

 


HOM frequency shift for RefCav is plotted below.

Y axis is the frequency shift due to Gouy phase in MHz.

X axis is the (n+m)th order of the Hermite Gauss mode

The waist of the beam inside the cavity is 261 um* (symmetric cavity, R =0.5m, L = 0.2032 m.) 
Thus, the frequency shift between n+m+1 and n+m mode is 219.763 MHz. (see Lasers, p 762 for details)

Blue line represents the 0th order of the carrier's frequency (thus y axis =0) The purple and the brown lines, at y= 24.5 and -24.5 MHz, are the 0th of + and - sidebands respectively.

The color dots represent the frequency shift from Higher order mode which is specified on x-axis, blue for HOM from the carrier's frequency, purple and brown for HOM from +/- sidebands.

Attachment 1: HOM_2011_05_19.png
HOM_2011_05_19.png
  2590   Wed Sep 23 00:21:02 2020 aaronMiscEquipment loanHP 8560E SA to Cryo

I entered CTN just before (Wed Sep 23 00:22:11 2020 ) to borrow a spectrum analyzer, which I took to Cryo. Wore shoe covers, goggles. Sanitized goggles and door after.

ELOG V3.1.3-