ID |
Date |
Author |
Type |
Category |
Subject |
9683
|
Mon Mar 3 10:42:53 2014 |
Jenne | Update | CDS | fb timing was off |
...yet again.
lsc and sus needed mxstream restarts after I restarted the ntp on fb. |
9684
|
Mon Mar 3 11:55:39 2014 |
Koji | Update | CDS | fb timing was off |
We need to correctly setup crontab or rc.local for the frontend machines. |
9706
|
Mon Mar 10 11:42:36 2014 |
Jenne | Update | CDS | fb timing was off |
fb timing was off again. |
9732
|
Mon Mar 17 12:31:58 2014 |
manasa | Update | CDS | fb timing was off |
Off again. Restarted ntp on fb. |
3628
|
Thu Sep 30 16:29:35 2010 |
josephb, alex | Update | CDS | fb update |
There currently seems to be a timing issue with the frame builder. We switched over to using a symmetricom card to get an IRIG-B signal into the fb machine, but the gps time stamp is way off (~80 years Alex said).
If there is a frame buiilder issue, its currently often necessary to kill the associated mx_stream processes, since they don't seem to restart gracefully. To fix it the following steps should be taken:
Kill frame builder, kill the two mx_stream processes, then /etc/restart_streams/, then restart the frame builder (usual daqd -c ./daqdrc >& ./daqd.log in /opt/rtcds/caltech/c1/target/fb).
To restart (or start after a boot) the nds server, you need to go to /opt/rtcds/caltech/c1/target/fb and type
./nds /opt/rtcds/caltech/c1/target/fb/pipe
At this time, testpoints are kind of working, but timing issues seem to be preventing useful work being done with it. I'm leaving with Alex working on the code.
|
3632
|
Fri Oct 1 10:56:30 2010 |
josephb,alex | Update | CDS | fb work continued |
Alex fixed the time issue with the IRIG-B signal being far off, apparently their IRIG-B signal in downs seems to be different. He simply corrected for the difference in the two signals in the code.
For debugging purposes we uncommented the following line in the feCodeGen.pl script (in /opt/rtcds/caltech/c1/advLigoRTS/src/epics/util/):
print EPICS "test_points ONE_PPS $dac_testpoint_names $::extraTestPoints\n"
This is to make every ADC testpoint available from the IOP (such as c1x02). |
3635
|
Fri Oct 1 14:13:29 2010 |
josephb, alex | Update | CDS | fb work that still needs to be done |
1) Need to check 1 PPS signal alignment
2) Figure out why 1PPS and ADC/DAC testpoints went away from feCodeGen.pl?
3) Fix 1PPS testpoint giving NaN data
4) Figure out why is daqd printing "making gps time correction" twice?
5) Need to investigate why mx_streams are still getting stuck
6) Epics channels should not go out on 114 network (seen messages when doing
burt restore/save).
7) Dataviewer leaves test points hanging, daqd does not deallocate them
(net_Writer.c shutdown_netwriter call)
8) Need to install wiper scripts on fb
9) Need to install newer kernel on fb to avoid loading myrinet firmware
(avoid boot delay) |
4009
|
Fri Dec 3 15:37:10 2010 |
josephb | Update | CDS | fb, front ends fixed - tested RFM between c1ioo and c1iscex |
Problem:
The front ends and fb computers were unresponsive this morning.
This was due to the fb machine having its ethernet cable plugged into the wrong input. It should be plugged into the port labeled 0.
Since all the front end machines mount their root partition from fb, this caused them to also hang.
Solution:
The cable has been relabled to "fb" on both ends, and plugged into the correct jack. All the front ends were rebooted.
Testing RFM for green locking:
I tested the RFM connection between c1ioo and c1scx. Unfortunately, on the first test, it turns out the c1ioo machine had its gps time off by 1 second compared to c1sus and c1iscex. A second reboot seems to have fixed the issue.
However, it bothers me that the code didn't come up with the correct time on the first boot.
The test was done using the c1gcv model and by modifying the c1scx model. At the moment, the MC_L channel is being passed the MC_L input of the ETMX suspension. In the final configuration, this will be a properly shaped error signal from the green locking.
The MC_L signal is currently not actually driving the optic, as the ETMX POS MATRIX currently has a 0 for the MC_L component. |
16325
|
Tue Sep 14 15:57:05 2021 |
jamie | Frogs | CDS | fb1 /var full after reboot, caused all sorts of problems |
/var on fb1 filled up today, which caused all sorts of CDS issues. I found out about the problem by reading the logs of the services that were having trouble running, in which they complained about not being able to write to disk. I looked at the filesystem status with 'df' and noticed that /var was full, which is where applications write temporary data, and will always cause problems if it's full.
I tracked the issue down to multiple multi-gigabyte log files: /var/log/messages and /var/log/messages.1. They were full of lines like this one:
Aug 29 06:25:21 fb1 kernel: l called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl ca
Seems like something related to the gpstime kernel module?
Anyway, I deleted the log files for now, which cleared up the space on /var. Things should be back to normal now, until the logs fill up again... |
16327
|
Tue Sep 14 16:44:54 2021 |
jamie | Frogs | CDS | fb1 /var full after reboot, caused all sorts of problems |
Jonathan Hanks pointed me to this fix to the gpstime kernel module that was unfortunately put in after the 3.4 release that we're currently using:
https://git.ligo.org/cds/advligorts/-/commit/6f6d6e2eb1d3355d0cbfe9fe31ea3b59af1e7348
I hacked the source in place (/usr/src/gpstime-3.4/drv/gpstime/gpstime.c) to get the fix, and then rebuilt the kernel module with dkms :
sudo dkms uninstall gpstime/3.4
sudo dkms install gpstime/3.4
I then stopped daqd_dc, unloaded gpstime, reloaded it, restarted daqd_dc. The messages are no longer showing up in /var/log/messages, so I think we're ok for the moment.
NOTE: the fix will be undone if we for some reason reinstall the advligorts-gpstime-dkms package. There shouldn't be a need to do that, but we should be aware. I'm discussing with Jonathan if we want to try to push out a new debian package to fix this issue... |
17250
|
Wed Nov 9 14:19:18 2022 |
Tega | Update | CDS | fb1 OS migration |
[Tega, Chris]
We migrated fb1 OS from the teststand fb1 drive to the internal 2TB RAID of fb1. We then rebooted twice to check that we no longer have the fb1 booting issue.
The next step is to set up software RAID and backup for chiara, which we plan to complete this week. Then we would work on nodus and workstation OS upgrade next week. |
2626
|
Mon Feb 22 11:46:55 2010 |
josephb | Update | Computers | fb40m |
I fixed the JetStor 416S raid array IP address by plugging in my laptop to its ethernet port, setting my IP to be on the same subnet, and using the web interface. (After finally tracking down the password, it has been placed in the usual place).
After this change, I powered up the fb40m2 machine and reboot the fb40m machine. This seems to have made all the associated lights green.
Data viewer is working such that is recording from the point I fixed the JetStor raid array and did the fb40m reboot. It also can go back in time before the IP switch over. |
1554
|
Thu May 7 12:21:36 2009 |
josephb, alex | Configuration | Computers | fb40m |
Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.
We brought it down and up several times between 11 and noon. We eventually were able to daisy chain the old raid and the new raid so that fb40m sees both. At this time, the RAID arrays are still daisy chained, but the computer is setup to run on just the original raid, while the full 14 TB array is initialized (16 drives, 1 hot spare, RAID level 5 means 14 TB out of the 16 TB are actually available). We expect this to take a few hours, at which point we will copy the data from the old RAID to the new RAID (which I also expect to take several hours). In the meantime, operations should not be affected. If it is, contact one of us.
|
1555
|
Thu May 7 15:22:19 2009 |
josephb, alberto | Configuration | Computers | fb40m |
Quote: |
Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.
We brought it down and up several times between 11 and noon. We eventually were able to daisy chain the old raid and the new raid so that fb40m sees both. At this time, the RAID arrays are still daisy chained, but the computer is setup to run on just the original raid, while the full 14 TB array is initialized (16 drives, 1 hot spare, RAID level 5 means 14 TB out of the 16 TB are actually available). We expect this to take a few hours, at which point we will copy the data from the old RAID to the new RAID (which I also expect to take several hours). In the meantime, operations should not be affected. If it is, contact one of us.
|
This afternoon the alignment script chrashed after returning sysntax errors. We found that the tpman wasn't running on the framebuilder becasue it had probably failed to get restarted in one of the several reboots executed in the morning by Alex and Jo.
Restarting the tpman was then sufficient for the alignment scripts to get back to work. |
1746
|
Wed Jul 15 08:59:30 2009 |
steve | Update | Computers | fb40m |
The fb40m just went out of order with status indicator number 8
It recovered on its own five minutes later. |
1756
|
Thu Jul 16 09:49:52 2009 |
Alan | Update | Computers | fb40m |
Quote: |
The fb40m just went out of order with status indicator number 8
It recovered on its own five minutes later.
|
Backup script restarted, backup of trend frames and /cvs/cds is up-to-date.
|
2385
|
Thu Dec 10 13:13:08 2009 |
Jenne | Update | Computers | fb40m backup restarted |
The frame builder was power cycled during the morning bootfest. I have restarted the backup script once more. |
1574
|
Mon May 11 12:25:03 2009 |
josephb,Alex | Update | Computers | fb40m down for patching |
The 40m frame builder is currently being patched to be able utilize the full 14 TB of the new raid array (as opposed to being limited to 2 TB). This process is expected to take several hours, during which the frame builder will be unavailable. |
3600
|
Thu Sep 23 12:05:20 2010 |
josephb, alex | Update | CDS | fb40m down, new fb in progress |
Alex came over this morning and we began work on the frame builder change over. This required fb40m be brought down and disconnected from the RAID array, so the frame builder is not available.
He brought a Netgear switch which we've installed at the top of the 1X7 rack. This will eventually be connected, via Cat 6 cable, to all the front ends. It is connected to the new fb machine via a 10G fiber.
Alex has gone back to Downs to pickup a Symmetricon (sp?) card for getting timing information into the frame builder. He will also be bringing back a harddrive with the necessary framebuilder software to be copied onto the new fb machine.
He said he'd like to also put a Gentoo boot server on the machine. This boot server will not affect anything at the moment, but its apparently the style the sites are moving towards. So you have a single boot server, and diskless front end computers, running Gentoo. However for the moment we are sticking with our current Centos real time kernel (which is still compatible with the new frame builder code). However this would make a switch over to the new system possible in the future.
At the moment, the RAID array is doing a file system check, and is going slowly while it checks terabytes of data. We will continue work after lunch.
Punchline: things still don't work. |
1831
|
Wed Aug 5 07:33:04 2009 |
steve | DAQ | Computers | fb40m is down |
|
1832
|
Wed Aug 5 09:25:57 2009 |
Alberto | DAQ | Computers | fb40m is up |
FB40m up and running again after restarting the DAQ. |
3602
|
Thu Sep 23 21:01:11 2010 |
josephb, alex | Update | CDS | fb40m still down, new fb still in progress |
Unfortunately, copying the data to the USB/SATA drive over at downs took longer than expected for Alex. We will be installing the new code on the new fb machine tomorrow and running it.
We will be running off of a timer on that machine until Monday. On Monday, a Symmetricom card will be arriving from LLO so that we can connect an IRIG-B timing signal into the frame builder and use a proper time signal.
There is no running frame builder for tonight and thus will be no trends until we get the new FB running tomorrow morning. |
2603
|
Sat Feb 13 18:58:31 2010 |
josephb, alex | Update | Computers | fb40m testpoints fixed |
I received an e-mail from Alex indicating he found the testpoint problem and fixed it today:
Quote from Alex: "After we swapped the frame builder computer it has reconfigured all device files and I needed to create some symlinks on /dev/ to make tpman work again. I test the testpoints and they do work now."
|
1743
|
Tue Jul 14 14:54:19 2009 |
steve | Configuration | Computers | fb40m2 in 1Y6 |
Alex and Steve,
SunFire x4600 ( not MEGATRON 2 , it is fb40m2 ) and JetStor ( 16 x 1 TB drives ) were installed on side rails at the bottom of 1Y6
We cleaned up the fibres and cabling in 1Y7 also |
7267
|
Fri Aug 24 00:23:20 2012 |
Den | Update | Modern Control | feedback using LQG method |
I did a simulation of linear quadratic gaussian (LQG) controller applied to local damping. The cost function was frequency shaped to have a peak at 1 Hz. This technique prevents the controller from adding sensor noise at high and very low frequencies.
Noise was simulated to have 1/f spectrum (seismic) multiplied by stack with a resonance at 4 Hz with Q=5.

