Tom noticed that two trhs are bad on rim.
They are reporting wacky temps and RH:
20m (ttyS15 on rim) TRH28 140.50 461.21 0 0 4605 2054 0\r\n TRH28 140.46 461.85 0 0 4604 2052 0\r\n TRH28 140.46 461.08 0 0 4604 2054 0\r\n 40m (ttyS8 on rimup) TRH19 139.79 0.00 46 0 4562 1999 144\r\n TRH19 139.79 0.00 46 0 4562 2001 144\r\n TRH19 139.82 0.00 46 0 4563 2004 143\r\n ^R\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 5.82 60.80 46 0 1138 126 143\r\n TRH19 5.82 60.80 47 0 1138 126 146\r\n TRH19 5.86 60.81 47 0 1139 126 146\r\n
Was able to get the 40m TRH to reset and start reporting believable data by sending ctrl-R from rserial as shown above.
That did not work for the 20m TRH (which we've seen before). Power cycling port 15 with eio also does not work
The SPN1 global radiation often is significantly (up to 100 W/m2) higher than Rsw.in on clear days. This could indicate a reflection problem, though without seeing the exact set-up, I can't imagine how reflections would affect only this sensor. Plotting the data as an x-y comparison, there appears to be some curvature (non-linear comparison) both at high and low radiation levels, as well as some hysteresis.
Looking at SOAS data, I also see higher SPN1 values than Rsw.in, but this is well modeled by a simple gain factor. The sky was never totally clear to replicate what is being seen in METCRAXII.
At the least, I would check that the SPN1 is level (though I still can't think of how being non-level would increase incoming radiation values).
10/9, twh
The high winds today provide an opportunity to adjust the wind directions on the profiles towers. We only measured the 3m sonic azimuth with the DataScope and assumed that the other sonics on the profile towers were aligned with the lowest level. For the past 6 hours, the wind speed above 3m at near has been higher than 15 m/s, while that at 3m has been 13-14 m/s. The following table shows the median wind directions relative to that at the lowest level. These values should be subtracted from the azimuth at each level.
This adjustment is perhaps more tenuous at RIM because of the complex topography, but the speed and direction plots suggest little terrain influence for winds from 200 degrees (SSW).
See accompanying plots, made with dir.diff.profile for the exact period selected for high wind speeds.
10/31: I redid the analysis with a miminum wind speed of 10 m/s at 10 m. This gives a much larger data sample (105 hours at NEAR and 150 hours at RIM) and a wider range of wind directions, 190 - 230 deg at NEAR and 178 - 242 deg at RIM, with mean wind directions for both sites near 208 deg.
z(m) |
NEAR dir(z) - dir(3m) |
RIM dir(z) - dir(5m) |
---|---|---|
10 |
0.1 - 0.37 = -0.3 |
1.0 + 0.87 = 1.9 |
15 |
-1.4 - 0.21 = -1.6 |
-0.7 + 1.07 = 0.4 |
20 |
-1.7 + 0.01 = -1.7 |
-3.7 + 1.56 = -2.1 |
25 |
-1.1 - 0.32 = -1.4 |
-1.2 + 2.21 = 1.0 |
30 |
-2.2 - 0.50 = -2.7 |
-2.4 + 2.3 = -0.1 |
35 |
-4.5 - 0.57 = -5.1 |
-2.4 +2.8 = 0.4 |
40 |
-2.1 - 0.947 = -3.0 |
-3.9 + 3.0 = -0.9 |
45 |
-0.9 - 0.58 = -1.5 |
|
50 |
0.8 - 1.11 = -0.3 |
|
Wind speed and direction at NEAR
10/31:
Wind speed and direction at RIM
10/31:
25m near and 20m rim TRH's have been reporting values of 0 for their fan currents.
I tried rserial to both TRHs and doing a ctrl-R, but that didn't help. The TRH's did not respond with their reboot message. The only effect was to stop the data, which only resumed after hitting CR several times.
I could power cycle the TRH at near with "eio 14 0", "eio 14 1" commands, so that Ifan.25m.near is now about 40.
Power cycling the TRH at rim (eio 15 0/1) didn't work, it continued to report wheh supposidly powered down. That port must not be FET controlled.
Tim bought a replacement for his blown UPS, and has loaned the new unit to us. It's a low-end consumer "CyberPower 425VA" unit.
I've moved some essential peripherals to it from the APC UPS with the dead battery:
- /media/backup external UPS drive
- Hughes satellite modem
- AP24 Alico WIFI access point.
- Dlink 8-port hub
- Netgear router
- Netgear 8-port hub
What's left are laptops with their own batteries, and monitors. These are all on the surge protection side of the UPS's.
During IOP1 the network to the back of the trailer suffered problems. I believe the network switch in the back of the trailer was connecting to a LAN port on the Netgear router, which apparently hung. The WAN port on that router is connected to the Hughes modem. The Netgear also serves the trailer "metcraxii" WIFI.
I've removed all LAN connections on the Netgear router except for one going to the D-link 8-port switch.
We'll connect all other switches to the D-link, and avoid further daisy-chaining the switches and connecting any other systems to the Netgear router and see if that helps.
10/9/13, twh
The trailer is rocking today; Spd.10m.base = 15 m/s, gusts to 30 m/s.
Wack-a-Mote continues...
Planned to make service visit to FLR today, but too windy.
Yesterday replaced TRH.25m.near, raised near sawhorse to 2.02 m, reseated radio in rad.far mote, etc.
T/RH: Ifan 20m.rim (10/9 8:00), 25m.near (10/8 15:00) = 0, but data looks okay.
RH.25m.rim replaced and now matches profile, but RH.50m.near and RH.35m.rim(?) high
T.20m.rim fits into profile at high wind speeds today
P: ok
csat u,v: ok
csat ldiag: ok
csat w, tc: ok
kh2o: FLR flaky; FLR fluxes noisy but believable
motes: FAR ok
NEAR ok
FLR rad just restarted around 10 am.
Wetness: ok
radiation: Rpile.out.far flat-lined since 10/7 09:00
Tsoil: Tsoil.3.1cm.near has offset since 10/7 12:15
Gsoil: ok
Qsoil: FLR, FAR < 0
Cvsoil: ok
2D sonic: ok, FLR wind direction not yet corrected
I installed the spare solar panel array and charge controller at the German Scintillometer on the south rim today. We did not utilize the cooler for battery containment, we used one of their existing boxes. The equipment that belongs to ISFS at this location is as follows:
1 set of solar panels on a frame
1 charge controller, mounted inside the battery box that belongs to the Germans
4 rebar stakes at the feet of the solar panels
1 solar panel connector cable
Thanks,
Tim
Tom, Gordon arrived 4:19
Replaced dessicant in 4x radiometers.
Inspected mote radios with "dental" mirror. Radio in radiation mote (ID4) was tilted a bit out of its contacts on the board. Removed the mote and took it back to the base for maintenance. Did not have a spare mote that is programmed to talk to base mote #17.
Radiation mote battery has not been charging. Removed cover on rad mote battery box. One of the connectors was loose. Saw 16V on the PV side of the little circuit board.
Departed at 4:50
Tom, Gordon arrived 2:45 local
Replaced trh transducer at 25m, due to anomalously high RH. Transducer was #43. Replaced with #25.
Checked base mote. Antenna cable connection inside white box was a bit loose, was able to tighten 3/4 turn by fingers.
Plugged ethernet cable from nearup into surge protector inside near DSM. It was going straight into the switch box.
Removed GPS jumper on soil mote. All antennas tight on motes.
Raised rad stand to 2.02 meters. Pyranometer bubble is in the circle. Pyrgeometer bubble high to south.
Left rad stand at 4:02. Departed site at 4:06
Just for fun, the plot below attempts to display all of the winds (one-hour averages) during the morning 00-06 Oct 06. In all of these profiles, there is a jet in the middle of both the NEAR and RIM profiles. I've shown winds from the other towers as an appropriately-colored rectangle (two in the case of the 2 slope sites). (I tried giving all the data to the image function, but a color mess resulted.)
I've put the code (<mostly> in R) for this in the METCRAXII project R directory.
Normally we do not use data at wind directions of +/- 45 degrees from 180 (in sonic coordinates), in order to eliminate winds blowing through the tower and into the back of the sonic. However, because of the topography at RIM, I used data at +/- 60 about the nominal axis of the gap, SSW or 202.5 deg. The tilt plots are done with respect to the sonic u axis, which was pointed to 253 degrees. Thus in instrument coordinates, the acceptable data is from -10 deg to 110 deg.
Also at RIM, there is a systematic descent of air into the crater, i.e. a vertical flow normal to the "surface". I find more realistic lean angles by setting w.off = 0 and use the latter results in the RIM cal_files.
sonic |
lean (deg) |
leanaz (deg) |
w offset (cm/s) |
---|---|---|---|
3m.near |
0.6 |
-3.2 |
-2 |
10m.near |
1.0 |
9.9 |
-2 |
15m.near |
0.5 |
43.2 |
0 |
20m.near |
0.6 |
27.8 |
-1 |
25m.near |
1.0 |
79.1 |
-1 |
30m.near |
0.7 |
38.1 |
-2 |
35m.near |
0.7 |
112.2 |
-2 |
40m.near |
0.6 |
96.2 |
1 |
45m.near |
1.1 |
33.7 |
-1 |
50m.near |
0.8 |
34.0 |
0 |
5m.rim |
1.3 |
-91.2 |
0 |
10m.rim |
2.2 |
-122.7 |
0 |
15m.rim |
1.7 |
-107.5 |
0 |
20m.rim |
1.4 |
-109.7 |
0 |
25m.rim |
1.1 |
-119.2 |
0 |
30m.rim |
1.4 |
-126.2 |
0 |
35m.rim |
1.2 |
-101.4 |
0 |
40m.rim |
2.4 |
-110.8 |
0 |
3m.far |
1.1 |
-31.8 |
-2 |
3m.flr |
0.7 |
162.1 |
-3 |
ssw2.flr |
10.1 |
-59.0 |
3 |
ssw4.flr |
30.5 |
-38.2 |
-5 |
10/8/13
T/RH: ok, high RH.25m.near
P: ok
csat u,v: ok
csat ldiag: ok
csat w, tc: ok
kh2o: Looks more believable today.
Wetness: ok
radiation: sensors ok, motes intermittent
NEAR SPN1 mote down 10/8 10:00
Tsoil: sensors ok, motes intermittent
NEAR Tsoil.3.1cm down
FAR soil mote down 10/8 09:25 FlR soil mote down 10/8 08:15
Gsoil: ok
Qsoil: FLR, FAR < 0
Cvsoil: Vpile off scale, Gordon changed NIDAS limits
2D sonic: ok, FLR wind direction not yet corrected
TP01:
We've seen the Lambasoil/Csoil problem before. I'm convinced that something is wrong in the signed math code in the TP01's PIC. If Vpile.off goes even slightly negative, it is reported as NaN by NIDAS. This behavior wouldn't rule out a NIDAS/mote parsing error, however the TP01's derived value for Lambdasoil (that depends on Vpile.off) also comes back as NaN, even though it should always be a positive number. Ideally, new code would be written, loaded onto a laptop, and downloaded to the sensors at each site. Otherwise, we can write code that sets Vpile.off always to 0 (a good assumption) and recompute Lambdasoil. To do this, we need to know the serial number of each TP01, since this calculation involves sensor-specific calibration coefficients. (This was the reason we had the PIC do the calculation in the first place.)
I'll talk to SRS about this code.
Single-soilT probe:
Chris and I discussed his installation of these probes (he did at FLR and FAR). He oriented them horizontally, nominally at the level of the second? picklefork tine (1.9cm). However, there have been HUGE soilT vertical gradients -- 15 degrees between 0.6 and 4.4cm is common in the middle of the day -- so even a small vertical (or even horizontal?) difference in position could cause the differences of up to several degrees that we are seeing.
I don't know how Kurt and Gordon positioned this sensor at NEAR.
I don't believe any action is required at this point.
The data show that the single probe appears to be at 0.6cm at flr, 2.5cm (or averaging) at near, and 4.4cm at far.