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.

IWR1443: profile parameters considerations regarding transmitter temperature and adc samples

Part Number: IWR1443


Hi,

I have an application were I am only interested in the range profile acquired as fast as I can (no velocity or aoa requirements).  I have modified the MmwDemo_dataPathTask function in the demo software to accomplish this.  One  major change was to determine the clutter signature outside the while(1) loop.  Performing clutter removal inside this loop provided a nice dynamic approach but I did not want to spend the time.  I have a few questions to pose.

1.  I have set the frame periodicity fairly small since I do not have any data to be transferred.  My output is only a state change on GPIO_0 which does not have any significant over head.  I am using only one transmit and receive antenna with one to 4 chirps.  For my fastest clutter removal algorithm, I need only one chirp which really allows me a fast chirping rate.  My question is: can the part overheat since I am consistently driving the transmitter and not letting it cool during any processing period?  I essentially have no processing period for part cooling.  The first few lines of the configuration file is:

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 1 1 0
adcCfg 2 1
adcbufCfg 0 1 0 1
profileCfg 0 77 7 4.6 125.19 0 0 25.11 1 556 4649 0 0 30
chirpCfg 0 0 0 0 0 0 0 1
frameCfg 0 0 4 0 10 1 0
lowPower 0 0
guiMonitor 0 0 0 0 0 0

2. The above parameters were derived from you mmwave sensing estimator 1.2.  It has the number of adc samples set at 556 and the number of  range fft bins at 1024.  Is there any way to force the number of adc samples to be 1024 to achieve the maximum numerical processing gain?  About another 6 db's in gain could be achieved by lowering the noise floor though sampling more data.  I assume the software zero pads the remaining bins from 557 to 1024.  I have tried to manual adjust the parameters to meet my constraints but I have not be very successful.

3. When I examined the configuration file generated by your demo visualizer gui configuration file for 1 transmitter and 1 receiver, the channel parameters specify receiver antenna to be "2" as indicated by channelCfg 2 1 0

Is there any particular reason for using one receiver antenna over another?

Thank you.

Al

  • Hi Allen,

    1) For each chirp, you have 7 idle us and 125.19 active us, giving a total chirp time of 132.19 us. For 4 chirp loops, that is 528.76 us, giving you a duty cycle of about 53%.  You should not need to worry about the EVM overheating.

    2) Please see the 4K FFT Stitching demo on TIREX. This will demonstrate maximizing the input of the FFT accelerator.

    3) There is no reason to favor a particular receiver with the antenna configuration on the IWR1443 EVM.

    Regards,

    Justin

  • Hi Justin,

    Thanks for the good information.  Regarding temperature, what might be  the maximum duty cycle ti advises?  I noticed that the data sheet specs a maximum junction temperature of 105C.  Since I am interested in sample as fast as I can, I could be reducing my duty cycle.  I thought I saw an old post indicating that the junction temperature can be monitored.  Would you have quick reference on this?  If one is cooking eggs on the streets of phoenix over the summer, I would like to be aware of the junction temperature.  I perfer to make assumptions based upon a laboratory environment.

    I looked at the 4k fft stitching demo.  I appears that 4, 1024 point fft's are done with 1024, 4 point fft's too.  Since I am looking for speed, this approach may not be desirable.

    Thanks.

    Al

  • Hi Allen,

    Thank you for your patience. TI's recommended duty cycle for the device is 50%. We run the device at 70% in the gesture demo, which is possible because the EVM design removes some heat from the device.

    To monitor the junction temperature, you will be interested in the mmwave_link api. This api has a monitoring module. You configure the module, and it sends periodic reports as an event. You can see the doxygen documentation in the sdk under
    <SDK>/packages/ti/control/mmwavelink/docs/doxygen/index.html -> then navigate to modules->monitoring.

    Regards,
    Justin