10:30 - Noticed usbdisk at near went down yesterday at 12:00Z.
SO moved the usbdisk to another usb port and mounted. Did mount usbdisk by hand. Took about 2 min, then passed ext3fs check. Disk back up.
Obviously, we have lost any data that may have been dropped by the AP24 during the last 29 hours! Fortunately, this was not during an IOP...
P.S. Actually, the IOP was still going on for the first 5 hours of this outage. During this time, 413 samples (20 seconds of data) were dropped from each of the sonics in the period 08:10 - 08:15 MDT. Just after the IOP ended, essentially the entire 5-minute block of data from 10:50-10:55 MDT was dropped. I guess losing 20 seconds of data from one DSM during an IOP isn't <too> bad, but it shouldn't have happened. In our defense, even if we had caught this error as soon as we got up (~06:30 MDT), we likely would not have gotten to the site in time to have prevented this 20-second outage.
10/25/13
Summary:
- No IOP last night
- mostly clear this morning, few clouds to the North
- 40m TRH on rim went out last night
Actions past 24 hours:
- SO added a Qsoil probe to base for testing
To dos:
- SO to water new Qsoil probe at base
- switch pocketec
Sensor status:
T/RH: ok, monitor 40m TRH on rim
P: ok
csat u,v: ok
csat ldiag: ok
csat w, tc: ok
kh2o: ok
motes: ok
Wetness: ok
radiation: ok
Tsoil: ok
Gsoil: ok
Qsoil: ok, monitor Qsoil at base since ground has been watered
Cvsoil: ok.
2D sonic: ok
Sometime between 22:00-23:00 last night, TRH.40m.rim went bad. I just (04:35) sent it a control-R and got it going again:
PS. HOWEVER, We have found that the "bad" data are correctable! Traw has 2 extra bits shifted in and RHraw has 4 extra bits. Dividing by 4 and 16, respectively, and recalculating restore these data! (We can do this for old projects as well!)
TRH19 157.85 0.00 37 0 5035 2147 117\r\n TRH19 157.85 0.00 38 0 5035 2148 120\r\n TRH19 157.85 0.00 39 0 5035 2150 124\r\n ^R\0x80\n \r Sensor ID19 I2C ADD: 12 data rate: 1 (secs) fan(44) max current: 80 (ma)\n \rresolution: 12 bits 1 sec MOTE: off\r\n calibration coefficients:\r\n Ta0 = -3.993325E+1\r\n Ta1 = 4.048482E-2\r\n Ta2 = -2.386631E-7\r\n Ha0 = -8.241113E+0\r\n Ha1 = 5.922000E-1\r\n Ha2 = -4.567768E-4\r\n Ha3 = 8.744341E-2\r\n Ha4 = 1.592101E-3\r\n Fa0 = 3.222650E-1\r\n TRH19 10.61 66.10 38 0 1258 134 119\r\n TRH19 10.61 66.10 38 0 1258 134 118\r\n TRH19 10.61 66.10 38 0 1258 134 118\r\n TRH19 10.57 66.58 37 0 1257 135 117\r\n
We've seen these before, but a spike in kh2oV.3m.flr is between 15:00:43 - 15:01:15 today. I'm calling these bugs, but I don't quite believe this explanation. If you want stranger ideas, ask Steve Semmer.
P.S. A better explanation is a drop of rain, though none was noticed at the base.
I just added a spare Qsoil to base in a plot that I will water. My goal is to characterize the behavior of an EC-5 probe in this soil with high iron content. Hopefully, it will still have a slope of 1, but just an offset. Although the soil structure changes a bit from site-to-site here, the iron content appears (based on my magnet test) to be about the same at base as at near, so I am optimistic that these test results will be relevant to the other sites.
Probe is ECHO005/PIC015.
The plan is simply to water this plot to field capacity and watch it dry out, while taking gravimetric samples regularly -- at least daily.
15:00 took the first sample (still before wetting; soil was a little bit moist). I'll just measure the 3-6cm ring, as being close to the location of the EC5 (volume = 3*pi*(5.31/2)^2 )
10/25: 09:35 First watering. Water ponded. I'll wait a bit and reapply.
09:45 Second watering. EC5 still hasn't seen it.
10:00 Water #3. EC5 still hasn't seen it.
10:15 Water #4. EC5 noticeably rising.
10:45 Water #5. EC5 up quite a bit.
11:05 Water #6.
11:15 Water #7. I'll stop here.
11:40 EC5 beginning to flatten out.
Date | Time | Tare | Wet | Dry | Rho | Grav% | Vol% | EC-5 |
|---|---|---|---|---|---|---|---|---|
10/24 | 15:00 | 2.4 | 84.3 | 77.8 | 1.14 | 8.3% | 9.5% | 9.5% (EXACT!) |
10/25 | 13:30 | 8.2 | 129.0 | 111.0 | 1.55 | 17.5% | 27.1% | 20.3% |
10/25 | 16:45 | 8.2 | 117.0 | 102.8 | 1.42 | 15.0% | 21.4% | 18.6% |
10/26 | 11:00 | 8.2 | 108.3 | 98.1 | 1.35 | 11.3% | 15.4% | 17.1% |
10/27 | 09:15 | 8.2 | 102.6 | 92.9 | 1.27 | 11.5% | 14.6% | 14.2% |
10/27 | 13:25 | 8.2 | 128.8 | 115.2 | 1.61 | 12.7% | 20.5% | 15.7% |
10/28 | 16:30 | 8.2 | 141.0 | 126.7 | 1.78 | 12.1% | 21.5% | 14.2% |
10/29 | 15:20 | 8.2 | 109.3 | 98.3 |
|
|
| 13.3% |
Here is a plot of these data, along with a 1:1 line and a linear regression to all but the first sample (when the EC-5 might not have been settled in). The regression line has an intercept of 9.9% and a slope of 0.34. Also shown are the 3 gravimetric samples at far (f), near 
, and flr (r). It was my intent that this slope would be applied to all of the METCRAXII Qsoil measurements, and to have the offset computed from the 1 gravimetric sample at each site.
With this philosophy, the adjustments are:
actual = (far + 2.3)/0.34
actual = (near - 4.4)/0.34
actual = (flr + 5.8)/0.34
actual = (base - 9.9)/0.34
The project measurements agree with these numbers reasonably well. However, near still goes negative at times, far goes negative one night, and flr goes over 61% during one rain event. Thus, I think that the 0.34 slope model above is not correct.
Subtracting only 7.6 (rather than 9.6) from flr makes the agreement quite good. Next, would be to check Cvsoil to see if sensor gains are consistent?
Using the in-field Qsoil adjustment (just a one-point bias correction), I see:
In this plot, I have placed an eyeball fit of a line with a slope equal to Cv_h2o through the data. Only at near is a systematic variation seen of Cv with Qsoil. If anything, the near plot has (slightly) too low a slope (Qsoil gain too high). I would say that this plot does not justify increasing the measured Qsoil values by a factor of 3.
To conclude:
- The test at base suggested increasing the Qsoil gain by a factor of 3. However, applying this correction to the site values makes negative values, too large flr values, and worse comparisons with Cvsoil from the TP01.
- The one-point in field adjustment of just the bias has none of these problems, though flr then is consistently larger by ~2%.
10/24/13
Summary:
- IOP last night, Dave says it was a good night
- cloudy this morning
Actions past 24 hours:
- SO and SC went to floor to fix P.sw.flr, battery replaced
- SO tried to improve RF comms for P.nne, refer to detail entry
- removed diode from soil battery system at near
To dos:
- SO looking into adding soil sensors to base
Sensor status:
T/RH: ok
P: ok
csat u,v: ok
csat ldiag: ok
csat w, tc: ok
kh2o: ok
motes: ok
Wetness: ok
radiation: ok
Tsoil: ok
Gsoil: ok
Qsoil: ok. Offsets based on yesterday's gravimetric samples make the data look reasonable (for the entire experiment).
Cvsoil: ok.
2D sonic: ok
At about 3:00 today, SRS visited near and removed the diode from soil.near. He chose this mote, since its Vmote cycles the most. We haven't noticed any effect from this change.
Just because we were tired of seeing red-lined Qsoil values in cockpit, I've added the offsets found from my gravimetric samples to metcraxii2.xml. The values now look much better, though I'd still like another gravimetric sample in different moisture conditions to make a better calibration.
Gordon: You might want to propagate this change to Boulder...
I've thought about how to have a discussion with Delta-T devices about the SPN1 morning "dip". Steve and I thought that reorienting the sensor would better inform such a discussion, so we did that 2 days ago. (It was oriented with the analog cable side facing north, now it is the dessicant plug facing north.) Since that time, the dips have not gone as low as zero, but the dip still is clearly present. However, both of the past mornings have had a tiny amount of haze, likely associated with the recent controlled burn to the south of the site. (This haze is clear in the ceilometer and lidar returns.) Looking at past data, obscured skies increase diffuse radiation (as expected) and can be of a magnitude to mask the "dip".
Thus, I believe we have to wait for another perfectly clear morning in order make a definitive comparison between the "dip" for different SPN1 orientations. Ideally, we would acquire data with the digital cable connector oriented north as well, but there likely won't be time during the rest of the experiment.
10:45: While showing flr to SteveC, I (SO) noticed that the sensor cable seemed to be blocking line-of-sight between the Bluetooth receivers and NNE, so I flipped the cable around to the front of the mote box. Apparently, this crashed NNE data transmission. SRS notified us about 40 min later (as we were about 1/4 way up the trail). Went back to flr, flipped the cable to the backside of the mote box and rotated the lower mote box by about 10 degrees to lessen line-of-sight blockage to NNE from the tower uprights. SRS reported that this brought NNE back and didn't adversely affect reception from the other Bluetooth motes. data_stats delta-t's still show worse reception from NNE than the others, but no worse than before. Odd that this mote is so finicky.
10:41-10:55 - SO "cleaned" the krypton at floor. He used a wipe, since he didn't have a swab and managed to make it worse (kh2oV drop from 1.8 to 1.5V).
10:20 - P.sw.flr is running again. Steve O. and Steve C. replaced the battery. Old voltage was down to 4.4V. New read upwards of 15V.
10/23/13
Summary:
- No IOP last night
- Low-level haze this morning, smelled like smoke from the fire to the south
- High cloud built up during the day (of 10/23)
Actions past 24 hours:
- generator replaced
To dos:
- Keep checking flr SPN1
- Check out P.sw.flr
- decide on orientation of SPN1 at floor
Sensor status:
T/RH: ok.
P: ok except for P.sw.flr
csat u,v: ok
csat ldiag: ok
csat w, tc: ok
kh2o: ok
motes: ok
Wetness: ok
radiation: ok
Tsoil: ok
Gsoil: ok
Qsoil: ok. Offsets based on yesterday's gravimetric samples make the data look reasonable (for the entire experiment).
Cvsoil: ok.
2D sonic: ok
Gordon pointed out to us that P.sw started dying at 12:40 today, and stopped reporting at 14:25. We're guessing that this is power related, but won't be able to do anything until tomorrow. Note that we get no response to:
rs SW-p::hci1
If we did, we could have tried "r" to restart. (This works with the other Vaisala barometers.)
13:00 - 13:30 - The generator was replaced with a new unit. The UPS kept the data system up during
the change over.