search

PreSenseRadar / OpenRadar

An open source library for interacting with and processing radar data, specialized for MIMO mmWave radars
Apache License 2.0
588 stars 197 forks source link

real time data loader, does this data loader actually rob data from mmwavestudio? #45

Open jrzhang1218 opened 2 years ago

jrzhang1218 commented 2 years ago

Hi, proof1

I have tried the data loader to capture data in real time, however, the number of frames received by mmwavestudio is actually quite larger than by this Python dataloader. For example, I used "1TX, 4RX, 256 ADC samples per second, 128 chirps per loop" and trigger frames for 12 seconds, the number of frames captured by mmwavestudio is actually 259 but the number of frames by Python dataloader is only 35. I also checked the excel log file (screenshot provided) which indicates that there were some packets missing when Python dataloader is used at the same time when mmwavestudio is triggering frames. If I only use mmwavestudio to capture data, then all packets are received in sequence. I also check when we fix the number of frames to be a exact number, for example 20, everytime if mmwavestudio triggers frames together with dataloader, the mmwavestudio will be stuck. I am not a profession in device communication, may I know whether this is caused by UDP, since there are two receivers at the same time( mmwavestudio save a bin file and adc dataloader save some frames), they are actually disturbing each other? Looking forward to your reply! Thank you!

girishvn commented 2 years ago

Hi Jiarui,

Did you ever end up figuring out what was happening? I am running into the same issue, and also suspect the issue has to do with multiple receivers over UDP.

I am considering increasing the packet delay (as described here https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/779361/dca1000evm-tcp-option .

I am also considering using a slightly faster computer. I'm wondering if its a clk speed issue since I am running on a fairly old machine.

jrzhang1218 commented 2 years ago

Hi Jiarui,

Did you ever end up figuring out what was happening? I am running into the same issue, and also suspect the issue has to do with multiple receivers over UDP.

I am considering increasing the packet delay (as described here https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/779361/dca1000evm-tcp-option .

I am also considering using a slightly faster computer. I'm wondering if its a clk speed issue since I am running on a fairly old machine.

Hi, I did find out that the dataloader can work perfectly and all packets have been received by DCA1000() instead of mmwave studio data bin file. The only problem is that once one frame data is received and passed to post processing, next certain frames may be lost because they are not saved and overwritten by new received frame. My current solution is that I will adjust the frame buffer bigger such that it can receive and save all packets continuously without losing.

ekurtgl commented 1 year ago

Hi Jiarui, Did you ever end up figuring out what was happening? I am running into the same issue, and also suspect the issue has to do with multiple receivers over UDP. I am considering increasing the packet delay (as described here https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/779361/dca1000evm-tcp-option . I am also considering using a slightly faster computer. I'm wondering if its a clk speed issue since I am running on a fairly old machine.

Hi, I did find out that the dataloader can work perfectly and all packets have been received by DCA1000() instead of mmwave studio data bin file. The only problem is that once one frame data is received and passed to post processing, next certain frames may be lost because they are not saved and overwritten by new received frame. My current solution is that I will adjust the frame buffer bigger such that it can receive and save all packets continuously without losing.

Did this resolve your issue? I am also facing the same problem which makes the repository unusable. I don't think it's because of the machine itself as we can get all the ADC samples using mmWave studio. Changing BYTES_IN_FRAME didn't help either. I was having the same problem in the CLI method provided by TI, and increasing the number of ADC samples to 512 insteaf of 256 in the .cfg file solved my problem, however CLI is still not a real-time method.

I want to utilize this framework, but simply changing the buffer size didn't help much. I was wondering if there is a way to capture the live stream from the CLI's receiver module.