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.

IWR1642BOOST: IWR1642BOOST battery operated .

Part Number: IWR1642BOOST
Other Parts Discussed in Thread: IWR1642, IWR1443, TIDEP-0091

IWR1642BOOST  connected to 5V consumes  around 400 mA  when not scanning , How can i reduce this current consumption on Idle mode ? 

My system is intended to be battery operated .

Thanks

  • Hello,

    In the case of IWr1642, we have 3 processors, that have to be managed, this depends on the setup of your system.

       a) in battery powered systems, we must have a demand based software architecture, and a system that puts the radar sensor to OFF when not making measurements, or computing radar results.

       b) typically there is a HOST processor that is low power, it controls when the radar sensor local power supplies are turned on, the radar sensor does NOT have a sleep mode.  It most be placed in OFF to reduce power consumption.

       in the level sensing reference design, www.ti.com/.../TIDEP-0091, the MSP432 wakes up from a timer event or communication message.   If it determines that a radar sensor measurement is needed.   A signal is sent from the MSP432 GIO to enable the PMIC quad DCDC converter for the radar sensor.   We then boot the radar sensor, in your case MSS (Boot Rom), then MSS (application), BSS (application - in ES3 from Rom), and DSS (DSP application).

    c) eventually we are done copying from QSPI to RAM, and the MSS application starts.  Following the OutOfBox Demo under the mmWave SDK, you can see there are specific CLI commands to configure the Radar synthesizer, Timing Engine, Digital Front End, and later DSP processing.   

         during the initialization - you can choose to read calibration from QSPI (this is not in the current demo, it will be in a future release)

         You would then do selective Initialization Calibration, and RunTime calibration.   

    d) Chirp Configuration, Measurement

         Eventually the RF calibration is complete, we then configure the Chirp parameters, at this point, we are ready

         When we program the frame, profile, chirp - we have specific high power RF tasks, we want to minimize this time.   If your post chirp processing is longer 

         than the minimum time to the next chirp, you could consider buffering up the data into L3 memory.

          When we are done chirping, collecting data, the device power will drop, because we are now not using RF.

    e)  You would post process your DFE output data, using the eDMA, DSP processors to detect your object / not knowing your application,

         I assume the DFE data, goes to L3 memory, and is then DMAed to DSP, the results are then placed back in L3 memory.

         Depending on your application, if the radar sensor is supposed to do more chirping with different parameters you would repeat.

    f) lower power, after the DSP is done, we put the DSP in idle, and then use the MSS to transfer the data to your desired peripheral.

    g) we put the data back to sleep,  you can follow the IWR1443 version of the single flow through code,  TIDEP-0091 .

    I would start be recoding the IWR1443 version to IWR1642, collecting the radar DFE output data for 'n' chirps to L3 memory.  Perform

    some DSP range processing, exporting that over SPI, and then going to sleep.

    You could then extend this to your application.

    Regards,

    Joe Quintal