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.

CC1101: No signal on GDO in WOR mode

Part Number: CC1101
Other Parts Discussed in Thread: TEST2, , CC1120

Hi,

I have a problem:

in my application the transmitter send 3 packet when the user push the botton on the remote control. The packets are delayed 60ms , the event 0 is every 50ms (I have try also 2,20,40,80...ms).

GDO2 (with setting 0x24) shows the Event0 but GD0(with setting 0x06) doesn't work. Why?

This is my INITIAL setting

    0x06,    //IOCFG2 - GDO2 output pin configuration
    0xAE,    //IOCFG1 - GDO1 output pin configuration
    0x06,    //IOCFG0 - GDO0 output pin configuration
    0x0F,    //FIFOTHR - RXFIFO and TXFIFO thresholds.
    0xD3,    //SYNC1 - SYNC1
    0x91,    //SYNC0 - SYNC0
    0x3D,    //PKTLEN - Packet length.
    0x04,    //PKTCTRL1 - Packet automation control.
    0x05,    //PKTCTRL0 - Packet automation control.
    0x00,    //ADDR - Device address.    
    0x00,    //CHANNR - Channel number.
    0x06,    //FSCTRL1 - Frequency synthesizer control.
    0x00,    //FSCTRL0 - Frequency synthesizer control.
    0x20,    //FREQ2 - Frequency control word, high byte.
    0x28,    //FREQ1 - Frequency control word, middle byte.
    0xC5,    //FREQ0 - Frequency control word, low byte.
    0xCA,    //MDMCFG4 - Modem configuration.
    0x75,    //MDMCFG3 - Modem configuration.
    0x03,    //MDMCFG2 - Modem configuration.
    0x42,    //MDMCFG1 - Modem configuration.
    0xE5,    //MDMCFG0 - Modem configuration.
    0x34,    //DEVIATN - Modem deviation setting (when FSK modulation is enabled)
    0x07,    //MCSM2 - Main Radio Control State Machine configuration
    0x20,    //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.
    0x43,    //AGCCTRL2 - AGC control.
    0x40,    //AGCCTRL1 - AGC control.
    0x91,    //AGCCTRL0 - AGC control.
    0x87,    //WOREVT1
    0x6B,    //WOREVT0
    0xF8,    //WORCTRL
    0x56,    //FREND1- Front end RX configuration.
    0x10,    //FREND0 - Front end RX configuration.
    0xE9,    //FSCAL3 - Frequency synthesizer calibration.
    0x2A,    //FSCAL2 - Frequency synthesizer calibration.
    0x00,    //FSCAL1 - Frequency synthesizer calibration.
    0x1F,    //FSCAL0 - Frequency synthesizer calibration.
    0x41,    //RCCTRL1
    0x00,    //RCCTRL0
    0x59,    //FSTEST - Frequency synthesizer calibration control
    0x7F,    //PTEST
    0x36,    //AGCTEST
    0x88,    //TEST2 - Various test settings.
    0x31,    //TEST1 - Various test settings.
    0x0B,    //TEST0 - Various test settings.
    0x00    //PARTNUM;

Before to WOR mode I change this registers in this way:

    CC1101_SpiWriteReg(CC1101_MCSM2, 0x30);

    CC1101_SpiWriteReg(CC1101_WOREVT1, 0x04); // EVENT0 = 800
    CC1101_SpiWriteReg(CC1101_WOREVT0, 0x20);

    CC1101_SpiWriteReg(CC1101_WORCTRL, 0x00);

    calib1 = CC1101_SpiReadReg(CC1101_RCCTRL1_STATUS);//??ReadReg oStatus
    calib0 = CC1101_SpiReadReg(CC1101_RCCTRL0_STATUS);//??ReadReg oStatus
    CC1101_SpiWriteReg(CC1101_RCCTRL1, calib1);
    CC1101_SpiWriteReg(CC1101_RCCTRL0, calib0);

    CC1101_SpiWriteReg(CC1101_IOCFG2, 0x24);
    CC1101_SpiWriteReg(CC1101_IOCFG0, 0x06);


    CC1101_SpiStrobe(CC1101_SWORRST);
    CC1101_SpiStrobe(CC1101_SWOR);


Anyone can help me?

Thanks

