40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 280 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  4591   Fri Apr 29 18:24:05 2011 SureshUpdateRF SystemRF system: 1X2 Rack cabling

[Joe, Jamie, Suresh]

We have installed the IDE to SCSI adaptor module into the 1X2 rack and have connected the AA filter outputs to it.

P4290070.JPG

 

We have removed the following cables running between the 1X2 and 1X3 racks.

The long twisted pair ribbon cable which previously carried the ADC signals.

1X2-ASC 6, 1X2-ASC 47, 1X2-ASC 9, 1X2-ASC 8, 1X2-ASC 10, 1X2-ASC 7,

CAB-1X2-LSC 42, CAB 1X2-LSC 56,  CAB 1X2-LSC 41, CAB 1X2-LSC 43

1X3-2 ASC 47

We have also removed the following by mistake.  We will put them back them on Monday

1X2-LSC 21, 1X2-LSC-20.

We have also removed the ASC QPD cables and moved the QPD cards which were present in the middle Eurocate (#2) to the unused Eurocrate at the bottom position (#3).

The binary input cables at the back of the cards require to be supported so that their weight does not pull them out of the sockets at the back of the crates.

Some of the slots where we plan to plug in Demod boards (the 165 MHz boards)  are not currently connected to any binary output on the C1:LSC computer.  We need these binary controls for the fitlter modules on the cards.

When we eventually begin to use the 15PDs as planned, then we will occupy 30 ADC channels (I & Q outputs).  Currently we have just one ADC card installed on the C1:LSC providing 32 ADC channels.  Joe found another 16bit 32 channel ADC card in his stash but we need to get a timing+adaptor board for it. In general we are going to need the third Eurocrate.

A platform for the power supply of the RF Distribution box needs to be built and the power supply needs to be moved into the 1X2 rack rather than sit on top of 1X2 rack.

 

 

 

  4622   Wed May 4 12:07:48 2011 SureshUpdateRF SystemREFL55 installed on the AP table

REFL55 has been installed on the AP table.  REFL11 has been moved to make space for a 50% beam splitter. The reflected beam from this splitter is about 30% of the transmitted beam power.  The reflected beam goes to REFL11 in the current configuration.  The DC levels are 1.2V on REFL 11 and 3.5V on the REFL55.

I redid some of the cabling on the table because the we need to choose the heliax cables such that they end up close to the demod board location.  As per the 1Y2 (LSC) rack layout given here, some of the PD signals have to arrive at the top and others at the bottom of the LSC rack.

Currently the PDs are connected as follows:

 

REFL11 PD --> Heliax (ASDD133) (arriving at the top of LSC rack) --> REFL11 Demod Board 

REFL55 PD --> Heliax (REFL166) (arriving at the top of LSC rack) --> AS55 Demod Board

AS55 PD --> Heliax (AS166) (arriving at the top of the LSC rack) --> not connected.

 

We are waiting for the Minicircuits parts to modify the rest of the demod boards.

 

The heliax cables arriving at the LSC rack are not yet fixed properly.  I hope to get this done with Steve's help today.

 

 

  4628   Wed May 4 15:39:32 2011 SureshUpdateRF SystemRF Source Harmonics


I have measured the RF source harmonics in dBm using the HP 8591E spectrum analyser. There is a small discrepancy (< 1 dBm) in the value of RF power shown by the power meter and the HP8591E. This is probably due to the loss of calibration over time.

Initial problem I faced was that when we try to measure the weak harmonics, many below -50dBm we have to choose a small band as advised by Rana. However due to the large amplitide of the fundamental typically around 15dBm or so, the preamp on the spectrum analyser becomes saturated and nonlinear. This gives rise spurious harmonics not present in the source but are rather an aritifact of measurement. The power in harmonics to avoid this I used filters to selectively attenuate the fundamental component (11 or 55 MHz) and then measure the weak harmonics.

However the filters proved difficult to use, because over their stop-band they do not have an input impedance of 50 Ohm. As a result they produce unreliable power measurements for those frequency components which are within the stop band.

To get around this problem I used a suitable attenuator so that even when the internal attenuation is decreased the preamp does not saturate

All the measurements are recorded in the attached document. Pages 4 and 5 give the reliable measurements with the attenuator.

Notes:
1) At times we can see the 29.5 MHz component reflected back from the triple resonant EOM driver.
2) In the 29.5 MHz source output there is a forest of peaks around 100 MHz, which disappear after passing through the AM stabiliser. This suggests that they are associated with AM modulation and have been removed by the stabilizer. But I did not check this further.










Quote:
You should be able tosd resolve the other harmonics by decreasing the IF BW or RBW on the analyzer. Even though
they're OK, its useful to have the final measurement of all of them in some kinds of physical units (like dBm, but
not dBm/Hz or dB or dBcubits).
  4644   Thu May 5 15:33:37 2011 steveConfigurationRF SystemLSC rack

New right angle PVC front panel with SMA bulkhead connectors are in place. The connections are still lose. It is ready for Suresh to finalise his vision on it.

  4650   Fri May 6 06:36:18 2011 SureshUpdateRF SystemPD DC signals at each port connected

We now have the DC signal from three PDs available in the ADC channels 14,15 and 16.  The signals are from  REFL55, AS55 and POY photodiodes respectively.  As the DC signals on all the other PDs of the same port (REFL, AS and PO)  have the same information we do not need to monitor more than one DC PD at each port.

The LSC PD Interface Card, D990543 - Rev B, can take 4 PDs and provides the DC signals of the PDs on the connector P2 (the lower of the two) on the back plane of the chassis. An adaptor card, D010005-00, plugs into the back plane from the rear of the Eurorack and provides the four DC signals on two-pin lemo sockets.

I have connected the three DC signals from the relevant RF PDs (above) to a DC whitening filter, D990694-B-1 which is associated with the channels 9 to 16 of the ADC card.

The cables are in a bit of a mess right now as some of the PD power supply lines are too short to reach up the the Interface card in the top Eurocart. Steve and I plan to redo some of the cabling later today

 

 


 

  4657   Sat May 7 10:59:11 2011 SureshUpdateRF SystemRF Source filters changed

 

