40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 204 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1201   Mon Dec 22 13:48:22 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
As a temporary fix, I cut the cable of the power supply and connected it to the Sorensen power supply +5V on the rack.
Now, the RFM bypass box is powered up, but some LEDs are red, which looks like a bad sign.
I restarted all the FE computers, but this time I got errors during the execution of the startup commands in the VxWorks machines.
The errors are "General Protection Fault" or "Invalid Opcode".
The linux machines do not show errors but still the status lights in EPICS are red.
We need Alex's help. He did not answer the phone, so Alberto left a voice mail.
  538   Wed Jun 18 16:07:57 2008 robSummaryComputersRFM network down

The RFM network tripped off around noon today. It's still down. The problem appears to be with the EPICS interface (c1dcuepics). Trying to restart one of the end stations yields the error: No response from EPICS.

Possible causes include (but not limited to): busted RFM card on c1dcuepics, busted PMC bus on c1dcuepics, busted fiber from c1dcuepics to the RFM switch. We need Alex.
  13436   Tue Nov 21 11:21:26 2017 gautamUpdateCDSRFM network down

I noticed yesterday evening that I wasn't able to engage the single arm locking servos - turned out that they weren't getting triggered, which in turn pointed me to the fact that the arm transmssion channels seemed dead. Poking around a little, I found that there was a red light on the CDS overview screen for c1rfm.

  • The error seems to be in the receiving model only, i.e. c1rfm, all the sending models (e.g. c1scx) don't report any errors, at least on the CDS overview screen.
  • Judging by dataviewer trending of the c1rfm status word, seems like this happened on Sunday morning, around 11am.
  • I tried restarting both sender and receiver models, but error persists.
  • I got no useful information from the dmesg logs of either c1sus (which runs c1rfm), or c1iscex (which runs c1scx).
  • There are no physical red lights in the expansion chassis that I could see - in the past, when we have had some timing errors, this would be a signature.

Not sure how to debug further...

* Fix seems to be to restart the sender RFM models (c1scx, c1scy, c1asx, c1asy).

Attachment 1: RFMerrors.png
RFMerrors.png
  13643   Tue Feb 20 21:14:59 2018 gautamUpdateCDSRFM network errors

I wanted to lock the single arm POX/POY config to do some tests on the BeatMouth. But I was unable to.

  • I tracked the problem down to the fact that the TRX and TRY triggers weren't getting piped correctly to the LSC model
  • In fact, all RFM channels from the end machines were showing error rates of 16384/sec (i.e. every sample).
  • After watchdogging ETMX, I tried restarting just the c1scx model - this promptly took down the whole c1iscex machine.
  • Then I tried the same with c1iscey - this time the models restarted successfully without the c1iscey machine crashing, but the RFM errors persisted for the c1scy channels.
  • I walked down to EX and hard rebooted c1iscex.
  • c1iscex came back online, and I ssh-ed in and did rtcds start --all.
  • This brought all the models back online, and the RFM errors on both c1iscex and c1iscey channels vanished.

Not sure what to make of all this, but I can lock the arms now.

  4524   Thu Apr 14 12:57:15 2011 josephbUpdateCDSRFM network happy again

[Joe, Alex]

Problem Symptoms:

There were red lights on the status screen indicating RFM errors for the c1scy, c1mcs and c1rfm processes.

The c1iscey, c1sus machines were receiving data sent over the RFM network from the c1ioo computer with a bad time stamp, a few cycles too late.  The c1iscex computer was receiving data from c1ioo fine.

Problem:

The c1iscex RFM card had gotten into a bad state and was somehow slowing things down/corrupting data.  It didn't affect itself, but due to the loop topology was messing everyone else up.  Basically the only one who wasn't throwing an error was the culprit.

Solution:

Hard power cycling the c1iscex computer reset the RFM card and fixed the problem.

  608   Tue Jul 1 09:26:33 2008 steveUpdateComputersRFM network is down
  2192   Fri Nov 6 10:35:56 2009 josephbUpdateComputersRFM reboot fest and re-enabled ITMY coil drivers

As noted by Steve, the RFM network was down this morning.  I noticed that c1susvme1 sync counter was pegged at 16384, so I decided to start with reboots in that viscinity.

