• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 17 subscribers
  • Views 1464 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.

CC2543: Minimum transmit interval

npb17
Expert 1615 points
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.

  • 0
    Expert 1615 points
    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.
  • 0 in reply to npb17
    TI__Guru** 105180 points
    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
  • 0 in reply to npb17
    TI__Guru 56590 points

    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
  }
}

  • 0 in reply to Eirik V
    Expert 1615 points
    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
  • 0 in reply to npb17
    Expert 1615 points
    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.
  • 0 in reply to Eirik V
    Expert 1615 points
    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.
  • 0 in reply to npb17
    Expert 1615 points
    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.
  • 0 in reply to npb17
    TI__Guru 56590 points
    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
  • 0 in reply to Eirik V
    Expert 1615 points

    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.