|
7732
|
Tue Nov 20 15:11:22 2012 |
Steve | Update | General | few more sensing cards |
New Lumitek IR Sensor Cards are here. We got 2 pieces of Q-11-T (2" x 2"), 2 pieces of Q-11-T (0.75" x 0.75") and one Q-11 (4" x 5") |
8985
|
Thu Aug 8 10:31:28 2013 |
Steve | Update | VAC | few reminders of this vent |
1, Vacuum envelope grounds must be connected all times! After door removal reconnect both cables immediately.
2, The crane folding had a new issue of getting cut as picture shows.
3, Too much oplev light is scattered. This picture was taken just before we put on the heavy door.
4, We were unprepared to hold the smaller side chamber door 29" od of the IOC
5, Silicon bronze 1/2-13 nuts for chamber doors will be replaced. They are not smooth turning.
|
Attachment 1: GROUND!.jpg
|
|
Attachment 2: bad_Folding.jpg
|
|
Attachment 3: toomuchred.jpg
|
|
Attachment 4: BETTERholder.jpg
|
|
238
|
Mon Jan 14 23:11:26 2008 |
tobin | Configuration | General | fiber |
John and I removed the fiber that ran from the SP table to the cleanroom. We plan to build a MZ interferometer with this fiber inserted into one of the arms, for the purpose of measuring its phase noise. |
14530
|
Wed Apr 10 16:58:54 2019 |
rana | Update | IOO | fiber MZ for NPRO freq noise measurements |
Can we get some panel mount FC/APC connectors and put them on a box? Then we could have the whole setup inside of a box that is filled with foam and sits outside the PSL hut.  |
247
|
Thu Jan 17 20:50:55 2008 |
tobin | Update | General | fiber coupling |
Sam, John, and I matched the beam from an NPRO into a fiber on the SP table today. In doing so we used our GigE camera for a physics application for perhaps the first time, viewing the transmitted mode from the fiber during initial alignment. (I used my laptop running Windows and a 100 megabit switch.) |
10677
|
Thu Nov 6 10:18:12 2014 |
Steve | Update | General | fiber insulation in cable tray |
Quote: |
[Steve, Diego, Manasa]
Since the beatnotes have disappeared, I am taking this as a chance to put the FOL setup together hoping it might help us find them.
Two 70m long fibers now run along the length of the Y arm and reach the PSL table.
The fibers are running through armaflex insulating tubes on the cable racks. The excess length ~6m sits in its spool on the top of the PSL table enclosure.
Both the fibers were tested OK using the fiber fault locator. We had to remove the coupled end of the fiber from the mount and put it back in the process. So there is only 8mW of end laser power at the PSL table after this activity as opposed to ~13mW. This will be recovered with some alignment tweaking.
After the activity I found that the ETMY wouldn't damp. I traced the problem to the ETMY SUS model not running in c1iscey. Restarting the models in c1iscey solved the problem.
|
AP Armaflex tube 7/8" ID X 1" wall insulation for the long fiber in wall mounted cable trays installed yesterday.
The 6 ft long sections are not glued. Cable tied into the tray pressed against one an other, so they are air tight. This will allow us adding more fibers later.
Atm2: Fiber PSL ends protection added on Friday.
|
Attachment 1: APT07810.jpg
|
|
Attachment 2: fromYend.jpg
|
|
8813
|
Tue Jul 9 17:03:06 2013 |
Steve | Update | Green Locking | fiber layed for Y arm |
Alex, Gautam and Steve,
Single mode fiber 50m long is layed out into cable tray that is attached to the beam tube of the Y arm.
It goes from ETMY to PSL enclosure. It is protected at both ends with " clear- pvc, slit corrugated loom tubing " 1.5" ID
The fiber is not protected between 1Y1 and 1Y4 |
Attachment 1: fromETMYtowardPSL.jpg
|
|
Attachment 2: fibreETMYtoPSL50m.jpg
|
|
Attachment 3: PSLfiberfromETMY.jpg
|
|
8578
|
Wed May 15 08:29:28 2013 |
Steve | Configuration | RF System | fiber protection at splitter box area |
I positioned the fiber loaded protecting tubing and anchored them so they can do their job.
However, the area needs a good clean up.
|
Attachment 1: fiberprotect.jpg
|
|
564
|
Wed Jun 25 11:01:45 2008 |
Masha | Update | Auxiliary locking | fiber stabilization |
For the first week, I have been learning about fiber noise cancellation, auxiliary locking techniques, and other relevant helpful topics in more detail. I am now working on a setup (more detail in previous entry) to measure phase noise introduced by 25m(?) fiber, and then will proceed to try to cancel the noise. |
4852
|
Wed Jun 22 01:59:43 2011 |
Sonali | Update | Green Locking | fibre-coupling of the IR beam |
What I did today.
1. Collimation of a beam.
- I then practiced collimation of a 700 nm laser (output) beam after being coupled through a fibre.
- I put together the set-up as shown in the attached picture where I used ....... to couple 650nm light into the PM.... fiber.
- I kept shifting the focus of the output beam to an appreciable distance till it was approximately collimated.
2. Coupling of the IR light at the ETMY table to a fibre.
- The fibre coupler was put in place to couple light into the fiber.
- I put in the mirrors as planned to direct the IR beam exiting the doubling crystal towards the fiber coupler (input).
- The mirrors were aligned such that the beam falls on the input lens of the coupler.
- The far-end of the fibre originally would have gone to to PSL table but it has been put on this table to study the power of the IR beam transmitted through this set-up. The output end of the fiber has been connected to another fiber optic coupler to collimate the exiting beam.
- The picture of the current status attached.
|
Attachment 1: ETMY_june_21.jpg
|
|
Attachment 2: collimation_700nm_21_june.JPG
|
|
7185
|
Wed Aug 15 00:52:17 2012 |
Den | Update | WienerFiltering | filter calculation |
A Matlab script to calculate Wiener filter coefficients and convert fir to iir is ready. Input is a file with zero mean witness and desired signals, output is a Foton zpk command to specify iir filter.
The plot shows comparison of offline fir , iir and online iir filtering. Spectrum below 4 Hz is still oscillating due to acoustic coupling, this is not a filtering effect. At 1 Hz actuator is badly compensated, more work should be done. Other then that online and offline filtering are the same.

