After Tuesday PZT mirror swap, the ISS photodiodes are misaligned, see attached trend (all ISS signal vertical scale is 0-2000). All diodes receive less than half the power they used to. Some even less than that.
07:00 Cris and Karen into LVEA
08:00 OIB set to UNDISTURBED
08:45 OIB set to Commissioning
08:46 begin alignment/locking
09:02 J Bartlett out to the LVEA to hang sensors for 3IFO
09:15 Bartlett out of LVEA
09:40 Fil and Andres out of LVEA
11:00 Operators meeting
12:00 Operators meeting over
14:02 Kyle to EX
15:15 Kyle back from EX
I did some initial alignment today. Locking happened up to the Resonance state. I never experienced the oscillation mentioned in Sheila's aLog (comments to 18020). IFO broke lock within 3 minutes of resonance 2 - 3 times. It never got past that then commissioners took over.
Had "tinkered" with out-building IP controllers -> As found, Y-mid was 5000V and 7000V -> changed current at which point one of the channels stepped from 5000v to 3000V such that now IP9 is 3000V and 5000V
Aidan, Elli, Nutsinee
Following up Elli's alog 17993
I took advantage of a ~9:30 lock loss this morning to rotate the CO2X rotation stage around (the operator was informed). It took longer than I expected so I accidentally worked through as the Guardian was building up IR power (if you see something weird during 9:30-9:50 that could have been me. Sorry...)
Procedure: I requested the rotation stage to search for home, then requested a power of 0.212 W (nominal). Then repeatedly go to minimum and request the same power again to see if the rotation stage accumulate some error in angles. Eventually, I searched for home again a couple times then brought the power back to nominal.
Result: I find the result quite puzzling and need some times to think about it, but it seems like after search for home the difference between the requested power and the output power grows significantly. However, after a few adjustment I managed to get the requested nominal power and the output power to agree within 1% and that's where it was left this morning.
Action | Requested Power (W) | Measured Angle (deg) | Measured Power out (W) | |Power out - Requested power| (W) | Note |
Search for home |
0 | 5.073 | |||
Request power |
0.212 | 43.92 | 0.245 | 0.035 (off by 16.5% of the requested power) | |
Go to minimum |
37.98 | -0.035 | |||
Request power |
0.212 | 43.95 | 0.248 | 0.037 (off by 17.4% of the requested power) | |
Go to minimum |
38.07 | -0.027 | Didn't wait until the output power settle | ||
Request power |
0.212 | 44.04 | 0.259 | 0.047 (off by 22.2% of the requested power) | |
Go to minimum |
38.09 | -0.034 | |||
Request Power |
0.212 | 44.06 | 0.264 | 0.052 (off by 24.5% of the requested power) | |
Go to minimum |
38.13 | -0.037 | |||
Request Power |
0.212 | 43.87 | 0.246 | 0.034 (off by 16.0% of the requested power) | |
Go to minimum |
38.01 | -0.036 | |||
Request Power |
0.212 | 43.92 | 0.246 | 0.034 (off by 16.0% of the requested power) | |
Search for home |
0 | 5.080 | |||
Request Power |
0.212 | 43.96 | 0.271 | 0.059 (off by 27.8% of the requested power) | |
Search for home |
0 | 5.054 | |||
Request Power |
0.212 | 44.15 | 0.306 | 0.094 (off by 44 % of the requested power) | |
Go to minimum |
38.24 | -0.035 | |||
Request Power |
0.212 | 43.94 | 0.257 | 0.045 (off by 21.2% of the requested power) | |
Request Power |
0.198 | 44.17 | 0.288 | 0.09 (off by 45.5% of the requested power) | |
Request Power |
0.178 | 44.00 | 0.260 | 0.082 (off by 46% of the requested power) | |
Request Power |
0.119 | 43.64 | 0.236 | 0.117 (off by 98% of the requested power) | |
Request Power |
0.149 | 42.42 | 0.140 | 0.009 (off by 6% of the requested power) | |
Request Power |
0.159 | 43.26 | 0.198 | 0.039 (off by 24% of the requested power) | |
Request Power |
0.169 | 43.10 | 0.169 | 0 (off by 0% of the requested power) | |
Request Power |
0.179 | 43.66 | 0.207 | 0.028 (off by 15.6% of the requested power) | |
Request Power |
0.189 | 43.57 | 0.180 | 0.009 (off by 4.8% of the requested power) | |
Request Power |
0.210 | 43.97 | 0.212 | 0.002 (off by 0.9% of the requested power) | Nominal |
I had a look at the SRCL coupling to DARM during last night lock. Indeed it is non stationary, and the transfer function changes shape significantly. It appears, as already seen, that there is a low frequency component which is more or less constant, plus a high frequency component with a quickly varying gain. See the first plot for an animation of the TF from SRCL output to (calibrated) DARM.
I analyzed the coupling at 40 Hz and at 300 Hz. For the low frequency, the fluctuations are mainly in the transfer function gain, which is on average about 3e-11 (in some units) and fluctuates between 2 and 8e-11. For the high frequency, it seems that the phase as well as the amplitude changes. So I analyzed the real and imaginary parts of the TF separately.
The attached plots show that the coupling fluctuations are very well correlated with angular motions. In particular H1:ASC-AS_A_RF36_I_PIT_OUT_DQ is the winner. This signal has the same content as H1:ASC-AS_B_RF36_I_PIT_OUT_DQ.
So my conclusions is that the non stationarity is still dominated by angular motions in the SRC. Indeed, we didn't switch on any ASC boosts on SR1/SR2. We have to improve SRC angular stability. In particular SRC1_PITCH
Scott L. Ed P. Chris S. This report will cover the following dates: 4/21 & 4/22. On Tuesday the crew cleaned 46 meters ending 10 meters north of HNW-4-008. Test results posted here. Wednesday was spent removing and re-hanging lights, applying bleach/water solution, vacuuming support tubes and safety meeting.
Sheila, Gabriele, Evan
Tonight we spent some more time refining the locking sequence with good recycling gain. Some lessons learned:
This evening we had a look at which signals could be used for ITM ASC. We dithered each TMS to find acombination of signal which is insensitive to TMS motion, the attached screen shot shows the combination we ended up with. We has to move the picomotor on TMSY (M14 only). While doing this we noticed that there is a bug in the software so that according to the epics record of the position it looked like we were moving M3 rather than M14. We drove down to the end station and saw that indeed, the right motor was selected in the driver. We also see that the beam on the QPD reacts as we expected to moving the motor, so this must be correct.
For anyone who tries to lock in the morning
We are currently using the guardian as is through the state resonance. Sometimes there is an oscillation that gets rung up in this state and dies down, we have been waiting for this to ring down before moving onto analog CARM in our sucessfull locking attempts tonight. We have also been skipping the states BOUNCE VIOLIN mode damping and INCREASE POWER. We have also been using no whitening on the OMC DCPDs since the violin modes are still rung up and we haven't finshed re commisioning all the damping.
If we had more enegry...
we might try more violin mode damping, or investiagting why we aren't able to power up. Our last idea on this was to adjust the alignment to get a good recycling gain before attempting to power up, taking small steps and re-adjusting the alingment as we go. Another option would be to commision the ITM loops to do this job for us, using the error signals in this screenshot.
Also, we are leaving the intent bit undisturbed, even though this isn't a great lock. We are missing some ASC cut offs which make the noise worse below 30 Hz, we are at 3 Watts, and we have our bothersome 90 Hz shelf still.
We measured the response of the TRANS QPD error signals to ITM motions. Here is the result, in QPD units over alignment slider units:
Pitch | CSOFT_P | DSOFT_P |
---|---|---|
ITMX | 0 |
0.05 |
ITMY | 0.15 |
0 |
Yaw | CSOFT_Y | DSOFT_Y |
---|---|---|
ITMX | 0 |
-0.10 |
ITMY | 0.05 |
0 |
Right after the power increased from 3 to 10W (still no DARM offset and the IFO was locked with RF), all TMs moved by a large angle in PIT, mostly in SOFT:
ETMX +0.2 to 0.3 urad, ETMY +0.9, ITMX +0.5, ITMY +0.6.
It's possible that this is indeed DC radiation pressure pushing optics and the ASC fails to restore things back because we don't have the full DOF controlled, twisting other controlled optics to make the servo happy. If that's the case you need to be able to get back the recycling gain just by pushing ITMs manually even if you get an instability by doing so.
Also, if the angular optical spring is messing with the stability of the ASC, it looks better to me to switch to true HARD-SOFT based business instead of optic-based. Update: Evan and Gabriele think that the instability is coupled to the centering.
As reported in the previous alog (17990), we noticed that the IM4 trans has shifted by -0.7 counts horizontally after the pzt move (alog 17976) yesterday. I think that we have introduced a horizontal translation in the beam on the PSL mirrors by about 2 mm during the pzt move which resulted in the different IMC output beam alignment. I corrected the alignment of the IMC output beam, by moving IM2 and IM4 this morning.
(Estimation of the shift)
I did an A2L measurement (see Jax's alog 6676 for more details) on MC1 and MC3 to measure the amount of off-centerings. Since we have an active control for the MC2 spot position (DOF3), I did not measure it assuming the in-vac MC2 trans QPD has not moved. The table below summarizes the measurement from today with ones from Dec-2013 for comparison:
Apr-22-2015 | Dec-13-2013 (alog 8943) | diff (today - past) | |
MC1 P | +2.2 mm | -1.8 mm | +4.0 mm |
MC1 Y | +3.1 mm | +1.2 mm | +1.9 mm |
MC3 P | -2.0 mm | +1.7 mm | - 3.7 mm |
MC3 Y | -4.6 mm | - 2.2 mm | - 2.4 mm |
Since we know that the vertical position on IM4 trans did not change this time, we ignore them for now. Apparently the horizontal position shifted by 1.9 mm and -2.4 mm on MC1 and MC3 respectively. Note that the MC1 and 3 have a beam radius of 2.12 mm (see T0900386-v7) and therefore the shift is as big as the beam size. If we believe these numbers, the beam must have shifted as depicted in the below cartoon:
Assuming that the distance from a mirror at the bottom of PSL periscope to MC1 is roughly 8 m, the translation we have introduced is about 2 mm toward the West, which I think does not sound too crazy.
If we want, we can correct this by steering a combination of some mirrors in the PSL so as to compensate the translation.
(Doublecheck with MC suspension biases)
In addition to the spot position measurement, I also checked the suspension bias sliders for double check. According to 2 days trend of the suspension bias values, it seems that the ASC servos introduced 35 urads differential yaw on MC1 and MC3 while MC2 did not move much in yaw after the pzt move. I attach a screen shot of the trend. Though, I have no idea what was happening in the vertical directions which also show some variation. Based on a geometrical arrangement of the IMC alignment (for example, J.opt.13 055504 ), one can write the amount of mis-centering on MC1 and OMC3 due to differental angles as
x_mc1 = -x_mc3 = 2 * sqrt(2) * L * theta_mc1
Substituting theta_mc1 = 35 urad, one can obtain x_mc1 = 1.6 mm for MC1 (and -1.6 mm for MC3). So this is consistent with the spot position measurement and explains large fraction of it.
(Moving IM2 and IM4)
I decided to correct the output beam of IMC by moving some combination of IMs in order to keep the same PRM spot position. Since I did not like moving IM1 as it is far from the input Faraday, I decided to move IM2 to recover the spot position on IM4 trans. Then I corrected the angle of the beam by steering IM4. Here is a table summarizing how much I moved the bias sliders.
before | after | |
IM2 YAW bias | 5274 urad | 3314 urad |
IM4 YAW bias | -5130 urad | -3430 urad |
The direction of the move on IM2 is consistent with the above arguments. Fortunately, the move on IM2 and IM4 were such that they reduced the absolute numbers.
Added 1233 channels Removed 416 channels 74 channels remain unmonitored (list attached)
8:53 Travis to LVEA
9:00 Travis back
9:59 Metal recycling container going on the truck
10:06 The truck left
10:08 Karen to Mid Y
10:57 Karen leaving Mid Y
14:13 Jeff B. to 3 IFO storage area in the LVEA
13:24 Jeff B. back
After the PSL periscope PZT swap, the periscope bottom mirror is a different high reflector. We are using the transmission through that optic to monitor the input power into the interferometer; since the transmission of the new optic seems to be a little higher than the old one our calibration of the power into the interferometer has been off since tuesday. We used to get a maximum power input of 22.7 Watts, after the swap our monitor reads a maximum power of something like 23.7 W. I adjusted the responsivity of the periscope PD, it used to be set to 0.35 and is now 0.311.
Next time someone is in the PSL it would be good to check this calibration using a power meter.
Actually, we didn't change the bottom periscope mirror. Rather, we placed what was the upper periscope mirror, the one actuated by a PZT stack, in the IO_MB_04 position, just downstream of the thin-film polarizers and just upstream of the bottom periscope mirror.
The original IO_MB_04 mirror was moved to the top of the periscope.
So the transmission through the bottom periscope mirror should have changed only slightly due to a small change in the incidence angle as we directed the beam to the upper newly-placed upper periscope mirror.
However, we didn't optimize the beam position on the power monitoring PD dowstream sampling the beam transmitted through the bottom periscope mirror.
We should have a look at this centering next time we are out in the Laser Room.
Kiwamu, Evan
Yesterday after maintence time ITMY bounce mode was rung up. Eavn and Kiwamu damped it with the following settings: +60 degrees phase shifter, bandpass at 9.73 (FM2+FM4 in ITMY_M0_DARM_DAMP_V) and a gain of -0.03. We did not add this to the guardian, since we have not seen ITMY get rung up before we are assuming something unusual happened yesterday.
Also, the ETMY roll mode damping which uses AS A 45 has changed sign. the settings that evan found which worked today are -100dB, a bandpass at 13.9, no phase shift and a gain of -8.
For bounce and roll, there shouldn't be any need to gues at which optic is rung up, if the motion is large enough. If a mode is badly rung up we can usually see the bounce mode in the top mass vertical osem and the roll mode in the L2 witness sensors, either Pitch or Yaw. Attached here is a template that is stored in /ligo/home/sheila.dwyer/Locking/BOUNCE_ROLL_MODE_CHECK.xml. It shows you spectra and coherences with DARM of local sensors that should be used to identify which optic is rung up when our normal bounce or roll damping is not working. If the damping as it is in the guardian is not working, we shoudl turn off the damping to avoid confusion and run this template to identify which optic is the culprit.
CS pressure ~1 x 10-8 torr which is just below values programmed to step to 5000V -> Adjusted step set points from 1.5 x 10-4 amps to 3.0 x 10-4 amps for 3 of the 6 IP controllers at the Corner Station -> will continue optimal tweaking over the next few days
Greg, Nutsinee, Aidan, Elli
In the current configuration, the ITMX CO2 laser is inputting 0.2W of central heating to ITMX, just as it has been doing so for the last few months. The power put onto ITMX is still 0.2W, as measured by the power meter on the CO2X table (H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT). But the requested power needed to get 0.2W output in now 0.71W, up from 0.35W yesterday. The rotation stage does not appear to be returning to the same location.
Details:
The CO2 laser power is requested by a setting H1:TCS-ITMX_CO2_LASERPOWER_POWER_REQUEST to the desired value, and then a rotation stage moves a 1/2 wave plate to the required angle for that power. After the model restart this morning, we had to request a very different power (0.44W this morning compared to 0.35W yesterday, compared to 0.3W in March) to get the same output power in H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT. None of the gains or calibration values had changed this morning, so we suspect hysteresis in the rotation stage. I moved the rotation stage back and forth between minimum power and 0.2W output power and back again. I needed to keep requesting higher powers to bring the output power to 0.2W, although there seems to be no clear pattern to the change. Perhapse the rotation stage is sticking sometimes. See attached data set of 20 mins of data where I was moving the rotation stage around.
Other comments on ITMX CO2 laser:
We noticed a few other things while trending the output power:
The laser temperature as measured by H1:TCS-ITMX_CO2_LASERTEMPERATURE jumped from 23 degrees Celcius to ~27C on 17 March, see plot . The temperature has been fluctuating a lot more since then. This does not corelate with the enclosure temperature, the laser power has been steady at 59W, and the chiller settings have not changed. Greg and Matt were poking around the CO2 lasers that day, although according to the alog no chages were made to the ITMX CO2 laser (alogs 17303, 17302).
The laser has been mode hopping since 10 April when Greg swapped out the CO2 laser AOM (alog 17737). We hadn't seen this previously. The laser power has been fluctuating by >1% (1W fluctuations from 59W output power). This does not have a big effect on the power level going onto ITMX.
There's a correlation between spikes in output power of the laser and shifts in the rotation stage. This is quite possible if there is a small reflection from somewhere on or after the rotation stage that is coupling back into the laser and causing the laser mode to shift.
The laser temperature shift may be a glitch in the electronics box. Rich and I noticed something similar at LLO but we could never identify exactly where it came from and then it seemed to disappear. We'll look into this some more.
There definitely seems to be an electronics glitch associated with the laser interlock controller (D1200745). If we look at the attached plot from about a month ago, we see that during an event where the laser was turned off and back on again, there were jumps in the flowrate and temperature voltage monitors (both of which run through D1200745) at the same time that there was a 10% increase in the current to the laser. The laser interlock controller is connected to the laser RF driver to turn the laser on and off.
Taking a look at the laser head output, I'm not sure that those glitches are the laser mode hopping. The power doesn't look like it jumps as much as you would expect for a mode hop. I suspect Aidan is correct that it may be reflecting back into the laser a little which can cause some weird effects since the reflected beam can steal gain.
Detchar would like to request that the HWS cameras in the center building be turned off for a few minutes at a known time. We're trying to track down some glitches in PEM and ISI sensors that happen every second, and Robert suspects the HWS. Just a few minutes with them off, and then on again, would be fine; we don't need the IFO to be in any particular state, as long as the ISIs are running fine. We would need the precise times (UTC or GPS preferred), as the channels that record the camera state don't seem trustworthy (alog).
This afternoon I tunred all HWS off and I will leave them off all night (both of the corner station HWS were on prior to this).
It seems like the HWS was in fact the culprit. The HWS was turned of at Apr 21 20:46:48 UTC, according to TCS-ITMX_HWS_DALSACAMERASWITCH. I checked the BLND_Z of the GS13s on BS and ITMX, and the table 2 PSL accelerometer. All three had glitches every second before the HWS was turned off. They all continued to glitch for 11 more seconds (until the end of the minute), and then all stopped at the exact same time. Attached is a spectrogram of the ITMX GS13. It's hard to see the glitches in the PSL by spectrogram or even Omega scan, but they're very apparent in the Omicron triggers.
Here are three better spectrograms showing the transitioning off of the HWS and the loud once per second glitches going away in the ISI-*_ST2_BLND_Z_GS13_CUT_IN1 channels. These plots are made with https://ldvw.ligo.caltech.edu using 0.25 seconds per FFT and normalization turned on. Conclusions same as Andy's post above.
David Shoemaker asked the good question, do these glitches even show up in DARM? Well, that's hard to say. There are once per second glitches that show up in the ISI channels, and once per second glitches that show up in DARM. We don't know if they have the same cause. Figures are: 1. DARM once per second glitches, 2,3, BS and ITMX, 4. overlay of all showing that the glitches in DARM are just slightly ahead in time (in this 0.25 sec/fft view, unless there is some sample-rate timing bias).
In order to test whether they are both caused by the HWS it would be really useful if folks on site could turn the HWS on, then off, for a minute or so in each configuration during a low-noise lock and record the UTC times of those states.
We got to a low noise state which is not at as low noise as our best, with the spectrum about a factor of 10 worse at around 90 Hz than our best reference. We were in low noise, HWS off from 10:42:30 UTC to 10:47:30 UTC, i turned the cameras on according to Elli's instructions and we left the cameras on from 10:48:20 UTC to 10:53:40.
Andy, Duncan When looking for times when the HWS camera was on or off, I found that the minute trends indicated that it was off on Apr 18 6:30 UTC for ~27 minutes. But the second trends indicate that it was turned off 20 minutes later than that (and back on at the same time). The raw data (sampled at 16 Hz) indicates that the camera was never turned off. This was originally found using data over NDS2, but Duncan has confirmed by using lalframe to read the frames directly. I've attached a plot below. The channels are H1:TCS-ITM{X,Y}_HWS_DALSACAMERASWITCH.
I was able to successfully run it in the Caltech (CIT) cluster using a matlab code i.e., the raw, minute and second trends agree. The matlab code uses ligo_data_find. But if I run the same code at Hanford cluster it produces the results Andy and Duncan saw i.e., the trends disagree. So there seems to difference between the frames at these two locations for the trend ones. I have attached the matlab codes here with incase some one wants to test it.
This is because the trend data from the two CDS framewriters can disagree. This happens if a framewriter restarts during the period covered by the trend file, and the averages from each framewriter are computed using a different number of values. These differences only happens with the trend data. See below for the details.
Note that at LHO, LDAS is using the CDS fw1 framewriter as the primary source of the scratch trends (saved at LHO for the past month) and the CDS fw0 frameswriter as the primary source of the archive trends (copied to CIT and saved permenantly at LHO and CIT). If a framewriter goes down, it will still write out the trend data based on what data it has since it restarted. Thus you can get trend frames that contain data averages for only part of the time period covered by the file. For the time given in this alog, the trend files under /archive (from framewriter-0) and /scratch (from framewriter-1) differ is size: $ ls -l /archive/frames/.../H-H1_M-1113372000-3600.gwf -r--r--r-- 1 ldas ldas 322385896 Apr 18 00:27 /archive/frames/.../H-H1_M-1113372000-3600.gwf $ ls -l /scratch/frames/.../H-H1_M-1113372000-3600.gwf -r--r--r-- 1 ldas ldas 310156193 Apr 18 00:46 /scratch/frames/.../H-H1_M-1113372000-3600.gwf Note that both files pass FrCheck (but have different checksum) and contain valid data according to framecpp_verify (e.g., run with the --verbose --data-valid options). However, if I dump out the data for one of the channels in question, I get: $ FrDump -i /archive/frames/.../H-H1_M-1113372000-3600.gwf -t H1:TCS-ITMX_HWS_DALSACAMERASWITCH.mean -d 5 | grep "0:" 0: 1 1 1 1 1 1 1 1 1 1 10: 1 1 1 1 1 1 1 1 1 1 20: 1 1 1 1 1 1 1 1 1 1 30: 1 1 1 1 1 1 1 1 1 1 40: 1 1 1 1 1 1 1 1 1 1 50: 1 1 1 1 1 1 1 1 1 1 $ FrDump -i /scratch/frames/.../H-H1_M-1113372000-3600.gwf -t H1:TCS-ITMX_HWS_DALSACAMERASWITCH.mean -d 5 | grep "0:" 0: 0 0 0 0 0 0 0 0 0 0 10: 0 0 0 0 0 0 0 0 0 0 20: 0 0 0 0 0 0 0 0 1 1 30: 1 1 1 1 1 1 1 1 1 1 40: 1 1 1 1 1 1 1 1 1 1 50: 1 1 1 1 1 1 1 1 1 1 These frames start at, $ tconvert 1113372000 Apr 18 2015 05:59:44 UTC and the 0's start about 28 minutes into the /scratch file (copied from framewriter-1), while the /archive version only contains 1's (copied from framewriter-0). Thus, I predict framewriter-1 restarted at around Apr 18 2015 06:28:00 UTC. It seems that 0's get filled in for times before that. If I check, H1:TCS-ITMX_HWS_DALSACAMERASWITCH.n, which gives the number of values used to get the averages, this is also 0 when then above numbers are 0, indicating the 0's came from times when framewriter-1 had no data. Note that this behavior only occurs for second-trend and minute-trend data. If data is missing in the raw or commissioning data, no file is written out. Thus, we never find a difference between the raw (H1_R) or commissioning (H1_C) frames between valid frames written by both framewriters. Note that the diffH1fb0vsfb1Frames process seen in the first row of green lights here, http://ldas.ligo-wa.caltech.edu/ldas_outgoing/archiver/monitor/d2dMonitor.html is continuously checking that the raw frames from the two framewriters is the same. (The same process runs at LLO too.) If differences are found, it sends out an email alert. I've never received an alert, expect when the RAID disk-arrays have either filled up (and 0 byte files were written by one framewriter) or when the RAID disk-array hung in some way that caused corrupt files to be written. In both cases, the files on the problem array never pass FrCheck and are never copied into the LDAS system. Thus, the above feature, is a feature of the second-trend and minute-frames only. To avoid this issue, code should check the .n channel to make sure the full number of samples were used to obtain the average. Otherwise, some of the trend data gets filled in with zeros.
Greg said:
Thus, I predict framewriter-1 restarted at around Apr 18 2015 06:28:00 UTC. It seems that 0's get filled in for times before that.
the restart log for 17th April says
2015_04_17 23:28 h1fw1
With local PDT time = UTC - 7, Greg gets a gold star.
There should also be a .n channel which tells you how many samples were included in the average.