low power receiver with TRW24

Wireless & IoT
1

I’m asking for advice in creating a wireless “unit” which basically can respond to commands sent to its address, and once in a while send out some unsolicited data.

Which is the best method to achieve this? Of course I put the MCU in sleep, ready to be waked by an interrupt (say DR1 signal).

But when the transceiver is in Stand-by mode, it won’t receive, and when it is in Receive mode, it will consume some 19mA. Is there a way to achieve a “real low power” mode, and yet being able to respond to incoming packets?

(Of course, as for the sending of data, there’s no problem: a timer wakes up the Micro once in a while, and data are sent).

Thanks

2

Ah, the devil in the details. If you need instantaneous response to a command, you’re stuck leaving the reciever on.

If you can wait you can use what you call your “unsolicited” response to do this. This is how Zigbee transcievers get to their rated low power mode. They have a listed 1% duty cycle for to achieve their low power operation in a correctly configured network. They wake up once a second and check in. If they have data to send, they do, and they also get information if need be. Then they shut down and wait for the next period.

3

Thank you for your answer: yes, I supposed it was some kind of tricky! (never believe to promises made by people in electronics :smiley: )

I did see something around Zigbee, concerning that issue, but I did not dig into that: thanks for the info, I’ll try to implement smth like that.

But, if I’m not wrong, when I tried to use Chipcon 2420 (and then let it down, at least temporarily, because of high prices and no real use at the time), I noticed in their datasheet that they could “allow for some data to come in, even when the receiver was somewhat powered down, store them, and provide to the MPU when asked for (i.e. completely active)”

I’ll take a look again at that note.

4

ZigBee (IEEE 802.15.4) has a sleeping receiver standard. Receivers can power down to low power, then wakeup and ask their neighbor router if there’s any traffic queued up and waiting. The first version of ZigBee has this only for “end points”, nodes in the network that cannot route (forward traffic).

The newest version (just starting to come out now) has “sleeping routers”, with a network time-sych strategy for waking up to check for own and forwarding traffic.

There are provisions in the products I’ve used to omit the use of ZigBee all together and you program your own sleep and wake-up strategy. This can be done via the serial port commands in modules like XBee/XBeePro and many others. Not recommended, but you can purchase the developer’s kit and compilers and do this kind of logic inside the chip itself, instead of via the serial port protocol of a low cost module ($20@1ea).

5

Thank you Stevech: your answer clarified me somewhat more on how a strategy can be implemented, having the “server” (my USB transceiver driven by C software, not Zigbee) queueing the messages for each node.

BUT… if I wanted a node to switch on a light when a switch is pressed on another node… or anyway a Light-On command is sent to it… how long am I supposed to wait until the node wakes up and flushes the commands from the “server” ? 1 sec. as stated? Or maybe more… but then it won’t be a good “responsesiveness”…

6

the sleep time is programmable, for end-nodes (in the original ZigBee). The new version of ZigBee changes this concept.

In the old version (2004), the scheme was driven by home automation use cases. Here, the battery powered nodes are the hand-held push-button controllers. They wakeup when you push a button, as a rule. They then talk to the nearest ZigBee node that’s installed and runs on AC line power - like a light switch or AC outlet. Thus, the battery powered controller sleeps until you push a button. It can also sleep and wake up every n seconds to see if the network is trying to talk to it - to get status, to assure it has a neighbor-router to talk to, or if it needs to change which router it will use.

Point being: the zigBee nodes controlling lights/appliances get their power from the AC mains.

Now the new standard allows for routers to be battery powered. So they can be nomadic, such as a communications device attached to things that move, like shipping containers and trailers. Or nomadic in the sense that the platform on which the ZigBee radio is located changes so it’s impractical to hard-wire it.

Many ZigBee networks will have all nodes being routers, no end-point devices than cannot route. This makes the mesh more robust.

The PC / Host interface for a ZigBee module (not a chip) like the Maxstream XBee/XBeePro, or the Silicon Labs or Hellicom, or the many other modules, is either RS232 or USB.