After power cycling crates containing c1sosvme, c1susvme1, and c1susvme2 (since the reset buttons didn't work) only c1sosvme and c1susvme2 came back normally.  I hooked up a monitor and keyboard to c1susvme1, but saw nothing.  I power cycled the c1susvme crate again, and this time I watched it boot properly.  I'm not sure why it failed the first time.

The RFM network is now operating normally.  I have re-enabled the watchdogs again after having turned them off for the reboots.  Steve and I also re-enabled the ITMY coil drivers when I noticed them not damping once the watch dogs were re-enabled.  The manual switches had been set to disabled, so we re-enabled them.

  5861   Thu Nov 10 11:52:00 2011 JenneUpdateCDSRFM signal transferring

I am not so happy with the control signals that are coming into the OAF via the RFM/Dolphin/shmem. 

The MCL/MCF signal travels via RFM from the IOO computer to the RFM model on the SUS computer, and then via dolphin to the OAF model on the LSC computer.

The MICH and PRCL signals travel via shmem from the LSC model to the OAF model, all on the LSC computer.  They don't go through the RFM model.

The seismometer channels travel via shmem between the PEM model on the SUS computer and the RFM model on the SUS computer, and then via dolphin between the SUS computer and the OAF model on the LSC computer.

Each pdf shows the power spectrum and a time series of the signals in their "original" model, and in the OAF model.  The seismometer is the only one that seems fine.  The time series match, except for a delay which is not surprising, since the signals have to travel.  The other signals seem pretty distorted.  What is going on??? Why can we trust some, but not all, of the signals that move between models and between computers???

 (This data was all taken while the MC was locked, but MICH and PRCL were not.  I don't think this should have any effect on the signal transfer though).

The MCL isn't soooo bad, so maybe we can keep moving forward with it, but I'm concerned that we're not really going to be successful OAF-ing the other degrees of freedom if the signals are so distorted.

Attachment 1: OAF_rfm_signals_MCL.pdf
OAF_rfm_signals_MCL.pdf
Attachment 2: OAF_rfm_signals_MICH.pdf
OAF_rfm_signals_MICH.pdf
Attachment 3: OAF_rfm_signals_PRCL.pdf
OAF_rfm_signals_PRCL.pdf
Attachment 4: OAF_rfm_signals_GUR1X.pdf
OAF_rfm_signals_GUR1X.pdf
  3845   Tue Nov 2 13:51:40 2010 josephb, yutaUpdateCDSRFM slowdown problem

Problem:

Each RFM memory location which needs to be read by a front end model slows the model significantly.

With no RFM memory locations to be read (replaced with grounds), the c1mcs model runs around 25 microseconds per cycle.

With 1 RFM memory location (MC_L), it runs around 29-33 microseconds.

With 3 RFM memory locations (MC_L, MC1_PIT, MC1_YAW), it runs around 45 microseconds.

With 7 RFM memory locations, the code generally doesn't run at all, going past the 62 microsecond maximum required to be able to keep up with the 16 kHz sample rate.

Last night Yuta somehow got it running with 7 RFM memory locations, but in that case, all the odd numbered RFM channels (1,3,5 as counted by the ipc file) did not work.  It was running at around 55 microseconds in that case.

The c1ioo code which is writing the data to the RFM card is experiencing no such slow down.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
                     ... 
  15719   Wed Dec 9 15:37:48 2020 gautamUpdateCDSRFM switch IP addr reset

I suspect what happened here is that the IP didn't get updated when we went from the 131.215.113.xxx system to 192.168.113.xxx system. I fixed it now and can access the web interface. This system is now ready for remote debugging (from inside the martian network obviously). The IP is 192.168.113.90.

Managed to pull this operation off without crashing the RFM network, phew.

BTW, a windows laptop that used to be in the VEA (I last remember it being on the table near MC2 which was cleared sometime to hold the spare suspensions) is missing. Anyone know where this is ?

Attachment 1: Screenshot_2020-12-09_15-39-20.png
Screenshot_2020-12-09_15-39-20.png
Attachment 2: Screenshot_2020-12-09_15-46-46.png
Screenshot_2020-12-09_15-46-46.png
  3293   Mon Jul 26 14:24:46 2010 josephb, kiwamuUpdateCDSRFM test take 1

Kiwamu and I strung a temporary RFM fiber from the c1iscex machine (in the new 1X9 rack) to the c1sus machine (in the new 1X4 rack).  This was connected into the respective RFM cards.  Once we put the fiber in correctly, the status lights came on the RFM card, which is a good sign.  This did not go through the RFM bypass, and did not interfere with any other RFM connections.

We created a simple model to test the RFM card, which basically was 4 RFM memory locations passing back and forth between 2 filters on each machine.  These models were called c1rf0 (on c1sus) and c1rf1 (on c1iscex).  We added 4 entries to the /cvs/cds/caltech/chans/ipc/C1.ipc file corresponding to the 4 RFM memory locations, set their ipcType=RFM and set the ipcRate to 65536.  The ipcNum were set from 0 to 3. The models ran, however, the data we were trying to pass over the RFM card did not seem to be being passed.  Currently trying to contact Alex via e-mail to get debugging advice, and confirm the ipc file is setup correctly.

  9012   Thu Aug 15 01:51:50 2013 KojiSummaryGeneralRFM<->Dolphin bridge distributed to c1rfm and c1mcs

Since the RFM-Dolphin bridges for the ASX model was added to the c1rfm model, c1rfm kept timing-out from the single sample time of 60us.

The model had 19 dolphin accesses, 21 RFM accesses, and 9 shared memory (SHM) accesses.

At the beginning 2 RFM and 2 SHM accesses were moved to c1sus (i.e. they were mistakenly placed on c1rfm).
But this actually made the c1sus model timed out. So the model was reverted.

The current configuration is that the WFS related bridges were accommdated in the c1mcs model.
This made the timing of c1rfm ~40us. So it is safe now.
On the other hand, the c1mcs model has the time consumption of ~59us. This is marginal now.

We need to understand why any RFM access takes such huge delay.

  2190   Fri Nov 6 07:55:59 2009 steveUpdateComputersRFMnetwork is down

The RFMnetwork is down.  MC2 sus damping restored.

  9004   Tue Aug 13 11:40:19 2013 Alex ColeSummaryElectronicsRFPD Demod Filter Frequency Response Measurement

 For the RF PD Frequency Response Measurement project, we get each PD signal from the "PD RF Mon" output of each demodulator board corresponding to our PD under test. Therefore we can't neglect the frequency response of various filters inside the demodulator board. I used our Agilent 4395 Network Analyzer to gather frequency response data for each demodulator board being considered for the RFPD frequency response project (AS55, REFL11, REFL33, REFL55, REFL165, POX11, POP22, POP110).

The NA swept over a frequency range of 1-500 MHz. Data was collected using NWAG4395A (from the netgpibdata directory). It should be noted that the command line options -a 16 -x 15 (averaging=16 and excitation amplitude=15 dBm[the max]), in addition to the usual command line options described in the help file, were used to minimize noise. 

The data is located in /users/alex.cole. The file names are in the format [PDNAME]DemodFilt_1000000.dat (e.g. REFL11DemodFilt_1000000.dat). Results for POP110 are shown below.

Attachment 1: photo_(3).JPG
photo_(3).JPG
Attachment 2: test.jpg
test.jpg
  15433   Fri Jun 26 16:53:38 2020 gautamUpdateElectronicsRFPD characterization

Summary:

While the vacuum system was knocked out, I measured the RF transimpedance (using the AM laser setup, didn't do the shot noise intercept current measurement for now) of all the RFPDs (except PMC REFL). At the very least, the following photodiodes are suspect:

  1. WFS heads - expected transimpedance is 50 kohm unattenuated, and 5 kohm attenuated. I measure values that are x10 lower than this, and the segments are significantly imbalanced. Morover, the attenuators for some quadrants appear to do nothing. This could be a problem with the Acromag system I guess, but the measured transimpedance is nowhere close to the "expected" value. See Attachments #1 and #2. You can also see that the response at 55 MHz is significantly attenuated, so I'm guessing trying to measure the AS port ASC sensing response is going to be difficult.

    Note that I assumed a 1kohm DC transimpedance, which is what I expect from the schematic and also is consistent with the DC voltage I measured, knowing the approximate optical power incident on the photodiode.
  2. POP 22/ POP 110 - this is a Thorlabs PDA10CF diode. It should have a flat gain profile out to ~100 MHz, but I measure some weird features. The other PDA10CF we use, at AS110, shows a more reasonable response. See Attachment #3. I don't know what kind of failure mode this is? Anyway I'll try testing another PDA10CF and if it looks more reasonable, I'll switch out this diode. FWIW, the measured AS110 gain is ~3kohms, whereas the datasheet tells us to expect 5 kohms.

For the remaining photodiodes, I measure a transimpedance that is within ~20% of what is on the wiki page. The notches may benefit from some retuning. While I have the data, I will fit this and post a more complete report on the wiki.

Update July 6 1145am: WFS response plots now have legends mapping quadrants, and I've also added the response of a spare PDA10CF (which is now the new POP22/POP110 photodiode).

Attachment 1: WFS1.pdf
WFS1.pdf
Attachment 2: WFS2.pdf
WFS2.pdf
Attachment 3: buildupMons.pdf
buildupMons.pdf
  15439   Mon Jun 29 15:56:02 2020 gautamUpdateElectronicsRFPD characterization

A more comprehensive report has been uploaded here. I'll zip the data files and add them there too. In summary:

  1. There are several problems with the WFS heads
    • Some attenuators don't seem to work. This could be a problem with the Acromag BIO, or with the relay on the head itself.
    • The measured transimpedance at 29.5 MHz is much lower than expected. We expect ~50 kohms with no attenuation, and 5 kohms without. I measure 100 ohm - 2 kohm with the attenuation disabled, and ~200 ohms with it enabled.
    • Quadrant #3 on both WFS heads behaves differently from the others. There is also evidence of a 200 MHz oscillation for quadrant 3.
    • For some reason, there is a relative minus sign between the TFs measured for the WFS and for the RFPDs. I don't understand where this is coming from - all the OpAmps in the LSC PDs and WFS heads are configured as non-inverting, so why should there be a minus sign? Is this indicative of the polarity of the LEMO output being somehow flipped?
  2. POX 11 photodiode does not have a notch at 22 MHz.
  3. AS55 resonance appears to have shifted closer to 60 MHz, would benefit from a retuning. But the notches appear fine.
  4. PDA10CF photodiode used as the POP22/POP110 readback appears broken in some strange way. As shown in the linked document, a spare PDA10CF in the lab has a much more reasonable response, so I am going to switch out the POP22/POP110 diode with this spare.

I'll upload the data and analysis notebook + liso fit files to the wiki as well shortly. The data, a Jupyter notebook making the plots, and the LISO fit files have been uploaded here.

I didn't do it this time but it'd be nice to also do the noise measurement and get an estimate for the shot-noise intercept current.

Quote:

While I have the data, I will fit this and post a more complete report on the wiki.

  11003   Wed Feb 11 17:31:11 2015 ericqUpdateLSCRFPD spectra

For future reference, I've taken spectra of our various RFPDs while the PRMI was sideband locked on REFL33, using a 20dB RF coupler at the RF input of the demodulator boards. The 20dB coupling loss has been added back in on the plots. Data files are attached in a zip.

Exceptions: 

  • The REFL165 trace was taken at the input of the amplifier that immediately preceeds the demod board. 
  • The 'POPBB' trace was taken with the coupler at the input of the bias tee, that leads to an amplifier, then splitter, then the 110 and 22 demod boards. 

I also completely removed the cabling for REFLDC -> CM board, since it doesn't look like we plan on using it anytime in the immediate future. 

Attachment 1: REFL.png
REFL.png
Attachment 2: AS.png
AS.png
Attachment 3: POP.png
POP.png
Attachment 4: 2015-02-PDSpectra.zip
  11004   Wed Feb 11 18:07:42 2015 ericqUpdateLSCRFPD spectra

After some discussion with Koji, I've asked Steve to order some SBP-30+ bandpass filters as a quick and cheap way to help out REFL33. (Also some SBP-60+ for 55MHz, since we only have 1*fmod and 2*fmod bandpasses here in the lab). 

  11008   Thu Feb 12 01:00:18 2015 ranaUpdateLSCRFPD spectra

The nonlinearity in the LSC detection chain (cf T050268) comes from the photodetector and not the demod board. The demod board has low pass or band pass filters which Suresh installed a long time ago (we should check out what's in REFL33 demod board). 

Inside the photodetector the nonlinearity comes about because of photodiode bias modulation (aka the Grote effect) and slew rate limited distortion in the MAX4107 preamp.

  16765   Thu Apr 7 20:41:15 2022 TommyUpdateElectronicsRFSoC 2x2 Board -- Gain Plotter

In this file (under Tommy), we have a notebook which runs through a spectrum of frequencies and determines the gain response of the attached filter. Below we have the output of a high pass filter. We use IQ demodulation to change IQ componets to DC. Then using a butterworth filter, we read out the DC components and determine the gain's magnitude and phase. However, the phase seems very noisy. This is because the oscillators in the different tiles are independent and a random phase is introduced by changing the mixer frequency in individual tiles. To resolve this we need Multi Tile Synchronization or "MTS". 

Original Pynq Support Forum Query: https://discuss.pynq.io/t/rfsoc-2x2-phase-measurement/3892

We also have the code to fit a resposne function using IIRregular, but this is not as useful without proper phase data.

Attachment 1: Screen_Shot_2022-04-07_at_8.40.23_PM.png
Screen_Shot_2022-04-07_at_8.40.23_PM.png
Attachment 2: Unknown-3.png
Unknown-3.png
Attachment 3: Unknown-4.png
Unknown-4.png
  16764   Thu Apr 7 20:37:06 2022 TommyUpdateElectronicsRFSoC 2x2 Board -- Simple Tone Generator

In the "Tommy" sub folder, I created a new notebook called "SimpleToneGenerator". This tunes the DAC and ADC mixers to a single frequency and reads off the Time Series and Fourier components. We can alos easily check the demodulation scheme and implement butterworth filters to check their function.

  16763   Thu Apr 7 20:33:42 2022 TommyUpdateElectronicsRFSoC 2x2 board -- setup for remote work

To access the board remotely through the 40m lab ethernet port, use

ssh -N -L localhost:1137:localhost:9090 xilinx@<ip_address>

Then in the browser go to

localhost:1137/lab

Other SSH commands using different ports or without the -N -L seemed to fail to open Jupyter. This way has been successful thereafter.

Quote:

[Tommy, Paco]

Since last week I've worked with tommy on getting the RFSoC 2x2 board to get some TFs from simple minicircuits type filters. The first thing I did was set up the board (which is in the office area) for remote access. I hooked up the TCP/IP port to a wall ethernet socket (LIGO-04) and the caltech network assiggned some IP address to our box. I guess eventually we can put this behind the lab network for internal use only.

After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP.

We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

 

  16689   Tue Mar 1 16:01:14 2022 PacoUpdateElectronicsRFSoC 2x2 board -- setup for remote work & BALUN saga

[Tommy, Paco]

Since last week I've worked with tommy on getting the RFSoC 2x2 board to get some TFs from simple minicircuits type filters. The first thing I did was set up the board (which is in the office area) for remote access. I hooked up the TCP/IP port to a wall ethernet socket (LIGO-04) and the caltech network assiggned some IP address to our box. I guess eventually we can put this behind the lab network for internal use only.

After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP.

We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

Attachment 1: balun_adc1.png
balun_adc1.png
Attachment 2: PXL_20220302_001734121.jpg
PXL_20220302_001734121.jpg
  16767   Fri Apr 8 16:03:58 2022 ranaUpdateElectronicsRFSoC 2x2 board -- setup for remote work & BALUN saga

Seems like it should be possible to just remove the transformer (aka as a BALUN ... BALanced, UNbalanced), or replace it with a lower frequency part. Its just a usual mini-circuits part. Maybe you can ask Chris Stoughton about this and ask Tommy to checkout some of the RFSoC user forums for how to go to DC.

Quote:
 

After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP.

We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

 

  16790   Wed Apr 20 14:56:06 2022 TommyUpdateElectronicsRFSoC 2x2 board -- setup for remote work & BALUN saga

Here are a few options for replacement BALUNs from Mini Circuits and specs:

Current. TCM1-83X+, 10-8000 MHz, 50 Ohms, Impedance Ratio 1, Configuration K

1. Z7550-..., DC-2500 MHz (some DC-2300), 50/75 Ohms, Impedance Ratio 1.5, Configuration Q. There are various types of the Z7550 which have different connectors (SMA and BNCs). These have much larger dimensions than the TCM1-83X. Can handle up to 5A DC current with matching loss 0.6 dB.

2. SFMP-5075+, DC-2500 MHz, 50/75 Ohms, Impedance Ratio 1.5, Configuration D. This is an SMA connected BALUN. It can handle 350mA, has a matching loss 0.4 dB, and has 1W power handling.

Quote:

Seems like it should be possible to just remove the transformer (aka as a BALUN ... BALanced, UNbalanced), or replace it with a lower frequency part. Its just a usual mini-circuits part. Maybe you can ask Chris Stoughton about this and ask Tommy to checkout some of the RFSoC user forums for how to go to DC.

Quote:
 

After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP.

We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

 

model_no case_style single2single single2bal bal2bal center_tap dc_iso freq_low freq_high impedance imped_ratio interface tech config
SFMP-5075+ FF1891 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE D
TCM1-83X+ DB1627 N Y Y N N 10 8000 50 1 SMT CORE & WIRE K
Z7550-BFNF+ H795-14 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE Q
Z7550-BMBF+ QP1876-1 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE D1
Z7550-BMNF+ QP1876 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE Q
Z7550-FFNM+ H795-1 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE Q
Z7550-FFSF+ H557-1 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE Q
Z7550-FMSF+ H795-3 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE Q
Z7550-FMSFDC+ H795-3 Y N N N Y 1 2500 50/75 1.5 CON CORE & WIRE Q
Z7550-NFNF+ H795-10 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE D1
Z7550-NMNF+ H795-4 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE Q
  16588   Fri Jan 14 14:04:51 2022 PacoUpdateElectronicsRFSoC 2x2 board arrived

The Xilinx RFSoC 2x2 board arrived right before the winter break, so this is kind of an overdue elog. I unboxed it, it came with two ~15 cm SMA M-M cables, an SD card preloaded with the ARM processor and a few overlay jupyter notebooks, a two-piece AC/DC adapter (kind of like a laptop charger), and a USB 3.0 cable. I got a 1U box, lid, and assembled a prototype box to hold this board, but this need not be a permanent solution (see Attachment #1). I drilled 4 thru holes on the bottom of the box to hold the board in place. A large component exceeds the 1U height, but is thin enough to clear one of the thin slits at the top (I believe this is a fuse of some sort). Then, I found a brand new front panel, and drilled 4x 13/32 thru holes in the front for SMA F-F connectors.

I powered the board, and quickly accessed its tutorial notebooks, including a spectrum analyzer and signal generators just to quickly check it works normally. The board has 2 fast RFADCs and 2 RFDACs exposed, 12 and 14 bit respectively, running at up to 4 GSps.

Attachment 1: PXL_20220114_211249499.jpg
PXL_20220114_211249499.jpg
  16857   Mon May 16 14:46:35 2022 TommyUpdateElectronicsRFSoC MTS Work

We followed the manual's guide for setting up MTS to sync on external signal. In the xrfdc package, we update the RFdc class to have RunMTS, SysRefEnable, and SysRefDisable functions as prescribed on page 180 of the manual. Then, we attempted to run the new functions in the notebook and read the DAC signal outputs on an oscilloscope. The DACs were not synced. We were also unable to get FIFOlatency readings. 

  16879   Fri May 27 15:53:17 2022 TommyUpdateElectronicsRFSoC MTS Work

With some help from the forums, we printed the status of the DAC MTS sync and were able to determined that our board's vivado design does not have MTS enabled on each tile. To fix this, we will need to construct a new Vivado desgin for the board. We were also warned to "make sure to generate correctly a PL_clock and a PL_sysref with your on board clock synthesizers and to capture them in the logic according to the requirements in PG269" of the RF Manual. From this we should be able to sync the DAC and ADC tiles as desired.

Quote:

We followed the manual's guide for setting up MTS to sync on external signal. In the xrfdc package, we update the RFdc class to have RunMTS, SysRefEnable, and SysRefDisable functions as prescribed on page 180 of the manual. Then, we attempted to run the new functions in the notebook and read the DAC signal outputs on an oscilloscope. The DACs were not synced. We were also unable to get FIFOlatency readings. 

 

  16876   Thu May 26 15:55:10 2022 TommyUpdateElectronicsRFSoC Power Spectrum

Finished building power spectrum analyzer for the RFSoC. There are two things that I would like to address down the road. First is that there is an oscillation between positive and negative voltages at the ADC sampling frequency. This creates an undesirable frequency component at the sampling rate. I have not yet figured out the cause of this positive to negative oscillation and have simply removed half of the samples in order to recover the frequency. Therefore, I would like to figure out the root of this oscillation and remove it. Also, we have a decimation factor of 2 as default by the board which we would like to remove but have been unable to do so.

Example: 8 MHz Square Wave from SRL signal generator.

Attachment 1: Screen_Shot_2022-06-02_at_2.51.23_PM.png
Screen_Shot_2022-06-02_at_2.51.23_PM.png
  16813   Tue Apr 26 16:23:22 2022 TommyUpdateElectronicsRFSoC2x2 MTS

We connected a 8 MHz signal generator to the device in order to sync up the ADCs and DACs and hopefully get phase data. 

Some things to note:

  • RF Manual (143)- Need to use XRFDC SYSREF for update event
  • RF Manual (171)- Synchronization steps require us to first enable all clocks and sysref generators (via xrfdc package)
  • RF Manual (173)- Sysref requirments, not clear if PL is syncing as needed.
  • RF Manual (181)- XRFDC example code, see also https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/rfdc/examples/xrfdc_mts_example.c

Xilinx RF Manual: https://docs.xilinx.com/v/u/2.4-English/pg269-rf-data-converter

  12086   Thu Apr 21 15:12:38 2016 SteveUpdateVACRGA is not working

 

Quote:

Steve pointed out that in the aftermath of the Nitrogen running out a couple of times last week, the RGA had shut itself off thinking that there was a leak and so it was not performing the scheduled scans once a day. So the data files from the scheduled scans were empty in the /opt/rtcds/caltech/c1/scripts/RGA/logs directory. The wiki page for getting it up and running again is up-to-date, but the script RGAset.py did not exist on the c0rga machine, which the RGA is communicating with via serial port. I copied over the script RGAset.py from rossa to c0rga and ran the script on that machine - but the error flags it returned were not all 0 (indicating some error according to the manual) - so I edited the script to send just the initialize command ('IN0') and commented out the other commands, after which I got error flags which were all 0. After this, I ran a manual scan using 'RGAlogger.py', and it appears that the RGA is now able to take scans again - I'm attaching a plot of the scan results. We've saved this scan as a reference to compare against after a few days. 

Our last RGA scan is from February 14, 2016  We had a power outage on the 15th

Gautom has not succeded  reseting it. The old c0rga computer looks dead. Q may resurrect it, if he can?

  16820   Fri Apr 29 08:34:40 2022 JCUpdateVACRGA Pump Down

Jordan and I, in order to start pumpig down the RGA Volume, we began by opening V7 and VM. Afterwards, we started RP1 and RP3. After this, the pressure in the line between RP1, RP3, and V6 dropped to 3.4 mTorr. Next, we tried to open V6, although an error message popped up. We haven't been able to erase it since. But we were able to turn on TP2 with V4 closed. The pressure in that line is reporting 1.4 mTorr.

 

PRP on the sitemap is giving off an incorrect pressure for the line between RP1, RP3, and V6. This is verified by the pressure by the control screen and the physical controller as well. 

Attachment 1: Screen_Shot_2022-04-29_at_8.46.53_AM.png
Screen_Shot_2022-04-29_at_8.46.53_AM.png
  16825   Tue May 3 13:18:47 2022 JCUpdateVACRGA Pump Down

Jordan, Tega, JC

Issue has been resolved. Breaker on RP1 was tripped so the RP1 button was reporting ON, but was not actually on which continuously tripped the V6 interlock. Breaker was reset, RP1 and RP3 turned on. The V6 was opened to rough out the RGA volume. Once, pressure was at ~100mtorr, V4 was opened to pump the RGA with TP2. V6 was closed and RP1/3 were turned off.

RGA is pumping down and will take scans next week to determine if a bakeout is needed

Quote:

Jordan and I, in order to start pumpig down the RGA Volume, we began by opening V7 and VM. Afterwards, we started RP1 and RP3. After this, the pressure in the line between RP1, RP3, and V6 dropped to 3.4 mTorr. Next, we tried to open V6, although an error message popped up. We haven't been able to erase it since. But we were able to turn on TP2 with V4 closed. The pressure in that line is reporting 1.4 mTorr.

 

PRP on the sitemap is giving off an incorrect pressure for the line between RP1, RP3, and V6. This is verified by the pressure by the control screen and the physical controller as well. 

 

  16777   Thu Apr 14 09:04:30 2022 JordanUpdateVACRGA Volume RGA Scans

Prior to venting the RGA volume on Tuesday (4/12/2022) I took an RGA scan of the volume to be vented (RGA+TP1 volume+Manual Gate Valve) to see if there was a difference after replacing the manual gate valve. Attached is the plot from 4/12/22, and an overlay plot to complare 4/12/22 to 12/10/2021, when the same volume was scanned with the old (defective) manual gate valve.

There is a significant drop in the ratio O2 compared the the nitrogen peak and reduced Argon (AMU 40) which indicates there is no longer a large air leak.

12/10/21 N2/O2 ratio ~ 4 (Air 78%N2 / 21%O2)

4/12/22 N2/O2 ratio ~ 10      

There is one significant (above noise level) peak above AMU 46, which is at AMU 58. This could possibly be acetone (AMU 43 and 58) but overall the new RGA Volume scans look significantly better after the manual gate valve replacement. Well done!

Attachment 1: 40mRGA_Overlay.pdf
40mRGA_Overlay.pdf
Attachment 2: RGAVolume_4_12_22.PNG
RGAVolume_4_12_22.PNG
  12116   Thu May 12 14:29:58 2016 gautamUpdateVACRGA back up and running

It looks like the hardware reset did the trick. Previously, I had just tried ssh-ing into c0rga and rebooting it. At the time, however, Steve and I noticed that the various LEDs on the RGA unit weren't on, as they are supposed to be in the nominal operating state. Today, Steve reported that all LEDs except the RS232 one were on today, so I just tried following the steps in this elog again, looks like things are back up and running. I'm attaching a plot of the scan generated using plotrgascan MATLAB script, it looks comparable to the plot in elog 11697, which if I remember right, was acceptable.

Unless there is some reason we want to keep this c0rga machine, I will recommission one of the spare Raspberry Pis lying around to interface with the RGA scanner when I get the time...

Quote:
Quote:

Our last RGA scan is from February 14, 2016  We had a power outage on the 15th

Gautom has not succeded  reseting it. The old c0rga computer looks dead. Q may resurrect it, if he can?

The c0rga computer was off, I turned it on via front panel button. After running RGAset.py, RGAlogger.py seems to run. However, there are error messages in the output of the plotrgascan MATLAB script; evidiently there are some negative/bogus values in the output. 

I'll look into it more tomorrow.

This is a cold scan.

Attachment 1: RGAscan_12May2016.png
RGAscan_12May2016.png
  8963   Mon Aug 5 10:50:48 2013 SteveUpdateVACRGA background

 RGA background at day 12 of this vent . The maglev is pumping on the rga through VM2

 

Attachment 1: v75bgMd12.png
v75bgMd12.png
  7939   Thu Jan 24 14:40:09 2013 SteveUpdateVACRGA backgroung

 RGA background with VM2 open to Maglev at day 37

 

Note: The PAN gauge of the  annulos is at atm.  Please do not vent this 200 ft long annulos line when you venting the annulos of a chamber. The chamber annulos should be closed off to this long 2"  OD. pipe before you vent the annulos of a chamber.

 

Attachment 1: Screenshot.png
Screenshot.png
  10548   Mon Sep 29 10:29:25 2014 SteveUpdateVACRGA is not running

 

 The RGA time stamp was correct last at 20140527

 

  Rga stopped scanning at 20140530

Attachment 1: rgascanTimeStamp.png
rgascanTimeStamp.png
  12530   Tue Oct 4 11:02:31 2016 SteveUpdateVACRGA is out of order

The last good rga scan at vent 78  day 38

Quote:

 

Quote:

RGA background scan

Quote:

Vacuum Status: Chamber Open

All chamber annuloses are vented.  Vac Monitor screen is not communicating with gauges. The valve position indicator are working.

RGA is pumped by Maglev through VM2

 

 

 

 

Attachment 1: lastBGscan.png
lastBGscan.png
  12589   Mon Oct 31 16:20:50 2016 SteveUpdateVACRGA is reinstalled

Quad rods and  ionizer kit: consisting of repeller cage, anode grid, focus plate and  filament were replaced....... under repair # RGA200/12 ECA 100416-12967

The electronic ECU is not connected. It is beeing pumped at IFO ITcc 9.7E-6 Torr vacNormal

Quote:

The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.

 

 

  12633   Tue Nov 22 11:31:52 2016 SteveUpdateVACRGA is running again

The Rga was turned on yesterday.

Quote:

The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.

 

 

Attachment 1: RGAisBack33d.png
RGAisBack33d.png
Attachment 2: pd80-560Hz-d33.png
pd80-560Hz-d33.png
Attachment 3: afterRepair1d.png
afterRepair1d.png
  1674   Mon Jun 15 16:31:36 2009 steveConfigurationVACRGA is scanning new Maglev

Quote:

Quote:

Joe and Steve

 

The retrofitted Osaka 390 was installed on the pumpspool yesterday.

V1 gate valve is disabled for safety by disconnected pneumatic power plug.

The foreline of this maglev now have a KF25 size viton o-ring directly on the turbo.

This is bad for leak hunting.

Joe is ready with new interface cable. Power supply and cables are in place.

The maglev was pumped down this morning.

All new gas kits and metal hose were leak checked by sprayed methanol.

There is no obvious sign of leak. I was expecting the pressure to drop below 1e-5 Torr in one hour.

TP2 is drying out the levitating coils of the turbo at ~7 l/s for N2

We'll start the pump as soon as Joe is in.

 

 

 Joe and Steve

 

The Maglev is running at 680 Hz, 40,800 RPM with V1 gate valve  closed and  valve disabled to change position. C1vac2 was rebooted before starting.

Interlocks are not tested yet, but the medm COVAC_MONITOR.adl screen is reading correctly. RGA scan will determine the need for baking on Monday

The foreline pressure is still  ~2e-5 Torr

Acceleration takes 3 minutes 30sesconds without load. There is no observabale temp effect on the body of the turbo during braking and acceleration.

 

The IFO is still pumped by the CRYO only

 The new Maglev fore line pressure is at 4e-6 torr at day 3

Valve VM1 was closed to isolate IFO from RGA and valve VM2 was opened so the RGA can scan the Maglev only.

 

  4133   Tue Jan 11 11:39:45 2011 steveUpdateVACRGA is turned on

Joe updated the rga procedure in the wiki and we turned on the filament. It will take a few days to reach thermal equilibrium.

TP2 dry fore pump was replaced at 910mTorr

Attachment 1: pd70d22.jpg
pd70d22.jpg
  1448   Wed Apr 1 10:22:13 2009 steveUpdateVACRGA logging is working

Thanks to Joe B who made the SRS RGA working with linux

Last data file logged at 2008 Oct 24 with old Dycor unit

First data file logged at  2009 Feb 10 with SRS

 

Attachment 1: rga-090401.png
rga-090401.png
  16701   Fri Mar 4 18:12:44 2022 KojiUpdateVACRGA pumping down

1. Jordan reported that the newly installed Pirani gauge for P2 shows 850Torr while PTP2 show 680 Torr. Because of this, the vacuum interlock fails when we try to open V4.

2. Went to c1vac. Copied the interlock setting file interlock_conditions.yaml to interlock_conditions_220304.yaml
3. Deleted diffpressure line and pump_underspeed line for V4
4. Restarted the interlock service

controls@c1vac:/opt/target/python/interlocks$ sudo systemctl status interlock.service  
controls@c1vac:/opt/target/python/interlocks$ sudo systemctl restart interlock.service
controls@c1vac:/opt/target/python/interlocks$ sudo systemctl status interlock.service

5. The above 2~4 was unnecessary. Start over.


Let RP1/3 pump down TP1 section through the pump spool. Then let TP2 pump down TP1 and RGA.

1. Open V7. This made P2 a bit lower (P2 is alive) and P3.
2. Connected the main RP tube to the RP port.
2. Started RP1/3. PRP quickly reaches 0.4Torr.
3. Opened V6 this made P3 and O2 below 1Torr.
4. Close V6. Shutdown RP1/3. Disconnect the RP tube.
5. Turn on auxRP at the wall powe
6. Turn on TP2. Wait for the starting up.
7. Open V4. Once the pressure is below Pirani range, open VM3.
8. Keep it running over the weekend.

9. Once TP2 reached the nominal speed, the "StandBy" button was clicked to lower the rotation speed (for longer life of TP2)

Attachment 1: Screenshot_2022-03-04_19-38-11.png
Screenshot_2022-03-04_19-38-11.png
  12537   Fri Oct 7 10:29:57 2016 SteveUpdateVACRGA removed

The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.

 

Attachment 1: RGAremoved.png
RGAremoved.png
  13233   Mon Aug 21 14:53:32 2017 gautamUpdateVACRGA reset

[gautam, steve]

In the aftermath of the accidental vent, it looks like the RGA was shutdown.

We followed the instructions in this elog to restart the RGA.

Seems to be working now, Steve says we just need to wait for it to warm up before we can collect a reliable scan.

Quote:

We have good RGA scan now. There was no scan for 3 months.

 

  2137   Fri Oct 23 09:13:45 2009 steveSummaryVACRGA scan

Pump down #66 is 435 days old. RGA scan is normal. New maglev is fine. New UPS is in place but not hooked up to communicate.

V1 has bare minimum interlock. Pirani vacuum gauges  PTP1 and PRP do not communicate with readout system.

There is no emergency dial out in case of vacuum loss.  Our existing vacuum dedicated desk top computer is dead.

New cold cathodes, Pirani gauges and gauge controller should be added.

In general: vacuum system needs an upgrade !

 

Attachment 1: pd66md435.jpg
pd66md435.jpg
Attachment 2: pd66d435ptt.jpg
pd66d435ptt.jpg
  4273   Fri Feb 11 09:27:03 2011 steveConfigurationVACRGA scan

The RGA scan is normal at day 52 of this pump down.

Light power BS 1064nm ~25mW, ETMX 532nm ~5mW

Attachment 1: rgascan20110211.jpg
rgascan20110211.jpg
Attachment 2: pressurepd70.jpg
pressurepd70.jpg
  5497   Wed Sep 21 11:35:07 2011 steveUpdateVACRGA scan

RGA scan with maglev pumping speed at day 14 of the pump down.

The larger inserted box contains the tuning parameters of the SRS  200 amu RGA

Attachment 1: rgascanpd71m14d.jpg
rgascanpd71m14d.jpg
ELOG V3.1.3-