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.

AWR6843AOP: Reduce Average Power Consumption at Power Terminals

Part Number: AWR6843AOP

Hello tech support,

In Table 8-4. Average Power Consumption at Power Terminals, 24% duty cycle 1TX, 4RX 1.19W case in AWR6843AOP datasheet, could you please support following questions?

1. Is it possible to set 13.13-ms frame time to 500ms? In this case how the average power consumption will be?
2. Could you please clarify 24% duty cycle definition? Does it mean 13.13ms frame in 54.7ms cycle time: 13.13ms/54.7ms=24%?
3. Is it possible to make average power consumption 10mW? If yes, by what configuration can it be possible?

Best Regards,
Katsuhiro

  • Hi Katsuhiro-san,

    1. Yes, it is possible to adjust the frame time (frame periodicity) to be 500ms. This is done by modifying the frameCfg command in the chirp configuration file. This alone will not cause a major change in power consumption. To optimize power consumption see the below resources.

    2. The duty cycle refers to how much of the frame period is spent transmitting chirps. In this case, 3.15/13.13 = 24%, therefore, 3.15ms is the total chirping time.

    3. Unfortunately, even with the power optimizations shown in the above resources, achieving an average power of 10mW would not be possible on AWR6843AOP.

    Best Regards,

    Kevin

  • Hi Kevin,

    Thank you very much for your quick response.
    I understand that the "13.13ms frame time" consists of "total chirping period = acquisition period 3.15ms" and "inter-frame period 9.98ms", this results in 24% duty cycle. Looking at "Figure 2-5. Radar Cycle - Acquisition and interframe periods" in "xWR6843 Power Optimization", "inter-frame period" consists of "processing & Output" and "Idle". Extending frame time to 500ms with maintaining "acquisition period" and "processing & output period", idle period is extended by 486.87ms = 500ms-13.13ms. This 486.87ms extension in idle period will not cause a major change in power, that means power consumption of idle time is relatively high. How much power consumption is expected during idle period? Is it 217.8mW indicated in "5.2.2 Full Power Down Scheme Measurement" in "xWR6843 Power Optimization"?

    Q1. Is the lowest power consumption during "Idle period" 217.8mW, which is described in "5.2.2 Full Power Down Scheme Measurement" in "xWR6843 Power Optimization"?
    Q2. Is the 217.8mW during "Idle period" the reason why "This alone will not cause a major change in power consumption."? That is, even if "Idle period" is long enough, average power consumption cannot be lower than 217.8mW?
    Q3. To achieve 10mW order of average power consumption, is the following control to AWR6843AOP feasible and/or useful?
          Power supply down in 1299.87ms (= 1313ms-13.13ms) and Active in 13.13ms?
          In this control, is expected average power consumption roughly 1/100 of 1.19W?
    Q4. If the control described in Q3 is feasible, what side effect is expected? For example, tracking people by AWR6843AOP is not possible.

    Best Regards,
    Katsuhiro

  • Sorry for pushing you, but I would appreciate it if you could reply by tomorrow.

  • Hi Katsuhiro-san,

    You are exactly right, increasing the frame time to 500ms would result in an "idle period" of 486.57ms and the power expected during this time is the 217.8mW value you've identified.

    A1. This is the lowest possible power number the device is capable of achieving on its own. However, in theory, if the application can use an external controller to shut off the device, you would be able to achieve a much lower average power consumption. Again, this would require some external source to power the AWR6843AOP device on and off, and would depend on if the application can handle this power cycling. In such a complete shutdown, the expected power consumption of the device would be about 2mW.

    A2. The reason why I said extending the frame time alone would not cause a change in power consumption is because the device does not go into idle mode by default. Instead, you have to call APIs to power down the DSP, slow the MSS clock to 40MHz, power down the RF, and power down APLL and GPADC. The Low Power Demo example I provided in my previous post will cover this.

    A3. This is feasible. The frame periodicity can be very slow if desired. 

    A4. The side effect of extending the frame time is that essentially there is a lot of information you would miss. Since you are decreasing how often you're chirping, there would be a lot of real-world information that will not get detected. This might be okay depending on the end application. If you are only concerned about range, and are okay with such a slow rate of data capture, then everything should be okay. Ultimately, the end application dictates if such a slow frame makes sense. Now if you need the radar to be able to detect more dynamic scenes and measure velocity, then the scenario described in Q3 will likely be too inaccurate. 

    Best Regards,
    Kevin

  • Hi Kevin,

    Thank you very much for your detailed explanation. All current questions have been cleared.

    Best Regards,
    Katsuhiro