IWR6843AOPEVM: the method for reducing Frame time

Hi Kevin,

Could you update to the latest version of the SDK (mmwave_sdk_03_06_00_00) from the link below?

https://www.ti.com/tool/download/MMWAVE-SDK

There is a new version of the Radar Toolbox available as well (1.20.00.11).

https://dev.ti.com/tirex/explore/

Could you also provide more details on how you are testing? Are you using one of our examples from the SDK or Radar Toolbox? How exactly are you changing the frame time and updating the device? Are you using one of our EVMs?

Thanks,

Clinton

Hi Clinton,

(1) For time being I give the working environment more detail first as followings, 

     Project: C:\ti\radar_toolbox_1_10_00_13\source\ti\examples\InCabin_Sensing\AWR6843_CPD_with_Classification

     Configuration file: 

     C:\ti\radar_toolbox_1_10_00_13\tools\visualizers\InCabin_CPD_w_Classification_GUI\config_file\vod_6843_aop_overhead_2row_classification.cfg

     IDE: CCS 12.3.0

     SDK: mmwave_sdk_03_05_00_04 

     Tool: radar_toolbox_1_10_00_13

     Hardware: using IWR6843AOP on own built board

     Platform: PC Windows 10

(2) Modified one line on configuraion file:

    I want to change frame time from 200 ms to 100 ms on this file in folder of

   C:\ti\radar_toolbox_1_10_00_13\tools\visualizers\InCabin_CPD_w_Classification_GUI\config_file\vod_6843_aop_overhead_2row_classification.cfg

File content:

//===================================================================================================

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 15 7 0
adcCfg 2 1
adcbufCfg -1 0 1 1 1
lowPower 0 0
profileCfg 0 60.00 2789 11 41 0 0 97.0 1 64 2200 0 0 36
profileCfg 1 60.00 20 11 41 0 0 97.0 1 64 2200 0 0 36
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 1 0 0 0 0 2
chirpCfg 2 2 1 0 0 0 0 4

frameCfg 0 2 54 0 100 1 0                  // changed from 200 ms to 100 ms

dynamicRACfarCfg -1 5 29 1 1 8 8 4 6 4 1 8.00 6.00 0.40 1 15
staticRACfarCfg -1 4 4 2 2 8 16 4 6 6.00 13.00 0.50 0
dynamicRangeAngleCfg -1 8.000 0.03 2 0
dynamic2DAngleCfg -1 5 1 1 1.00 8.00 2
staticRangeAngleCfg -1 0 1 1
dopplerBinSelCfg -1 0 64 0 4
antGeometry0 -1 -1 0 0 -3 -3 -2 -2 -1 -1 0 0
antGeometry1 -1 0 -1 0 -3 -2 -3 -2 -3 -2 -3 -2
antPhaseRot -1 1 -1 1 -1 1 -1 1 -1 1 -1 1
compRangeBiasAndRxChanPhase 0 0.9929 -0.1188 -0.9842 -0.1769 0.9994 0.0349 -0.9981 -0.0623 0.6777 -0.7353 -0.8517 0.5241 0.7782 -0.6280 -0.8004 0.5995 0.6842 -0.7293 -0.8495 0.5275 0.7969 -0.6041 -0.8090 0.5877
fovCfg -1 75.0 75.0

numZones 5
totNumRows 2
sensorPosition 0 1.2 1.1 90 0 0

% state machine threshold first parameter is #zoneType
occStateMach 0 10 10 3 50 1 3 12 20 4 700.0
occStateMach 1 10 10 3 50 3 3 12 15 3 700.0
classParam 1 50 36 36 36 40 36 0.025 0.025 0.025 0.022 0.025

% seat zone definition, independent of mounting location
interiorBounds -0.9 0.9 0.0 2.2

