CC1101: CC1101 WOR not working

Nicola_75

Part Number: CC1101

Good morning,
I am a freelancer and for my client I am developing an anti intrusion system.
In particular I am writing the firmware for the radio based on the CC1101 which will operate on battery power and for this reason I kindly ask for help for the management of WAKE ON RADIO.
I have already followed many discussions on the forum for this topic, but something still eludes me ...
I also found this "e2e.ti.com/.../181405 which was answered by a TI FAE named Siri who clarified many doubts about it, but even if I understand his reasoning and the settings of the registers, I NEVER receive when I am in WOR.
The CC1101 has a 26 Mhz crystal and works at 868 Mhz
When everything works, the goal is to send a packet with a 10 byte payload, but I'm currently trying to make the example taken from Siri's answer to the link above work, to send a packet like this:
Baud 1200
Preamble 24 bytes
4 byte synchronization
Payload of 4 bytes (1 byte long, 1 byte dest addr, 2 bytes of data)
2 bytes CRC

Below you can see the code I'm using ...
I ask kindness to help me because I don't know what to do anymore ...
Thanks you so much !!

CONFIGURATION:

   0x07,  // IOCFG2        GDO2 Output Pin Configuration
   0x2E,  // IOCFG1        GDO1 Output Pin Configuration
   0x24,  // IOCFG0        GDO0 Output Pin Configuration
   0x07,  // FIFOTHR       RX FIFO and TX FIFO Thresholds
   0x57,  // SYNC1         Sync Word, High Byte
   0x43,  // SYNC0         Sync Word, Low Byte
   0x3E,  // PKTLEN        Packet Length
   0x46,  //6E PKTCTRL1      Packet Automation Control
   0x45,  // PKTCTRL0      Packet Automation Control
   0xFF,  // ADDR          Device Address
   0x01,  // CHANNR        Channel Number
   0x08,  // FSCTRL1       Frequency Synthesizer Control
   0x00,  // FSCTRL0       Frequency Synthesizer Control
   0x21,  // FREQ2         Frequency Control Word, High Byte
   0x62,  // FREQ1         Frequency Control Word, Middle Byte
   0x76,  // FREQ0         Frequency Control Word, Low Byte
   0xF5,  // MDMCFG4       1200 BAUD Modem Configuration
   0x83,  // MDMCFG3       1200 BAUD Modem Configuration
   0x17,  // MDMCFG2       Modem Configuration
   0x72,  // MDMCFG1       Modem Configuration
   0xF8,  // MDMCFG0       Modem Configuration
   0x15,  // DEVIATN       Modem Deviation Setting
   0x07,  // MCSM2         Main Radio Control State Machine Configuration
   0x0C,  // MCSM1         Main Radio Control State Machine Configuration
   0x18,  // MCSM0         Main Radio Control State Machine Configuration
   0x16,  // FOCCFG        Frequency Offset Compensation Configuration
   0x6C,  // BSCFG         Bit Synchronization Configuration
   0x03,  // AGCCTRL2      AGC Control
   0x40,  // AGCCTRL1      AGC Control
   0x91,  // AGCCTRL0      AGC Control
   0x02,  // WOREVT1       High Byte Event0 Timeout
   0x26,  // WOREVT0       Low Byte Event0 Timeout
   0x78,  // WORCTRL       Wake On Radio Control
   0x56,  // FREND1        Front End RX Configuration
   0x17,  // FREND0        Front End TX Configuration
   0xA9,  // FSCAL3        Frequency Synthesizer Calibration
   0x0A,  // FSCAL2        Frequency Synthesizer Calibration
   0x00,  // FSCAL1        Frequency Synthesizer Calibration
   0x11,  // FSCAL0        Frequency Synthesizer Calibration
   0x41,  // RCCTRL1       RC Oscillator Configuration
   0x00,  // RCCTRL0       RC Oscillator Configuration
   0x59,  // FSTEST        Frequency Synthesizer Calibration Control,
   0x7F,  // PTEST         Production Test
   0x3F,  // AGCTEST       AGC Test
   0x81,  // TEST2         Various Test Settings
   0x3F,  // TEST1         Various Test Settings
   0x0B   // TEST0         Various Test Settings


