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.

AWR1243BOOST: Advanced frame configuration, data acquisition fails.

Part Number: AWR1243BOOST

Hi, TI experts!

I'm trying to test advanced frame configuration with AWR1243BOOST + DCA1000 and mmWave Studio but have met the difficulties.

Test configuration combine four subframes each of which comprises only one burst.

- 1 subframe has a three chirps (0, 1, 2) burst which is looped 128 times, total burst duration is about 14,5 ms (3 chirps duration*128);

- 2 subframe has a three chirps (3, 4, 5) burst which is looped 128 times, total burst duration is about 14,5 ms (3 chirps duration*128);

- 3 subframe has a one chirp (6) burst which is looped 128 times, total burst duration is about 7,0 ms (chirp duration*128);

- 4 subframe has a one chirp (7) burst which is looped 128 times, total burst duration is about 5,0 ms (chirp duration*128).

According to Radar Interface Control and SWRA533 it is needed additional time for next burst triggering (InterBurstBlankTime >= 100 us), and also we need to add InterSubFrameBlankTime >= 100 us for subframe period. In attached configuration additional blank time for burst period is slightly more than 500 us, and about 1000 us for subframe period, - so the timing requirements is seemed to be met, and mmWave Studio reporting "passed" for all configuration steps. But frames acquisition fails after a while (several seconds or minutes depending on configuration). "data_transfer_prg" led on DCA board stops blinking and stays green, no other led is on. This fail is not depend on data bitrate and occur any time I start data acquisition.

Could you look through attached configuration and say if it has any bugs?

Thanks,

Timur

  • Hello Timur,

    Sorry for the delay. Now regarding your query, have you checked the captured data file size? Does it match with your configuration? If not, are you able to figure out the number of chirps/bursts captured successfully?

    Regards,

    Ishita

  • Hello Ishita.

    Yes, captured data file size matches with my configuration. For example, if I set frames number to 8, then all 8 frames are captured correctly (not for every configuration). However, I'd like to capture data continiously, so I set frames number to 0. At this case number of frames captured successfully is configuration-dependent value, it can be tens (usually) or hundreds (for very few configurations), or frames acquisition fails at once.

    Thank you,

    Timur

  • Hello Timur,

    Have you tried the Continuous stream capture as well? It is recommended to use this if you want to capture data continuously. You could refer to our FAQ page for some details on this (also produced below for your reference).

    Please check and see if you're observing the same behavior with DCA1000 here as well.

    Regards,

    Ishita

  • Hello Ishita,

    Advanced frame configuration is object of my interest, so I meant a continuous frame sequence, not a Continuous stream in terms of mmWaveStudio, sorry for confusion. I haven't try Continuous stream mode (can't find any guide clarifying ContStream tab in mmWaveStudio and default setup fails). However I've tryed each of four subframes in my configuration (profile/chirp) to be run in simple frame mode (frame number = 0) and there were no any fails.

    Thank you,

    Timur

  • Hello Timur,

    So if I understood your issue correct, you're saying the frame acquisition either stops abruptly (after a few frames, depending on configuration) or fails if you try to capture infinite frames (i.e. num_frames = 0) using advance frame config. But if you to try to capture individual subframes using legacy frame, it works well and the capture doesn't stop. 

    Is that correct?

    Also, one more question : when you say the frame acquisition fails, what error message is displayed on the mmWave Studio output window?  

    Regards,

    Ishita

  • Hello Ishita,
    Yes, your understanding is correct. Several messages of the mmWave Studio before capturing stops:
    [12:41:51] [RadarAPI]: RECORD_START_CMD_CODE Async event recieved(5)
    [12:41:52] [RadarAPI]: ar1.StartFrame()
    [12:41:52] Frame start async event received!
    [12:41:52] [RadarAPI]: Status: Passed
    [12:43:01] [RadarAPI]: STS_RECORD_COMPLETED Async event recieved(8)
    [12:43:01] [RadarAPI]: ar1.CaptureCardConfig_StopRecord()
    [12:43:01] [RadarAPI]: Status: Passed
    [12:43:01] [RadarAPI]: RECORD_STOP_CMD_CODE Async event recieved(6)
    Thank you,
    Timur
  • Hello Timur,

    Could you please provide information on a couple of things mentioned below:

    1. In the above log, the capture stopped after almost 70 seconds. Can you tell the file size of the captured file?

    2. Also, if you have data for any of your previous captures saved, could you see if all of them have the same or different size? (assuming you have data for various configs)

    3. Could you also share your cf.json file present in the postproc folder of mmWave studio?

    Regards,

    Ishita

  • Hello Ishita!

    Your questions bring some new details. I have two setups (AWR_EVM + DCA + mmWaveStudio), the first setup's mmWaveStudio version is 1.0.0.0 and the second one's version is 2.0.0.2. I've tried both.
    But first information on your query.
    1. Unhappily I haven't save this file but I remember there were about 5-7 files (1 Gb each one). Datastream rate ~ 700 Mbps (according to Windows taskmanager), it matches with my configuration.
    2. Data for previous captures saved have different size even for the same configs (also for various configs) and for the same mmWaveStudio version. Most commonly data captured with mmWaveStudio version 1.0.0.0 have larger size.
    3. I've update mmWaveStudio to version 2.1.1.0, so attaching cf.json file.
    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/cf.7z
    And some more updates on my part due to mmWaveStudio version 2.1.1.0.
    a) I run my configuration with new version of mmWaveStudio and it works well for 8 minutes (about 40 GB data captured) after that acquisition fails (there was a plenty of free disc space).
    b) I run all the same and then close mmWaveStudio after acquisition starts (watching the data transfer with Windows taskmanager), data transfer continues more then hour, while I stop it by myself.
    I'll continue experimenting next day.
    Thank you,
    Timur.
  • Hello Timur,

    Glad to hear that it works on mmWave studio 2.1.1.0.

    I would request you to do a couple of more tests with different configurations fin order to be 100% sure that it works. 

    Regards,

    Ishita

  • Hello Ishita!
    Sorry for long silence, I wasn't able to make any conclusion. And today the matter is a little bit weird but hopeful. It seems to me that I do nothing different from my preceding actions, however in the last days capturing with different configurations works well. I'm going to keep experimenting for some time because few days ago there were fails on mmWaveStudio version 2.1.1.0.
    By the way, Ishita, can you confirm the correctness of my undersdanding of the BurstPeriod and SubFramePeriod. Do this values are the durations of burst and subframe accordingly? And does the next subframe trigger right at the moment SubFrametStart + SubFramePeriod (and the same for burst)?
    Thank you,
    Timur.
  • Hello Timur,

    Sorry for the delay from my part as well. It was a long weekend.

    - So yes, let us know if you face similar issues again. Just make sure your the mmWave studio and DCA FPGA Firmware are up to date. 

    - Yes your understanding is correct and as of now, your burst and sub frame periods look good to me. I hope you have also referred to the mmWave DFP user guide to understand about Advance Frames in detail. That document has a good explanation about timings.

    Regards,

    Ishita

  • Hello Ishita,

    There are stable configs, I'll use it for a time. Thank you for your help.

    Regards,

    Timur