• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 892 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1352R: Does PHY config impacting RX-TX turnaround time?

Chencheng Zhang
Prodigy 10 points
Part Number: CC1352R
Other Parts Discussed in Thread: LAUNCHXL-CC1310, CC1310

Hi,

I have looked at this thread https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/sub-1-ghz-forum/562134/cc1310-cc1310-tx-rx-turnaround-time

But I think my question is different.

If I use chained radio command to do RX to TX switching using different PHY (e.g., bitrate 200kbps, 500kbps, 1mbps), will this RX-TX turn around time change / be impacted?

If so, how does PHY impact this turnaround time? Is there a theoretical way to calculate it?

Thanks & BR,
Chencheng

  • 0
    TI__Mastermind 34000 points

    Hi,

    The Rx to Tx switching time will be more or less constant using different PHYs. 

    Regards,

        Richard

  • 0
    Prodigy 10 points

    Just to elaborate more with some testing examples.

    I route the radio core signals of RAT_GPO0 and RAT_GPO1, which indicated as green signals in the probing pictures.

    And I also probe on the demodulator signal MCE_GPO1 which indicated as blue signals in the probing picutres.

    In this first picture I chained TX command which schedule after 32us of RX.

    The actual measurement between "RX end" and "TX start" in the picture is ~135us.

    On the demodulator signal, I found an interested signal which I marked as "glitch A".

    It looks like the time between "glitch A" and "TX start" is a constant among different measurements.

    My guess is that, the "32us" is actually entailed in the time between "RX end glitch" and "glitch A" (~58us) in the demodulator signals.

    Then I changed the chain to trigger immediately with TRIG_NOW:

    Then the time between "RX end glitch" and "glitch A" goes down to ~46us.

    But still, 58us - 46us = 12 us which does not match 32us which I put in the chain delay in the picture.

    So how exactly to correlate the delay in the chain and the real command execution time?

    How do I count "32us" in the first picture?

    What does "glitch A" in the pictures mean?

    Thanks & BR,

    Chencheng

  • 0 in reply to RGW
    Prodigy 10 points

    Hi, just replied with some elaboration.

    Could you please take a look at my reply?

    Thanks!

    Chencheng

  • 0 in reply to Chencheng Zhang
    TI__Mastermind 34000 points

    Hi,

    Do you get the same results when your perform this test on the LAUNCHXL-CC1310 hardware ?

    Regards,

       Richard

  • 0 in reply to Chencheng Zhang
    TI__Guru* 87001 points

    I strongly recommend that you look at the current profile to see the timing between RX and TX. Do you see the same thing there?

    Siri

  • 0 in reply to Siri
    Prodigy 10 points

    Hi Siri,

    What does "current profile" mean?

    Currently the examples showed in the picture are of 1Mbps.

    /Chencheng

  • 0 in reply to RGW
    Prodigy 10 points

    Hi Richard,

    Sorry we don't have CC1310 for now.

    May I ask what is your expectation there by redo the measurement on CC1310? should it look different?

    But our main question is:
    We schedule a 32us delay but we got ~138us delay in reality.

    We need to know why and how to tackle this problem.

    Thanks!

    /Chencheng

  • 0 in reply to Chencheng Zhang
    TI__Mastermind 34000 points

    Hi,

    We will look at this on the LP platform to see if we see the same behavior. We normally look at the current profile since we know the level of current consumption for each state and then measure the time delta between the Rx state and Tx state.

    By testing on the LP, then we will have a common platform so we can compare results directly. 

    Are you using the same crystal as used on the reference design?

    Regards,

       Richard

  • 0 in reply to RGW
    Prodigy 10 points

    Thanks for your reply Richad.

    We are using https://www.ti.com/tool/LAUNCHXL-CC1352R1

    /Chencheng

  • +1 in reply to Chencheng Zhang
    TI__Guru* 87001 points

    First of all, what I meant by current profile, was that if you are interested in the time from RX state to TX state, measuring the current consumption with a Power analyzer will give you the most accurate indication on when the device is actually in RX state and TX state. Other signals might have processing delays etc.

    We do not have a full overview of internal delay and how many cycles it takes from one state to another, so the best thing to do is to adjust the trigger times until you have the timing that you want.

    Once you have found that with a special startTrigger and startTime it takes x us to move from RX state to TX state, this time should be pretty stable.

    I did a test where I used CPE_GPO0 and CPE_GPO1 (PA and LNA signal) to measure the time from RX to TX using the 1 Mbps PHY.

    When using TRIG_NOW on the TX command, I measure 124 us from LNA signal was de-asserted to the TX signal was asserted.

    I do not have a power analyzer available, but my point was that if you looked at the current profile, this timing might look a little bit different, as the LNA and PA signals are intended to control an external LNA and PA, and therefor is asserted a little bit before the radio enters active state, and de-asserted a little bit after it exit active state, to make sure that the LNA/PA is ON for the entire Active period.

    When using the TRIG_REL_PREVEND instead, and setting the start time to 32, you should maybe think that you would measure 32 + 124 = 156 us from LNA was de-asserted until PA was asserted, but this is not the case (I measure 140 us). What that means is that TRIG_NOW is not the same as TRIG_REL_PREVEND and startTime = 0.

    If you, however, use TRIG_REL_PREVEND, and increase the startTime from 32 to 132 us, you will see a delta of 100 us if you measure the time between the LNA and the PA signal (goes from 140 us to 240 us).

    To conclude, the fastest switching time between RX and TX you get with command chaining and using TRIG_NOW. It is not possible to decrease this time further.

    Not sure what you are trying to achieve with the TRIG_REL_PREVEND and the startTime of 32 us. If the goal was that TX should be active 32 us after RX was active, this is not possible. If you want to increase the minimum time (of 12x us), you can achieve this by using TRIG_REL_PREVEND, and then testing with different StartTimes to get the timing you want. Once you have found the correct startTime, you should verify that this works OK for all the different PHYs you are using.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 10 points

    Thanks a lot Siri for your detailed explanation!

    I took your suggestion and did some other measurements with different PHYs using TRIG_NOW. It looks like that the shortest RX to TX turn-around time is around 124us to 125us on my launchpad.