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: Sensors forum

Part Number: IWR1642BOOST
Other Parts Discussed in Thread: DCA1000EVM, IWR1642

Currently, we are using IWR1642BOOST+DCA1000EVM to capture raw data with custom applications.

For DCA1000EVM, we are using the DCA CLI program provided in C:\ti\mmwave_studio_02_01_00_00\mmWaveStudio\ReferenceCode\DCA1000\ to record raw data.

For IWR1642BOOST, we flashed mmWave Demo image provided in C:\ti\mmwave_sdk_03_03_00_03\packages\ti\demo\xwr16xx\mmw into the sensor board and set the board to SOP-4 mode before power-cycle (reboot). We then successively send configuration commands to IWR1642 by COM port. The sample configuration file can be found at C:\ti\mmwave_sdk_03_03_00_03\packages\ti\demo\xwr16xx\mmw\profiles, but we customized the configuration by our needs. 

We use both the above method and mmwave studio to capture raw data to measure the distance of objects. We perform FFT on the collected raw data, and the results are below. The first figure is obtained by above method and the second figure is obtained by mmwave studio. Through the FFT result by mmwave studio, we could calculate the correct distance of the target. But through the FFT results by above method, we could not calculate the correct result. We find that the FFT result is reserved in the first figure. If I reserve the order of the FFT results, I would gain the right result. Is it some different part between different data capture method? Or may I make  some mistakes in the configuration file? Thank you! 