void C_Transceiver_CC1101::EnableWorState(void)
{

	SetIdle();

	WriteRegister(MCSM0, 0x18);  
	WriteRegister(MCSM2, 0x18);   
	WriteRegister(WOREVT1, 0x11);  
	WriteRegister(WOREVT0, 0x9A);
	WriteRegister(WORCTRL, 0x78); 
	DelayuS(200);
	WriteStrobe(SFRX);            
	WriteStrobe(SWORRST);    

	WriteStrobe(SWOR);      
}

over 5 years ago

0 Siri over 5 years ago

TI__Guru* 86191 points

There are several things I recommend that you do to debug this.

First of all, you should test that everything work as expected when not using WOR. Use ordinary RX to receive your packets to make sure that your radio is set up correctly from an RF perspective. For the transmitter you should use the long preamble as you want to do when using WOR mode.

When you have verified that your HW is OK and that your RF settings are OK, you can start with the WOR implementation. It is alwasy a good idea to output different debug signals on the GDO pins to see if everything runs as expected. good signals to monitor is WOR_EVENT0/1 to see that the timing is correct for the events, PA_LNA signal to see how long the radio is in RX.

You are obviously not showing me your complete application, so I do not know what interrups you are suing and how/when you are putting the radio back in WOR mode after you have received something.

What do you for example do if you receive a packet in the FIF with CRC not OK? You are not using the autoflush feature, and you have GDO2 set to 0x07, so if you have an interrupt on this pin, the application will never know of something faulty has been received, and you are must likely not putting the device back in WOR mode for this cases?

Siri

0 Nicola_75 over 5 years ago in reply to Siri

Prodigy 40 points

Hi Siri, thank you very much for your reply.
I try to explain the matter better.

First of all, you are absolutely right about autoflush, before doing the tests for WOR I had 0x6E ... but then I forgot to change it.
Before trying to run the WOR, the configuration I had, allowed me to receive a 10 byte packet of payload without problems, even over long distances ... Then I started the tests and now RX does not work well (with wor disabled ).
With WOR disabled, I send a packet consisting of a 24 byte preamble + 4 sync + 4 (payload) +2 crc with the Tx radio ...
To receive it, the MCU waits for the interruption on the GDO2 pin set to 0x07, but I often lose the packet if the radio is not close to 30 cm ... (I have the PA at most 0xC0)
But even when I lose the packet, I see with the oscilloscope that the gdo0 pin set to 0x08 moves, so I receive the preamble correctly.
Now my problem is to go back to RX mode with wor disabled, fully functional without losing packages.

WOR QUESTION:
Thinking that normal RX functionality was fine, and I tried to do WOR. I realized that my transmission had to be long enough to last 2 awakenings, so if the first RX has expired, be able to receive again when the radio switches back to Rx
The values I set for the WOR are turning correctly on the CC1101, I see it through the oscilloscope on GDO_0 (IOCFG0 = 0x24) I noticed carefully that the Event0 radio wakes up approximately every 129.98 mS (and should remain awake for 16 , 25 mS).
Considering that the preamble of my packet lasts ((24) * 8) / 1200 = 160mS, so there are about 30mS to receive 4 bytes of preamble ... But instead I NEVER receive anything. I also tried looking at the gdo0 pin set with 0x08, but it doesn't move, so it doesn't even seem to receive the preamble.

Do you have any advice for me?
Thanks so much.
Nicola

0 Siri over 5 years ago in reply to Nicola_75

TI__Guru* 86191 points

Hi Nicola

Step one is to get back to a fully functional link without using WOR. Not sure how you best can do this (maybe start from scratch?). You should at least use SmartRF Studio to generate the settings for you so that you know that you are using characterized settings.

If you have made your own HW you should also test performance and check the RSSI before starting to implement WOR. If your RSSI is off due to bad Rf performance of the HW you will get into trouble as the WOR mode look for RSSI.

When the RF Link is OK you can start with WOR. It is then important that you monitor both TX and RX at the same time (use for example PA_PD on the TX) to verify that you are in RX mode while transmitting. If the RF link is OK, issues with WOR is most of the time related to wrong timing.

Siri

0 Nicola_75 over 5 years ago in reply to Siri

Prodigy 40 points

