• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 518 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: DCA1000EVM&IWR1642BOOST

user6021183
Prodigy 40 points
Part Number: IWR1642BOOST
Other Parts Discussed in Thread: DCA1000EVM, , IWR1642

I use IWR1642BOOST&DCA1000EVM to capture raw data by mmwave_sdk rather than mmwave studio. 

In FrameCfg, I find that IWR1642BOOST can only work when 'loopNum'  is no more than 64. If 'loopNum' is more than 64, IWR1642 could not transmit signals. I am sure that duty cycle is less than 100%. Is it any possible limit about the number of chirp loops? What should I do? Thank you!

  • 0
    TI__Mastermind 38025 points

    Hi,

    Can you describe how you use mmwave SDK to capture raw data with IWR1642Boost + DCA1000?   

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Prodigy 100 points

    Hello Zigang,

    Thanks for your quick reply. I'm one of the colleagues of the consumer who posted this thread.

    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. 

    What puzzled us was that the loopNum field in the configuration file is constrained by anonymous factors. When the loopNum is larger than specific threshold (64 in his case and 160 in my case), IWR1642BOOST fails to send signals and DCA1000EVM fails to capture packages. So, what have we missed when setting the sensor parameters?

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

    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

    Thanks.

    Eson

  • 0 in reply to Eson John
    TI__Mastermind 38025 points

    HI, there:

    With SDK demo code, the radar cube is saved in L3 memory.  There is a limitation of that memory.   The radar cube size is decided by:  numAdcSample * numTXAnt * numRXAnt * 4 * numLoops

    You can check whether you reach the maximum L3 memory size, which is 640K is iwr1642.

    But data capture with radar studio does not have the same limitation.  

    Best,

    Zigang