Displaying reports 68981-69000 of 83394.Go to page Start 3446 3447 3448 3449 3450 3451 3452 3453 3454 End
Reports until 17:14, Monday 03 November 2014
H1 CDS
david.barker@LIGO.ORG - posted 17:14, Monday 03 November 2014 (14816)
CDS planned maintenance

Dave [WP#4929] new models for h1calex, h1caley. Same functionality, split code into a common library part. May install h1calcs on h1oaf0 if the specific_cpu assignments can be verified for this front end. DAQ restart is required.

Dave: Reconfigure EDCU for latest Beckhoff and resync to guardian. Restart DAQ.

Jeff K, Stuart A: possible SUS model optlev changes, DAQ restart required.

Dave: recompile h1lsc against older version of RCG to fix slow-data-channel-offset-in-daq problem which was reintroduced last week

No other work planned.

H1 SEI
hugh.radkins@LIGO.ORG - posted 16:35, Monday 03 November 2014 (14815)
WHAM2 HEPI--New Controllers (Generic) for corrected Matrices ready to Load

They are not 'prepared' yet but that is but a moment.  So this uses TF data from 4 Sept 2013 but with the correct Local <--> Cartesian matrices.  Additionally, these are Hugo's Generic Controllers in use already on HAMs 4 5 & 6; we'd like to use these where ever we can.  Otherwise I attach them here if you wish to look at them.  A few of the dofs have phase margins less than 30; but, our problem at EndX had only 20 degrees of margin.

I plan to 'prepare', load , and test them tomorrow morning.

Non-image files attached to this report
H1 General
travis.sadecki@LIGO.ORG - posted 16:00, Monday 03 November 2014 (14814)
OPS shift summary

9:00 Bubba to LVEA measuring cleanrooms

~10:58 Rai and Kyle to EY removing ionizer setup

12:00 Rai and Kyle back from EY

1:00 Cris and Karen to MX and MY respectively

1:45 Karen leaving MY

H1 AOS (TCS)
alastair.heptonstall@LIGO.ORG - posted 13:34, Monday 03 November 2014 (14812)
TCS CO2 laser mask holder flippers installed and working

Alastair

The flipper mask holders are installed on the X and Y tables.  Both are cables up and working using a 'caput' command.  At the moment they won't work using the MEDM screen since this requires checking the state of the flipper (up/down) using sensors that are not yet on the table.

Final outstanding intstall work is :  X-table needs 1 flipper sensor.  Y-table needs 2 flipper sensors, FLIR camera and baffles around PDs.

H1 ISC
peter.fritschel@LIGO.ORG - posted 12:29, Monday 03 November 2014 - last comment - 13:44, Tuesday 04 November 2014(14809)
Top level differences between H1 and L1 for interferometer locking

The difficulties with H1 DRMI locking, and with getting H1 to full lock, prompt me to survey the top level configuration differences between H1 and L1.

Some other comparisons that should be made (not in the table) are:

At this point we don't know which of these differences, if any, are significant for the lock acquision. Please post comments to this entry if you have some ideas on this, or if there are other known differences that we should be looking at.

parameter L1 H1 comments
 input power for locking 2 W 10 W

 

 modulation depths, 9/45 MHz 0.25/0.29 0.19/0.28

not sure if L1 values are current

 ETM global feedback hierarchical distributed

 

 SUS local damping A B

They're different; see G1401267; Jeff K and Stuart A are working on comparison plots

 DRMI ASC servos 4 loops 3 loops

BW probably lower on H1; more complete comparison needed

 HSTS feedback & coil drivers increased M2 drive for PRM & SRM increased M2 & M3 drive for all HSTS  
 LSC servo loops    

comparison needs to be made

 3-f PD photocurrent (DRMI) 0.15 ma 27 mW -> 3 ma

H1 has done limited trials with a reduced photocurrent

 WFS centering loops    

different, but comparison needed

 ALS ETM feedback ? Done when needed to bring frequency in range  
 Michelson contrast defect: modeled, no arms, no TCS 6400 ppm 10,800 ppm

SIS model, using as-built ITMs

 Modeled power recycling gain: carrier, no arms, no TCS 40 33

SIS model, using as-built ITMs

Comments related to this report
peter.fritschel@LIGO.ORG - 13:44, Tuesday 04 November 2014 (14839)

RF spectra from the 3-f BBPD have been posted to both LHO and LLO logs recently, so here is a comparison of those.

LLO data: log 15430  , photocurrent: 0.21 ma

LHO data: log 14807 , 27 mW -> inferred photocurrent: 3.0 ma (better would be a direct measurement of photocurrent)

Comparison of 6 highest RF peaks:

Frequency L1 H1 Delta
9 MHz -41 dBm -11 dBm +30
18 MHz -29 dBm -12 dBm +17
36 MHz -18 dBm -1 dBm +17
45 MHz -30 dBm -12 dBm +18
54MHz -25 dBm -6 dBm +19
90 MHz -33 dBm -14 dBm +19

 

 

 

 

 

 

 

 

Other than 9 MHz, the BBPD output RF components on H1 are all about 20 dB higher than the corresponding components for L1. This is about what is expected from the higher photocurrent used on H1 -- in fact we'd expect closer to 24 dB, if the inferred H1 photocurrent is right. The 9 MHz on H1 is another 10 dB higher (on top of the 20 dB), which is odd considering that the f1 modulation depth on H1 is smaller. This may indicate that on 3-f locking, there is more of an offset on PRCL (or MICH?) in H1 than L1, or maybe more residual motion.

In any case, L1 can hold a stable DRMI lock with the lower 3-f signal level, but H1 has not been able to so far. The LLO log entry also included demod error signal spectra for the DRMI. I'm hoping someone at LHO can post a comparison of that with the H1 situation.

H1 CDS
david.barker@LIGO.ORG - posted 10:47, Monday 03 November 2014 (14808)
Reminder, clocks went back at 2am Sunday, so autoburt entry to 1am was written twice (overwritten)

A reminder that at 2am PDT, the clocks went back one hour to 1am PST. This means the hourly autoburt wrote out two "1am" sets of data, the second one overwriting the first. This can be seen if we look at a GPS time channel in one of the snap files. There gap between the midnight entry and the "1am" entry is 7198 seconds, or 1.999 hours.

Also remember local time is now UTC - 8hr

00:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098947755000000e+09

01:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098954953000000e+09

02:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098958553000000e+09

03:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098962155000000e+09

H1 General
travis.sadecki@LIGO.ORG - posted 09:58, Monday 03 November 2014 (14806)
PSL Checklist
Adjusted REFSIGNAL from -2.02V to -2.06V to bring diffracted power down from ~12% to ~10.8%.  I am hesitant to make more aggressive adjustments since last time I did, Rick was surprised that such large adjustments were required.  Further investigation?


Laser Status: 
SysStat: Warning “VP program online” is red
Output power is 29.4 W (Should be around 30 W)
FRONTEND WATCH is active
HPO WATCH is red

PMC:
It has been locked 5 days, 21 hours, 58 minutes.
Reflected power is 2.0 Watts and PowerSum = 25.4 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 15 hour, 22 min.
Threshold on transmitted photo-detector PD = 2.20 V (should be at least 0.9V)

ISS:
The diffracted power is around 10.8% (should be 8-10%) 
Last saturation event was 1 hour, 34 minutes ago 
H1 General
travis.sadecki@LIGO.ORG - posted 09:48, Monday 03 November 2014 (14805)
Morning meeting and commisioning meeting notes

Morning meeting:

Commissioning:

H1 SEI
jim.warner@LIGO.ORG - posted 08:15, Monday 03 November 2014 (14804)
Sensor correction on HAM6

No commissioners asked for this, but I was curious so I installed Rich's sensor correction filter on the HAM6 ISI. It looks like it does good things, but I've only tried Z so far. I don't really know if there are any optics or useful oplevs on HAM6, so I'll bug commissioners about what metrics they would use at that chamber to measure performance, but the ISI's own sensors show improved performance down to 100mhz and very little re-injection below that. First attached plot is before, second is after. Comparing the upper right plot on each shows the improvement. It's interesting that RX and RY also seem to be improved.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 07:52, Monday 03 November 2014 (14802)
CDS model and DAQ restart report, Saturday and Sunday 1st, 2nd November 2014

model restarts logged for Sat 01/Nov/2014
2014_11_01 15:27 h1fw1

model restarts logged for Sun 02/Nov/2014

One unexpected restart Saturday. No restarts reported Sunday.

H1 ISC
daniel.hoak@LIGO.ORG - posted 00:21, Monday 03 November 2014 (14801)
modulation depths, OMC shutter

Rana had asked me to perform another sweep of the OMC to measure the modulation depth.  The results using a single-bounce beam from ITMY are attached; the observed modulation depths are:

Gamma1 (9MHz) = 0.191

Gamma2 (45MHz) = 0.284

This should be compared to the previous measurements from Sep 28th, and also Kiwamu's measurement of the modulation depth and the recycling gain (and subsequent measurements after an RF amp was installed).  There is probably an error of order one percent in these measurements, in particular the 9MHz sideband which is close enough to the carrier peak that it relies on the subtraction of the TEM00 lorentzian.  The results above include this subtraction, but my lorentzian fit isn't perfect, perhaps due to the very slight nonlinearity of the PZT drive.  The plot attached shows the five mode scans that were used to calculate the Gamma's, the peaks identified as the upper and lower sidebands are marked with black crosses.  The measured values for Gamma are consistent (to much better than 1%) between the upper and lower sidebands at each frequency, and from one sweep to the next, so the statistical errors are small.  The raw data are here.

(FWIW the mode-matching from ITMY is still 0.91, consistent with the previous measurement and with the predictions from beam propagation.)

Other OMC work: I connected the OMC shutter controller box above ISCT6, the input for channel 1 comes from the ASC-AS_C SUM output fro the transimpedance board, the controller output goes to the trigger on the OMC PZT driver.  The polarity of the shutter logic seems backwards, 'open' gives 0V and 'closed' is 5V, also I can't get the trigger to fire using the threshold on the PD input.  Probably there is some work to do in Beckhoff-land.

Images attached to this report
H1 AOS
robert.schofield@LIGO.ORG - posted 17:48, Sunday 02 November 2014 (14799)
Shaking at one beam tube baffle moves many

The regular ~1nm variations in ETM coating thickness cast a diffraction ring onto beam tube baffles that may produce excess noise through modulation of retro-reflected light (https://dcc.ligo.org/T1300354). We are considering making an estimate of the noise produced by this effect by shaking the beam tube at one of the baffles with large enough amplitude to produce noise at the current LLO sensitivity (here). In making this noise prediction, it is important to know if the shaking moves more than the one baffle. To answer this, I measured the relative motion and phase of every baffle in a 550m stretch of the beam tube centered on the baffle by the shaker. 

The relative motions of the neighboring baffles are shown in Figure 1. The relative motions can exceed 0.1 even for baffles a couple of hundred meters away from the shaker. The motion is also not symmetrical about the shaken baffle. I had a hard time believing this at first and returned to many of the baffle locations, remounting an accelerometer and re-starting the shaker, several times. The relative amplitudes were consistent, as were the phases, except for one early set of measurements at one location. Because the asymmetry suggests a location dependence, I think I will have to measure the motion of neighboring baffles when the experiment is done for real at LLO, a significant increase in the difficulty of the experiment. 

Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:06, Sunday 02 November 2014 - last comment - 13:12, Monday 03 November 2014(14798)
guardian work today

I spent some time working on the ISC guardians today, in the hope that we could save ourselves alot of mindless clicking in the coming week.  The users guide:

Now there is a generator for states where we sweep some channel and search for the transmitted light, which is used by both COMM and DIFF for a coarse then a fine sweep.  This is slow but does work, and will be faster than doing it by hand.  After COMM finds the resonance, it is now resetting the VCO set frequency, so that when the set frequency offset is 0, the arms are on resonance.  However, there is some kind of a bug in the beckhoff that causes an error in the VCO after this.  I will look into it tomorrow, since I try not to work on beckhoff on the weekends. 

There is another bug, either in the IMC_LOCK guardian, the node manager, or the way that I am trying to use the node manager.  When the IMC goes to its fault state (which usually happens because the FSS has dropped lock) it gets stuck there and won't move on.  Dan pointed out that one difference between this and other transitions that seem to be working fine, is that the arrow goes from the fault state to INIT.  We tried having it return 'INIT' instead of return True with an edge to INIT, this didn't work either (It got to down and just didn't move on from there). 

I've added a goto state called bring_down_nicely to the DIFF guardian.  The current DIFF down state gives the suspensions a terrible kick, I think this is not necessary. 

Comments related to this report
jameson.rollins@LIGO.ORG - 13:12, Monday 03 November 2014 (14810)

The issue you're seeing with the managed IMC_LOCK node is the intended behavior of "MANAGED" nodes.  When a managed node undergoes a jump transition, it goes into a "stalled" state whereby it waits for a new request from before proceeding along it's path.  This gives the manager a chance to react and coordinate the actions of the subordinate with other subrodinates.

There are two solutions:

  • Do not "manage" the IMC_LOCK node.  This will prevent it from going in to MANAGED mode, allowing it to handle it's own recovery from faults and lockloss.
  • Modify the manager to re-request the lock state after a fault.

I've thought about this before, and I think there is a definite need to have a "watching only" manager mode that doesn't put the subordinate into MANAGED mode, but allows the manager to monitor it's progress with the same NodeManager interface.  I'll work on adding that to the next guardian release.

H1 ISC
evan.hall@LIGO.ORG - posted 17:19, Saturday 01 November 2014 - last comment - 20:22, Tuesday 04 November 2014(14796)
RF power at the REFLAIR_B diplexer

Rana, Alexa, Sheila, Peter, Evan

Given last night's strange behavior from REFLAIR_B, we wanted to check the RF powers coming out the BBPD and going into the ISC rack.

With DRMI locked (on 1f, and then on 3f), we used the HP4395A to take an RF spectrum of the "direct" output of the REFLAIR_B diplexer board. This should be the raw RF signal out of REFLAIR_B, with 12 dB of attenuation from a coupler inside the diplexer.

The spectra (adjusted for the 12 dB coupler) are attached.

For 27 MHz, the power into the diplexer is -41 dBm. Using the diplexer schematic (D1300989), this should give -23 dBm at the diplexer's 3x output, which is well below the compression point of the amplifier (ZHL-500HLN+; 1 dB comprsesion occurs at +16 dBm). Similarly, for the 15x output we expect -13 dBm.

The analogous LLO measurement is at LLO#10494.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 10:49, Monday 03 November 2014 (14807)

Power levels were as follows:

  • LSC-REFLAIR_B_INMON = 2.62(1)×104 counts
  • LSC-REFLAIR_B_OUTPUT = 27.5(1) counts (= 27.5(1) mW, since this channel has a calibation)
  • LSC-POPAIR_B_RF18_I_MON = 270(40) counts
  • PSL-PERISCOPE_A_DC_POWERMON = 10250(25) counts (=10.250(25) W into IMC)

Dan remeasured the modulation indices (LHO#14801).

Non-image files attached to this comment
evan.hall@LIGO.ORG - 14:29, Monday 03 November 2014 (14813)

A quick estimate of the amount of distirtion in the BBPD amplifiers (MAR-6SM+ and GALI-6+):

The total amount of RF power in the attached spectrum is about +1 dBm (coming mostly from 4f1). Before the GALI-6+ in the BBPD, that's −11.2 dBm at the output of the MAR-6SM+.

The output-referred IP3 of the MAR-6SM+ is +18.1 dBm. Assuming the third-order distortion of the amplifier grows like the cube of the input power, this means the expected power of the third-order distortion is −11.2 dBm − 2×(18.1 dBm + 11.2 dBm) = −70 dBm out of MAR-6SM+. Then after the GALI-6+, the distorted power is −58 dBm.

koji.arai@LIGO.ORG - 20:22, Tuesday 04 November 2014 (14852)

[Koji, Rana]

The preamp chain of the BBPD was electrically tested. It turned out that intermodulation can explain the observed RF signals at 27MHz and 135MHz.


Method:

A spare BBPD at the 40m was used for this test.
The photodiode was removed from the BBPD circuitry and an SMA connector was soldered instead. (Attachment 1)

The measurement setup is depicted in Attachment 2.
The RF signals from two signal sources were combined with a power combiner and fed to the modified BBPD.
The output was connected to a network analyzer in order to monitor the output levels at each frequency.

Measurement 1:

Firstly, Intermodulation produced from strong 9MHz and 35MHz components was tested.
WIth these two signals injected, our taget signals appear at 26MHz and 44MHz.
This way we can avoid the interference by the third harmonic distortion of the 9MHz signal.

The result is shown in Attachment 3. The 9MHz and 35MHz input levels were adjusted such that the output levels are -10dBm and 0dBm respectively.
These levels were obtained from the measurement in alog14807 (above).

It is clearly seen that symetric intermodulation appeared at 26MHz and 44MHz. The intermodulation level is linear to the level of the 35MHz signal.
In fact, -10dBm@9MHz and 0dBm@35MHz explain -40dBm@26MHz which Evan observed in the inlock spectra.

Measurement 2:

In the second measurement, it is tested if the intermodulation can produced enough amount of 135MHz signal.
Evan's measurement shows that both 45MHz and 90MHz have -15dBm.

From the lmitation of my setup, I had to use 30MHz and 80MHz to produce 110MHz, instead.
This indeed produced the 60dBm intermodulation, which is consistent with Evan's measurment.

Meaning of this measurement:

What happens if the intermodulation overwhelms the intrinsic signals at 27MHz and 135MHz?

- The intermodulation without fluctuation itself imposes unreasonable offsets in the 3f signals at DC.

- Power fluctuation of the sideband power in the 36MHz (f1-f2) or 91MHz (2xf2) causes unnecessary (=meaningless) signal to the 3f demodulated signals.

- The londitudinal IFO error signals in the 9MHz or 45MHz signals are imprinted to the 3f signals at a certain unknown demod phases,
and thus screw up the demod phase of 3f signals, as well as the immunity of them against the carrier audio sidebands.

Remedy:

- Lower the light power on the PD, if possible to maintain lock.
- Notch out/filter out unncesessary RF components before the BBPD preamps by adding components on the BBPD boards.
- Use resonant type photodetectors in stead of the broadband one  to selectively amplify the desired lines.

Images attached to this comment
Non-image files attached to this comment
H1 SEI (DetChar)
krishna.venkateswara@LIGO.ORG - posted 14:29, Friday 31 October 2014 - last comment - 10:19, Wednesday 05 November 2014(14779)
ETMX HPI controller change improved Stage 1 X low frequency performance

This is related to Hugh's log 14774. To elaborate a bit on Hugh's log, I made a measurement with Stage 1 Damped only and HPI isolated. The first plot shows the GND_T240_X ,  ST1_T240_X  and HPI L4C (out of loop witness). There was no coherence with ground below 0.1 Hz but there was significant coherence with HPI L4C. This meant that HPI was somehow introducing excess low-frequency motion.

We then did the same measurement on ETMY and saw no such excess motion. The second pdf shows the corresponding measurement. Stage 1_Y was very coherent with ground_Y. Jim mentioned he had modified the HPI controllers on ETMY as described in Hugh's log, so we decided to try the same on ETMX in X and Y.

This has made a significant difference to the low frequency performance of Stage 1 as shown in the third file. Performance below 0.1 Hz is much closer to ground motion now.

Non-image files attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 08:06, Monday 03 November 2014 (14784)

Some more plots of the old vs new isolation filters, per Jeff's request. I dug into the foton file to find numbers to back up what I thought the original design was. The gains of the old and new foton filters are shown in the first image, they show that not much was done to the filter design, just that the gain was reduced. Solid lines are the old design(higher gain, UGF), dashed lines are the current design. Second and third images are the currently installed plant design and a reconstruction of the orignal design (no plots were found from the original design from earlier this year). The solid and dashed orange lines tell most of the story, mostly we just cut the UGF to 2hz, and modified the boost to get more phase margin. No idea why this affect the very low frequency noise, Jeff and Krishna suggested maybe we were re-injecting IPS noise with the higher gain.

Images attached to this comment
hugh.radkins@LIGO.ORG - 08:04, Monday 03 November 2014 (14803)

Here is another look at the controller with the amplitude scale zoomed out to see the lowest frequencies of the open loop.

Images attached to this comment
krishna.venkateswara@LIGO.ORG - 10:19, Wednesday 05 November 2014 (14863)

J. Warner, K. Venkateswara

We repeated this measurement today and did not see the same results. Sensor correction was off. The attached pdf shows the before (old controller) and after (new low gain UGF controller) data. Very strange. We may have been fooled by different ground motion or perhaps by sensor correction. There is good coherence with ground till ~60 mHz in either controllerconfiguration.

Jim has reverted to the new low gain UGF controller as it should help with ringing of HEPI at 9 Hz.

Non-image files attached to this comment
H1 SYS
jameson.rollins@LIGO.ORG - posted 12:21, Thursday 30 October 2014 - last comment - 13:27, Sunday 02 November 2014(14739)
new cdsutils.avg() interface and bug fixes

The current cdsutils installation (r361) has a new and improved NDS avg() function.  The previous version was buggy, was calculating the standard deviation incorrectly,  and had a clunky interface.  This new version fixes those issues:

fixes to standard deviation calculation

The standard deviation was previously being calculated incorrectly and the returned values were wrong (off by some unknown but kind of large factor).  The new version uses the python numpy.var() function to calculate the variance, from which the standard deviation is calculated.  It has been verified to be correct.

channel IFO prefixes no longer need to be specified

Previously, the avg() function required full channel names, with IFO prefixes.  This new version works like the ezca interface whereby the IFO prefix can be left off of the channel name.  This makes things much cleaner, and allows scripts to be portable.  E.g., instead of:

cdsutils.avg(2, IFO+':LSC-DARM_OUT')

just do:

cdsutils.avg(2, 'LSC-DARM_OUT')

new format for returned values

Probably the thing that's going to cause the most trouble is that the interface to the function has been fixed up.  Previously, the function was returning a dictionary of channel:avg key pairs.  This was very clunky to use.

The return value of the function now mirrors the input argument.  So for instance, if a single channel is requested, a single avg value is returned.  If a list of channels is requested, a list of average values is returned, in the same order as the input channel list.  So calls like:

avg = cdsutils.avg(2, 'LSC-DARM_OUT').values()[0]

can now just be:

avg = cdsutils.avg(2, 'LSC-DARM_OUT')

If the stddev option is provided, the output will be an (avg, stddev) tuple, or if multiple channels is requested, a list of such tuples, e.g.:

avg, stddev = cdsutils.avg(2, 'LSC-DARM_OUT', True)

I have fixed all calls to cdsutil.avg() that I could find in the USERAPPS/release.  I likely didn't catch everything, though, so be aware of the new interface and update your code appropriately.

Comments related to this report
rana.adhikari@LIGO.ORG - 23:07, Friday 31 October 2014 (14791)

controls@opsws5:sbin 0$ cdsutils -h

Usage:
  -c [OPTION...] - GStreamer initialization
 
Help Options:
  -h, --help                        Show help options
  --help-all                        Show all help options
  --help-gst                        Show GStreamer Options
 
controls@opsws5:sbin 0$ cdsutils avg -h
Usage:
  -c [OPTION...] - GStreamer initialization
 
Help Options:
  -h, --help                        Show help options
  --help-all                        Show all help options
  --help-gst                        Show GStreamer Options

rana.adhikari@opsws5|~> cdsutils avg -n 2 H1:LSC-MICH_IN1
ignoring first online block...
received: 1098858364 + 1.0
received: 1098858365 + 1.0
-195.380218506
 
Also would be helpful if these extraneous junk messages can be removed from the output. The idea of the "-n" flag is that only the number is returned so that we can use it in command line scripting.
jameson.rollins@LIGO.ORG - 13:27, Sunday 02 November 2014 (14797)

I pushed a new version of cdsutils (r366) that fixes the issue with the help.  Commands were being intercepted by one of the gstreamer libraries:

jameson.rollins@operator1:~ 0$ cdsutils -h
usage: cdsutils  

Advanced LIGO Control Room Utilites

Available commands:

  read         read EPICS channel value
  write        write EPICS channel value
  switch       read/switch buttons in filter module
  sfm          decode/encode filter module switch values
  step         step EPICS channels over specified range
  servo        servo EPICS channel with simple integrator (pole at zero)
  trigservo    servo EPICS channel with trigger
  avg          average one or more NDS channels
  audio        play NDS channel as audio stream
  dv           plot time series of NDS channels
  water        NOT SUPPORTED: No module named PyQt4

  version      print version info and exit
  help         this help

Add '-h' after individual commands for command help.
jameson.rollins@operator1:~ 0$ 

The "junk" messages, as you refer to them, in the avg output are actually just logging that are going to stderr, and therefore do not affect the stdout output:

jameson.rollins@operator1:~ 0$ foo=$(cdsutils avg -n 2 H1:LSC-MICH_IN1)
ignoring first online block...
received: 1098998811 + 1.0
received: 1098998812 + 1.0
jameson.rollins@operator1:~ 0$ echo $foo
75.2394218445
jameson.rollins@operator1:~ 0$ 

Displaying reports 68981-69000 of 83394.Go to page Start 3446 3447 3448 3449 3450 3451 3452 3453 3454 End