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.

CC1352P: Reducing CC1352P transmission duration

Part Number: CC1352P
Other Parts Discussed in Thread: ENERGYTRACE

I am using the example program - CC1352P-2 Launchpad/TI Drivers/rfPacketTx/CCS Compiler/rfPacketTx.

The line RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx,RF_PriorityNormal, NULL, 0);

transmits the packet and this method is implemented in the TI driver. This method takes around 15ms to transmit 60 bytes @ 450 MHz, GFSK 25kHz dev, 128kbps data rate and 10ms to transmit 60 bytes @ 450 MHz, GFSK 25kHz dev, 200kbps data rate, the maximum possible.

Additionally, the method RF_runCmd is blocking. Is there any way to execute RF_runCmd faster? Any alternative method is available for this to speed up the process?

  • First of all, is you are operating in the 433 MHz band, you need to use the P4 Lp and not the P2 Lp (optimized for 868 MHz).

    Transmitting a packet with payload 60 bytes at 128 kbps takes (4 + 4 +1 + 60 + 2)*8/128000 = 4.44 ms and this time can be verified by using energyTrace and looking at the current profile.

    Not sure how you are measuring the time when you get 15 ms.

    Doing RF_runCmd is blocking and will not return before the packet has been sent. You can replace this with a RF_postCmd(), which will returns without waiting for the command to finish.


  • 1. Just for testing I am using P2. Our final hardware follows P4. We are aware that P2 is not optimized for 433 MHz.

    2. Just before RF_runCmd() I am setting a GPIO low and after this command I am setting the same GPIO high. I am measuring the low-high pulse using an oscilloscope. The time taken by this command is more than 10ms.

    3. We are using RF_runCmd() as we want a blocking statement. We are fine with it but it should be faster.

  • Unfortunately there are no magic settings you can apply to speed up the RF_runCmd (or the other commands).

    The only thing I can think of is that you can play around with the optimization settings for the compiler.

    If you do not have time to wait for a blocking call, I do not understand why you cannot use RF_postCmd instead.

    You can also use a start trigger for the command to make sure that it is executed at a given time.