This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Wake on radio methods

Other Parts Discussed in Thread: CC1200, CC1120

Hi!


In our application we have several sleeping, battery supplied CC1200 based nodes in WOR state with Event0= ~3-4 secs. Power saving here is paramount since the nodes are outdoors. There is a gateway module which is connected to mains (no powersaving issues) and it has to wake up all the nodes. What would be the best way to achieve this?

We tried to send out 100+ short packet bursts and it gave decent results. Since the RX session is waiting for preambles + valid sync word what if we send a long (100+ bytes) packet  filled with sync words in the payload field?

  • Hi

    Please look at the CC112x/CC1200 Sniff Mode application report,

    http://www.ti.com/lit/pdf/swra428

    and Smart Preamble app note:

    http://www.ti.com/lit/pdf/swra438

     

  • Hi Martin B,

    thank you for the information. I've already studied these documents but I'm not sure RX sniff is preferred over eWOR when we would like to use 3-4 second long tEvent0 periods.

  • It depends a bit on your system.

    If you want to sleep for 3 s periods you have to ensure in some way that the node is awake when you send a packet from the gateway.

    This can be done in different ways dependent on the degree of sync between Rx and Tx.

    - Having a packet with a preamble longer than 3 s ensuring that when the node is waking up it starts receiving preamble. The SmartPreamble may be used to ensure the longest possible sleeptime in this setting.

    - If both Rx and Tx uses a real time clock the Tx side could know within a given accuracy when the Rx side will wake up. In this setting the Rx node code sleep for a bit less than 3 s (given by the in accuracies of the clocks) and then starting to use sniff mode to ensure that the packet Tx sends will be received. Here a much shorter preamble could be used saving current on the Tx side.

    - Note that if you send a lot of short packets you have to be in Rx until you receive a valid packet. If you go to Rx just after the sync word the Rx has to be on for some time before a valid sync is received which is not optimal to save power. Normally you want the Rx side to go down in SLEEP if no energy is on the air.

  • Hi TER,

    thank you for your help. We haven't got RTCs on the boards (which are actually already designed and manufactured) so syncing the RX/TX modules based on a RTC is not an option.


    There are a couple of things which are not clear so I'd like to ask more questions. If I'm correct the WOR functionality works like the RX chip wakes up at every event0, changes to RX and waits for preambles and a valid sync word. If it fails to receive that, after the RX timeout period it goes back sleep. So it is important that in the period between start RX - RX timeout the TX has to be able to send at least 4 preamble bits plus a valid sync word to keep the RX side's 'attention' up for finishing the RX and waking up.
    My initial question was that if we are providing a particular pattern in the payload (e.g. 0xAA, 0xAA, 0xAA, syncH, syncL, 0xAA, 0xAA, 0xAA, syncH, syncL, syncL) then in one packet there are multiple sync words and maybe it is easier to catch the attention of the RX side. Is that good idea?

  • Your fundamental thought is good but you loose the ability to use the packet engine since you will start receiving the packet when it finds the first sync word and then you have to post process the rest of the packet to remove the rest of the sync words.

    The Smart Preamble example Martin linked to is based on the same principle but with more freedom. CC1120/ CC1200 are able to search for two sync words at the same time. One sync word is used in the preamble and the other one is used just in front of the payload. In addition information about how long the preamble is is embedded in the preamble pattern lowering the power consumption.  

  • Thank you TER, I'll take a closer look at that example.