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

RTOS/LAUNCHXL-CC1310: In our SDK project rfWakeonRadioRx.c, How to change PQT?

Eggsy Pang
Expert 4985 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Tool/software: TI-RTOS

Hi Team,

       In our SDK project rfWakeonRadioRx.c, How to change PQT? I would like to make PQT smaller for improving the sensitivity and range.

Best Regards,
Eggsy

  • 0
    TI__Guru**** 317180 points
    Sorry, did an assumption that was not fully correct. PQT on CC1310 looks for correlation tops which is possible to set in the API for the command. Normally you would check RSSI in addition to PQT to check if a correlation top was found in noise and hence PQT would not limit the sensitivity.
  • 0 in reply to TER
    TI__Expert 4985 points
    Hi TER,

    sorry about that I don't understand what you mean.
    1. You mean that PQT is higher, sensitivity is not lower?
    2. Where is correlation tops? Which API I can change PQT, could you show to me ?

    Thank you!
  • 0 in reply to Eggsy Pang
    TI__Expert 4985 points
    As for Question 2, I guess I know where it is. It is numCorrBusy and numCorrInv.
    /* PQT configuration */
    rxSniffCmd->corrConfig.numCorrBusy = 1; /* One busy PQT samples signals that the channel is busy */
    rxSniffCmd->corrConfig.numCorrInv = 1; /* One busy PQT samples signals that the channel is busy */

    if I change

    /* PQT configuration */
    rxSniffCmd->corrConfig.numCorrBusy = 2; /* One busy PQT samples signals that the channel is busy */
    rxSniffCmd->corrConfig.numCorrInv = 2; /* One busy PQT samples signals that the channel is busy */

    What will it happen? Short range? Lower power?
  • 0 in reply to Eggsy Pang
    TI__Guru**** 317180 points
    Increasing the numCorr settings require that more preamble has to be found within the window given. This could make it less likely to find preamble in noise but should not impact range/ power.
  • 0 in reply to TER
    TI__Expert 4985 points

    Hi  TER,

            Thank you!

    But I have a question.

    Let call working without WOR mode A,  call working with WOR (numCorr=1) mode B and call working with WOR (numCorr=2) mode C.

    I tested their translation distance, I found the translation distance, mode A > mode B > mode C.

    I guess the numCorr is bigger , will make it less likely to find preamble in noise, which will also be harder to receive the packet and impact the translation distance.

    Do you think so ?

  • 0 in reply to Eggsy Pang
    TI__Guru**** 317180 points
    How long preamble do you send?

    You also have to calculate the correlation period. If you increase the number of correlation tops you also have to increase the correlation time to have time to receive the number of samples required to generate a correlation top.
  • 0 in reply to TER
    TI__Expert 4985 points
    Sorry for late to reply it case I am on the travel .
    As for mode B, I run our SDK WOR project, sending 1s preamble.
    As for mode C, I run our SDK Tx/Rx rf_packet project.
    As for mode A, based on SDK WOR project, change number of correlation tops :

    /* PQT configuration */
    rxSniffCmd->corrConfig.numCorrBusy = 2; /* One busy PQT samples signals that the channel is busy */
    rxSniffCmd->corrConfig.numCorrInv = 2; /* One busy PQT samples signals that the channel is busy */

    But I don't know how to change the correlation time. I see below code .

    uint32_t correlationPeriodUs = (syncWordSymbols + CORR_PERIOD_SYM_MARGIN)*symbolLengthUs;

    rxSniffCmd->corrPeriod = (uint16_t)(correlationPeriodUs * US_TO_RAT_TICKS);

    Do you have any suggestions ?
  • 0 in reply to Eggsy Pang
    TI__Genius 14860 points

    Hi Egsy,

    I don't think that you need to change the correlation period. In the WoR RX example, the csEndTime is much shorter (about 650µs) than correlationPeriod (about 960µs) and an evaluation is forced at that time. If the number of correlation tops has not reached corrConfig.numCorrBusy until csEndTime, the correlation result remains "INVALID" and hence, the channel is treated as "INVALID" (csConf.operation is 1, see table 10 here.

    If I understand your original post correctly, then you want to make the carrier sense operation less strict. Therefore, you should increase csEndTime. Try to increase it in steps of 100 µs. But this will make it also more likely that the sniff command reports a BUSY channel when there is an interferer. Increasing the sensitivity with this wake-on-radio system architecture has to come at a certain cost, which is always power consumption.

  • 0 in reply to Richard W.
    TI__Expert 4985 points
    Hi Richard，

    Thank you very much!