10Oct13, ~16z
Continuing rad/soil mote outages appear related in at least some cases to the 3hourly xbee resets automatically done by the motes. Because the gps's and the local storage options are now turned off, having radio outages is problematic. In an attempt to improve the situation the timing was changed:
Flr: id1 & id2 & id17: xbee reset = hourly (xr=3600), gps=off (gr=0)
Near: id3=xbee reset hourly, id8 & id10=xbee reset off; gps=off(gr=0)
Far: id4 & id22: xbee reset = 2hours (xr=7200), gps=off (gr=0)
With this mix, hopefully the outages will be less and we can see if the reset timing is still the critical factor instead of hardware issues.
We may want to consider having the dsm's send 'hb' heart-beat commands to the motes and re-enable xbee reset values (which only reset if there is no heart-beat received).
14Oct13, ~1Z GMT
Noticing that Tom reported in the mote status that flr was having additional problems I logged in and rserial'd to the xbee's.
ID1 and 2 were reporting but not 17 as noted. I tried a 'hb<cr>' command and then a simple <cr> and 17 began reporting.
Further commands issued and normal responses were received.
Changed xbee reset timing: was xr=3600 (1hour), to xr=43200 (12hours). Maybe they should be turned off, however, what i notice is that things work much better after commands are received from the base radio, so we should consider the cron-'hb' i believe.
14Oct13, ~19Z
flr: The flr motes had outages last night and at least 2 rebooted. The setting above hadn't gotten 'eeupdate'd so i reset the xr=43200 and stored the setting. While interacting with them, id2, which had been 'down', again began sending data.
near: Daily status reported outage of the spn. All 3 were reporting when i logged in. I changed id3 to disable the xbee reset, xr=0, to match the other 2 and not be what appears to be problematic hourly resets. Gordon's cron 'hb' heartbeat is running so we might try setting xr=12hrs, but not yet.