Well everything is wired up and works as planned. Sort of. The journey there was not simple. The datasheets on the xbee around sleep modes covers everything one needs to set that up. The problem is that it is not a first pass approach for a newbie. I had to scratch my head a few times.
Specifically the following:
Pin Sleep for periods longer than 5 seconds caused the end device to send information every 30 seconds or so. In the back of my mind, I knew that the coordinator and router handled all the registration process for end devices and that if one of them went MIA then it would be removed from the child table entry. It did not dawn on me that I had to set the SP/SN on the coordinator and router to a value that is longer than the sleepiest end device. I thought those parameters were to be used for just sleep mode configuration. Alas, I was wrong and perusing the data sheet it states for the SN value.
On the parent, this value determines how long the parent will buffer a
message for the sleeping end device. It should be set at least equal to
the longest SP time of any child end device.
My initial thoughts were that I don’t have any messages sent from the host as they are initiated by the end device upon waking so why bother to change the defaults on the coordinator and router? Then I started questioning the datasheet version I was using. Although the datasheet supported the firmware version of the xbee, I did not pay attention to the differences between OEM (doc # 9000976a) vs non-oem (doc #9000976d). The d version has a lot more updates and included a section on child poll timeout. That was the aha moment for me to get things to work.
To quote the datasheet “D” and not in “A”.
The child poll timeout is settable with the SP and SN commands. SP and
SN should be set such that SP * SN matches the longest expected sleep
time of any end devices in the network. The actual timeout is
calculated as (3 * SP * SN), with a minimum of 5 seconds.
Rant
What is the difference between A and D from the front page? A Hardware line not in previous versions and the absence of OEM. Nice change log.
Now as a hobbyist, I have to ramp up on a lot of fronts and time wasting, although annoying, is par for the course. When one googles xbee and sleep modes, etc. there is a lot of chatter. I’m sensing the XBee evolution and corresponding documentation suffers from a quality issue around information management. What is the cost of ignoring quality in productivity losses in companies? A lot.
Perhaps the problem was between the chair and keyboard in this case. If I compare the effort in ramping up on the arduino vs xbee, the arduino is a no brainer. I can focus on algorithms and more cerebrally challenging problems. I can’t say that for the XBee.
I’ll get into the mechanics next.