10/16/13 ~18:30Z
Flr,Near,Far; Changed all xbee status message rates from 1/2hourly (sx=360 at 5sec datarate) to 0 to disable them.
The reason is because the flux computer 'wisardMessageDecoder' of raw-files looking for mote COMMENTS was not showing any of these type messages coming in which is abnormal. The procedure does work because I tried it via operator command (xs) to get mote responses at flr:
ID1:\0x01\0x02Xbee: CH=15 ID=6 DL=40625DF1 SP=3E8 ST=7D0 SM=0 SO=0 NP=49 PL=4 U\0x03\0x04\r
ID2:\0x01\0x02Xbee: CH=15 ID=6 DL=40625DF1 SP=3E8 ST=7D0 SM=0 SO=0 NP=49 PL=3 Q\0x03\0x04\r
ID17:\0x01\0x02Xbee: CH=15 ID=6 DL=40625DF1 SP=3E8 ST=7D0 SM=0 SO=0 NP=49 PL=4 m\0x03\0x04\r
However, we have been having outages especially at flr and it is conceivable the mote's attempt to grab status values from the xbee was causing problems. The motes perform this task by switching the xbee radios into 'command-mode' and then issue specific commands to the xbee for grabbing these parameters. Timing is important, so if the radios were to remain in command mode even though the mote issued the 'go back to data mode' then they would be unable to send any data messages sent. Testing in Boulder in the past showed that the method was working, but perhaps in a noisy rf environment the interaction becomes more dicey. Timing also relies upon the 'guard-time' needed for the xbee i/o, the mote rtcc interrupts, etc. Maybe this will help eliminate radio outages.