The SLP-50 filters which were on the 55 MHz lines have been replaced with the SBP-60.  Their respective characteristics are given below:

 

at 55MHz Insertion loss (dB) Return Loss (dB)
SLP-50 4.65 1.5
SBP-60 1.36 23

 

SBP-60 has lower insertion loss and higher return loss.  

This may however change the phase of I and Q in the demod boards and they will therefore need to be readjusted.  Currently the output power level of 55 MHz demod is at 2dBm, whereas it ought to be at 6dBm.   I have not yet corrected that.  Once that is completed Kiwamu will adjust the phases.

 I shifted the temperature sensor to a new location.  See the photograph below.  I noticed that the higher temperature is reached on the side where there are two RF Amps.  So it would be better to check the temperature of that  area and make sure that it remains well below 65 deg.  The operating maxium is 65deg C

 

Here is a picture of the new RF source layout.

RF_Source_Schematic.png

And here is a photograph of it

RF_Source.jpg

 

  4670   Mon May 9 17:23:25 2011 SureshUpdateRF SystemRF Cables near LSC Rack

[Steve, Suresh]

We started to clean up the RF cables (heliax and PD interface cables)  at the LSC rack.

We have pulled out all the RF cables from the small hole on the side-board close to floor.  Passing the cables through this hole makes some of the cables much too short for good strain relief.  So we removed the side panel on the vacuum tube side and are going to pass the cables into the rack from there at about waist height.  We now have plenty of cable lengths to tie them off to the rack at several points.

We have traced all the available Heliax cables and have attached blank tags to them.  We have allocated some cables to REFL11, REFL55 and AS55.  These are therefore back in working order.  We have also taken stock of the available PD interface cables.  They do not have consistent names on both ends of the cable and we will identify and label the ends tomorrow.

MC is locked.  The auto-locker works fine.

Handing over the system for night time interferometer work now.  Will continue with the cabling tomorrow.

 

  4675   Tue May 10 01:39:41 2011 SureshUpdateRF SystemRF source troubles

Today after Steve and I finished the RF cabling work for the day, Kiwamu noticed that there were no RF signals to be seen.  The problem was traced to disconnected 11 and 55 MHz Demod lines from the RF source.  But reconnecting them did not restore the signals.  It turned out that one of the Heliax cables had a loose N-type connector at its end and it finally came off while we were tightening it into place.