Ivo

  • From your settings it look like you are using a data rate of 37 kbps. That means that it takes (1/37000)*8*8 = 1.73 ms to send 4 bytes preamble and 4 bytes sync. I do not know how long your packet is, but assuming it 8 bytes including length byte and CRC, then you transmit 2*1.73 ms = 3.46 ms every 60 ms.

    You receiver is in RX 2.88 ms every 50 ms, meaning that there are plenty of chance that you will not be in RX while you are transmitting a packet.

    To make sure that you will receive the packets you send you need to transmit a preamble that take more than 50 ms. If you send a shorter preamble you need to wake up more often.
    To conclude, you need to make sure that your receiver enters RX during the preamble of the packet you are trying to receive.
  • Hi Siri,

    Thanks for your help!!

    You are rigth! My transmission is very short, but I can only program the receiver because the remote control is not my application so I must to adapt my receiver to this transmitter.

    How should I set up the Event 0? If I increase the event 0, I receive some commands, if I restrict the event it works worse.

    Thank you!!!!

    Ivo

  • Without knowing the packet format of the transmitter I cannot give you any settings. However, it is my feeling that WOR mode is not a good option for your application. The CC1101 needs at least 2 bytes preamble to be able to detect a sync word.
    That means that if your transmitter transmits for example 4 bytes of preamble, your EVENT0 must be short enough to be sure that you are receiving at least 2 of these bytes.
    That means that tEVENT0 < (1/37000)*8*2 = 432.4 us (Startup time of crystal and time to go from IDLE to RX NOT taken into account).
    If you are not able to set the wakeup interval short enough, what you need to do is to use normal RX mode. Assume that the 3 packets your transmitter sends are all 16 bytes long (3.46 ms) and are transmitted every 60 ms (3 times).
    If you wake up at an interval < 3.46 ms to check CS, you will be able to find out if there is a signal on the air or not. If there are, you can go back to SLEEP again and then wake up and enter RX again in less than 60 ms to be able to detect the second packet sent.
  • Hi Siri,

    This is my packet:

    Preamble: MDMCFG2 = 0x03 (30/32 sync word bits detected)
    Sync word: MDMCFG1 = 0x42 (8 bytes)
    Length field: 1byte
    Addr Field option: 1byte
    Payload = 21bytes
    Crc = 2 bytes

    The consumption must be low, I have a MCU that manage many device (motor, encoder, rs232, buttons...and CC1101). The microcontroller goes to sleep when the application is in stop; each device wakes autonomously  the MCU through interrupts except the CC1101.

    About your instructions: "If you wake up at an interval < 3.46 ms to check CS, you will be able to find out if there is a signal on the air or not. If there are, you can go back to SLEEP again and then wake up and enter RX again in less than 60 ms to be able to detect the second packet sent." The micro of my application, does not have a auto-wake so fast.

    I think that the only solution is require at my costumer to change the transmission of his remote control. So, in your opinion, to not lose compatibility with the old systems:

    1-what would be the best solution? Increase the preamble or increase the number of the packets sent?

    2- MDMCFG2 let me to sent 24 bytes of preamble, it is the size max of the preamble? If i want to send 50ms of preamble how can I do?

    Thanks so much!!!!!!!

    Ivo

  • You can transmit preamble as long as you want to by strobing STX with an empty FIFO. The radio will then start to transmit preamble and it will continue with this until the MCU starts filling up the TX FIFO.
    If you transmit a preamble that is 50 ms, you can in theory wake up at an interval of (50 ms) – startup time – IDLE to RX time – (the time to transmit 2 bytes preamble).
    Assume you set tevent0 to 48 ms.
    You can then try to set MCSM2.RX_TIME_QUAL=1, to make sure you will continue receive if sync word has been found, or if the preamble quality is above threshold (PQT).

    Siri
  • Unfortunately, my client does not allow me to change the remote control package at this time. Do you know another solution to put the radio in a sleep state (or any low power consumption) and wake it up only when there is a signal on the air? I have not found any other solution on the data sheet of the CC1101 but if you know, please can you write me? Otherwise I will have to change the radio electronics!

    I hope to solve the problem. Thanks so much Siri

  • With 8 bytes of preamble I think it should be possible to use WOR, but I do not know how low the current consumption would be. You need to set tEvent0 to less than 6 bytes @ 37 kbps (minus startup time and IDLE-RX time) to make sure that you will always receive at least 2 bytes of preamble.
    Have you tried to see if this is possible?
    You should also consider to take a look at the CC1120. It only require 4 bits of preamble. Please take a look at the www.ti.com/lit/swra428 describing sniff mode on this device.

    BR
  • Hi Siri,

    Thanks for your help!!

    I'm not sure that it is possible to set Event0 each 2 or 3 ms because the Data Sheet and the AN047 indicate TimeSleepMin = 750/Fsc*384 = 11.08ms

    If I set event0 < 11,08ms the radio work?

    BR

  • Hi Siri,

    Thanks for your help!!

    I'm not sure that it is possible to set Event0 each 2 or 3 ms because the Data Sheet and the AN047 indicate TimeSleepMin = 750/Fsc*384 = 11.08ms

    If I set event0 < 11,08ms the radio work?

    BR

  • Yes it will but if tSLEEP < 11.08 ms, there is a chance that the consecutive Event 0 will occur (750·128)
    / fXOSC s too early.

    I think that this would only be a problem in a synchronous system.

    Siri
  • Hi Siri,

    Can I ask you the last question? The only soltion is increase the preamble and I am working to make the change but when the cc1101 is in WOR mode and the radio receive a packet, the GDO1 (configurated 0x0E) wake the system, but when I read the RxFifo, in the register is present the last packet received before the WOR mode. I can't flush the RX FIFO, why?

    BR

    Ivo

  • Settings IOCFG1 to 0x0E will not indicate if a packet is received or not. This signal is asserted if CS is above threshold. When a packet is received, the signal is most likely asserted, but it will also be asserted every time you detect noise in the channel above a certain threshold. The whole purpose of using WOR is that you should not wake up the MCU before you have actually received a packet. To detect this, you should have an interrupt on sync received. I would also recommend that you use GDO0 or GDO2 for this, as GDO1 is also used by the SPI interface.

    If you, for some reason want to wake up the MCU every time there is a signal on the air (CS asserted) you still need to check that there are bytes in the TX FIFO before trying to read it. You should NEVER try to read an empty FIFO.

    BR

    Siri