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: mmWavestudio 1.0 has empty data file .matlab post processing failed

Part Number: AWR1243BOOST

Hi,

I also encountered the same problem when I try to do the long-term measurement with more ADC samples.

(For the short-term test with less ADC samples, everything is OK)

I am wondering where I can modify the package delay?

Thank you very much

Yen-Pang

  • Sorry for the typo.

    What I want to ask is how to increase the packet delay.

    Thank you.

    Yen-Pang

  • Hi,

    I found the packet delay and change it to 300, but it doesn't work.

    Is there any other solution?

    Thank you very much.

    Yen-Pang
  • Hello,

    A few things to check/debug would be:
    1. Provide log/config files - for us to help effectively.
    2. Check that path of data file is valid. Has write permissions
    3. PC has no firewall issues. Try alternate PC.
    4. Number of Rx lanes and LVDS lanes for data out are the same.
    5. Change the configuration to have less samples/chirps in frame to eliminate throughput related issues.

    There are few threads on e2e.ti.com that talk about similar issues.
    Please let us know if you continue to see issues.


    Thank you,
    Vaibhav
  • Hi Vaibhav,

    The error message is shown below and it happens when I pressed "PostPorc" to get the ADC raw data.

    For the solution No. 4, I am wondering how I can use 4 RX channels since there are 2 LVDS lanes in DCA1000?

    Thank you very much. 

    Yen-Pang

  • Hello

    Can you please share your confirm that your configuration does not violate the Data transfer time needed to get the data out on LVDS.

    This would depend on the configuration you are using.  We will provide the requirement for data transfer time.

    Thank you,

    Vaibhav

  • Hello Yen,

    Please make sure that the chirp time (idle time + ramp end time) is sufficient enough to allow transferring the desired amount of chirp data on the LVDS interface as detailed below:

    1. Data per chirp = numAdcSamples * numRxChannels * 4 (size of complex sample) rounded up to multiples of 256 bytes. (Assuming you have selected ADC only data format i.e. no CP_CQ information)
    2. Chirp time Tc in us = idle time + ramp end time in the profile configuration.
    3. For n-lane LVDS with each lane at a maximum of B Mbps, maximum number of bytes that can be send per chirp = Tc * n * B / 8 which should be greater than the total amount of data generated per chirp
      1. i.e Tc * n * B / 8 >= round-up(numAdcSamples * numRxChannels * 4, 256).
    4. For example, if n = 2, B = 600 Mbps, idle time = 6 us, ramp end time = 44 us, numAdcSamples = 512, numRxChannels = 4, then
      1. Maximum data that can be sent out on 2 lane LVDS running at 600Mbps, in the given chirp time = (6+44) * 2 * 600 / 8 = 7500 bytes
      2. Data generated per chirp = 512 * 4 * 4 = 8192 bytes, which violates the timing. So you need to increase the idle time to at least 11us to be able to stream the 8192 bytes the chirp generates.

    Thanks

    -Nitin

  • Hi Nitin,

    Problem is solved.

    Thank you very much.

    Yen-Pang

  • Hi Nitin,

    There is still one thing I don't understand.

    Why the data per chirp should be rounded up to multiples of 256 bytes? 

    In your example, it seems you didn't rounded up it.

    Thanks.

    Yen-Pang

  • Hi Yen-Pang,

    The requirement to round the total output size to 256 bytes comes from the DCA1000 FPGA implementation. If you're not using the DCA1000 to capture LVDS data, the 256 byte rounding is not required.

    In my example calculation, the size of the output data i.e. 8192 is already a multiple of 256 so I did not have to explicitly round it up.

    Regards

    -Nitin