11:00 - 12:00: Soil samples were taken at sites A and B in increments of 0 - 3 cm and 3 - 6 cm.
Weather: clear skies this morning
Sensors:
Sonics: ok, some Idiag activity on 43.9m early this morning
TRH, P: ok
H2O, CO2: ok, some clipping on 38m
Tsfc, Rpar: ok
Krypton: ok, low signal on 13.9m
soils: soil sensors at b questionable, Tsoil.b out, qsoil.b funny
Rad: ok
wetness: ok, out at rad due to bad port
Vdsm: ok
Vmote: ok, 12.1 to 12.7
After the rain last night (timing not verified), the undercanopy Rsw.in died, though it wasn't noticed until late in the day. About 1815-1830 determined that water got into the mote box and the next-to-the-left port no longer works. Pulled the wetness sensor to allow the radiometers to occupy the remaining ports. Ultimately, this mote should be replaced. (It may be good that I brought a spare with me!)
We've noticed that the 8m sonic dies in rain, though it was able to be restarted this morning. I replaced the cable (by tower climbing from about 1530-1545), which killed it. We then (1615?) swapped serial ports (from ttyS5 to ttyS19) and now it works. We haven't gone back to the original serial cable to see if it is okay. In any case, the old cable backshell on the sonic side of the cable should be resealed. I'll tape it when I next climb. We also should try to debug port ttyS5.
Since Tsoil.a.4cm has been noisy, we installed a new sensor on a new mote. This was installed about 50cm north of the previous Tsoila, so pretty close. It is now configured as Tsoil.c. This added about 1500 t
Data from 8m sonic quit around 22:00 local last night, June 13, which was shortly after the rain started.
This morning at about 6:15 logged tried to restart it with rserial and '&', 'D' commands, but failed.
What did work was "eio 5 0; eio 5 1"
This serial port is showing many errors (rather like the 20m sonic).
cktty 5 5: uart:ST16654 port:F1000100 irq:3 tx:24312 rx:335503663 fe:1254623 brk:548000 RTS|CTS|DTR
These high counts for fe (framing errors) and brk (break condition) are since the last reboot of the low DSM, 16 days ago, so we don't know if they happened last night.
A storm came in from the north last night. It rained intensely for about 2min while we had dinner in Tuscaloosa. All gauges saw it at about 2145 with totals:
undercanopy: 5.0mm (includes an event earlier in the day)
ott: 3.1mm
new tipping bucket: 3.1mm
pond: 4.3mm
Thus, perfect agreement between the 2 new sensors and general agreement between all.
All systems stayed up, though all sensors stayed wet overnight.
Replaced the 30A fuse in the 8kVA this afternoon. We have three fuses left.
Noticed tipping bucket at soil.b was clogged. Un-clogged tube. All good again.
Gordon
The satellite internet service for the folks at the AABC center has been poor recently, and the drop in service seemed to be coincident with the start of our operations. At Paul Johnson's PC, DNS was not working, and I couldn't ping their DNS servers, or the google DNS servers: 8.8.8.8
I tried turning off the etherant wifi at the Lidar, since that was closest to their satellite dish. They rebooted their satellite modem, but there was no improvement.
They then had an ISP tech come out to check their dish alignment, and replace some components. That improved things but it still appeared to be worse than before SOAS.
So we tried adjusting the TX power on the AP24 at the base trailer. It is pointing basically straight at the AABC buildings.
The previous setting was
interface wireless print 0 ... frequency-mode=manual-txpower antenna-gain=0 tx-power=15 tx-power-mode=card-rates
From the AP24 Router OS manual, available at http://wiki.eol.ucar.edu/sew/ISFS/WIFI
- frequency-mode (regulatory-domain | manual-tx-power | superchannel; default: superchannel) -
defines which frequency channels to allow- regulatory-domain - channels in configured country only are allowed, and transmit power is
limited to what is allowed in that channel in configured country minus configured antenna-gain.
Also note that in this mode card will never be configured to higher power than allowed by the
respective regulatory domain - manual-tx-power - channels in configured country only are allowed, but transmit power is
taken from tx-power setting - superchannel - only possible with superchannel license. In this mode all hardware supported
channels are allowed
- regulatory-domain - channels in configured country only are allowed, and transmit power is
- tx-power (integer: -30..30; default: 17) - manually sets the transmit power of the card (in dBm), if
tx-power-mode is set to manual or all-rates-fixed (see tx-power-mode description below)
• default - default value of the card
- tx-power-mode (all-rates-fixed | card-rates | default | manual-table; default: default) - choose the
transmit power mode for the card:- all-rates-fixed - use one transmit power value for all rates, as configured in tx-power
- card-rates - use card default rates
- default - use the default tx-power
- manual-table - use the transmit powers as defined in /interface wireless manual-tx-power-table
From the above settings I don't know what transmit power would be used, 15 dBm, or the default for the card.
Anyway, on Jun 11 I changed the tx-power to 13 and Paul saw an improvement.
Later I changed it to:
frequency-mode=regulatory-domain tx-power-mode=default
According to Scarlet and Paul in the AABC office things are working fine. We'll leave it at that until we hear otherwise.
SOAS ISFS Status, June 13, 2013
Summary: Due to troubleshooting the 20m licor yesterday, I was unplugging serial couplers to find the licor. Doing this I unplugged all sensors at 20m. Few sensors did not return in normal status.
Sonics: ok
TRH, P: ok
Wind speed & direction: ok
Soil, Rainr: Tsoil.4.4cm bad
Vmote.(rad,a,b): Radiation, Wetness: Radiation wetness not responding
h2o, co2: ok
System (GPS, Vdsm): ok
The 20 meter barometer was generating data
*D1 1008.13652\0xa5hPa \r\n *DG2097\r\n *D1 1008.13636\0xa5hPa \r\n *DG2097\r\n
Apparently it reverted back to some default mode after being power cycled yesterday when we were checking cables at 20 meters.
rserial'd to it and entered the initialization string "*0100P4 ctrl-m ctrl-j" and it is back to normal. The above data may be salvageable with some clever xml.
*D1 1008.13635\0xa5hPa \r\n *DG2097\r\n *D1 1008.13650\0xa5hPa \r\n *DG2097\r\n *0100P4*D1 1008.13649\0xa5hPa \r\n ^M^J\0x95\0xb8100\0xd04\r\n *00011008.13592\r\n *00011008.13605\r\n *00011008.13589\r\n
Replaced 4G modem with another 3G. So two-3G modems are running at top of tower. 4G would not stay connected with 3G signal. [crying]
Gordon, June 13
On June 11th we took the 4G back to Tuscaloosa and tested it with VZ Access manager on Chris' macbook. I worked well, making an LTE (4G) connection and staying up. As I remember download/upload speeds (measured at dslreports.com) were around 2.5 Mbit/sec.
On Jun 12 we took the 4G back to the tower. It would only connect for a couple of minutes at 3G speeds (EVDO-a1) and then drop out. This was with and without the 3G modem connected. Also, I never have seen the 4G modem make a LTE connection. So it appears only 3G service is available in this area. With the external antenna at the top of the tower we have good signal, with an RSSI of about -63 dBm.
I tried settings on the cradlepoint to limit the 4G to 3G speeds only, and to 3G or lower, but it still did not stay connected.
Replaced the 4G modem with a 3G and things are working well. Both 3Gs are connected at 3G speeds (EVDO), and have stayed connected for 23 hours. load-balancing=spillover is enabled.
Attached are the info pages shown from Status -> Internet Connections, after pointing a browser at 192.168.0.5. The 3G that has been on the tower since the beginning has phone number 303 241 0359, unique identifier d163a26c. The new 3G modem is phone number 303 241 0137, unique id 76f22d5e.
Found the problem with the 20m licor was the serial cable from electronics to dsm. Bulgin connector at dsm was full of water. Ran a new serial line from Licor to dsm. All is good!