MMWCAS-DSP-EVM: .bin files data format

Hi Luca,

A similar topic has been discussed in the following thread -

(+) AWR2243: format of the raw bin file collected from the cascaded 2243 radar (MMWCAS-RF-EVM / MMWCAS-DSP-EVM) - Sensors forum - Sensors - TI E2E support forums

Please refer to the above thread for your query.

Regards,

Shruti

Hello,

I'm sorry to report, I read through this thread and looked deep into the PDFs mentioned, but nowhere I did find the answer I was looking for. (I may add that this thread is, indeed, not marked as solved - as neither the creator of the thread, nor me, was actually able to find the information they were looking for, which was pretty much the same thing that I needed help for.)

It's mentioned quite a lot of times how the deep internal hardware structure of the device works, together with some other details that are not directly related to the problem I'm having, but I did not find the clear answer on how those real data bytes, that I find in my .bin files after a capture, should be converted in complex numbers representing the final measure. Perhaps a quick explaination on how this works, in the context of the device I'm using, could be more beneficial.

Thanks in advice to anyone who will respond to this comment.

Let me add another question related to this topic.

Apart from parsing the data itself from raw bytes into complex values to extract the measure from, which it's a problem on its own, I was wondering how can I make this device work as a single device for itself. For example, if I have only 1 device with 2 TX antennas, and 4 RX antennas for every device (having the slaves as RX-only devices), how do my .bin files need to be parsed? Am I limited to elaborating the data separately for each cascaded device? If so, is it even possible for me to have RX-only devices, without messing up the number of virtual antennas I'm using? 

I really need to treat my radar as a unit, capable of 12 TX and 16 RX antennas, instead of a group of 4 identical devices with 3 TX and 4 RX antennas each, and right now I can't think of a good way of parsing my data like this. I may add, that my use case with RX-only antennas is kind of impossible at the moment, as separating the data parsing for devices without TX active antennas yields an impossible number of 0 virtual antennas, and I have absolutely no clue in how to work around this problem.

I hope that's something I can easily work with, and most importantly I can use my device in a context like this... it would be a real shame if I was limited in treating my radar as a group of 4 sub-units with limited capabilities, and at the moment it seems that the only problem I'm facing, that doesn't allow me to operate with this device in the way I want, is a real comprehension of the binary data encoding of the files, and the separated data elaboration I'm forced to do (and I don't want to do).

Hello, sorry for adding more and more stuff to work on, but I did find something else that doesn't really make sense, and is completely messing up my elaboration setup. I need to know as soon as possible how to fix this, because it's a problem I didn't even know of until a couple of minutes ago, but is the first of the list of problems I need to work on, in order to get back to a reliable setup for data parsing.

I was trying to reduce the values of the parameters I'm working with, to try and come up with a setup that could work for a small capture, and see how changing those values would affect the results, in order to adjust my personal setup accordingly. But what I did find by changing the Lua script parameters needs to be brought up. I don't know why it is the case, in my head it just doesn't make sense, and it kind of seems an unwanted behaviour (more like a bug than a strange feature), but the number of TX antennas activated for a setup don't seem to have any effect on the results.

I tried to use only 1 TX antenna in my device, and do the AdcConfig and ChirpConfig with only 1 active TX antenna, and the size of the .bin file returned makes sense: the data cube I'm able to parse fits the size (num_virtual_antennas * num_adc_samples * num_chirps) for a single frame. I then activated all 3 TX antennas in the AdcConfig parameters, but leaving unchanged the number of TX antennas used in the ChirpConfig, and the result didn't change; which is to be expected, as I never asked for more antennas to actually activate and transmit chirp signals. What did not make any sense, though, was seeing my file size stay unchanged even activating all the TX antennas inside both the AdcConfig and the ChirpConfig API calls. And this happens if I set the device as a Master, without Slaves connected to it, but even if I set the device as a Single-Device in the AdcConfig. Even trying to set up the device directly via mmWave Studio, instead of using custom Lua scripts, did not help at all. It doesn't matter, I can't make the data produced by the device differ in size based on the number of TX antennas.

This strange behavioiur from mmWave Studio, for me, is a real problem, because I can't even rely on the number of TX and RX antennas I'm using to extract the size of a single frame from my data capture, and parse it using an array of virtual antennas calculated on the number of TX and RX antennas from a single device. Thus, I don't even know how the number of virtual antennas I should use, in order to parse the .bin files, has to be calculated, in order to properly parse a single frame of data, and get a radar data cube of fixed size, to calculate a range-Doppler map from that RDC.

Everything seems so out of my control, starting from the setup of the Lua parameters, which does not seem to work in the way I'm expecting, to the parsing of the data, which doesn't seem to be affected by the number of virtual antennas I'm expecting to use, and moreover doesn't have a clear indication of the way I should decode the raw bytes in order to get a measure from the frame I just captured.

And I guess I'm doing something horribly wrong, or maybe some PDF sources I really need to look into are hiding from me, and I'm not able to find them. I can't imagine I'm bringing up a series of problems that are out of my control, because there's no way to make my device work in the way I'm intending because of architectural choices for the hardware design. There must be a solution, and I'm not able to find it.

Hi, I'm back again with some more discoveries. They kind of helped, but also kind of didn't.

Searching through parallel threads on the same topic, I stumbled on suggestions for looking into Matlab sources, that should be run in order to get the GUI displaying the results of a frame capture. I initially kind of discarded those threads, as my goal is to implement my data processing outside of Matlab, but being completely helpless as I was I tried anyways to find something useful. They actually showed something that I didn't think of, which is combining all the data inside a single array that I can parse, having multiple RX channels parallel to each other instead of having each frame captured from a single device after the other (I don't know why, but this didn't come into my mind).

And this is quite helpful for me, because it allows me to combine data from every device, and apply the data parsing for the radar data cube construction, considering more than 4 RX antennas (as now I have access to all the 16 channels I need). And because every device is giving me data, regardless of the number of TX antennas I'm using, it's also going to work without TX antennas for the slaves actually activating.

However, I'm still looking forward to know how I should integrate MIMO techniques to the data parsing, as my goal is to have more than 1 TX antenna sending chirps (something that, at the moment, I'm not able to do without completely breaking my setup), and most importantly how should I parse those binary values into a complex number array I can use.

Hello, it's me one more time. Just wanted to make sure this topic didn't fall short of your list. Thanks

Hi Luca,

Apologies for the delay, allow me some time to look into this query and understand your issue. I will get back to you by tomorrow.

Regards,

Shruti