Every ZigBee network has a “Coordinator” node. This node is often a module (in a box) with a USB link to a PC and from there, onward to wide area networks via some application software messaging.

The ZigBee coordinator is responsible for network addresses (kind of like a DHCP server, but IP isn’t used in ZigBee networks). It also help create and sustain the self-forming, self-healing mesh (uses AODV which is an Internet RFC standard).

So all this meshing is transparent to the application program. When you move a ZigBee node, it will find a new neighbor and form a route to reach whatever other node it is trying to communicate with. The Network addresses in ZigBee, like IP addresses, don’t define what MAC layer addresses are used to route packets. Every ZigBee node has a neighbor table and a route table; these are discovered and updated as the mesh changes.

It’s all pretty amazing, given the whole module is $20 with ZigBee meshing and the radio (or $35 for the higher transmit power version), at least in the case of XBee.

Z-Wave is a similar network, for home automation, and is in production whereas ZigBee home automation stuff is not expected until late '06. However, Z-Wave does not have a IEEE standard MAC and PHY as does ZigBee. Z-Wave is proprietary to one company and licensed to affiliates.

ZigBee is also an aliance but the MAC/PHY is IEEE 802.15.4 meaning there are many manufacturers of compatible chips. That is, ZigBee standards and compliance proof is to IEEE 802.15.4 what WiFi is to IEEE 802.11a/b/g.

The ZigBee protocols are firmware that you download into the chip (on the OEM module). You can talk to the module using RS232 or serial.

It makes no sense to start with ZigBee chips given the price of modules.

7

Thanks for the detailed explanation.

I do know the details of Zigbee network, the coordinator rule, the addresses assignment and so on…

You’re right, it would not be needed to start from the scratch, but it is for 2 reasons: we developed our own RS485 home network several years ago and wanted to extend it in wireless, since before Zigbee (tried Aurel and such).

And then we wanted to experiment by ourselves the best ways to make low-consumption nodes.

That’s why I came concerned about a good way to make them work.

And indeed you’re right when it comes to Light dimmers which will work from the Mains, necessarily: I was thinking of some LED-lights battery-powered (emergency i.e.)

8

RS485 home network - great, if you get this in before the drywall goes up!

9

stevech:
ZigBee (IEEE 802.15.4) has a sleeping receiver standard. Receivers can power down to low power, then wakeup and ask their neighbor router if there’s any traffic queued up and waiting. The first version of ZigBee has this only for “end points”, nodes in the network that cannot route (forward traffic).

Hi Steve, I had my pseudo-zigbee node working, using smth similar to the above strategy.

I was wondering if it would make sense, to “refine” this strategy, to have the wakeup-time “prolonged” if a message is received.

I mean: now the thing is set to wake-up every 1second, for some 50mSec (a little more than 1% in mind). It sends out a “I’m here” message and the PC (acting as coordinator) sends the messages in queue. Would it make sense to “lengthen” that 50mSec time if a message is received by the node, intended for it (i.e. correct address) ? Say in 25msec Units, so that more messages could be sent by the coordinator if needed, in the same time-slice ?

Thanks for your suggestions.

10

What IEEE 802.15.4 and ZigBee do, for sleeping end-nodes, is to wakeup (less often than 1 second- depends on your latency goal/human factors), then poll the parent node for that module. The parent is rarely the coordinator. The end-node stays awake until all queued frames are received and ACKd. If you’re making your own protocol - you might want to have the application layer decide when to go back to sleep and tell the network (NWK) layer, since the application layer understands the context and state and the NWK does not.

ZigBee sleeping routers (new in the latest) do the same thing, but each talks to its parent, not the coordinator, and it goes back to sleep if the output queue fills, and wakes up now and to try to empty the output (relayed traffic) queue. That’s a queue of frames addressed to a child node of the router.

The $20 OEM modules do all of this stuff.

11

The end-node stays awake until all queued frames are received and ACKd. If you’re making your own protocol - you might want to have the application layer decide when to go back to sleep and tell the network (NWK) layer,

Thank you Steve, I’m glad I reached up for the same conclusion!

Going on…