Linux/DCA1000EVM: AWR1843BOOST+DCA1000EVM Detection algorithm, Profiles, Calibration, and BPM Processing

Erlik,

If you are planning on using the AWR1843BOOST + DCA1000EVM with mmWave Studio, then you will need a Windows PC in order to do that. mmWave Studio has only been released for Windows and there are no current plans for a Linux release.

You can download the latest version of our mmWave SDK here: http://software-dl.ti.com/ra-processors/esd/MMWAVE-SDK/latest/index_FDS.html

You can take a look at the MRR demo leverage the chirp provided in the lab to cover longer ranges as specified in your thread: http://dev.ti.com/tirex/explore/node?node=AObIl5yAPR-DjIwxgdgyuA__AocYeEd__LATEST

Regards,
Kyle

Hi,

mmWave Studio is not supported for Linux.

It seems that you are using a customer setup. We are not able to provide support for ROS and other components not used in our demos.

We can provide you support for the chirp configuration and other related information.

Which SDK do you have in mind.

The mmWave SDK supports the AWR1843 device. It does not include matlab code

Thank you

Cesar

Kyle,

Thanks for the quick reply.

Regarding Processing pipeline and CFAR, we will look into mmWave-SDK to see if it contains everything we need.

We will try to use the suggested configuration in http://dev.ti.com/tirex/explore/node?node=AObIl5yAPR-DjIwxgdgyuA__AocYeEd__LATEST to see if it will function well. And we will write about our findings here. Do you think this configuration works with DCA1000?

Lastly, do you have any suggestions regarding the Calibration and BPM-MIMO modes?

Hi,

We have flashed "xwr18xx_demo.bin" from mmWave-SDK 3.02 to the sensor.

We have used the MRR parameters from the following table as the SRR and USRR are not usefull for us.

The detailed parameters are listed in this .cfg file:

% ********** Main Parameters ****************
% User Description: ti MRR Range 125m doppler 63kmph
% Frequency (GHz): 77
% Maximum unambiguous Range (m): 138.87500000000003
% Range Resolution (m): 0.27775000000000005
% Maximum Radial Velocity (m/s): 17.63124676818665
% Maximum Radial Velocity (km/h): 63.47248836547194
% Radial velocity resolution (m/s): 0.1377441153764582
% Radial velocity resolution (km/h): 0.4958788153552495
% Frame Duration (msec): 100
% Number of Frames: 0
% Number of Transmitters: 2
% Number of Receivers: 4
% **********************************************

% ********** Secondary Parameters ****************
% Number of ADC Samples: 500
% Number of chirps per loop: 128
% ADC Start Time (usec): 6
% ADC Sample rate (ksps): 11110
% Chirp Slope (MHz/usec): 12.0
% Chirp Idle Time (usec): 10
% Chirp Ramp End Time (usec): 45
% Transmitters to enable (binary index): 101
% Receivers to enable (binary index): 1111
% **********************************************

sensorStop
flushCfg

dfeDataOutputMode 1
channelCfg 15 5 0
adcCfg 2 2
adcbufCfg -1 0 1 1 1
profileCfg 0 77 10 6 45 0 0 12.0 1 500 11110 0 0 30
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 4
frameCfg 0 1 128 0 100 1 0
lowPower 0 0
lvdsStreamCfg -1 0 1 0

% Post-Processing Parameters
guiMonitor -1 1 1 0 0 0 1
cfarCfg -1 0 2 8 4 3 0 15 1
cfarCfg -1 1 0 8 4 4 1 15 1
multiObjBeamForming -1 1 0.5
clutterRemoval -1 0
calibDcRangeSig -1 0 -5 8 256
extendedMaxVelocity -1 0
compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
measureRangeBiasAndRxChanPhase 0 1.5 0.2
CQRxSatMonitor 0 3 4 35 0
CQSigImgMonitor 0 31 4
analogMonitor 0 0
aoaFovCfg -1 -90 90 -90 90
cfarFovCfg -1 0 0 138
cfarFovCfg -1 1 -17 17

In these settings, sensor works only if we reduce number of samples per chirp to 256 (original 500) and reduce number of chirps to 64 (original 128).

Could you please take a look at the parameters being used and suggest a solution for this issue.

Thanks

Hi,

For MRR you will need to use the configurations provided with the demo.

The numbers provide in the tables are based on a processing chain without clustering and tracking.

Thank you

Cesar

As far as we know, the "xwr18xx_demo.bin" we used does not include clustering and tracking in its processing chain.

We got the chirp configurations from this pdf http://www.ti.com/lit/an/swra553/swra553.pdf . We are not currently using the MRR demo, as it seems to require a Windows machine. Would the MRR demo work with the DCA1000EVM capture board? If so how? We only need to output the raw data over the LVDS channel, and we can handle the rest.

Thank you

Hi,

There is some confusion. The process to capture raw data does not require to flash a binary on the target. You should not flash "xwr18xx_demo.bin"

Please follow directions in this video training

training.ti.com/dca1000-training-video

Thank you

Cesar

Hi,

Since we are using Ubuntu as our OS, we do not have access to mmWaveStudio for our main capture pipeline, though we can use Windows to test the board and its configurations. However, we have already managed to use the demo binary in combination with our own Python script to get raw data from the AWR1843+DCA1000EVM on Ubuntu.

The demo binary seems to have some limitations, as settings that work properly when using mmWaveStudio do not allow the AWR1843 to start capture properly when using the demo binary. Using the config file attached before, we do not get a "Done" response from the AWR1843, and it does not start frame capture.

Since we can take care of programming the DCA1000EVM board ourselves, we only need a binary image for the AWR1843 that will function with the appropriate radar parameters while sending data out over the LVDS lane. Could you provide this to us?

Alternatively, we would need to figure out which issue is preventing our current configuration from functioning with the latest demo binary. Could you suggest a fix for this issue?

Thank you,
Erlik

Thank you

I think I understand now what you are trying to do.

Your question is basically why the mmwave SDK 3.2 demo does not work with the MRR configuration mentioned above.

The reason for that is that the mmwave SDK demo was designed to showcase as many features as possible of the mmwave sensor. For that reason it includes a lot of buffers that can be exported to the host to display in the GUI or save to a file

Because of this, some of the memory is dedicated to these buffers.

There is not enough memory to support the MRR use case mentioned above.

You would need to use the MRR demo I mentioned before for this type of use case.

thank you

Cesar

Hi,

As far as we can tell from looking at the MRR demo from the Automotive Toolbox Labs, turning on the LVDS setting in the included binary file would send partially processed data to the DCA1000EVM. Could you confirm this?

If this is correct, could you recommend a way of modifying the DSS/MSS source files to stream raw ADC data over the LVDS lanes?

Thank you,

Erlik