Joe and I have taken control of the EPICS channels C1:PEM-Stacis_EEEX_geo and C1:PEM-Stacis_EEEY_geo since we heard that they are no longer in use.  We are currently 
using them to test the ability for the Snap camera code to read and write from EPICS channels.  Thus, the information being written to these channels is completely unrelated
to their names or previous use.  This is only temporary; we'll create our own channels for the camera code shortly (probably within the next couple of days).

- Eric

 Kiwamu and I brought 2 SUPER MICRO PCs from Willson house into 40m.

Both PCs are hooked up into Martian network. One is named as bscteststand for BSC which has been set up by Cds people and another one is named kami1 for temporary use for CLIO which is a bland new, no operating installed PC. This bland new PC will be returned Cds or 40m once another new PC which we will order within several days arrives.

IP address for each machine is 131.215.113.83 and 131.215.113.84 respectively.

We have installed CentOS5.2 into the new PC.

This morning there was a confliction of tpman running on fb40m and kami1. Alex fixed it temporary but Rana suggested it was better to move both PCs outside martian. We moved both PCs physically to the control room and connected to general network with a local router. I believe it won't conflict anymore but if you guess these PC might have trouble please feel free to shutdown.

Today's work summary:

 *connected expansion chassis to bscteststand

 *obtained signals on dataviewer, dtt for both realtime and past data on bscteststand with 64kHz timing signal

Questions:

Excitation channels are not shown, only "other" is shown.

qts.mdl should run with 16kHz but 16kHz timing causes a slow speed on dataviewer and failing data aquisition on dtt. We are using 64kHz timing but is it really correct?

I borrowed SR785 to measure AA, AI noise and TF.

For the purpose of testing out the temperature sensors, I stole the PEM-SEIS_MC1X,Y,Z channels.

I unplugged Guralp NS1b, Guralp Vert1b, Guralp EW1b cables from the PEM ADCU(#10,#11,#12) near 1Y7 and put temp sensors in their place (temporarily).

I plugged the Guralp cables back into the PEM ADCU

       Guralp NS1b ---> #11

       Guralp Vert1b --->#10

       Guralp EW1b --->#12

rob, alberto, rana, pete

we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)

I just added two slow channels to C0EDCUEPICS to monitor the input of PD11. The names are:

[C1:LSC-PD11_I_INMON]
[C1:LSC-PD11_Q_INMON]

I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).

I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again.  Utter failure. 

I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.

 I think the problem was caused by a failure of the RFM network: the RFM MEDM screen showed frozen values even when I was power recycling any of the FE computers. So I tried the following things:

After Alberto's bootfest which was more successful than mine, I tried powercycling the AWG crate one more time.  No success.  Just as Alberto had gotten, I got the DAQ screen's AWG lights to flash green, then go back to red.  At Alberto's suggestion, I also gave the physical reset button another try.  Another round of flash-green-back-red ensued.

When I was in a few hours ago while everything was hosed, all the other computer's 'lights' on the DAQ screen were solid red, but the two AWG lights were flashing between green and red, even though I was power cycling the other computers, not touching the AWG at the time.  Those are the lights which are now solid red, except for a quick flash of green right after a reboot.

I poked around in the history of the curren and old elogs, and haven't found anything referring to this crazy blinking between good and bad-ness for the AWG computers.  I don't know if this happens when the tpman goes funky (which is referred to a lot in the annals of the elog in the same entries as the AWG needing rebooting) and no one mentions it, or if this is a new problem.  Alberto and I have decided to get Alex/someone involved in this, because we've exhausted our ideas. 

Yet again, the DAQAWG flipped out for an unknowable reason.  In order of restart activities listed on the Wiki, I keyed the crate and nothing really happened, then I hit the physical reset button and nothing happened, and then I did the 'telnet....vmeBusReset', and a couple minutes later, it was all good again.

I added a temporary channel, to input 9 on the PEM ADCU.    Beware the 30, 31, and 32 inputs.  I tried 32 and it only gave noise.

FB40m up and running again after restarting the DAQ.

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames


So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.


Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.

The process had been completed and now we can read the trends again.

Alberto, Kiwamu, Koji,

this morning we found the RFM network and all the front-ends down.

To fix the problem, we first tried a soft strategy, that is, we tried to restart CODAQCTRL and C1DCUEPICS alone, but it didn't work.

We then went for a big bootfest. We first powered off fb40m, C1DCUEPICS, CODAQCTRL, reset the RFM Network switch. Then we rebooted them in the same order in which we turned them off.

Then we power cycled and restarted all the front-ends.

Finally we restored all the burt snapshots to Monday Dec 7th at 20:00.

[Alberto, Koji, Rana]

The RFM network failed today. We had to reboot the frame builder anf restart all the front end following the instructions for the "Nuclear Option".

Burt-restoring to May 1st at 18:07, or April 30 18:07 made c1sosvme crash. We had to reset the front ends again and restore to April 15th at 18:07 in order to make everything work.

Everything seems fine again now.

Alex wrote a new code to implement LSP noise generator. The code is based on 64 bit random number generator from Numerical Recipes 3rd ed ch 7.1 (p 343).

Joe made two instances in the LSP model.

The attached plot shows the spectra and coherence of two generators. The incoherence is ~1/Navg - statistically consistent with no coherence.

I was getting an excess noise in the C1:IOO-MC_DRUM1 channel - it was a flat spectrum of 10 cts/rHz (corresponding to 600 uV/rHz).

I tried a few things, but eventually had to power cycle the crate with c1iovme in order to recover the standard ADC noise level of 3x10^-3 cts/rHz with a 1/sqrt(f) knee at 10 Hz.

I checked the gain of the channel by injecting a 2 Vpp sine wave at 137.035 Hz. 2Vpp as measured on a scope gives 31919 cts instead of the expected 32768, giving a 2.5% error from what we would have naively calculated.

Even so, the noise in this channel is very surprisingly good: 0.003 / (31919 / 2) = 187 nV /rHz.  The best noise I have previously seen from an ICS-110B channel is 800 nV/rHz. What's going on here?

we had to reboot the IOO VME crate right before lunch as the DAQ wasn't working correct meaning showing no real signals anymore, only strange noise. The framebuilder and everything else was working fine at that time.

• The channel used for the phase noise measurement stopped showing any useful signal right after midnight, so all the other IOO-MC signals.
  
• The data taken with those channels showed something like a 140 counts or so of steady offset with something which looked like the last bit fluctuating.
  
• Whatever signal we connected to the input it didn't change at all, floating/shorted input, sine wave etc.
• the other channels for the MC which we checked showed the same strange behaviour
  

As the other channels showed the same effect we decided to reboot the crate and everything was fine afterwards.

• ND10 and ND20 neutral density filter
  
• EOM and mount set for 4 inch beam height
  
• Post for fiber launch to get to 4 inch
  
• Mode matching lens at 4in
  
• 3x steering mirror at 4in
  
• RF photodiode at 4in
  
• Post for camera to 4in
  
• Light sheild for camera
  
• Long BNC cable
  

MC1     28.21625 kHz
MC2     28.036   kHz
MC3     28.21637 kHz