Using 2 dBm for a Level 7 mixer is so bogus, that I will dismantle this as soon as I come over.
PLEASE DO NOT DISMANTLE THE SETUP !
Actually we tried looking for a level-3 or a smaller mixer, but we didn't find them at that moment. That's why we kept the level-7 mixer for the coarse path.
As you pointed out we can try an RF amplifier for it.
Something happened about 8 years ago.
Old iLog entry by AJW (2003/Sep/8)
Old iLog entry by AJW (2003/Sep/9)
Last night I noticed that PZT1 didn't work properly
Rana and I found that the QPD for the optical lever at X end are showing small signals.
At this moment each of the segments exhibits approximately 200 counts when the oplev beam is centered.
These small numbers may be due to the coating of ETMX, but we are not sure.
Probably we have to increase the gain of the QPD depending on situations.
So a set of the tomorrow's daytime task is:
1. check the trend data of the QPD outputs to see how much signals were there in the past.
2. check the whitening filters to make sure if it's on or off.
3. If it's necessary, increase the gain of the QPD to have reasonable readouts.
I am going to ask somebody to do this task.
We added a channel on c1psl in order to monitor the temperature of the PPKTP sitting on the PSL table.
To take continuous data of the temperature we added the channel by editing the file: target/c1psl/c1psl.db
We named the channel "C1:PSL-PPKTP_TEMP".
To reflect this change we physically rebooted c1psl by keying the crate.
Is this a setpoint temperature that we can change by writing to the channel or is it a readout of the actual temperature of the oven?
This is a readout channel just to monitor the actual temperature.
This did the trick - I simply ran
sudo systemctl restart daqd_*
on FB1, and now all the CDS overview lights are green again.
I thought I had done this already, but I realize that I was supposed to restart the daqd processes on FB1 (which is where they are running) and not on c1ioo .
Thanks Jamie for the speedy resolution!
From page 21 of T1100625, DAQ status "0x2000" means that the channel list is out of sync between the front end and the daqd. This usually happens when you add channels to the model and don't restart the daqd processes, which sounds like it might be applicable here.
It looks like open-mx is loaded fine (via "rtcds lsmod"), even though the systemd unit is complaining. I think this is because the open-mx service is old style and is not intended for module loading/unloading with the new style systemd stuff.
Huge random numbers are flowing into ETMX/ETMY ASC PIT/YAW. Because of this, I could not damp the ETMX/ETMY suspension at the beginning during the recovery from rebooting. (Attachment 1)
By turning off the output of the ASC filters, the mirrors were successfully damped.
Looking at the FE model view of the end RTSs, there were two possibilities: (Attachment 2)
- They are coming from RFM connection
- They are coming from ASXASY
ASX/ASY are not active and I could not see anything producing these numbers. Burtrestore didn't help.
The possibility was something at the other side of the RFM, or corruption of the RFM signal.
- Looking at the RFM model (Attachment 3), the ASC signals are coming from ASS and IOO. The ASS path has the filter module (C1:RFM-ETMX_PIT and etc). This FM is quiet and not guilty.
- Why do we have the RFM from IOO? I went to IOO and found the new ASC (WFS) model is there. I didn't realize the presence of this model. In fact ASC screen showed that these random numbers are flowing into the end SUSs.
So I did burtrestore of c1iooepics. Alas! they are gone.
Now I can go home.
Yeah, this is a known issue actually. We go to ASC screen and manually swich off all the outputs after every reboot. We haven't been able to find a way to set default so that when the model comes online, these outputs remain switched off. We should find a way for this.
you can hand edit the autoBurt file which the FE uses to set the values after boot up. Just make a python script that amends all of the OFF or ZERO that are needed to make things safe. This would be the autoBurt snap used on boot up only, and not the hourly snaps.
The autoBurt file for FE already has the C1:ASC-ETMX_PIT_SW2 (and other channels for ETMY, ITMX, ITMY, BS and for YAW) present, and I checked the last snapshot file from Feb 7th, 2022, which has 0 for these channels. So I'm not sure why when FE boots up, it does not follow the switch configuration. Fr safety, I changed all the gains of these filter modules, named like C1:ASC-XXXX_YYY_GAIN (where XXXX is ETMX, ETMY, ITMX, ITMY, or BS , and YYY is PIT or YAW) to 0.0. Now, even if the FE loads with switches in ON configuration, nothing should happen. In future, if we use this model for anything, we can change the gain values which won't be hard to track as the reason why no signal moves forward. Note, the BS connections from this model to BS suspension model do not work.
When I finished my measurements, the modulation setup was reverted to the conventional one.
If someone wants to use the 3f cancellation setting, it can be done along with this HOW-TO.
The 3f cancellation can be realized by adding a carefully adjusted delay line and attenuation for the 55MHz modulation
on the frequency generation box at the 1X2 rack. Here is the procedure:
1) Turn off the frequency generation box
There is a toggle switch at the rear of the unit. It's better to turn it off before any cable action.
The outputs of the frequency generation box are high in general. We don't want to operate
the amplifiers without proper impedance matching in any occasion.
2) Remove the small SMA cable between 55MHz out and 55MHz in (Left arrow in the attachment 1).
According to the photo by Alberto (svn: /docs/upgrade08/RFsystem/frequencyGenerationBox/photos/DSC_2410.JPG),
this 55MHz out is the output of the frequency multiplier. The 55MHz in is the input for the amplifier stages.
Therefore, the cable length between these two connectors changes the relative phase between the modulations at 11MHz and 55MHz.
3) Add a delay line box with cables (Attachment 2).
Connect the cables from the delay line box to the 55MHz in/out connectors. I used 1.5m BNC cables.
The delay line box was set to have 28ns delay.
4) Set the attenuation of the 55MHz EOM drive (Right arrow in the attachment 1) to be 10dB.
Rotate the attenuation for 55MHz EOM from 0dB nominal to 10dB.
5) Turn on the frequency modulation box
For reference, the 3rd attachment shows the characteristics of the delay line cable/box combo when the 3f modualtion reduction
was realized. It had 1.37dB attenuation and +124deg phase shift. This phase change corresponds to the time delay of 48ns.
Note that the response of a short cable used for the measurement has been calibrated out using the CAL function of the network analyzer.
c1x01 timing issue was solved. Now all of the models on c1iscex are nicely running.
- c1x01 was synchronized to 1PPS in stead of TDS
- C1:DAQ-DC0_C1X01_STATUS (Upper right indicator) was red. The bits were 0x4000 or 0x2bad.
C1:DAQ-DC0_C1X01_CRC_SUM kept increasing
- c1scx, c1spx, c1asx could not get started.
- login to c1iscex "ssh c1iscex"
- Run "sudo shutdown -h now"
sudo shutdown -h now
- Walk down to the x end rack
- Make sure the supply voltages for the electronics are correct (See Steve's entry)
- Make sure the machine is already shutdown.
- Unplug two AC power supply of the machine.
- Turn off the front panel switch of the IO chassis
- Wait for 10sec
- Turn on the IO chassis
- Plug the AC power supply cables to the machine
- Push the power switch of the realtime machine
Rana showed me that if c1sus machine runs c1mcs stuff(and c1x02 stuff) only, we can use dataviewer without crashing fb.
Also, if we set correct NDS server and port(fb/8088), we can use diaggui on every machine.
During my investigation on what he did, I accidentally deleted daqd......
I am very very sorry.
I don't know if it helps or not, but all I have is the following information:
[What I deleted]
-rwxr-xr-x 1 controls controls 6583071 Oct 1 11:57 daqd
[help message for daqd existed]
CDS Data Acquisition Server, Frame Builder, version 2.0
California Institute of Technology, LIGO Project
Client communication protocol version 11.4
daqd [-f <input frame file name>]
[-c <configuration file (default -- $HOME/.daqdrc)>]
[-s <frame writer pause usec (default -- 1 sec)>]
This executable compiled on:
Fri Oct 1 10:33:18 PDT 2010
Linux fb 22.214.171.124 #7 SMP Fri Sep 24 14:09:53 PDT 2010 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux
Please help me, Joe.
Missing daqd file, i.e. the framebuilder executable.
1) Go to /opt/rtcds/caltech/c1/core/advLigoRTS/
2) Look in the Makefile for a likely build suspect. In this case it was build dc, which stands for data concentrator.
3) So we ran "make dc"
4) Go to the sub-directory build/dc/ and then copy the daqd file there to the /opt/rtcds/caltech/c1/target/fb directory
5) Test it to ensure we're getting channels (Yay!)
Place the new target directory under SVN control.
3f modulation cancellation theory http://nodus.ligo.caltech.edu:8080/40m/11005
3f modulation cancellation adjustment setup http://nodus.ligo.caltech.edu:8080/40m/11029
Receipe for the 3f modulation cancellation http://nodus.ligo.caltech.edu:8080/40m/11032
Modulation depth analysis http://nodus.ligo.caltech.edu:8080/40m/11036
I wonder if DRMI can be locked on 3f using this lower 55 MHz modulation depth. It seems that PRMI should be unaffected, but that the 3*f2 signals for SRCL will be too puny. Is it really possible to scale up the overall modulation depths by 3x to compensate for this?
This KTP crystal has the maximum allowed RF power of 10W (=32Vpk) and V_pi = 230V. This corresponds to the maximum allowed
modulation depth of 32*Pi/230 = 0.44. So we probably can achieve gamma_1 of ~0.4 and gamma_2 of ~0.13. That's not x3 but x2,
so sounds not too bad.
Then Kiwamu's triple resonant circuit LIGO-G1000297-v1 actually shows the modulation up to ~0.7. Therefore it is purely an issue
how to deliver sufficient modulation power. (In fact his measurement shows some nonlinearity above the modulation depth of ~0.4
so we should keep the maximum power consumption of 10W at the crystal)
This means that we need to review our RF system (again!)
- Review infamous crazy attn/amp combinations in the frequency generation box.
- Use Teledyne Cougar ampilfier (A2CP2596) right before the triple resonant box. This should be installed closely to the triple resonant box in order to
minimize the effects of the reflection due to imperferct impedance matching.
- Review and refine the triple resonant circuit - it's not built on a PCB but on a universal board. I think that we don't need triple
resonance, but double is OK as the 29.5MHz signal is small.
We want +28V supply at 1X1 for the Teledyne amp and the AOM driver. Do we have any unused Sorensen?
On Friday, I grabbed the Zurich Instruments HF2LI lock-in amplifier and brought it home. As time permits, I will work towards developing a similar readout script as we have for the SR785.
I returned the Zurich Instruments analyzer I borrowed some time ago to test out at home. It is sitting on first table across from Steve's old desk.
It took at least ten years to rust away.
We have no coffee machine.
We are dreaming about it
We still do not have it.
New all organic machine.
Updated IOO.strip on Zita to show WFS2 pitch and yaw trends (C1:IOO-WFS2_PIY_OUT16 and C1:IOO-WFS2_YAW_OUT16) and changed the colors slightly to have all pitch trends in the yellow/brown band and all yaw trends in the pink/purple band.
No one says, "Here I am attaching a cool screenshot, becuz else where's the proof? Am I right or am I right?"
Mon May 24 18:10:07 2021 [Update]
After waiting for some traces to fill the screen, here is a cool screenshot (Attachment 1). At around 2:30 PM the MC unlocked, and the BS_Z (vertical) seismometer readout jumped. It has stayed like this for the whole afternoon... The MC eventually caught its lock and we even locked XARM without any issue, but something happened in the 10-30 Hz band. We will keep an eye on it during the evening...
Tue May 25 08:45:33 2021 [Update]
At approximately 02:30 UTC (so 07:30 PM yesterday) the 10-30 Hz seismic step dropped back... It lasted 5 hours, mostly causing BS motion along Z (vertical) as seen by the minute trend data in Attachment 2. Could the MM library have been shaking? Was the IFO snoring during its afternoon nap?
and so it begins...until this is finished I have turned off the projector and moved the striptools to the big TV (time to look for Black Friday deals to replace the projector with a 120 inch LED TV)
the upgrade seems to have been successfully executed - the machine was restarted at ~430pm local time. Projector remains off and diagnostic striptools are on the samsung.
Initially I was using RFPD-1611to get the IR beat frequency. Its gain was not very high, so I was getting a very low signal of power -37 dBm.
I used ZHL-32A-S with a gain of 25 dBm to amplify it before feeding it into the spectrum analyser.
I connected the ground of the amplifier circuit to the red of the power supply, which blew the amplifier.
I learnt that there is a small tab indicating the ground side of the BNC to banana connectors which I should have noticed.
I learnt to plug in the side with th little tab on it into the ground of the power supply. (Learnt it the hard way I guess!!)
Our visiting graduate student Yuta Michimura received 40m specific basic safety training today.
Yoichi's final words on what do next with the interferometer (as of 5 PM on May 21, 2009):
My personal sub-comments to these bullets:
No exciting progress today. I did PSL green alignment for the Yarm, although I now think that the Xarm green needs realigning too.
Also, I was foiled for a while by ETMX jumping around. I think it's because the adapter board on the Xend rack didn't have any strain relief. So, I zip tied the heavy cable in a few places so that it's no longer pulling on the connector. Hopefully we won't see ETMX misbehaving as often now, so we won't have to go squish cables as often.
As discussed at the meeting, I decided to effect a satellite box swap for the misbehaving MC1 unit. I looked back at the summary pages Vmon for the SRM channels, and found that in the last month or so, there wasn't any significant evidence of glitchiness. So I decided to effect that swap at ~4pm today. The sequence of steps was:
One thing I was reminded of is that the motion of the MC1 optic by controlling the bias sliders is highly cross-coupled in pitch and yaw, it is almost diagonal. If this is true for the fast actuation path too, that's not great. I didn't check it just now.
While I was working on this, I took the opportunity to also check the functionality of the RF path of the IMC WFS. Both WFS heads seem to now respond to angular motion of the IMC mirror - I once again dithered MC2 and looked at the demodulated signals, and see variation at the dither frequency, see Attachment #1. However, the signals seem highly polluted with strong 60 Hz and harmonics, see the zoomed-in time domain trace in Attachment #2. This should be fixed. Also, the WFS loop needs some re-tuning. In the current config, it actually makes the MC2T RIN worse, see Attachment #3 (reference traces are with WFS loop enabled, live traces are with the loop disabled - sorry for the confusing notation, I overwrote the patched version of DTT that I got from Erik that allows the user legend feature, working on getting that back).
The MC1 suspension has begun to show evidence of glitches again, from Friday/Saturday. You can look at the suspension Vmon tab a few days ago and see that the excess fuzz in the Vmon was not there before. The extra motion is also clearly evident on the MCREFL spot. I noticed this on Saturday evening as I was trying to recover the IMC locking, but I thought it might be Millikan so I didn't look into it further. Usually this is symptomatic of some Satellite box issues. I am not going to attempt to debug this anymore.
[Jamie, Jenne, Manasa]
Yesterday's goal was to get the input beam centered on the PRM, the BS and ETMY simultaneously.
Steve helped us remove the ETMY door first thing in the morning. We then iterated with TT1, MMT1 and TT2 to try to get the beam centered on all the optics. We were using MMT1 instead of TT1 for a while, so that we could keep TT1 in the center of its range, so that we had more range to use once we pump down. Also, at one point, the beam was high on PRM, centered on BS, and high on ETMY, so Jamie poked PR3 a little bit. This helped, although we closed up for lunch / group meeting soon after, so we didn't finalize any alignment stuff.
We decided to leave the rest of the full IFO alignment alone until after the PRM-flat test.
Zach has just replied, and said that we should feel free to take the laser from his iodine setup in the West Bridge subbasement, in the ATF lab.
Annalisa, please ask Koji or Tara to show you where it is, and help you bring it to the 40m. You should install it (temporarily) on the PSL table, measure the waist, and find the beat in IR. Elog 3755 and elog 3759 have some of the details on how it has been done in the past.
Ok, I'm going to contact Koji.
1) Annalisa is going to start working on mode profiling and beat note search for the old MOPA NPRO.
2) In the meantime, Manasa is working on the end table items. This will be reviewed by KA in the afternoon.
The laser at ATF is moved to the 40m when the status of 1) and 2) is determined by KA to be reasonable.
We also make the beat note measurement for the ATF laser too.
We also make the beat note measurement for the ATF laser too.
Today I installed mirrors to steer the pick-off from the main laser beam in a more free part of the PSL table and make the beat note measurement between it and the NPRO.
At the beginning I took the beam from the harmonic separator after the doubling crystal, and I was going to bring it in a less full part of the table . At the end I realized that there was already a beam steered up to a more free part of the table, and the beam is taken from the transmission of the PMC.
Tomorrow I'm going to use that beam to find the beat note with the NPRO.
I also removed almost all the steering optics that I used on the ITMY table to send the auxiliary beam for ABSL through the window parallel to the POY beam. The most important thing is that I removed the BS, which was on the same path of the POY beam (see elog 8257).
In light of the Yend auxiliary laser's ill health, I think we should reconsider the possibility of changing out the Yend laser table next week.
My thinking here is that if whatever the new mode matching solution is for a replacement laser (Tara has borrowed our spare NPRO that used to sit on top of the fridge, or we could take Annalisa's) requires a rework of the table layout, we might as well put the new layout onto the new table. So, we need to figure out what laser we will put in as the new Ygreen, and what it's waist looks like. If it just requires a small movement of existing lenses or new lenses in similar positions to the current ones, we can keep living with our current table. But, if the mode matching solution requires enough changes to distances / lens placement / whatever, we should think seriously about putting in the new table next week.
Here's what I would like to see happen on / before Monday:
Annalisa - Mode matching solution for new laser. If we get the laser back from Tara, this will involve first measuring the waist, otherwise we already know the waist of the ABSL laser that Annalisa is currently using.
Annalisa and Steve - Find optics for new mode matching in the lab, or order them by Monday afternoon.
Manasa - List of every screw, washer, optic, mount, etc. that will go on the new Y end table, with a notation as to whether or not we have it in-hand, and if not, what needs to happen before we do. Also, for things that we don't have, I'd like to see a summary of temporary solutions (e.g. keep using current mount for doubling crystal while new one is being machined).
Manasa / Annalisa / Koji - will the new mode matching solution fit within the existing layout, or do we need to redo the table layout?
I made a Simulation with COMSOL for the Yend table. Mainly, I tried to see how the lower eigenmode changes with the number and the size of the posts inside.
The lateral frame is just sitting on the table, it is fixed by its weight. I also put a couple of screws to fix it better, but the resulting eigenfrequency didn't change so much (less than 1 Hz).
In Fig. 1 I didn't put any post. Of course, the lowest eigenfrequency is very low (around 80 Hz).
Then I added 2 posts, one per side (Fig. 2 and Fig. 3), with different diameter.
In some cases posts don't have a base, but they are fixed to the table only by a screw. It is just a condition to keep them fixed to the table
Eventually I put 4 posts, 2 per side.
The lowest eigenfrequency is always increasing.
At the end I also put a simulation for 4 1.6 inch diameter posts without base, and the eigenfrequency is slightly higher. I want to check it again, because I would expect that the configuration shown in Fig.5a could be more stable.
P.S.: All the post are stainless steel.
To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable. The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it. Removing the shutter from the system did not change anything.
I re-plugged in the Yend shutter, and turned it on.
Details later - empty entry for a reply.
Short story - Yend is now same as Xend filters-wise and lack of gain sliders -wise. Both ends have 13.7k resistors around the AD620 to give them gains of ~4.5.
Xend seems fine.
Yend seems not fine. Even the dark noise spectrum sees giganto peaks. See Diego's elog 10801 for details on this investigation.
[Jenne, Rana, Diego]
We did some test on the modified QPD board for the Yend; we saw some weird oscillations at high frequencies, so we went and check more closely directly within the rack. The oscillations disappear when the cable from the QPD is disconnected, so it seems something is happening within the board itself; however, looking closely at the board with an oscilloscope in several locations, with the QPD cable connected or disconnected, there is nothing strange and definitely nothing changing if the cable is connected or not. In the plots there are the usual channels we monitor, and the 64kHz original channels before they are downsampled.
Overall it doesn't seem being a huge factor, as the RMS shows at high frequencies, maybe it could be some random noise coming up, but anyway this will be investigated further in the future.
Just as predicted, all realtime models reported "0x4000" error. Read the parent post for more details. I fixed this by following the instructions. I add folowing lines to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1:
Then is made the package and reloaded it after stoping the daqd services. This brought back all the fast models except C1SUS2 models which are in red due to some other reason that I'll investigate further.
Just restarting all the c1sus2 models fixed the issue. (Attachment 1)
SUS2 ADC1 CH21 is saturated. I'm not yet sure if this is the electronics issue or the ADC issue.
SUS2 ADC1 CH10 also has large offset. This should also be investiagted.
Every new year (on Dec 31 or Jan 1), all of the realtime models will report a "0x4000" error. This happens due to an offset to the GPStime driver not being updated. Here is how this can be fixed (slightly modified version of what was done at LASTI).
Steps to fix the DC errors:
/* 2019 had 365 days and no leap seconds */
pHardware->gpsOffset += 31536000;
/* 2019 had 365 days and no leap seconds */
pHardware->gpsOffset += 31536000;
sudo make install
sudo systemctl daqd_* stop
sudo modprobe -r symmetricom
sudo modprobe symmetricom
sudo service daqd_* start
Independent of this, there is a 1 second offset between the gpstimes reported by /proc/gps and gpstime. However, this doesn't seem to drift. We had effected a static offset to correct for this in the daqd config files, and it looks like these do not need to be updated on a yearly basis. All the daqd indicators are now green, see Attachment #1.
I dedicated my evening to trying to get the Ygreen beatnote (the idea being to then get the Xgreen beatnote).
First up was tweaking up the green alignment. Per Yuta's suggestion, elog 8283, I increased the refl PD gain by 2 clicks (20dB) to keep the lock super stable while improving the alignment. After I finished, I turned it back to its nominal value. I discovered that I need lenses in front of the DC PD (for Ygreen, and I'm sure Xgreen will be the same). The beam is just barely taking up the whole 2mm diode, so beam jitter translates directly to DC power change measured by the diode. I ended up going just by the green transmission camera for the night, and achieved 225uW of Ygreen on the PSL table. This was ~2,000 counts, but some of the beam is always falling off the diode, so my actual counts value should be higher after installing a lens.
I then opened up the PSL green shutter, which is controlled by the button labeled "SPS" on the shutter screen - I will fix the label during some coffee break tomorrow. Using my convenient new PSL green setup, removing the DC PD allows the beam to reflect all the way to the fuse box on the wall, so you can check beam overlap between the PSL green and the arm green at a range of distances. I did this for Ygreen, and overlapped the Ygreen and PSL green.
I checked the situation of the beat cabling, since Jamie has the beatbox out for whitening filter modifications tonight. In order to get some signal into the control room, I connected the output of the BBPD amplifier (mounted on the front of the 1X2 rack) directly to the cable that goes to the control room. (As part of my cleanup, I put all the cables back the way I found them, so that Jamie can hook everything back up like normal when he finishes the beatbox.)
I then started watching the signal on the 8591E analyzer, but didn't magically see a peak (one can always hope....).
I decided that I should put the offset in the Y AUX laser slow servo back to the value that we had been using for a long time, ~29,000 counts. This is where things started going south. After letting that go for a minute or two, I thought to go check the actual temperature of the laser head. The "T+" temperature on the controller read something like 42C, but the voltmeter which reads a voltage proportional to the temp (10C/V) was reading 5.6V. I immediately turned off the offset, but it's going to take a while for it to cool down, so I'll come back in the morning. I want the AUX laser to be something like 34C, so I just have to wait. Ooops.
Still to do (for the short-term FPMI):
* Find Y beatnote.
* Align Xgreen to the arm - it's still off in pitch.
* Align Xgreen and PSL green to be overlapped, hitting the BBPD.
* Find the X beatnote.
* Reinstall the beatbox.
* Use ALS to stabilize both arms' lengths.
* Lock MICH with AS.
* Look at the noise spectrum of AS - is there more noise than we expect (Yuta and Koji saw extra noise last summer), and if so, where does it come from? Yuta calculated (elog 6931) that the noise is much more than expected from just residual arm motion.
* Write a talk.
After much hassle, the Guralp cable from the ADC Out of the breakout box to the ADC is fixed, and everything is plugged in and working again. The seismometers are back in their regular positions at the ends of the MC, ready for some excellent seis/MC combo data.
I solidified the change of putting the Gur2Z channel into a different BNC input on the ADC. The C1ADCU_PEM.ini file has been changed so that what used to be the Ranger's channel is now recognized as Gur2Z.
Also, I changed the same .ini file to reflect Koji's move of ACC_MC1_Z to the old AUDIO_MIC2 channel, so now all 6 Accelerometer channels have the same calibrations again.
Another big change is the change from old-left-handed convention to new-right-handed convention. The seismometers are aligned the same way they always have been (with the North-South markers aligned with the MC), but now the North-South output is plugged into the BNC on the ADC that is associated with Gur*_X, and the East-West output is plugged into the ADC channel associated with Gur*_Y. This is true for both Guralp Seismometers.
So, now we have:
Gur1_X = Gur1_NS = ADC#10
Gur1_Y = Gur1_EW = ADC#11
Gur1_Z = Gur1_Vert = ADC#12
Gur2_X = Gur2_NS = ADC#2
Gur2_Y = Gur2_EW = ADC#3
Gur2_Z = Gur2_Vert = ADC#24
SEIS_Ranger_Y = no longer in the .ini file