• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 258 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.

AWRL6432: LPDS mode frame time delay issues

Lina Kim
Prodigy 750 points
Part Number: AWRL6432


Tool/software:

*Re-upload to public E2E as the person in charge commented

.

.

Hi team,

Regarding LPDS mode (lowPowercfg 1 or 2), there is an issue. 

When customer set lowPowercfg 1 or 2, both case face frame time delay issue.
No fixed time delay, there is a different time delay for each Frame cycle setting.

The code used basic examples with no modifications. They found that it happened in both examples.

.

.

I received an answer from Kristien to adjust the LPDS latency value. 

So, I increased the LPDS latency value and tested it. My additional questions are below.

 

  1. ‘xWRL6432 Power Consumption.pdf’ contains LPDS latency, with a typical time of 2ms. Can you tell me how the value of 2ms came out?
  2. If what I understand is correct, Remain frame time cannot be changed and sleep time is expected to be reduced when the LPDS latency value is adjusted to more than 2ms, so does that not affect power consumption?



  3. If you check the attached test results, you can see an error when set above a certain value.




I think it is inefficient to test all values so that frame delay does not occur. Is there a guide to how much LPDS latency should be set if the frame period is x ms? The method of putting it one by one and checking it through the oscilloscope is less reliable.

Regards,

Lina

  • 0
    TI__Prodigy 750 points

    FYI

    [Configuration]

    sensorStop 0

    channelCfg 7 3 0

    chirpComnCfg 20 0 0 256 4 56.4 0

    chirpTimingCfg 8 16 0 16.8 60.51616

    % <NumOfChirpsInBurst>-<NumOfChirpsAccum>-<BurstPeriodicity>-<NumOfBurstsInFrame>-<FramePeriodicity>-<NumOfFrames>

    frameCfg 128 0 8359 1 200 0

    antGeometryCfg 0 0 1 1 0 2 0 1 1 2 0 3

    guiMonitor 2 1 0 0 0 1 1 0 0 0 0

    sigProcChainCfg 256 64 1 2 4 4 0 15

    sensorPosition 0 0 0.3 0 0

    cfarCfg 2 8 4 3 0 12.0 0 0.95 0 1 1 1

    aoaFovCfg -80 80 -40 40

    rangeSelCfg 0.1 10.0

    clutterRemoval 0

    compRangeBiasAndRxChanPhase 0.0 1.00000 0.00000 -1.00000 0.00000 1.00000 0.00000 -1.00000 0.00000 1.00000 0.00000 -1.00000 0.00000

    adcLogging 0

    lowPowerCfg 1

    factoryCalibCfg 0 0 40 0 0x1ff000

    compressionCfg 0 0.5

  • 0 in reply to Lina Kim
    TI__Genius 14436 points

    Hey Lina, 

    Thanks for posting this on E2E. See some of my comments below.

    Lina Kim said:
    ‘xWRL6432 Power Consumption.pdf’ contains LPDS latency, with a typical time of 2ms. Can you tell me how the value of 2ms came out?

    The default 2 ms latency we use is based off of an average of multiple real world measurements of the transition time into and out of LPDS.

    Lina Kim said:
    If what I understand is correct, Remain frame time cannot be changed and sleep time is expected to be reduced when the LPDS latency value is adjusted to more than 2ms, so does that not affect power consumption?

    You are partially correct. Remaining frame time can technically be changed if you were to use a different chirp configuration since it is based upon the frame period minus the elapsed demo time. The elapsed demo time includes chirping, processing, and data output via UART. For example, if you were to reduce the number of chirps by half, then chirping time will decrease and the processing and data output time will decrease as well since there is less data to process and send out. 

    The average frame power will increase if the sleep time is reduced since you will be spending overall less time in LPDS which is the most power efficient state. 

    Lina Kim said:
    Is there a guide to how much LPDS latency should be set if the frame period is x ms?

    Unfortunately, we do not have any guidelines or documentation for determining the LPDS latency as far as I'm aware, but let me check with a few other engineers internally.

    Regards,

    Kristien

  • 0 in reply to Kristien Everett
    TI__Prodigy 750 points

    Hello Kristien,

    Thank you for your kind answer. I understood your explanation!

    Kristien Everett said:
    The default 2 ms latency we use is based off of an average of multiple real world measurements of the transition time into and out of LPDS.

    Then I'd like to know what settings you conducted the test in.

    How many chirps and how long frame period did you set up and test? Customers wonder how you got an average of 2ms when you set the values range variously.

    And if TI doesn't have any guide, it would be nice to have a LPDS latency guarantee value that recommends setting at least from A to B. Could you please check if it is possible?

    I appreciate your help always.

    Regards,

    Lina

  • 0 in reply to Lina Kim
    TI__Genius 14436 points

    Hey Lina,

    No problem! As always, see my comments below:

    Lina Kim said:

    Then I'd like to know what settings you conducted the test in.

    How many chirps and how long frame period did you set up and test? Customers wonder how you got an average of 2ms when you set the values range variously.

    I will have to check internally with the validation team that did the latency benchmarks to see what settings they used.

    Lina Kim said:
    And if TI doesn't have any guide, it would be nice to have a LPDS latency guarantee value that recommends setting at least from A to B. Could you please check if it is possible?

    I can check on this point as well with the validation team.

    Please give me until early next week to compile together answers.

    Thank you for your patience,

    Kristien 

  • 0 in reply to Kristien Everett
    TI__Prodigy 750 points

    Hi Kristien,

    While waiting for an answer from the validation team, the customer raised a question.

    They think root cause happened by PRCM Clock. As you know, the wake-up time is set in the PRCM by subtracting the LPDS Latency value and calculating the clock tick at 32.768KHz, which is the clock of the PRCM. (PRCMLPDSIntervalSet function)

    Obviously, the calculation of the remaining time up to the sleepTimeus – LPDSlatency part was correct, but after the clock tick was not correct.
    So, they are doubting that PRCM's 32.768KHz is correct.
    - Do you have any documents related to PRCM?
    - Where can they find out and confirm the clock is 32.768 KHz?
    Regards,
    Lina
  • 0 in reply to Lina Kim
    TI__Genius 14436 points

    Hey Lina,

    I confirmed with some of our engineers that worked with the clocking architecture for the AWRL6432 that the clock rate is 32768 Hz, so this calculation should be correct. Do note that the actual clock rate will fluctuate with temperature.

    I'm still waiting on a response regarding the LPDS latency benchmarks. 

    Regards,

    Kristien