Tapatalk

example code for nodes listening for control msgs from base?

example code for nodes listening for control msgs from base?

2

PostJul 25, 2017#1

Hi,
Is there any easy code samples around for whisper avr boards organised as a base + control nodes rather than sensor nodes? I mean low power nodes capable of sleeping most of the time but still able to receive control instructions from the base when sent.

The nodes would then wake on receipt of the message and perform the control task, then go back to sleep. Presumably this involves either periodic waking for RX listen for a sufficient proportion of the time to catch a transmitted message, or ideally interrupt wake up on message reception? I'm not too sure of the capabilities and function of the boards and libraries yet - I'm waiting for some boards to arrive so I can test ideas like this.

thanks.

1885
1885

PostJul 25, 2017#2

Hi robonut,

Just Listening
Sending remote commands to a "sleeping" node is a bit more complicated. That's because to receive messages the radio would need to stay in "listening mode", which consumes some significant energy to be considered an ultra-low power: around 15-20mA.

If the power consumption figures above are OK for your project, you can simple put the MCU into deep sleep and once the radio module receives a valid message, an interrupt will be generated. This interrupt can be used to wake-up the MCU and you can receive the message continue from there.

Polling
Now, if you plan to go down to a micro-amp sleeping average, one method is to use polling mechanism. You basically need to have a "base station" always awake, which will implement some kind of "command queue" or "mailbox".

The sleeping nodes would periodically "ping" the "base station" and ask if there's a command in the queue, stay a few milliseconds in listening mode, waiting for a reply, and go back to sleep.

The polling method above can be adjusted between low-power consumption and how often (or how quickly) the remote nodes will "poll" the base station. Making sure the ping messages are very short will reduce the "ping-pong" time.

Periodic Listening
Another approach is to make the Base station keep broadcasting a "message for you" (at random interval, but very often), while your remote node is configured to wake-up and listen for messages from time-to-time.

Additionally to that, the RFM69 radio has a "low-power listening mode", but I personally haven't had much success with it, and prefer to implement this behavior as part of my program.

Synchronous
One more option, is to use a synchronization method, having a RTC or GPS to coordinate time-slots where the remote node will wake-up. This technique can also be used to slice the channel in multiple time-divisions and have nodes talking without clashing with each other.

Note that in this method, the time-sync is essential and even RTC chips will have time drift from time-to-time, which will need to be trimmed after while.

Cheers,

2

PostJul 25, 2017#3

Thanks for the great reply.

It sounds like the pooling approach is the most accessible / least effort. I would know this as polling, I hadn't heard the Pooling term before ;)

It would come down to how often the sleeping nodes could call home to check for pending messages for a given level of control responsiveness / latency and still maintain a long battery life consumption average. Probably half a second intervals would be ok for me, and still give the appearance of real time.

Another more complicated synchronous method without requiring an accurate synchronised clock could be to have each node allocated a time division based on ID hash or some such algorithm, listen for any message from any node or base to get in sync, use the ID of that message to calculate the amount of milliseconds to sleep until it's allocated timeslot comes up during which it would listen. Drift could be corrected by either correctly receiving a message from the base (considered to be the master time keeper) in the timeslot, then sleeping the right duration afterwards, or if no messages have been received for X number of timeslots, just staying in listen mode until any message is received to get back on track. Whether all this complication would give better or worse results for a small network is another matter though.

thanks again.

1885
1885

PostJul 25, 2017#4

Sorry, corrected my typos: polling is the right term :D

For the time-division, you might be interested in the "https://en.wikipedia.org/wiki/Self-orga ... ple_access", which is used by AIS in the marine industry. Basically all transceivers use the GPS clock to self-organize the time-division, and prevent collisions (of boats and packets)