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.

  • Resolved

CC2543: Minimum transmit interval

Expert 1615 points

Replies: 9

Views: 1315

Part Number: CC2543

I'd like to setup the minimum transmit interval with the CC2543.  Specifically I want to achieve 500us intervals or less.  I am using the "per_test" software project as a starting point.

On line 289 of "per_test_cc254x.c", I can shorten the TX Interval with the argument to halRfPacketTxInterval( ).  However, any argument below 600 doesn't result in a shorter duration between packets.

Could you provide guidance how to achieve a shorter Tx interval?  I am guessing there's something in the radio configuration I'm missing.

  • I might have answered my own question: I can achieve a shorter TX interval if I disable synthesizer recal by setting REPEAT_CONF=1 and SYNTH_ON=1. I'm not changing channels between TX messages, so this might be a viable option. I'm guessing there is some degredation in performance by not recalibrating the synthesizer.

    Please let me know if there is another way to achieve shorter intervals, or significant drawbacks to this approach.
  • Expert 105180 points

    In reply to npb17:

    Hello Nick,

    I was going to direct you to this post: e2e.ti.com/.../2354950
    but I see you already found it! Although we don't perform this case, you results seem to show that it's acceptable.

    Best wishes

    Please click the "This Resolved My Issue" button on this post if it answers your question

  • Guru 56510 points

    In reply to npb17:

    Then simply send them back2back by repeating something like this:

    // Start each receive/transmit immediately on command
    PRF.TASK_CONF.START_CONF        = 0;
    
    while(1) {
      // Start transmitter.
      halRfStartTx();
    
      // Wait for TASKDONE.
      while (!(rfirqf1 & RFIRQF1_TASKDONE));
      if(PRF.ENDCAUSE == TASK_ENDOK) {
        if(rfirqf1 & RFIRQF1_TXDONE) {
          halRfCommand(CMD_TXFIFO_RETRY);
        } else {
          // Handle other possible interrupt flags.
        }
      } else {
        // Handle error
      }
    }

    Best Regards, Eirik
    Please refer to the resources and abbreviations below for explanations and answers to many questions.


    SLA - Simplelink Academy, SCS - Sensor Controller Studio, SC - Sensor ControllerTI Cloud ToolsResource Explorer, Bluetooth low energy software stack, Bluetooth low energy software stack archiveTI BLE Wiki (OLD)BLE Getting Started and FAQCC1352R and CC26x2R Intro, Bluetooth SIG Core Spec, CC2640R2F SDG, CC26X2 SDG, CC2650/CC2640 SDGBLE PACKET SNIFFER

  • In reply to Eirik V:

    Hi Eirik,

    Unless I'm missing something, what you posted is how the PER example is setup and I have not modified that loop. I cannot achieve under ~600usecond packet intervals unless I disable SYNTH recalibration.

    Turns out I do need to change channels between transmit. So disabling SYNTH recalibration is not a good approach.

    -Nick
  • In reply to npb17:

    Nevermind the first part of my comment. I see you are using the RETRY command, which is different than the example software. I will give that a shot.
  • In reply to Eirik V:

    Using TXFIFO_RETRY command results in TASKERR_TXFIFO after the second packet is sent. I did not reload another packet into the FIFO as per your example above.
  • In reply to npb17:

    If I shorten my payload to 12 bytes, I can achieve 500us packet intervals for transmit, including changing frequency channel every packet. I'm using the 2Mbps 5ookHz Basic fixed-length mode, forgot to say that earlier.

    Let me know if there's a particular setting I can use to gain back 100useconds or so of turnaround time. We need to support a payload of around 30 bytes.
  • Guru 56510 points

    In reply to npb17:

    Hello,
    I forgot to mention you need to enable reuse to make sure that the packet in the FIFO is not deallocated after transmission.
    PRF.ADDR_ENTRY[0].CONF.REUSE = 1; // Reuse packet in FIFO

    Best Regards, Eirik
    Please refer to the resources and abbreviations below for explanations and answers to many questions.


    SLA - Simplelink Academy, SCS - Sensor Controller Studio, SC - Sensor ControllerTI Cloud ToolsResource Explorer, Bluetooth low energy software stack, Bluetooth low energy software stack archiveTI BLE Wiki (OLD)BLE Getting Started and FAQCC1352R and CC26x2R Intro, Bluetooth SIG Core Spec, CC2640R2F SDG, CC26X2 SDG, CC2650/CC2640 SDGBLE PACKET SNIFFER

  • In reply to Eirik V:

    I ended up determining that a large portion of the delay is due to the LCD update within the core software while-loop.

    With those statements removed, there is no problem reaching under 500usecond packet intervals for transmit.

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.