|
7052
|
Mon Jul 30 16:05:36 2012 |
Den | Update | digital noise | filter checker |
We decided to write a script that will check online filters for digital noise. One method can be implemented using the following algorithm:
- calculate filter output using single precision
- calculate filter output using double precision and assume that it is precise
- find digital noise at the output of the filter when single precision is used
- extrapolate the result to the double precision filter dividing by 2D-S ~ 107, D - number of bits used in double precision mantissa, S - in single precision
Restriction: Single precision filter internal variables must be checked for overflows.
I applied this method to filtering a 1 Hz sine wave with a notch filter. Precise output should also be a 1 Hz wave => at other frequencies we see noise => digital noise spectrum should coincide with filter output. The plot shows the method worked out for this example.

Using this method I estimated digital noise of butter("LowPass", 2, 0.001) applied to white noise. Sampling frequency was 16 kHz.

|
7085
|
Sat Aug 4 17:32:31 2012 |
Den | Update | digital noise | filter checker |
The script estimates digital noise produces by online filters. First version of Matlab files and complied c files are in scripts/digital_noise directory.
Algorithm for 1 filter bank (max number of filters = 10):
- extract sos - representation from Foton file for each filter (Matlab)
- download data from corresponding DQ channel using NDS (Matlab)
- find filters that are switched on (Matlab)
- filter signal using Df2 and BQF with single and double precision (C)
- estimate digital filter noise (Matlab)
- calculate power spectral density and plot the result (Matlab)
More details on (2)
Often DQ channels have reduced sampling rate. In this case the script will upsample data adding zeros.
AI filter is not applied. But in the end only the frequency range (0, DQ RATE / 2) is analyzed.
More details on (3):
This is done by reading C1:MODEL-BANK_NAME_SW1R and C1:MODEL-BANK_NAME_SW2R channels.
_SW1R channel value is the sum of the following numbers:
- input switch ON / OFF => 4 / 0
- filters 1 - 6 ON /OFF
- 1 => 48 / 0
- 2 => 192 / 0
- 3 => 768 / 0
- 4 => 3072 / 0
- 5 => 12288 / 0
- 6 => 49152 / 0
- If a switch is ON but there is no corresponding filter (one green and one red line under the switch) then the switch value is divided by 3
_SW2R channel value is the sum of the following numbers:
- decimation switch ON / OFF => 512 / 0
- output switch ON / OFF => 1024 / 0
- filters 7 - 10 ON /OFF
- 7 => 3 / 0
- 8 => 12 / 0
- 9 => 48 / 0
- 10 => 192 / 0
- If a switch is ON but there is no corresponding filter (one green and one red line under the switch) then the switch value is divided by 3
Note: as for now Matlab script assumes that input, output and decimation filters are switched ON and there are no turned ON filter switches that do not correspond to any filters
More details on (5)
Digital noise using double precision is estimated by extrapolation of digital noise with single precision. The last is calculated by subtracting outputs of the filters with single and double precision. Then this noise is multiplied by 3 * 10-7.
This extrapolation number was achieved by printf tests of the number 0.123456789012345678 with single and double precision on C. Using type 'float' variables 10 significant numbers show up, using type 'double' - 17.
I also did 'calibration tests' to achieve extrapolation number - signal was filters with an aggresive low-pass filter. At high frequencies filter output spectrum is flat => digital noise amplitude must be the same. The plot shows GUR1_X channel filtered with low-pass chebyshev type 1 filter.