% Origin = -X to psngr, +X to driver, yStart, yEnd (0 = brake panel), zStart, zEnd (z: 0 start of the floor)
% zone 1 (driver) cuboids
cuboidDef 1 1 0.15 0.75 0.6 1.2 0.85 1.1
cuboidDef 1 2 0.2 0.75 0.3 1.1 0.4 0.85
cuboidDef 1 3 0.2 0.75 0.0 0.6 0.0 0.4
% zone 2 (front passenger) cuboids
cuboidDef 2 1 -0.75 -0.15 0.6 1.2 0.85 1.1
cuboidDef 2 2 -0.75 -0.2 0.3 1.1 0.4 0.85
cuboidDef 2 3 -0.75 -0.2 0.0 0.6 0.0 0.4
% zone 3 (2nd row driver side) cuboids
cuboidDef 3 1 0.30 0.8 1.6 2.2 0.80 1.1
cuboidDef 3 2 0.30 0.8 1.4 2.2 0.3 0.80
cuboidDef 3 3 0.30 0.8 0.9 1.4 0.0 0.3
% zone 4 (2nd row middle) cuboids
cuboidDef 4 1 -0.10 0.10 1.6 2.2 0.80 1.1
cuboidDef 4 2 -0.10 0.10 1.4 2.2 0.3 0.80
cuboidDef 4 3 -0.10 0.10 0.9 1.4 0.0 0.3
% zone 5 (2nd row passenger side) cuboids
cuboidDef 5 1 -0.8 -0.30 1.6 2.2 0.80 1.1
cuboidDef 5 2 -0.8 -0.30 1.4 2.2 0.3 0.80
cuboidDef 5 3 -0.8 -0.30 0.9 1.4 0.0 0.3

% zoneType and zone neighbor definition,
% zoneNeighDef #zoneID, #zoneType, #number of Neighbor needs to consider, #the list of neighbors,
% zoneType=0: normal seat, zoneType=1: middle seat; users can add other zoneType for footwell door and etc
% when adding new zoneType, you will need to add a new line of occStateMach
zoneNeighDef 1 0 0
zoneNeighDef 2 0 0
zoneNeighDef 3 0 1 4
zoneNeighDef 4 1 2 3 5
zoneNeighDef 5 0 1 4

sensorStart

//===================================================================================================

(3) I just wonder using the larger Valid Start Time of 2789 us than other examples, why?

for example:

profileCfg 0 60.00 2789 11 41 0 0 97.0 1 64 2200 0 0 36

where  <adcStartTime> "ADC Valid Start Time" in u-sec, 2789 us

Does it possible to change this value of 'Valid Start Time' for reduce Frame Time?  

Regards,

Kevin

Hi Kevin,

Thanks for following up with more information. Please allow some time to evaluate. I will provide feedback in the next day or so.

Thanks again,

Clinton

HI, Kevin:

The total chirping time is already longer than 100ms.  Currently, the total chirp time is (2798 + 41 + (20+41) *2) * 54 = 159.89ms.  Therefore, you need to limit the total chirping time to about 60ms.    You can modify 2789us to 900us. 

profileCfg 0 60.00 2789 11 41 0 0 97.0 1 64 2200 0 0 36
profileCfg 1 60.00 20 11 41 0 0 97.0 1 64 2200 0 0 36

to

profileCfg 0 60.00 900 11 41 0 0 97.0 1 64 2200 0 0 36
profileCfg 1 60.00 20 11 41 0 0 97.0 1 64 2200 0 0 36

But you need to be aware that the shorten the frame duration will reduce the detection sensitivity slightly for this demo.

Best,

Zigang 

Hi Zigang,

Thanks, I will try it by 900 what you mentioned

Could you explain detail on ' be aware that the shorten the frame duration will reduce the detection sensitivity'?

Regards,

Kevin

Hi, Kevin:

The chirp interval basically determines the maximum ambiguous velocity and affects the velocity resolution.   In general, longer chirps gives you smaller velocity resolution, i.e., you will be able to detect smaller movement. 

Best,

Zigang