DigiMesh routing, pin-based sleep, etc.

I am trying to set up an outdoor sensor network where sensor units will periodically (once every 1-5 minutes or so) “phone in” with a sensor reading. It would be desirable to minimize energy consumption in these sensors as much as practical, by having the units send out a message, wait briefly for a reply indicating whether there are any changes to its instructions, and go back to sleep either when the reply is received or a timeout expires. To avoid having the units in the field drain the batteries in the event the main system is shut down, I would like to make the reply timeout as short as practical.

I would expect the most energy-efficient approach would be to have the sensor units use single-hop broadcasts to relay their information to relay nodes; a relay node which heard a sensor’s transmission could reply, after a short (0-30ms or so) coordinated delay, with the new instructions for the sensor, and then later forward the sensor’s information to the base unit. This would, from the standpoint of the sensor unit, avoid any routing delays. My customer, however, doesn’t like the idea of using broadcasts. What can I do to minimize any necessary timeouts when using routed unicast packets? If I use pin-based wakeup, and release DTR while the module is negotiating a route, will the module finish its routing, try to deliver the packet, and then go to sleep, or will it abandon its routing attempt? If relay nodes will be talking regularly to the main controller, and are thus always know a route to it, should the sensor units’ modules be configured that if they don’t get a routing response within a single hop’s time, they will assume none is forthcoming? If the main unit talks to e.g. 100 sensor units in round-robin fashion, can it be expected to usually have the route to them cached, or could it glean the route for the reply packet from the route taken by the incoming packet, or would route-cache thrashing compel a new route discovery for each outgoing packet?

Hmm, if you don’t want Unicast or routing, why not use 802.15.4 or Zigbee. If you need 900Mhz, there are ‘point-to-multipoint’ modules and firmware which do not ‘mesh’ - or look at the XSC XBee.

DigiMesh assumes all nodes wake at the same time & help each other route unicasts (so NO support for pin-sleep). Broadcasts will always create congestion and conflict on the RF band due to the need for all nodes to repeat them. You seem to want to treat a DM900 XBee like a DP900 XBee.

802.15.4, DP900 and XSC do no routing and love broadcast. You have a single fully awake node, and all sensor can just wake and broadcast. As long as their time is kept skewed, they would rarely collide and no one bothers to repeat the broadcasts.

If you assume only in rare cases you’ll need ‘repeaters’, it would not be hard to create a manual ‘repeater’ node & program your host to ignore duplicates when the host hears BOTH the original reading and the repeater.

With Zigbee (but only 2.4Ghz), you have a collection of ‘powered routers’ which act as parents & mesh for the sensors. The sensors wake and literally just ‘hand-off’ their message to a parent, which includes an ACK from the parent. The sensor never gets an ACK from the ‘host’, but assuming the Zigbee is healthy, the parents will move the message as required with high reliability.