• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 137 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: TrxEB Command Strobe Timing

Ruth Desta
Prodigy 40 points
Part Number: CC1101

Tool/software:

Hello,

I had 2 questions regarding the timing of command strobes.

1. After filling up the TX FIFO, the TrxEB waits 97us before sending the TX command (0x35), is there a reason for this?

2. Whenever its about to start a transmission, it will send the following command strobes 0x36, 0x3B, 0x3A, 0x3D then waits for ~6ms before sending out 0x3B. Is there a reason for this specific sequence and why it waits ~6ms before sending out 0x3B and starts to configure registers for a transmission?

Thank you in advance.

Ruth

  • +1
    TI__Guru* 86151 points

    I am not sure what code you are running.

    The TrxEB does not do anything other than what you have programmed the MCU on the TRxEB to do.

    Are you running your own code or any of our code examples, or are you using SmartRF Studio to control the board?

    There are no requirement on the CC1101 to wait for anything between filling the TX FIFO and issuing the strobe command. Any delay you are seeing is either cased by the application SW you have running on the TrxEB or delays both in the firmware and on the PC side if you are running SmartRF Studio.

    I assume you are using Studio based on your questions regarding the strobe command.

    Remember that Studio does not know what settings the user input and therefore also what error state etc. the device can enter.

    Before starting for example a transfer it will then make sure that all FIFOs are cleared etc.

    When you are writing you application this is not necessarily something that you need to do, as it is fully possible to write an allocation that will never overflow/underflow the FIFOs etc, so flushing of the FIFOs will not be necessary.

    I recommend that you look at the code example for the CC1101 to understand how the device is to be used, instead of looking at what is going on when using SmartRF Studio.

    For example will Studio report what state the device is in when using it, meaning that it will send SNOP commands at a regular rate just to get status back from the device.

    This si something that you would not do in a “normal” application.

    Siri