Thanks for the advice Siri,
I try to start again and update the discussion in a few days.

Nicola

0 Nicola_75 over 5 years ago in reply to Nicola_75

Prodigy 40 points

Hi Siri,
I completely redone the configuration from scratch, via smartRf Studio, and now the transmission and reception work perfectly.
I'm using the 250Kb baud rate with 13 payload bytes + 24 Preamble +4 Sync + 2 crc.
Now I ask you for help on the theory of the functioning of the Wor, because I have already done various tests and I think I have not yet understood how it works ...
During the tests I observed with an oscilloscope the GDO0 / 2 pin set as 0x25 and 0x08 to monitor the Tevent1 signal on Rx
and simultaneously on the Tx side the pin gdo0 set as 0x1b (PA_PD) to understand if the transmission is in the rx window, before it expires. I have seen that even when the transmission is exactly in the timeout window (set to 1 mS), I have never seen gdo2 set to 0x08 (preamble) generate a signal.
Is this the correct way to proceed or should I look at something else?
The time to send the TX message is: (24 + 13 + 4 + 2) = ((43x8) / 250000) = 0.001376 ~ 1.4mS
If I understand correctly, you must make sure that when the TX transmits, the Rx radio must receive at least 4 bytes of preamble ... and therefore it does not expire but continues to receive the rest of the packet (synchronization etc.) Right?
RX_TIME_QUAL should I set it to 1 or 0?
The rx timeout must be long enough to guarantee ONLY 4 reception bytes (if set the PQT threshold on 4) Right?
What should be the wake-up time and rx timeout sufficient to guarantee the reception of my message with low current consumption?
At 250Kb the 24 bytes of preamble requires for transmission 768 uS, so if I want on a much longer awakening time, I have to manually generate the breamble, using STX with zero buffer ... right?
But, in this case the "automatic" transmission preamble must be setted at minimum (2 bytes)?
1)Please, can you clarify how to interpret the 3 bits of the PQT of the PKTCTRL1 register? Accept values from 0 to 7 ??
2)To understand when the radio activates the Rx, do I have to consider the moment when T1 occurs and add the calibration time, so that it remains in Rx for the set timeout time... Right ?
Thanks so much,
Nicola

0 Siri over 5 years ago in reply to Nicola_75

TI__Guru* 86191 points

Hi Nicola

It do not think you will manage to do WOR mode at a data rate of 250 kbps and a 24 bytes long preamble. You need to receive 4 bytes of preamble to detect sync, meaning that you would have to wake up and enter RX at a rate less than 20*8/250000 = 640 us.

I tested this, and were monitoring EVENT0 and CHIP_RDYn it seems like the radio will not be able to go in and out of SLEEP at that rate. I strongly recommend that you program tEvent0 to be larger than 11.08 ms (see the data sheet). That means that you need to transmit a minimum of tEvent0 + 4 bytes preamble to be able to always wake up in the preamble. To achieve this you need to strobe STX with an empty FIFO. Once you start filling up the FIFO, the radio will start to transmit sync (you can program NUM_PREAMBLE to 0).

Regarding PQT.

Assume PKTCTRL1.PQT[2:0] = 5

The PQT threshold is then set to 4*5 = 20

An internal counter is being increased by one each time a bit is received that is different from the previous bit (preamble 01010101) and decreased by 8 each time a bit is received that is the same as the last bit.

That means that when 20 or more preamble bits are received, PKTSTATUS.PQT_REACHED will be asserted. If you have RX_TIME_QUAL = 1, the radio wills stay in RX as long as PQT_REACHED is asserted (even if the RX timeout has expired). Once you start receiving bits from the sync word, the internal counter will start to decrement, and if it goes below threshold, the PQT_REACHED will stay high for one more sync length before it is de-asserted and RX terminated. This “buffer” of 1 sync length it to make sure that the radio does not exit RX mode in the middle of the sync word.

Event1 is then time when the SRX strobe is issued internally, so you need to add calibration time, if calibration is enabled, or just the transition time (75 us), if not.

Unfortunately I do not have the BW to make a demo for you at this time, but I hope my hints has given you something to work on.

Siri

Sub-1 GHz

Sub-1 GHz forum

CC1101: CC1101 WOR not working