The below provides the configuration file we used for IWR1642 configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
sensorStop
flushCfg
% 1:frame based chirps, 2:continuous chirp, 3:adv frame config [1/3]
dfeDataOutputMode 1
%* <rxChanEn><TxChanEn><0(cascading)>[15][x][0]
channelCfg 15 1 0
%* <numADCBits 0:12bit,1:14bit,2:16bit>[2]
% <adcOutputFmt 0:real,1:complex1,2:complex2>[1/2]
adcCfg 2 1
%* <subFrameIdx>[-1]
% <adcOutFmt 0:Complex,1:Real>[0]
% <sampleSwap 0:I in LSB Q in MSB,1 otherwise>[1]
% <ChanInterleave 0:Interleaved,1:NonItl>[1]
% <ChirpThreshold..MUST be 1 for LVDS>[1]
adcbufCfg -1 0 1 1 1
%* <profID> <startFreq:GHz> <ideleTime:us> <adcStartTime:us>
% <rampEndTime:us> <txOutPower>[0] <txPhaseShift>[0]
% <freqSlopeConst:MHz/us> <txStartTime:us> <numAdcSample>
% <digOutSampleRate:ksps>
% <hpfCornerFreq1 0:175KHz,1:235,2:350,3:700>
% <hpfCornerFreq2 0:350KHz,1:700,2:1400,3:2800>
% <rxGain>
profileCfg 0 77 10 6 47 0 0 85.069 0 256 6250 0 0 30
%* <startIdx> <endIdx> <profID>
% <startFreqVar>[0] <freqSlopeVar>[0] <idleTimeVar>[0]
% <AdcStartTimeVar>[0] <txEnableMask>
chirpCfg 0 0 0 0 0 0 0 1
%* <startIdx> <endIdx>
% <loopNum>[should be 4x] <frameNum> <framePerio:ms>
% <trigSel 1:Software,2:Hardware>[1] <frameTrigDelay:ms>
frameCfg 0 0 160 0 50 1 0
%* <Ignored>[0] <AdcMode 0:Regular,1:LP Mode>
lowPower 0 1
% <subFrameIdx For Demo Visualizer,streamed on UART not LVDS>[-1]
% <detectedObj 0:disable,1:enable Point Cloud&side info,2:enable PC>
% <logMagRange 0:disable,1:enable>
% <noiseProf 0:disable,1:enable>[0]
% <rangeAziHeatmap 0,1>[0]
% <rangeDFSHeatmap 0,1>[0]
% <stasInfo 0,1>[0]
guiMonitor -1 1 1 0 0 0 0
% Must be two lines
cfarCfg -1 0 2 8 4 3 0 15 1
cfarCfg -1 1 0 4 2 3 1 15 1
% <> <enabled>[0] ...
multiObjBeamForming -1 0 0.5
% <> <enabled>[0]
clutterRemoval -1 0
% <> <enabled>[0] ...
calibDcRangeSig -1 0 -5 8 256
% <> <enabled>[0]
extendedMaxVelocity -1 0
% <> <enabled>[0] ...
bpmCfg -1 0 0 1
%* <subFramIdx>[-1] <enableHeader 0,1>[0]
% <dataFmt 0:HW disable,1:ADC,2:CP_ADC_CQ>[1] <enableSW 0,1>[0]
lvdsStreamCfg -1 0 1 0
% <rangeBias> <I/Q Bias compen for 2Tx*4Rx>
compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
% <disable compRangeBiasAndRxChanPhase>[0] ...
measureRangeBiasAndRxChanPhase 0 1.5 0.2
CQRxSatMonitor 0 3 5 121 0
CQSigImgMonitor 0 127 4
% <disable CQRxSatMonitor 0,1>[0] <disable CQSigImgMonitor 0,1>[0]
analogMonitor 0 0
% <subFrameIdx>[-1] <minAzimuthDeg> <maxAzimuthDeg>
% <minElevationDeg> <maxElevationDeg>
aoaFovCfg -1 -90 90 -90 90
% <subFrameIdx>[-1] <0:range,1:Doppler>
% <min> <max>
cfarFovCfg -1 0 0 8.92
cfarFovCfg -1 1 -1 1.00
sensorStart
  • Hi Guidong,

    We have assigned this to the relevant expert and they should respond back to you next week. Thanks for your patience.

    Regards

    -Nitin

  • Hi, GuiDong:

    Your configuration looks good to me. 

    The ADC raw data have a special data format, it is described in radar studio users guide.  If you did not interpolate correctly, you will have wrong range profile.   Maybe your real and imaginary order is wrong.  Or something else.

    Can you double check your script on data loading?  An example is listed below for iwr1642

    % through xwr1642+ DCA1000, radar_data has data in the following format
    % Rx0I0, Rx0I1, Rx0Q0, Rx0Q1, Rx0I2, Rx0I3, Rx0Q2, Rx0Q3, ...
    len = length(dataChunk) / 2;
    adcOut(1:2:len) = dataChunk(1:4:end) + 1j*dataChunk(3:4:end);
    adcOut(2:2:len) = dataChunk(2:4:end) + 1j*dataChunk(4:4:end);

    Best,

    Zigang

  • Hello, Zigang,

    Thank you for your reply!

    I have already check the script on data loading, and I have not found something wrong. Actually, I use the same script on the data captured both from mmwave studio and DCA CLI program. The FFT result by mmwave studio is correct and result by DCA CLI program is wrong. 

     The code on data loading is below. 

    %file_path is the path of .bin file.
    %The capture data is in 'collect_data',the row is the number of chirp and
    %the column is the number of Rx, the default is 4.
    frame_sample_rate=256;
    chirp_data_number=frame_sample_rate*8;
    fid=fopen(file_path,'rb');
    yy=fread(fid,'short');
    data_length=length(yy);
    chirp_number=size(yy,1)/chirp_data_number;
    sub_data_length=data_length/4;
    collect_data=zeros(sub_data_length/2,4);
    B=reshape(yy,[],chirp_number);

    for ii=1:chirp_number
    target_chirp=B(:,ii);
    target_chirp2=reshape(target_chirp,[],4);
    for jj=1:4
    for kk=1:chirp_data_number/(4*4)
    temp(2*kk-1,jj)=target_chirp2(4*kk-3,jj)+1j*target_chirp2(4*kk-1,jj);
    temp(2*kk,jj)=target_chirp2(4*kk-2,jj)+1j*target_chirp2(4*kk,jj);
    end
    end
    collect_data((ii-1)*chirp_data_number/8+1:ii*chirp_data_number/8,:)=temp;
    end

  • Hi, 

    The data collected using CLI control interface is with a different data format.  Please check page 16 at  

    C:\ti\mmwave_sdk_03_03_00_03\docs\mmwave_sdk_user_guide.pdf

    Best,

    Zigang

  • The data collected by DCA1000 CLI control interface have 32 byte of header for every chirp data received. 

    Did this solves your problem?

    Best,

    Zigang