I'm using the WOR functionality on a CC1101 transceiver.
To make sure that a packet is available when the receiver is in RX mode I need another CC1101 to transmit the same packet repeatedly for a little less than 1 second (about 50 times)
Is there any way I can do it without pauses between one packet and the other?
They way one usually handles this kind of issues is to make sure that the preamble is long enough for the RX to "find/hear". If you flush the TX FIFO (so that it's empty) and then enter TX mode, the CC1101 will continuously send preamble, then load the data into the FIFO when you want to send your payload.
Thanks Jonas for your answer,
so your suggestion is to send a loooong preamble lasting the time needed to have the RX surely "connected" (in my case about 700 ms) then add the payload? Sounds great!
Just one maybe stupid doubt: does the receiver in WOR mode stay in RX for the entire preamble (in case it "connects" as soon as I start sending it) or it goes to sleep at the end of the RX Timeout?
Yes, that is my suggestion.
The RX_TIME bits set the timeout for sync word search in RX for both WOR mode and ordinary RX operation. When using WOR mode, RX_TIME can have a value between 0 and 6 when WORCTRL.WOR_RES = 0, and between 0 and 3 when WORCTRL.WOR_RES = 1. RX_TIME = 7 means that the radio will stay in RX mode until a packet is received, regardless of the WORCTRL.WOR_RES setting. The timeout is relative to tEvent0. The longest RX timeout possible when using WOR is 1.18 s. This is achieved by settings WORCTRL.WOR_RES[1:0] = 1 and MSCM2.RX_TIME[2:0] = 0.
You'll find all information you need in this Application Note.
Hi Jonas thanks again,
one last question..
I know that AN, and the DN111 but I thought that there wont be any RX Timeout in case of recognised packet (preamble)
I mean: setting WOR_RES=0 and RX_TIME between 0 and 6 the receiver would stay in RX for a certain time UNLESS during that time it gets a preamble, in this case it would stay in RX untill the end of the packet whenever it occurs...is that wrong?
Or do I need to set RX_TIME=7 to obtain something like that? (timeout relative to tEvent0)?
If RX_TIME is between 0 and 6 you will timeout unless you find a SYNC WORD (not preamble, to be exact). If you find a SYNC WORD you will receive that packet.
Preamble is used for bit sync while sync word is used for byte sync of the data.
I'd like to clarify two things that I found out in the last two days for any interested reader...
1- it is possible to send packets back to back setting the TXOFF_MODE in Stay in TX (Start sending preamble);
send the first packet, then:
- wait for the GDOx to de-assert (in case you use it in mode 0x06)
- load the packet in the TX FIFO and so on...
2- it is possible to avoid the RX timeout (in WOR mode or not) with just a preamble (before the sync word) setting the parameter PQT in PKTCTRL1 and RX_TIME_QUAL in MCSM2. This way when the receiver gets 4*PQT bits of preamble, remains in RX till the end of the packet.
This last consideration, together with Jona's suggestion (set the CC1101 in TX with no data in the FIFO: it will send an unlimited preamble) made my WOR work great with a minimum (0,781%) duty cycle!!
Glad you solved your problem! :)
Miche, sorry to dig up this old thread but I am trying to get your second suggestion to work and wanted to ask if you could clarify a bit. What do you set RX_TIME_QUAL to? It works for me if I set it to 7, but that also disables the WOR duty cycle and it is on permanently. Any other setting of RX_TIME_QUAL does not work because RX times out before the sync word is sent.
Can you state exactly what setting you used please? Thanks.
Never mind, I fixed it. For anyone else who discovers this thread here is my explanation.
On the receiver set PQT to 1 and set RX_TIME to 1. Enable WOR.
On the transmitter set up a fixed 1 byte packet and send the extended preamble, followed by putting a single byte in the FIFO to generate the sync word.
Like Miche I can get down to a 0.781% duty cycle but no lower, using a 1 second polling cycle, or a 7.81ms on time. This is quite disappointing because with other radios like the RFM12B I can get down to 2ms. With the CC1101 some of that time is spent in idle while the RC oscillator calibrates, but even so it is a bit high. I am going to experiment with higher data rates to see if that helps (I am using 1.2k baud).
I'm glad you fixed it , I'll share my settings anyway.
RX_TIME_QUAL = 1
RX_TIME = 4 (100) with WOR = 0 makes a 0.781% duty cycle
PQT = 2 (010) then it needs to recognize 8 bit of preamble
Thanks for your reply. I increased the data rate to 4.8kbps and was able to reduce the duty cycle to 0.391% reliably. At 0.195% wake-up is only triggered about 75% of the time. This is all with PQT=1.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.