However, extrapolation number is not the same for all cases. In the following example of analyzing BS_SUSPOS filter bank using extrapolation 3 * 10-7 we get noise that is slightly overestimated. In some other examples we need to take a larger number. But in average, I think, this is a good approximation.

To avoid extrapolation problem we can use long double precision (~19 digits). I was able to do this with gcc compiler. However, in mex compiler using long double in filter calculations, I do not get any better precision then using double precision. I'll think more about it. |
6137
|
Mon Dec 19 17:17:02 2011 |
Den | Update | Adaptive Filtering | filter tap dependence |
Online filter diverges. I did offline simulations with current c-code. Offline filter also diverges, even in the simplest case
witness = randn(1e6, 1); target = witness + 0.01*randn(1e6, 1);
I tried to create a new implementation of FXLMS algorithm as a c code. Then with this c code I did offline filtering with MCL and GUR signals and compared the error signals depending on the length of the filter.

One can see the code at the svn
adaptOnline - start here and choose algorithm
adaptive_filtering - Matlab implementation of AF
current_version.c - current version of the Filter (Matt's)
fxlms_filter.c - new version of the FXLMS filter
oaf.c - agent between Matlab and C (edited Matt's file)
Data samples can be found at nodus /users/den/wiener_filtering/data |
480
|
Thu May 15 14:39:33 2008 |
Caryn | Summary | PEM | filtering mode cleaner with mic |
Tried filtering for mode cleaner data(C1:IOO-MC_L) using a siso-firwiener filter and microphone data(C1:PEM-AS_MIC) for noise input. The noise reduction in mode cleaner data using the microphone-filter is comparable to the noise reduction when an accelerometer(C1:PEM-ACC_MC1_X) filter is used. See attached graphs. |
Attachment 1: MC_L_with_PEM-AS_MIC_filter.pdf
|
|
Attachment 2: MC_L_with_PEM-ACC_MC1_X_filter.pdf
|
|
494
|
Fri May 23 21:21:52 2008 |
Caryn | Summary | General | filtering mode cleaner with wiener filter |
I tried filtering some saved MC_L data (from Mon May19 4:30pm) with multiple MISO filters of different orders, with various sampling rates, at different times. Plotted the max rms error (where error is signal minus signal-estimate). 2min of data (around Mon May19 4:30pm) were used to calculate each filter. And each filter was applied to data at later times to see how well it performed as time progressed. Plots are attached. There appears to have been a disturbance during the 3rd hour. Rana pointed out perhaps it would be better to use data from the evening rather than during the day. |
Attachment 1: error_vs_N_for_different_times_64Hz.pdf
|
|
Attachment 2: error_vs_N_for_different_times_128Hz.pdf
|
|
Attachment 3: error_vs_N_for_different_times_256Hz.pdf
|
|
Attachment 4: error_vs_N_for_different_times_512Hz.pdf
|
|
Attachment 5: error_vs_srate_for_different_times_256.pdf
|
|
Attachment 6: error_vs_srate_for_different_times_512.pdf
|
|
Attachment 7: error_vs_srate_for_different_times_1024.pdf
|
|
Attachment 8: error_vs_time_for_different_srates_256.pdf
|
|
Attachment 9: error_vs_time_for_different_srates_512.pdf
|
|
Attachment 10: error_vs_time_for_different_srates_1024.pdf
|
|
12562
|
Fri Oct 14 15:47:00 2016 |
rana | Update | Treasure | filters + clip |
I say just fix the clipping. Don't worry about the PRM OSEM filters. We can do that next time when we put in the ITM baffles. No need for them on this round. |
1418
|
Mon Mar 23 15:50:44 2009 |
rana | Configuration | LSC | filters deleted, lsc rebooted |
The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.
The filters all looked like old trash to me, but its possible they were used.
I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the
filter_archive/ |
5355
|
Wed Sep 7 08:14:01 2011 |
steve | Update | SUS | final OSEM check |
All fine, except ITMX_sensor_UL's 60 counts deep hoop for an hour. |
Attachment 1: finalcheck.jpg
|
|
Attachment 2: ITMX10min.jpg
|
|
Attachment 3: finalsum.png
|
|
13704
|
Mon Mar 26 16:10:33 2018 |
Kira | Update | PEM | final setup sketch |
I made sketches of the final setup. There will be a box in the rack that contains both the heater circuit and the temperature sensor boards. One of them is in the loop while the other isn't. Instead of having many cables leading to the can, there will only be these three, though they can be made into a single wire. It will be connected to the can through a D-9 connector. The second attachment is what will be inside of the box, with all the major wires and components labeled.
-----
Edit: I've canged the layout to (hopefully) make the labels easier to read. I've also added in a cable to the ADC that reads out the voltage across the 1 ohm resistor. I also attached the circuit diagrams for the heater circuit and the temperature sensors. The one for the heater circuit was made by Kevin and I used the same design, except I have LM7818 and LM7918, since the 15V ones were not available at the time I made the circuit.
In addition, all the wires leading to the can will all be part of one bundle of wires (I didn't clearly indicate it as such). There will be a total of 6 wires: two are needed for the wire to supply power to the heater and will have a LEMO connector on the rack end and two are needed for each temperature sensor, which will be attached to the board directly on the rack end.
Also, we don't need two voltage regulators for each temperature circuit. We can just have one of each of LM7815 and LM7915 to supply +/- 15V to the boards. |
Attachment 1: heater_1_new.png
|
|
Attachment 2: heater_2_new.png
|
|
Attachment 3: HeaterCircuit.pdf
|
|
Attachment 4: temp_sensor.png
|
|
13759
|
Wed Apr 18 12:18:39 2018 |
Kira | Update | PEM | final setup sketch |
I've updated the sketches and added in front panels for the seismometer block and the 1U panel (attachments 3 and 4). There was an issue when it came to the panel on the block because the hole is only big enough for the cable that already exists there and there is no space to add in the D-9 connector. Not quite sure how to resolve this issue. Attachment 7 is the current panel on the seismometer block. Attachments 5 and 6 are the updated temperature circuit and the heater circuit.
The boxes will be located in the short racks at EX and EY to minimize cable length. |
Attachment 1: heater_1_new.png
|
|
Attachment 2: heater_2_new.png
|
|
Attachment 3: 1U-panel.pdf
|
|
Attachment 4: EX-can-panel.pdf
|
|
Attachment 5: IMG_20180412_120427.jpg
|
|
Attachment 6: HeaterCircuit.pdf
|
|
Attachment 7: IMG_20180418_121115.jpg
|
|
13782
|
Tue Apr 24 09:10:20 2018 |
Kira | Update | PEM | final setup sketch |
I've attached the final sketch for the panel on the granite block. |
Attachment 1: EX-can-panel_1.pdf
|
|
13800
|
Mon Apr 30 15:36:18 2018 |
Kira | Update | PEM | final setup sketch |
I've attached a sketch of how the panel will be mounted. We should make a small rectangular box that would raise the panel from the block by 1 cm or so to allow the cables to fit into the hole in the block without getting bent. It also has to be airtight so maybe having a thin layer of rubber between the mount and block would be good. |
Attachment 1: mount.png
|
|
13769
|
Thu Apr 19 12:23:30 2018 |
Kira | Update | PEM | final setup sketch update |
I've added in the dimensions to my sketch.
It seems like placing the two connectors right next to each other would allow both cables to just barely go through the hole in the block.
Quote: |
Can you please add dimensions to the drawing, so we can see if things fit and what the cable lenghts need to be?
For the panel on the granite slab, we should use a thinner piece of metal and mount it with an offset so that the D-sub cable can be fished through the hole in the slab. The hole is wide enough for 2 cables, but not 2 connectors.
|
|
Attachment 1: heater_1_new.png
|
|
Attachment 2: heater_2_new.png
|
|
13771
|
Thu Apr 19 18:23:51 2018 |
Kira | Update | PEM | final setup sketch update |
since we're just going from the short rack (not the tall rack) to the seismometer, can't we use a cable shorter than 45' ?
Quote: |
I've added in the dimensions to my sketch.
|
the panel should be completely replaced like I described. We don't want to try to squeeze it in artificially and torque the wires. It just needs to be separated from the slab by a few more cm. |