We replaced the damaged heliax with another (we have two spare running from 1X2 IOO rack to the 1Y2 LSC rack.  The new cable is used to be the LO 33.  It seems to have a 1.5dB loss.  Have to check this again tomorrow.

In the mean time I noticed that the power output of the 55MHz Demod port of the source was less than about -12dB. So I opened the source to take a look and found that all the voltage stabilisers were supplying 15V.  Even those which were supposed to be supplying 24V.  This was traced to a mistake in wiring the external power supply.  The wires had been labeled wrongly and as a result the 18V input line was connected to 28V source and vice versa.

After fixing this problem I reassembled the source checked the power output on all the ports and found everything was functioning as expected.  However after installation once again the unit failed.  The blue light on the power supply was not lighting up when switched on.  Suspecting a power supply problem I opened the unit again and found that a weak solder joint on one of the RF amplifiers had come loose and had overloaded one of the 24V stabilisers.   We, found a spare and replaced it.  The unit has been reassembled and is functioning fine.  The output power levels are

11MHz Demod -- 6dBm

55MHz Demod -- 5.5 dBm

11MHz EOM --   24dBm

55MHz EOM -- 28dBm

The Marconi is serving as the 11MHz source.  The Wenzel 11MHz source is giving 13.3 dBm and is okay.  But it needs to be checked for its performance as it may have been exposed to higher than rated power supply levels.

The 29.5MHz source is giving 7dBm.  It is supposed to be giving 13dBm. 

The Laboratory DC power supplies currently used for both the RF source and Distribution boxes need to be replaced with rack mounted Sorensen power supplies available in the lab.

 

  4698   Thu May 12 02:31:07 2011 SureshUpdateRF Systeminstallation of RF splitters in Demod boards

[Jamie, Koji, Suresh]

We replaced splitters in several demod boards as per the table given below:

 

Demod boards in which splitter has been replaced on 11May2011
Demod Board S. No. Power Splitter Frequency range of splitter (MHz) Phase unbalance from datasheet (deg) Amplitude Unbalance from datasheet (dB)
REFL55 118 PQW-2-90 30 to 90 90.14 0.92
AS11 021 PSCQ-2-51W 5 to 50 87.49 0.1
POY11 119 PSCQ-2-32 3.2 to 32 87.58 0.05
POY22 020 PSCQ-2-32 3.2 to 32 90.26 0.02
POY110 120 PSCQ--120 80 to 120 90.88 0.58

 

While doing a rough check of the boards I noticed that the REFL11 demod board had no signal on the Q output.

Rana also advised that we must use the boards which have the piggy-back amplifiers on those signals which are most useful.  We referred to Alberto's thesis and chose POY55 (MICH and SRCL), REFL11(PRCL)  and AS55 (DARM) as the most useful signals.  We currently have these amps on AS11, REFL11 and AS55.  We need to convert either AS11 or REFL11 into a POY55.  Since we need to troubleshoot REFL11, I thought we might as well modify that and in the process also fix its Q output.  So I renamed AS11 as REFL11 and will convert the old REFL11 into POY55 tomorrow.

Power splitter of different types have different pin-outs.  The way we mount a splitter depends on which type we are using.   I will detail the mounting scheme in a separate elog tomorrow.

 

 

 

  4702   Thu May 12 10:27:02 2011 ranaUpdateRF Systeminstallation of RF splitters in Demod boards

Quote:

Rana also advised that we must use the boards which have the piggy-back amplifiers on those signals which are most useful.  We referred to Alberto's thesis and chose POY55 (MICH and SRCL), REFL11(PRCL)  and AS55 (DARM) as the most useful signals.  We currently have these amps on AS11, REFL11 and AS55.  We need to convert either AS11 or REFL11 into a POY55.  Since we need to troubleshoot REFL11, I thought we might as well modify that and in the process also fix its Q output.  So I renamed AS11 as REFL11 and will convert the old REFL11 into POY55 tomorrow. 

 I think we should leave them as is; the AS11 was made by taking into account the SB levels at the AS port and should not become REFL11. We should instead convert one of the old 25 or 33 MHz diodes into a POY55.

  4703   Thu May 12 16:50:22 2011 SureshUpdateRF Systeminstallation of RF splitters in Demod boards

We have no plan to change the AS11 PD. I was referring to the AS11 Demod board which currently has the "Demodulator Preamp" circuit installed as a piggy back. In future I will append "_Demod" when I am referring to a demod board, to avoid confusion.

Quote:

Quote:

Rana also advised that we must use the boards which have the piggy-back amplifiers on those signals which are most useful.  We referred to Alberto's thesis and chose POY55 (MICH and SRCL), REFL11(PRCL)  and AS55 (DARM) as the most useful signals.  We currently have these amps on AS11, REFL11 and AS55.  We need to convert either AS11 or REFL11 into a POY55.  Since we need to troubleshoot REFL11, I thought we might as well modify that and in the process also fix its Q output.  So I renamed AS11 as REFL11 and will convert the old REFL11 into POY55 tomorrow. 

 I think we should leave them as is; the AS11 was made by taking into account the SB levels at the AS port and should not become REFL11. We should instead convert one of the old 25 or 33 MHz diodes into a POY55.

 

  4708   Thu May 12 23:50:10 2011 SureshUpdateRF SystemPOY55_Demod board Hardware change completed

The Demod board with S. No. 022 (being used earlier as REFL11) has been modified.  It now has SCLF-65 as its input LP filter on the PD input line and a PQW-2-90 power splitter.  The unit functioning okay (I and Q signals are 90 deg apart.

The loss of Q output was traced to a possible loose solder joint and we now have both the I and Q signals after resoldering all components in the vicinity of U7 (Ref Schematic of D990511)

There is a strong oscillation around 350Hz present on I and Q signals of both REFL55_Demod and POY55_Demod.  Don't know the source. 

We have run out of power splitters to continue with the Demod board modification. We do not currently have an AS11_Demod board.  All the others are in place and ready for the I<->Q phase angle measurement.

In summary we now have the following Demod boards in place:

[ REFL11, POY11, REFL55, AS55, POY55, POY22, POY110]_Demod

 

  4711   Fri May 13 01:51:56 2011 SureshUpdateRF SystemRF Status update

I have posted the attached RF status update and 1Y2 rack layout to the svn.

  4714   Fri May 13 22:45:37 2011 SureshUpdateRF SystemThe full set of 8 Demod boards is ready for testing

We have Completed the hardware changes to the full set of 8 demod boards.  The last one completed today is AS11.  I have collected the info on all the demod boards available so far in the table below.  As we measure the actual phase and amplitude unbalance we will expand this table to include new info.

The set of 8 demod boards
Demod Board S. No. Power Splitter Frequency range of splitter (MHz) Phase unbalance from datasheet (deg) Amplitude Unbalance from datasheet (dB)
AS11 121 PSCQ-2-51W 5 to 50 87.49 0.1
REFL11 021 PSCQ-2-51W 5 to 50 87.49 0.1
POY11 119 PSCQ-2-32 3.2 to 32 87.58 0.05
AS55 029 PSCQ-2-51W 5 to 50 no info no info
REFL55 118 PQW-2-90 30 to 90 90.14 0.92
POY11 119 PSCQ-2-32 3.2 to 32 87.58 0.05
POY22 020 PSCQ-2-32 3.2 to 32 90.26 0.02
POY110 120 PSCQ--120 80 to 120 90.88 0.58

 

  4715   Fri May 13 23:04:58 2011 SureshUpdateRF SystemDC power supply on RF distribution box has been replaced.

[Steve, Koji, Suresh]

   We shifted two Sorensen power supplies from the Auxiliary rack next to 1X2 to 1Y2.  And have installed them there (pic below).  The local ground reference was picked up from the racks ground reference.  A shielded cable with two twisted pairs was used to make a new power cable for the RF rack.  Since we are using three of the four conductors (+18,+28 and ground), one of them is not connected to anything.  This situation can be improved in a future iteration when, for example, we might wish to relocate the Sorensens to a different rack.

   We are still working on changing the power supply to the RF source.  Will complete this early next week

P5130120.JPG

  4716   Sat May 14 14:12:16 2011 KojiUpdateRF SystemDC power supply on RF distribution box has been replaced.

Key points of the power supply installation

  • We followed the grounding configuration for KEPCO except for the signal ground connection
  • AC power supply has been obtained from the local power strip. This also provides chassis earthing (for safety)
  • The chassis is connected to the shieldin of the DC supply cable. The other end should be isolated.
  • The low voltage side of Sorensen's DC outputs are connected in order to share the same reference  level.
  • The ground level is provided from the cross connect. The cable is connected between the cross connect ground to the sorencen.
    Unlike the KEPCO case, this cable does not have the current return, but just is to define the voltage level of those Sorensens.
  • New AC&DC cables have been nicely strain-relieved.

Quote:

[Steve, Koji, Suresh]

   We shifted two Sorensen power supplies from the Auxiliary rack next to 1X2 to 1Y2.  And have installed them there (pic below).  The local ground reference was picked up from the racks ground reference.  A shielded cable with two twisted pairs was used to make a new power cable for the RF rack.  Since we are using three of the four conductors (+18,+28 and ground), one of them is not connected to anything.  This situation can be improved in a future iteration when, for example, we might wish to relocate the Sorensens to a different rack.

   We are still working on changing the power supply to the RF source.  Will complete this early next week

 

  4736   Wed May 18 07:13:00 2011 SureshUpdateRF SystemDemod board measurements

I measured the amplitude and phase imbalances of the demod boards which have been modified.  This is just a basic health check.  We hope to use the script that Kiwamu is developing for a more accurate test.  The script can also use these measurements as a sanity check.  POP110  requires some further attention. 

Demod_Board_measurements.png

 

The RF distribution box outputs corresponding to the demod board (eg. AS55_LO --> AS55_demod) were used as LO sources.  The RF signal was generated with a Marconi and held a kHz away from the LO frequency.  The amplitude and phase unbalance were measured with SR785.  The RF Power meter was used to check the LO power in each case.

 

 

  4737   Wed May 18 07:18:15 2011 SureshUpdateRF SystemPOY55_Demod board Hardware change completed

The ~350 Hz noted in the elog below was traced to an RF modulation of the 11 MHz sideband.  This modulation was set up in the Marconi which is currently supplying the 11 MHz local oscillator signal to the RF source.  lt was used during the MC length study completed last week by Valera and Ryan.  The frequency measured was 322 Hz.

As we do not require this any longer, I have switched off this modulation.

 

 

Quote:

The Demod board with S. No. 022 (being used earlier as REFL11) has been modified.  It now has SCLF-65 as its input LP filter on the PD input line and a PQW-2-90 power splitter.  The unit functioning okay (I and Q signals are 90 deg apart.

The loss of Q output was traced to a possible loose solder joint and we now have both the I and Q signals after resoldering all components in the vicinity of U7 (Ref Schematic of D990511)

There is a strong oscillation around 350Hz present on I and Q signals of both REFL55_Demod and POY55_Demod.  Don't know the source. 

We have run out of power splitters to continue with the Demod board modification. We do not currently have an AS11_Demod board.  All the others are in place and ready for the I<->Q phase angle measurement.

In summary we now have the following Demod boards in place:

[ REFL11, POY11, REFL55, AS55, POY55, POY22, POY110]_Demod

 

 

  4738   Wed May 18 15:54:50 2011 KojiUpdateRF SystemDC power supplies for the RF generation box in place

[Koji, Steve]

DC power supplies for the RF generation box are now in place. They are the top two of the 6 Sorensens in the OMC short rack next to 1X2.

We made the connections as we did for the RF distribution box, the power supplies labele, and the cables strain-relieved.

The power supply is not yet connected to the actual RF generation box. This should be done by Suresh or someone with the supervision of him.

Note:
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop
although the grounding situation of the OMC side is not known to me.

  4739   Wed May 18 16:52:23 2011 SureshUpdateRF SystemCables for AS11 PD are in place

[Larisa, Suresh]

All the cables needed for the AS11 PD are in place... the heliax cable runs from the AS table to the PSL rack.  The LO and RF cables to demod board as well as the I and Q cables into the LSC Whitening board are connected.

The cables get rather densely packed when the LSC Whitening filter sits between the PD Interface Board and the LSC AA filter board.  This makes it difficult to access the SMA connectors on the LSC whitening filter.  So we shifted the LSC Whitening and AA Filter boards one slot to the right.  The LSC rack looks like this just now.  We have also shifted the binary cables at the back of the Eurocart by one slot so the same cables are associated with the cards.

1Y2_Rack_Layout_short-term.png

 

 

  4740   Wed May 18 17:06:39 2011 SureshUpdateRF SystemDC power supplies for the RF generation box in place

 

I have checked the voltages on the connector.  They are okay and I have plugged in the Sorensen power into the RF Source.  The ground reference for the Sorensens comes from the 1X2 Rack ground reference lines on the south side of the rack. 

I looked for the OMC ground reference. Could not find one on either of the the OMC half racks.

Quote:

[Koji, Steve]

DC power supplies for the RF generation box are now in place. They are the top two of the 6 Sorensens in the OMC short rack next to 1X2.

We made the connections as we did for the RF distribution box, the power supplies labele, and the cables strain-relieved.

The power supply is not yet connected to the actual RF generation box. This should be done by Suresh or someone with the supervision of him.

Note:
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop
although the grounding situation of the OMC side is not known to me.

 

  4751   Thu May 19 19:41:17 2011 SureshUpdateRF SystemDAQ channel Assignments for RF PDs

[Kiwamu, Suresh]

In trying to keep the wiring of the LSC rack as neat as possible, we came up with the following channel assignments of the RF PD signals. 

PDI = PD Interface, The PD Interface D-type connectors (#1 to #12) are numbered:  Top -> Bottom and Left -> Right in ascending order. 

The Analog channels on the LSC Whitening Filter boards are numbered similarly, 1 to 32 in four sets.

1Y2_Rack_Layout.png

  4755   Fri May 20 05:41:22 2011 SureshUpdateRF SystemDemod board measurements

The POP110 board which had the large Amplitude and Phase unbalances was examined today.  It turned out that there was some stray solder which had connected the Sum port of the PSCQ-2-120 splitter to its body (ground).  After I removed that the amplitude unbalance was 0.3dB however the phase was 105deg.  The phase reduced to 90 deg only if the power on the splitter is around 19 dBm.  So removed the AT1 (10dB attenuator) and the phase unbalance dropped to 91 deg.  However this is not a sustainable solution as the ERA-5 max output is about 19.5 dBm.

As this is a side band power monitor (and not a length sensing RFPD), we can make do with a poorer phase.  I will therefore replace the AT1 and adjust the residual phase with cable delay lines.  

Quote:

I measured the amplitude and phase imbalances of the demod boards which have been modified.  This is just a basic health check.  We hope to use the script that Kiwamu is developing for a more accurate test.  The script can also use these measurements as a sanity check.  POP110  requires some further attention. 

Demod_Board_measurements.png

 

The RF distribution box outputs corresponding to the demod board (eg. AS55_LO --> AS55_demod) were used as LO sources.  The RF signal was generated with a Marconi and held a kHz away from the LO frequency.  The amplitude and phase unbalance were measured with SR785.  The RF Power meter was used to check the LO power in each case.

 

 

 

  4804   Fri Jun 10 12:04:57 2011 JenneUpdateRF SystemBad RF connections!!

I am in the process of calibrating AS55's shot noise, and I noticed that the AS55 PD input to the demod board was only finger-tight.  I then checked all of the other SMA connections in the set of RF PD demod boards, and found several more that were loose, including all of the REFL55 connections.  This is no good!!!! RF connections need to be tightened!  I went through and tightened all of the offending connections with my personal Snap-on SMA wrench. 

  4957   Fri Jul 8 19:50:19 2011 SureshUpdateRF SystemLSC rack channel assignment

[Jamie, Suresh]

   We looked at the ADC channel assignments in the LSC model and wanted to make sure that the LSC rack wiring and the LSC model are in agreement with each other.  So the plan is to wire the rack as shown below.  I will also post this file on svn so that we can keep it updated in case there are changes.

 

1Y2_Rack_Layout.png


 

  5249   Tue Aug 16 16:59:20 2011 AnamariaUpdateRF SystemAM in the PM

Kiwamu, Keiko, Anamaria

Looking at the I and Q signals coming from REFL11 and REFL55 we saw large offsets, which would mean we have amplitude modulation, especially at 11MHz. We checked the PD themselves with RF spectrum analyzer, and at their frequencies we see stationary peaks (even if we look only at direct reflection from PRM). We changed the attenuation of the PSL EOM, and saw the peak go down. So first check is beam out of PSL EOM, to make sure the input beam is aligned to the crystal axis and is not giving AM modulation in adition to PM.

  5251   Wed Aug 17 02:48:56 2011 kiwamuUpdateRF SystemRe: AM in the PM

[Keiko / Suresh / Anamaria / Kiwamu]

 The AM components do exist also on the beam after the EOM.

The peaks were found at 11, 29 and 55 MHz, where the PM are supposed to be imposed.

Suresh and Keiko minimized them by rotating the HWP, which is in front of the EOM.

Also Anamaria and I tried minimizing them by adjusting the EOM crystal alignment.

However everytime after we minimized the AM peaks, they grew back in a time scale of ~ 1 min.

Potentially it could be a problem of the HWP and/or EOM alignment.

Since we wanted to proceed the in-vac work anyways, we stopped investigating it and decided to postpone it for tomorrow.

We again adjusted the incident power to 20 mW.

 

-- P.S.

 The incident power going to MC went down to 7 mW for some reasons. This was found after ~ 6 hours from our works on the PSL table.

We haven't touched anything on the PSL table since the daytime work.

Possibly the angle of the HWP is drifting (why?) and changed the amount of the P-polarizing beam power.

Suresh locked the angles of two HWPs, which are the one just after the EOM and the one after the attenuation PBS.

Quote from #5249

So first check is beam out of PSL EOM, to make sure the input beam is aligned to the crystal axis and is not giving AM modulation in adition to PM.

 

  5278   Mon Aug 22 20:37:43 2011 AnamariaConfigurationRF SystemPlan for install of 3f PDs

I made a quick sketch of how to include two more RF PDs on the REFL beam, given the space we have on the table. We want to install REFL33 and REFL165, 3f signals for the the two modulation frequencies we are using. The point is to make the distance from first beam splitter the same to all PDs so that we can use only one lens before this BS to make the beam the right size. Currently there are 2 PDs on the refl beam, REFL11 and REFL55, predictably. So the drawing shows 4 PDs. Drawing is to scale but is a bit coarse. Hopefully we'll take pictures once we're done.

Reference from current BS splitting beam to the existing PDs.

  5921   Thu Nov 17 11:04:02 2011 JenneUpdateRF SystemStochmon?

Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see. 

I'll start making the adapter plate while I wait...

  5923   Thu Nov 17 11:35:27 2011 KojiUpdateRF SystemStochmon?

The  Stochmon channels for 11&55MHz have been reasonably working since last night.

The output is not yet calibrated as the RF power detector has a strange scaling.
I am analyzing the calibration data.

  5926   Thu Nov 17 14:38:16 2011 ZachUpdateRF SystemStochmon?

It turns out that we don't have all the parts I would need to do a full prototype of the precision temperature controller. I am guessing that we won't want to sit around and wait for the parts given the upcoming TAC meeting, so I'll do the next best thing:

  • Standard DC temperature readout using an AD590.
  • More-or-less complete heater driver

Does anyone have a suggestion for how this thing will be packaged? I.e., should it be in a box or should it be mounted in a rack, etc. In the end, a real board will be printed and stuffed, so this need not be a really professional job in the short term.

 

Quote:

Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see. 

I'll start making the adapter plate while I wait...

 

  5951   Fri Nov 18 19:07:07 2011 JenneUpdateRF SystemFoam house on EOM

[Jenne, Zach, Frank]

Frank helped Zach and I cable up at PT-100 RTD, and make sure it worked with the Newport Model 6000 Laser Diode Controller.  We're using this rather than the Newport 3040 Temperature Controller because Dmass says the output of that isn't working.  So we're using just the temp control part of the Laser Diode controller.

The back of the controller has a 15-pin D-sub, with the following useful connections.  All others were left Not Connected. 

1 & 2 (same) - Pin 2 is one side of TEC output (we have it connected to one side of a resistive heater)

3 & 4 (same) - Pin 4 is the other side of the TEC output (connected to the other side of the resistive heater)

7 - connected to one side of PT-100 temp sensor

8 - connected to other side of PT-100 temp sensor

I used aluminum tape to attach the sensor and heater to the 40m's EOM, and we plugged in the controller.  It seems to be kind of working.  Zach figured out the GPIB output stuff, so we can talk to it remotely.

 

  5954   Sat Nov 19 00:09:02 2011 ZachUpdateRF SystemFoam house on EOM

Quote:

I used aluminum tape to attach the sensor and heater to the 40m's EOM, and we plugged in the controller.  It seems to be kind of working.  Zach figured out the GPIB output stuff, so we can talk to it remotely. 

I stole the Prologix wireless GPIB interface from the SR785 that's down the Y-Arm temporarily. The address is 192.168.113.108. (Incidentally, I think some network settings have been changed since the GPIB stuff was initially configured. All the Prologix boxes have 131.215.X.X written on them, while they are only accessible via the 192.168.X.X addresses. Also, the 40MARS wireless router is only accessible from Martian computers at 192.168.113.226---not 131.215.113.226).

In any case, the Newport 6000 is controllable via telnet. I went through the remote RTD calibration process in the manual, by measuring the exact RTD resistance with an ohmmeter and entering it in. Despite this, when the TEC output is turned on, the heating way overshoots the entered set temperature. This is probably because the controller parameters (gain, etc.) are not set right. We have left it off for the moment.

Here are a couple command examples:

1. Turning on the TEC output 

nodus:~>telnet 192.168.113.108 1234
Trying 192.168.113.108...
Connected to 192.168.113.108.
Escape character is '^]'.
TEC:OUT on
TEC:OUT
TEC:OUT?
++read eoi
1
 
2. Measuring the current temperature
 
TEC:T?
++read eoi
32.9837
 
3. Reading and then changing the set temperature
 
TEC:SET:T?
++read eoi
34.0000
TEC:T 35.0
TEC:SET:T?
++read eoi
35.0000
 
4. Figuring out that the temperature is unstable and then turning off the TEC (this is important)
 
TEC:T?
++read eoi
36.2501
TEC:OUT off
TEC:OUT?
++read eoi
0
 
(The "++read eoi" lines are the commands you give the Prologix to read the controlled device output.)
 
As I understand, Frank has some code that will pull data in realtime and put it into EPICS. This would be nice.
  5955   Sat Nov 19 00:34:36 2011 ZachUpdateRF Systemwhy the Newport 6000 isn't working

 I just figured out why the Newport 6000 isn't stabilizing the temperature. It is designed to drive a TEC, so that when the temperature is too high, it just applies a negative current. Of course, this doesn't work with a resistive heater; it just keeps heating it up more.

I'm not sure if Frank has actually used this with a restive heater before, but it doesn't appear that you can limit the low-current level or add an offset.

  5976   Tue Nov 22 06:12:43 2011 ZachUpdateRF SystemPrototype temperature controller

Tonight I built a simpler version of what will be the new general-purpose precision temperature controller. This one is built on a breadboard and will be used for RFAM testing at the 40m until a better version is made. Some  differences between this version and the final one:

  • In the interest of time, this controller senses temperature using a DC wheatstone bridge, instead of the audio-frequency bridge of the final controller.
  • I eschewed the more complicated transistor current source in favor of a simple current buffer. In effect, using a constant-current source is not absolutely necessary, since we are not interested in constant current but rather a constant system temperature. In this sense, it doesn't matter if we have a transistor current source or a transistor voltage source or a current-buffered op amp voltage source; the loop will simply drive the heater with the proper current to keep the error signal nulled. 

So, how it works:

  1. The DC bridge drive voltage is supplied by a voltage-divided and buffered AD587 (low-noise 10-V reference).
  2. The reference resistors are just 1% metal film leaded resistors, but I have put some effort into making them quiet:
    1. Each resistor's body is wrapped in Al tape, and then all the resistors are taped together using Al tape, as well. This is to strongly couple them to each other thermally.
    2. All the reference resistors are embedded in some foam I found in the Bridge sub-B hallway. It's nothing fancy, but it keeps large advection currents from causing thermal drifts.
  3. The sensing element is a PT100 100-ohm RTD. Tempco is ~0.0037 1/K
  4. The bridge differential voltage is read out by an AD620 instrumentation amplifier with G = 100
  5. The AD620 output is fed directly to an OP27 with G = 0-20
  6. This is fed to an LF356 (FET-input op amp, to reduce the effects of bias current when the integrator is on) with a single pole at 0.1 Hz, switchable via jumper to DC for true integration
  7. This is summed with an offset via an OP27 summer (the offset determines the heater current with no signal---half the maximum current of ~120 mA is optimal)
  8. The summer output is buffered with a BUF634, which can provide well over the maximum current we can push through our heater, and the BUF634 directly drives the heater
  9. Between the BUF634 and the heater is a back-biased diode to ground. This is to prevent the current from going negative when the error signal is well below zero.

I have tested the circuit using a spare resistive heater and a potentiometer to simulate the RTD. First I tested the sensing and drive circuits separately, then I connected the sensor output to the drive input and modulated the potentiometer resistance while monitoring the current. The circuit behaved as expected.

When I got to the 40m, it struck me that the resistance I had chosen (115 ohms) corresponded to 40 C, which I realized might be above what we could reach with the current we can provide. I used the Newport 6000 via telnet to drive the heater at several current values and see what the resistance became. I found that with I = Imax/2 ~ 0.6, the resistance was around 113 ohms (it was ~111 at room temp). So, I switched the reference resistor in the leg above the PT100 from 115 -> 113.

I then plugged everything in while monitoring the heater current and AD620 output (error signal), and it seemed not to do anything. I was tired so I figured I'd leave it for tomorrow.

Here is a sketch of the schematic, as well as some pictures:

refres1.pngrefres2.pngproto_temp_ctrl.png

schematic.png

  5984   Wed Nov 23 00:30:14 2011 ZachUpdateRF SystemEOM temperature controller trials

[Jenne, Zach]

We did some testing of the prototype temperature controller. When I left it late last night, it was not working in conjunction with the real heater and PT100 mounted to the EOM, but had been tested using simulated loads (a spare heater and a potentiometer for the RTD).

We measured each of the reference resistors carefully, as I should have done in the first place since they are only 1% tolerance (I am using 100-ohm ones in series with ~15-ohm ones, so they have a variation of +/- an ohm or so, which is consequential). We calculated the estimated zero-signal resistance of the RTD, then used a trimpot to verify that the AD620 output behaved as expected. We realized that I didn't tie the 620's reference to ground, so the output was floating around by a lot. Once we did that, the readout was still not working properly, but eventually magic happened and we got an appropriate signal. I did find that there was a discrepancy between the estimated zero-signal resistance and that measured across the trimpot with the readout nulled---this may be caused by a small offset in the 620, but is not important so long as the output still scales properly.

Before trying it out again on the real McCoy, I tested the whole, closed-loop circuit with the spare EOM on Jenne's desk. The temperature oscillated at first, but a reduction of gain at the input stage of the driver allowed it to stabilize. The temperature of the EOM (sitting on the electronics bench) was kept constant with a control current that varied from ~40 - 70 mA, depending on how many people were around it, etc. This is pretty much perfect for the quiescent level, but that means that we might have to increase the baseline operating resistance of the PT100 (by changing the reference resistors) once it is sitting in a hot foam box. Otherwise, we will have no gain on the cooling side. I tested the circuit response by cupping my hands over the EOM to increase the temperature and ensuring that the current dropped so as to null the error signal. It worked pretty well, with a thermally-limited bandwidth of I would estimate around 0.1 Hz. 

I went to try it out on the PSL table, but again it didn't work. It turned out that this time I had broken one of the soldered connections from the broken-out D-sub cable to the (tiny) wires going to the PT100, so there was no temperature signal. I resoldered it, but I forgot that there is a thin insulating layer on the wire, so no connection was made. Frank tutored Jenne on how to properly strip these wires without damaging the core, but alas I didn't pay attention.

The RTD/heater/D-sub package lies in wait on Jenne's desk, where I have left an apologetic note. Once it is fixed, we should be able to finally hook it up for realz.

  6022   Mon Nov 28 14:27:35 2011 JenneUpdateRF SystemEOM temp driver

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

  6023   Mon Nov 28 14:40:43 2011 KojiUpdateRF SystemEOM temp driver

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

  6025   Mon Nov 28 15:43:36 2011 steveUpdateRF SystemEOM temp zoomed

Quote:

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

 It is not working

  6032   Tue Nov 29 02:09:15 2011 ZachUpdateRF SystemEOM temp stabilization fixed

I inspected the temperature stabilization circuit today to see why it wasn't working. It didn't make sense that it just kept railing the heater even though the error signal was negative (which should turn the heater current OFF).

It turns out that the LF356 (FET-input op amp) that serves as the filter stage for the heater driver was broken---I measured a full, railed positive output even though the input was negative. We didn't have any more LF356s, so I replaced it with an OPA604 (Burr-Brown FET-input), and all seemed to work fine.

Since we were having too much digitization noise, I also added a temperature monitor buffer using a non-inverting OP27 circuit with G=99. This makes the overall calibration ~7.6 V/K into the ADC.

Below is a time series showing that it is working. The circuit was turned on near the beginning, and you can see that the heater is railed at +10V until shortly after the error signal goes negative, at which point it adjusts and ultimately approaches a steady-state value of ~7.8V.

EOM_temp.png

I have no figures to demonstrate this, but it seems that even with this 100x increase in monitor gain, the error signal is still below the ADC noise level. This could be because the ambient temperature fluctuations are just that small on timescales of less than a few hours. I'm not sure if we really need to be able to see the temperature noise level above a few mHz, but if we do we will have to find some way to increase our dynamic readout range. 

Also, Koji told me where he stashed the nice protoboards, so I will get onto transferring this circuit onto one ASAP. Since it is working now, I think I'll leave it until after the TAC.

  6035   Tue Nov 29 14:22:03 2011 ZachUpdateRF SystemEOM temp stabilization performance

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

Here are both long-term (~13-hr) and short-term (1-hr) trends of the EOM temperature and the heater drive level. From the long trend you can see that the heater departed the steady value of ~7.8V that I observed last night to accommodate the diurnal heating of the lab in the morning---the temperature was held near zero offset.

From the short-term trend, there are 2 things to notice:

  1. We are still very close to the digitization noise level for both signals. This is bad, because we want to look at the residual noise level, etc.
  2. There appears to be some strange sort of disturbance of f~0.01-0.02 Hz. I'm not sure what causes the strange shape

Screen_shot_2011-11-29_at_1.33.50_PM.png Screen_shot_2011-11-29_at_1.34.06_PM.png

 

Finally, here is a trend over the last ~24 hours of the EOM temperature, heater drive level, and the 11- and 55-MHz Stochmon signals. I believe that the abrupt shelves noticeable on the Stochmon trends are when c1sus was turned on and shut down, respectively (I'm not sure why that causes the signals to die, but the times seem right, and nothing obvious happens to the EOM temp stabilization signals at either time). The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. There is some residual drift (common-mode to both RF frequencies), which is most likely caused by a drift in some other parameter (e.g. laser frequency or power).

Screen_shot_2011-11-29_at_1.41.03_PM.png

I took some relatively inconclusive power spectra and coherence measurements, but I'd rather wait until we have an uncontrolled data stretch with which to compare. I think what we should do now is disconnect the controller and then let it sit for a while.

 

  6036   Tue Nov 29 15:25:29 2011 steveUpdateRF SystemEOM temp stabilization performance

 It is not obvious what is working.

 

  6040   Tue Nov 29 18:17:27 2011 ZachUpdateRF SystemEOM temp stabilization performance

Quote:

 It is not obvious what is working.

 

It should be. As I mentioned, you can only trust the Stochmon signals between 0840 and 1130 UTC; before this time, the temperature controller was not connected, and after this time, c1sus is shut down and the MC is not locked, as you can see in your DV plot.

Within this time frame, the Stochmon signals are relatively stabilized (though there is some residual common-mode-ish drift since we are not using RFAM as the error signal---i.e., other things like laser power and frequency can mix in). Also, anytime after 0840, the controller signals behave as they should (these are unaffected by the status of c1sus):

  • The EOM temperature signal (error signal) is stabilized to a value very near zero
  • The heater drive signal (control signal) moves around in such a way as to null the error signal, and you can confirm that it looks roughly like the opposite of the FSS_RMTEMP signal, as it should.

I am concerned with the other issues that I mentioned in my previous post, namely:

  1. Error signal dominated by digitization noise above some low frequency despite 100x amplification
  2. Strange ~0.01-Hz level disturbances in error signal.
  6043   Tue Nov 29 19:08:53 2011 ZachUpdateRF SystemEOM heater disconnected

I disconnected the heater at ~2:20 UTC, leaving the sensor circuit operational. Don't be fooled by the apparent railing of the heater in the monitor trace below---the heater has been physically disconnected, so there is no current flowing even though the servo is railed (since the error signal is huge with the loop open).

Kiwamu and I also restarted c1sus and locked the MC so that we can get some uncontrolled Stochmon data. I think he is planning to reconnect the heater some hours from now so that we can get yet another controlled data stretch (since the first one was cut short by c1sus's going down).

Screen_shot_2011-11-29_at_7.03.36_PM.png

  6044   Tue Nov 29 22:10:18 2011 kiwamuUpdateRF SystemRFAM fluctuation reduced

Quote from #6035

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. 

Indeed the fluctuation of the RFAM became quieter with the temperature control ON.

However the absolute value of the RFAMs stayed at relatively high value.

I guess we should be able to set the right temperature setpoint such that the absolute value of the RFAM is smaller.

Here is the calibrated RFAM data (for 5 hours around the time when Zach activated the temperature control last night):

RFAM_withEOMheater_edit.png

  6047   Tue Nov 29 23:03:34 2011 ZachUpdateRF SystemRFAM fluctuation reduced

I was hesitant to claim that this is definitely true without the control data we were taking after the heater was turned off today. This is because before I replaced the malfunctioning op amp last night, the heater was actually ON and injecting temperature noise into the system that would not be there with it off. I think the best idea is to compare the data from today (heater on vs. heater off, but with functioning circuit).

Quote:

 

Indeed the fluctuation of the RFAM became quieter with the temperature control ON.

  6050   Wed Nov 30 03:01:55 2011 kiwamuUpdateRF SystemRFAM fluctuation reduced

Okay I have turned ON the temperature control at 2:40 AM and will leave it ON for a while.

Quote from #6047

I was hesitant to claim that this is definitely true without the control data we were taking after the heater was turned off today. This is because before I replaced the malfunctioning op amp last night, the heater was actually ON and injecting temperature noise into the system that would not be there with it off. I think the best idea is to compare the data from today (heater on vs. heater off, but with functioning circuit).

 

  6053   Wed Nov 30 13:52:09 2011 ZachUpdateRF SystemEOM temp stabilization ineffectual

This recent off/on run proved what I was afraid of: the temperature stabilization setup appears to do nothing except very near DC. The plot that Kiwamu posted is misleading because the "uncontrolled" data stretch at the beginning actually had the heater injecting random noise (since the circuit was broken). Below are some plots (sorry in advance for their crappiness---the plot tools wouldn't let me print to file for some reason):

Time series of the temp monitor, the heater monitor, and the 11- and 55-MHz RFAM monitors. The heater was disconnected at ~2:20 UTC, and the temperature is seen to equalize to the surroundings (note that the TEMP_MON is inverted, so positive change means decreasing temperature). The heater was reconnected by Kiwamu around 10:40 UTC, and you can see the temperature being driven back to the zero point by the loop. Note that the temperature was still decreasing at a fair rate when the heater is re-engaged---this could mean that we really need to take longer samples.

Screen_shot_2011-11-30_at_1.31.44_PM.png

 

Spectra and coherence of the 11- and 55-MHz RFAM monitors before and after the control was re-engaged. It appears that the 11-MHz signal is unaffected while the 55-MHz signal actually gets worse. This also seems evident from the noisiness in the time series for that signal above (top right). Bad, bad, bad. 

Screen_shot_2011-11-30_at_1.29.48_PM.png

 

Spectrum of the EOM temperature signal before and after control was re-engaged. There seems to be no change whatsoever. Of course, as mentioned before, this signal seems to be close to the digitization noise level as seen in DV. I am not sure what the ADC noise looks like at these low frequencies. In case someone knows, the magnitude of this signal in counts is ~0.1 ct/rHz at 10 mHz; is this too low? Another thing to note is that the noise level in K is pretty low! I would be surprised if the RTD can really see 10 uK/rHz at and below 10 mHz.

 

Screen_shot_2011-11-30_at_1.21.16_PM.png

 

I need to try and increase the gain of the servo to see if I can get it much higher without it becoming unstable.

  6054   Wed Nov 30 14:12:53 2011 JenneUpdateRF SystemNew EOM mount almost ready

The new EOM adapter plate and riser just got back from the shop.  I just had Mike do the milling, and I'll drill and tap them tomorrow after the TAC.  Then we can remount the EOM to see if stiffening the mount helps at all.

  6055   Wed Nov 30 22:09:20 2011 ZachUpdateRF Systemsome final EOM stabilization efforts

First, things that were done:

  • I was troubled by the odd-looking noise in the EOM temperature signal, so I investigated the circuit with a probe and found that there was quite a bit of line pickup, which I traced to the wires going to and from the RTD (if I placed a dummy resistor directly on the board, it went down markedly).
    • I put a 3-Hz RC LPF between the AD620 and the driver input buffer, which reduced the line noise significantly
    • The error signal looks much cleaner and there are no longer strong peaks in the error spectrum at ~1+ Hz and harmonics
  • I had tried earlier to increase the gain of the servo at the driver input stage. It seemed to stay stable. Since I knew the error signal  with the loop closed was at the level of the ADC noise, I decided to push my luck with increasing the servo gain and juice up the AD620 gain from 100 to 990.
    • The servo stayed stable and the error signal level is now manageable.

Things that I noticed:

  • With the latest increase in gain, I measured that the error signal was suppressed with the loop closed (the suppression is below ~0.1 Hz, and the reason that the high-frequency level is different is because it has been amplified above the ADC noise by the time of the second trace).

 EOM_temp_stab_and_unstab_new_11_30_11.pdf

  • Despite the above, the Stochmon signals remained unchanged no matter what I did. I noticed that the Stochmon signals, too, were fluctuating basically at bit-level. I terminated the 11-MHz signal and compared it to the normal level---it is not exactly the same, but only a factor of 2-3 lower, which is not great. Of course, the RMS detector is logarithmic, but I think we still want the dark noise to be at least an order of magnitude lower here.
    • I tried to amplify the signal with an SR560, but since the DC level is supposed to be ~1-2 V, I could only get about 2x gain---not enough.

 11MHz_wandwo_ctrl_and_adc_noise_11_30_11.pdf

Conclusion

I think there are two things that could be happening here, given the above information:

  1. We are limited by the noise of the temperature sensing circuit, which would explain why the in-loop error signal is suppressed while the RAM levels appear not to be. This should be easy enough to test (though there's not enough time right now) with an out-of-loop sensor.
  2. The RAM is not dominated by temperature noise here. With the loop open, one would expect to see coherence between the RAM signal and the temperature sensor, if indeed one was the cause of the other. Instead, we see that---while the 11- and 55-MHz signals ARE pretty coherent with each other---there is no appreciable coherence between the temperature and the Stochmon signal.
ELOG V3.1.3-