• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 53 subscribers
  • Views 283 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1101EM868-915_REFDES: CC1101 Asynchronous Communication Mode Receive Issue

Cherry Zhou
Mastermind 22235 points

Part Number: CC1101EM868-915_REFDES

Hi team,

System setting:

Transmit side: Connect the MCU1 serial port TXD end to the GDO0 of the CC1101, 868-MHz signal transmission over TXD

Receive side: Connect the RXD side of the MCU2 serial port to GDO2 of the CC1101 and receive 868 MHz of data resolved by the CC1101 via RXD

Issue:

When the transmit side is turned off (and there are no related devices around), the receive side GDO2 will always receive data, but it should be held at 0 (1) as described in the data sheet, and the customer set IOCFG2 = 0x0D, but theoretically it should be 0. When the transmit side is powered on (TXD default low), the receive side GDO2 is low and no data is generated. And the customer intends to test if the transmit side is always sending data with IOCFG2 = 0x1D.

The customer would like to know the root cause of the issue, is it related to the settings or the hardware and how to resolve it?

Thanks!

Best Regards,

Cherry

  • 0
    TI__Guru* 81931 points

    Hi Cherry

    Not sure I understand.

    The text you have highlighted says that the pin will be 0 when in SLEEP state. If you are in RX mode, which I assume you are, there will be RX data on the pin, regardless if you are transmitting something or not (in RX mode the radio will receive noise if no data are present).

    If you transmitting data, you should see the data on the GDO2.

    This can easily be tested with SmartRF Studio:

    Select one of the typical settings and select the “Cont. RX” tab.

    Select Async Mode.

    IOCFG will then be 0x0D, and in addition I set IOCFG0 to 0x0E (Carrier Sense).

    On the transmitter I transmit preamble only (strobe STX with an empty FIFO in the "RF Device Commands" tab)

    On the GDO2 pin you will see noise when the transmitter is off (CS not asserted), and preamble when the transmitter is on (CS asserted).

    BR

    Siri

  • 0 in reply to Siri
    TI__Mastermind 22235 points

    Hi Siri,

    Thanks for your support.

    1. By reading the status command of the receive side, it is found that the state machine returns a value of 0x0D, that is, it is always in the RX state. If we assume receiving radio noise, then what should be done to avoid it? Or is there a way to put it in SLEEP state and then activate the receiver when the transmitting device transmits the message and return it to the RX state?

    2. There is also garbled code when it is transmitted normally (is it RF noise?) Especially when the transmit side is far from the receive side, there is also a lot of garbled code even do not transmitted.

    Could you help resolve the 2 questions? Thanks.

    BS,

    Cherry

  • +1 in reply to Cherry Zhou
    TI__Guru* 81931 points

    Cherry

    There are no ways of not receiving noise when the radio is in RX. I do not see why this would even be a problem. When the “real” data comes along, they would have a signal that is stronger than the noise, and you should be able to receive it anyway (unless there are some interferers transmitting on the same frequency that you are operating at).

    If you have a synchronous protocol (i.e. you know that your transmitter is transmitting packets at a fixed interval) you can write your RX code such that you first enter RX and stays there until you receive the first packet, and after that you can enter SLEEP, and not go into RX mode again before you know that it is time for the transmitter to transmit the next packet.

    Wake-On-Radio is also a method that can be used, mainly to reduce RX current consumption.

    See the data sheets for more details on WOR (Cannot be used in serial mode, only normal packet mode/FIFO mode)

    When the signals get weaker and you get close to the sensitivity level, you will start getting errors in the packet. This is how wireless communication works. You can only receive data down to a certain level (sensitivity limit), and noise/interference on the air can “ruin” your data.

    Can I ask why you are using serial mode and not the normal FIFO mode? This mode is the preferred way of using the radio, and the MCU does not have to do any processing except reading out the packet of the FIFO once it is received without errors.

    Siri

  • 0 in reply to Siri
    TI__Mastermind 22235 points

    Hi Siri,

    Thanks for you support again, and the case is resolved with your help by using ASK modulation and CS carrier monitoring.

    Siri said:
    Can I ask why you are using serial mode and not the normal FIFO mode?

    Because the data being transmitted is a dynamically changing data, and because of the time transfer requirements, the use of FIFO requires more data to be processed, there is a time problem.

    Thanks and Best Regards,

    Cherry