AWRL6844: Getting raw data from DCA1000 in real time

[Nasrudin78]

Hi all,
I've posted a thread in texas instruments forum regarding the raw data acquisition using DCA1000, but I wanted you, as creators of this awesome library, if you can help me to parse the data correctly for the AWRL6844 Ti radar sensor with DCA1000.
The thread is published at https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1499272/awrl6844-getting-raw-data-from-dca1000-in-real-time

Please , ignore Option 1 that is more focused using their fpga tools to wake up DCA1000 and LAN. I'm interesting on Option 2 which uses your API. The problem comes, when I send the cfg via uart to 6844 and wake up DCA1000 with your API, I'm always receiving the same constant packet shape ( "data" is 393216 of uint16 type). My guess is that I have to change ADC_PARAMS accordingly to cope with the cfg for this sensor. More precisely, as : ADC_PARAMS = {'chirps': 64, 'rx': 4, 'tx': 4, 'samples': 256, 'IQ': 2, 'bytes': 2} within the adc.py .
Is it correct for my cfg file ?

Doing in this way, the DCA1000().read functionality will work as expected and then apply doppler, range fft , cfar, bla bla pipeline from your API?
Thanks a lot
BR,
Alberto

[loeens]

I am obviously not the creator of this repo, but as you can see in adc.py the number of uint16 values is calculated as such:
BYTES_IN_FRAME = (ADC_PARAMS['chirps'] * ADC_PARAMS['rx'] * ADC_PARAMS['tx'] * ADC_PARAMS['IQ'] * ADC_PARAMS['samples'] * ADC_PARAMS['bytes'])

This means for you, that you have 64 * 4 * 3 * 2 * 256 * 2 / 2 =393.216 uint16 values, where each ADC sample is made up of two uint16 values (because of real and complex parts). This leaves you with 196.608 ADC samples per frame.

All what you have to do then is structure it properly, which presumably works with the organize() function:
frame = DCA1000.organize(adc_data, 64, 4, 256)

And after that you should be able to perform the subsequent signal processing steps.

[Nasrudin78]

Thanks for the reply ,
What we checked is that the data shape returned by DCA1000 is 524288 . Then if we organize the data as you pointed:
frame = DCA1000.organize(adc_data, 64, 4, 256) it's not working because there is a least common multiple of 8 ( 524288/ 64 / 4 / 256 = 8). The only thing that works is doing a previous reshape (4,-1) but we don't know if it makes sense or not. What's your guess?

for i in range(20):
data = dca.read()
data = data.reshape(4, -1)
result = np.apply_along_axis(DCA1000.organize, 1, data, num_chirps=64, num_rx=4, num_samples=256)

Thanks a lot!

[loeens]

Sorry, my mistake, I got the 6843 and 6844 mixed up (3 TX antennas vs. 4 TX antennas). Also, I don't know why I didn't notice yesterday, the ADC_PARAMSare the issue. The chirpsparameter doesn't refer to the number of chirps per frame, but instead refers to the number of chirp loops, meaning the number of chirps each TX antenna emits. The name of the variable is misleading in my opinion.
This means number of chirp loops = number chirps per frame / number TX antennas. In your case it is 64 / 4 = 16.

So your frame is made up of 16 * 4 * 4 * 2 * 256 * 2 / 2 = 131.072 uint16 values.

Your organize() call stays the same (here the num_chirpsparameter actually refers to the number of chirps per frame): frame = DCA1000.organize(adc_data, 64, 4, 256)

The number of ADC samples are calculated in the function as (len(raw_frame) // 2 and finally reshaped into ret.reshape((num_chirps, num_rx, num_samples)).
So 131.072 // 2 = 65.536 complex-valued ADC samples and which are reshaped into 64 * 4 * 256 = 65.536 => All good.

Good luck with your project! :)

[Nasrudin78]

Hi, nice.
So , I need to change the default ADC_PARAMS = {'chirps': 64, # 32
'rx': 4,
'tx': 4,
'samples': 256,
'IQ': 2,
'bytes': 2}

in adc.py ? Or there is an easy way to set "chirps" = 16 ? without modifying original code? After this, I let frame = DCA1000.organize(adc_data, 64, 4, 256)

as it is, and the it should work?

Thanks in advance!

[loeens]

Yeah, you need to modify it, no idea why it wasn't parameterized in the beginning. Problem is, that this repo seems unmaintained, which really is a shame. I'd love to contribute to this project with PRs, but don't see any point in it, as none of the code in the main branch has been modified in the last 5 years.

Anyway, in your case you need to edit it as such:

ADC_PARAMS = {'chirps': 16
              'rx': 4,
              'tx': 4,
              'samples': 256,
              'IQ': 2,
              'bytes': 2}

[Nasrudin78]

Ok, I have this code , does it make sense for plotting range-doppler?
taking into account above instructions?
BR.

