Resolved

CC2543: Minimum transmit interval

npb17

Replies: 9

Views: 1321

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.

Expert 1615 points

npb17
- Nov 9, 2017 6:57 PM
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.
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Expert 105180 points

JXS
- Nov 10, 2017 12:17 AM
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
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Guru 56550 points

Eirik V
- Nov 10, 2017 9:37 AM
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 Controller, TI Cloud Tools, Resource Explorer, Bluetooth low energy software stack, Bluetooth low energy software stack archive, TI BLE Wiki (OLD), BLE Getting Started and FAQ, CC1352R and CC26x2R Intro, Bluetooth SIG Core Spec, CC2640R2F SDG, CC26X2 SDG, CC2650/CC2640 SDG, BLE PACKET SNIFFER
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Expert 1615 points

npb17
- Nov 13, 2017 2:45 PM
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
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Expert 1615 points

npb17
- Nov 13, 2017 3:20 PM
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.
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Expert 1615 points

npb17
- Nov 13, 2017 4:10 PM
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.
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Expert 1615 points

npb17
- Nov 13, 2017 5:12 PM
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.
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Guru 56550 points

Eirik V
- Nov 13, 2017 11:14 PM
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 Controller, TI Cloud Tools, Resource Explorer, Bluetooth low energy software stack, Bluetooth low energy software stack archive, TI BLE Wiki (OLD), BLE Getting Started and FAQ, CC1352R and CC26x2R Intro, Bluetooth SIG Core Spec, CC2640R2F SDG, CC26X2 SDG, CC2650/CC2640 SDG, BLE PACKET SNIFFER
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question
Expert 1615 points

npb17
- Nov 14, 2017 12:37 PM
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.
- Locked
- Cancel
Do you have another question?

We are glad that we were able to resolve this issue, and will now proceed to close this thread.

If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.

Ask a related question Ask a new question