plt.ion()  # Enable interactive mode for dynamic plotting

# Set up the plot
fig, ax = plt.subplots(figsize=(10, 6))
initial_data = np.zeros(( 256,16))
im = ax.imshow(initial_data, aspect='auto', cmap='viridis')
plt.xlabel('Doppler Bin')
plt.ylabel('Range Bin')
plt.title('Range-Doppler Map')
cbar = plt.colorbar(im, ax=ax, label='Amplitude')
 
for i in range(20):
    print(f"Frame {i}")
    dca._send_command(CMD.RECORD_START_CMD_CODE)
    data = dca.read()
    frame = DCA1000.organize(data, 64, 4, 256)
    radar_cube = dsp.range_processing(frame, window_type_1d=Window.BLACKMAN)

    det_matrix, aoa_input = dsp.doppler_processing(radar_cube, num_tx_antennas=4, clutter_removal_enabled=True, window_type_2d=Window.HAMMING)
    det_matrix_vis = np.fft.fftshift(det_matrix, axes=1)

    im.set_data((det_matrix_vis / det_matrix_vis.max()))
    im.set_clim(vmin=det_matrix_vis.min(), vmax=1)  # or use data min/max
    plt.draw()
    plt.pause(0.1)

    dca._send_command(CMD.RECORD_STOP_CMD_CODE)
 
dca._send_command(CMD.RECORD_STOP_CMD_CODE)

plt.ioff()
plt.show()

[loeens]

I can't go through your code line by line, but I can point out two things:

• the dca._send_command(CMD.RECORD_START_CMD_CODE) you only need if you aren't triggering this via mmWave Studio. Also if you would want to use this command instead of triggering via mmWave studio, it should only be called once before the loop (but it won't entirely replace mmWave studio).
• you are doing everything (receive UDP packets, DSP, visualize) in one loop. This is fine as long it is not so computational intensive as it may be now, but just as a small note, it may become an issue when performing more and more DSP steps and especially more visualizations. While you are performing DSP operations (not the huge issue in this case as it is only 1-2 ms) and visualizing (this may become an issue), you aren't listening for packets, potentially causing for lost data, if your framePeriodicity isn't large enough. So what I personally would do once you run into that issue is separate everything into their own threads/processes.

This is just my personal understanding of things, I could be wrong though. Apart from that your code looks good to me. You'll just have to do your own trying around and refer to the examples in the demo directory of the repo. In realtime.py they also calculate range doppler btw.

[Nasrudin78]

Yes, we are trying to replace mmwave studio to do it at runtime -not online- (for that , we send previously via UART the .cfg sensor parameters before calling your API). We are aware of the computational cost, but it's only a first approach for us.
Thanks a lot, I appreciate your answers
BR,
Alberto

[loeens]

Ah ok, I see. It also is possible to not use mmWave Studio entirely as you probably have already noticed, I do it myself.

As I find it quite hard to find documentation of TI sometimes, I want to share the path: ti/mmwave_studio_04_01_00_06/mmWaveStudio/ReferenceCode/DCA1000/Docs/TI_DCA1000EVM_CLI_Software_DeveloperGuide.pdf (I run Ubuntu and used Wine to install mmWave Studio just to get the docs). This document shows exactly how each command data packet is structured, which parameters each command has and so on.

Someone also mentioned the hex-string here which needs to be changed, although the hex-string contains config which for example is different for my board (IWRL6432): #17 (comment)

[Nasrudin78]

very much appreciated!

[loeens]

One more thing, since you are actively working with this repo: I want to point out that I encountered the same issue as described in #56 (only half the frame rate) plus slightly corrupted data. I created a pull request #75 yesterday which should fix these two issues. So if you run into one of the issues, you can just replace the adc.py with the fixed one. If you do so, it would be great if you could comment on the issue if it worked for you or not.

Edit: Based on my assumption you will most probably run into this issue when using the ADC parameters you mentioned here (65536 % 1456 != 0). So it would be interesting to hear your feedback if you have this issue and if the PR fixes it.

[LadiAdeoluwa]

Yeah, you need to modify it, no idea why it wasn't parameterized in the beginning. Problem is, that this repo seems unmaintained, which really is a shame. I'd love to contribute to this project with PRs, but don't see any point in it, as none of the code in the main branch has been modified in the last 5 years.

Anyway, in your case you need to edit it as such:

ADC_PARAMS = {'chirps': 16
              'rx': 4,
              'tx': 4,
              'samples': 256,
              'IQ': 2,
              'bytes': 2}

If you are looking to collaborate and create a new repo, where we solve some of these issues I would be very interested

[loeens]

@LadiAdeoluwa thank you for your offer! I have thought about it, but as I am currently working on my Bachelor's Thesis, I don't really have the time to create a new repo.

[Nasrudin78]

Thanks for your reply,
As soon as we can check , I'll come back to you.
Thanks again for your support.