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.

AWR1642BOOST: + DCA1000 EVM ::: disparity between mmwave Studio setting and dimensions of adcData matrix received

Part Number: AWR1642BOOST
Other Parts Discussed in Thread: DCA1000EVM

Hi,

I am using a AWR1642BOOST (ES2.0) + DCA1000 EVM + Dell Laptop running Windows 10 64-bit.

1)  I am collecting raw 2x complex ADC data through these two EVMs and I am using mmwave Studio 2.0.0.2. Following is screen shot of my mmwave Studio setting (using one Tx and two Rx) :

From above, I assume and understand that there will be 200 frames, and 32 chirps in each one frame (as number of loops is 32). The number of ADC samples is 256 and I am using 16-bit adc configuration. 

I am using the MTALB code / utility titled readDCA1000.m provided by TI for parsing the data received through DCA1000 into a matrix called adcData in my computer . This matrix has dimensions AxB , where A = Number of receivers, and B = Number of chirps.

I understand that in my above case, the number of chirps will be  =  Number of adc samples (256) x Number of chirps/ frame (32) x Number of frames (200) = 1638400. As 2 Rx are used, so the adcData matrix should have dimensions 2 x 1638400. However, the adcData matrix has dimension 2 x 3276800. The number of chirps is NOT as per my calculation, it is further more multipled by two. I tested with number of loop = 16 and result was same, i.e. the number of chirps was not as per my calculation, it was additionally multiplied by 2.

The relevant text from " adc_data_LogFile " generated at location C:\ti\mmwave_studio_02_00_00_02\mmWaveStudio\PostProc is appended below for your additional info :

09-May-2020 16:50:41: API:SensorStart,0,
09-May-2020 16:52:37: API:ProfileConfig,0,1435384036,1000,600,5714,0,0,1408,100,256,5209,0,0,30,0,
09-May-2020 16:52:39: API:ChirpConfig,0,0,0,0,0,0,0,1,0,
09-May-2020 16:52:42: API:EnableTestSource,0,1,0,
09-May-2020 16:52:43: API:FrameConfig,0,0,200,32,8000000,0,512,0,
09-May-2020 16:52:43: API:AdvancedFrameConfig,1,0,0,0,1,32,8000000,0,1,1,8000000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,200,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

2)  Can you please indicate what is wrong ? What should be the correct numbe rof chirps and hence what should be the correct dimensions of matrix adcData and why adcData is not having dimensions as per my calculation ?

My subsequent algorithm depends on number of chirps so this is critical for me.

3)   Please refer the red color command line (frameconfig) above from " adc_data_LogFile " . I assumed that this command structure would tally with Configuration Command format given under the heading of " 3.4 Configuration (.cfg) File Format "  in various mmwave sdk packages (e.g. mmwave SDK 3.2.1.2 or 3.3.0.3). However, on close examination of individual bits, I find that, particularity for the following command: 

09-May-2020 16:52:43: API:FrameConfig,0,0,200,32,8000000,0,512,0,

The structure of above command does not tally / match the structure of framecfg  command in section 3.4 of mmwave sdk 3.2.1.2 or 3.3.0.3. For example, it seems that the position of number of frames (200) and number of loops (32) is swapped in above command in red when compared with structure of frameCfg command in mmwave sdk.

3a)  Can you please advise a document that defines exact and precise structure of above API FrameConfig and other APIs used in mmwave Studio ?

3b)  What is meant by 8000000 and 512  in above API:FrameConfig ?

3c)  Are the APIs used in mmwave Studio, different than the APis used in mmwave SDKs ?

 

Thanks and regards

 

 

  • Hi, 

    Sorry for a textual mistake.

    I understand that the number of chirps will be = Number of chirps/ frame (32) x Number of frames (200) = 6400

    and the adcData matirx will have dimensions :  This matrix has dimensions AxB , where A = Number of receivers, and B = Number of chirps x Number of adc samples / chirps.

    In this case, B should be = Number of adc samples (256) x Number of chirps/ frame (32) x Number of frames (200) = 1638400. However, I am getting B = 3276800.

    In MATLAB work space, the number of chirps is additionally mutiplied by 2, It means, instead of showing 6400 chirps as above, it is showing 12800 (=6400x2) chirps.

    In addiiton, the PostProc graphical output of mmwave Studio shows correct number of frames (200) and correct number of chirps/frame (32). The following figure might help :

    I hope this further clarifies my question and removes the confusion and mistake made in description of original question.

    Thanks

  • Hi,

    Further additional info ::::::

    I tried additional combinations and found the same problem.

    Then, I tried some earlier archived DCA1000 raw adc data files  ( adc_data.bin ) files that I had. I rechecked. Earlier, the system was working fine. 

    The size of adcData matirx was as per my (and TI calculations) , which is :

    This matrix has dimensions AxB , where A = Number of receivers, and B = Number of chirps x Number of adc samples / chirps.

    and Number of chirps = Number pf frames x Number of chirps / frame

    I re-confirmed : The problem now is that that the number of chirps is further additionally multiplied by 2 which is an error.

    Earlier, the system was working perfectly fine and there was no such error. I wonder what had caused this and I wonder how it can be solved.

    The only thing NEW that I have done is that I have installed MATLAB R2020a and earlier I was using MATLAB R2019b, but I dont suspect that this has caused this problem. The old archived raw adc file ( adc_data.bin ) is giving correct results with newwe MATLAB R2020a that I recently installed.

    I have not attempted re-flashing / re-programming the DCA1000 EVM. I may do it if TI advises so or I hope TI can suggest some other (better) and easy solution.

    Regards

  • Hi,

    Further additional info ::::::

    I worked further on trying to resolve the issue at hand.

    1)  I tried re-programming DCA1000 EVM as per document DCA1000EVM Data Capture Card (spruij4a.pdf). The re-programming was successful, but the problem remained the same.

    2)  Please note that I am using mmwave Studio 2.0.0.2. I cannot upgrade to mmwave Studio 2.1.0.0. For some reason, I have not been able to get it working. I raised a question related to it on TI website but could not resolve it ( https://e2e.ti.com/support/sensors/f/1023/t/866891 ) . I tired again today but in vain. 

    3)  So, again, I am using mmwave Studio 2.0.0.2 with FPGA version 2.7. I tired another configuration as per following screen shot setting :

    4)  I found that after the first column in the PARSED adcData matix (obtained by running MATLAB script readDCA1000.m), a column of zeros in inserted alternately, between every two columns. This essentially doubles the number of columns in adcData and hence the number of chirps is doubled. The following screen shot further explains that :

    I hope the situation is more clear now, although the problem persists.

    Your valuable advice is requested.

    Regards

  • Hi,

    Further additional info ::::::

    I am working on the problem and continually adding details. I hope TI team will go successively through all details and then will extend advice. Thanks in advance for your effort and patience.

    Further more, I have managed to delete the extra POSSIBLY ERRONEOUSLY added zero columns in the adcData Matrix using MATLAB. 

    However, the whole episode is now casting doubts on the reliability and authenticity of the whole raw adc data acquired through DCA1000.

    After replying my above queries, please also comment that can I be confident that the raw adc data (after deleting the added erroneous zero columns) is fairly authentic, accurate, correct and reliable ?

    Best regards

  • Alper,

    You are missing one key element on your understanding of how large the expected ADC file size should be.

    Since you are using compelx2x mode, each ADC sample will consist of 4 bytes of data. 2 bytes constitute the real part and another 2 bytes constitute the imaginary part. That is why your calculations are off by a factor of two every time.

    This issue is addressed in the DCA1000 Debug Handbook, which you can find here: https://e2e.ti.com/support/sensors/f/1023/t/872161

    Regards,

    Kyle

  • Hi Kyle,

    Thank you for your reply and for provision of DCA1000 Debugging Handbook, I have read it after you provided it, It is really valuable document.

    1)  I already understand and upon your advice, I understand again that one adc sample in complex 2x mode covers 4 bytes of data. However I fear that this is not my issue. I am not concerned with the file size, my problem is related with number of chirps in adcData matrix. One might say that file size is related to number of chirp, however, in my case, the problem is clearly caused by insertion of redundant zero columns in adcData matrix.

    Probably I have not been able to convey my issue clearly enough earlier, therefore, I will again state my problem summarily and concisely.

    2)  Figure 1 shows the mmwave studio setting screenshot and figure 2 shows the adcData matrix. As can be  seen from figure 1, the number of chirps should be 128 ( 16 frames x 8 chirps / frames), however, as can be seen in figure 2, the number is chirps is 256. The number of chirps is doubled due to CLEAR insertion of redundant alternate zero columns as seen in figure 2. Please note that it does not relate to the fact of adc sample being 4 bytes long. 

    It can be seen that a full additional column is added after every adc sample (real + imaginary part). it can be further seen that the zero column has format of  ( 0.0000 + 0.0000 i ). So, if I am not wrong, another additional 4 bytes are added for this complex 2x (but zero) sample. This is causing the number of chirps to be (wrongly) doubled.

    I understand that number of columns in adcData matrix is = number of adc samples x number of chirps. However, in this case, I am not referring and suspecting number of adc samples as number of adc samples is same in figure 1 (mmwave studio setting) and figure 2 (adcData).

    Figure 1

    Figure 2

    3)  I really wonder where the problem is being caused, because, the Post Proc utility of mmwave studio is (apparently) showing correct results. I tried another configuration with 200 frames and 32 chirps / frame which gives total 6400 chirps ( 200 x 32 ). Figure 3 shows the mmwave studio setup and figure 4 shows the correct frames and number of chirps /  frame after Post Proc.

    Figure 3

    Figure 4

    I thought may be  zero order utility is causing problem, or may be DCA1000 is corrupting the data with insertion of zero columns. However, apparently, Post Proc is producing correct results with same data (same adc_data.bin file) while after running readDCA1000.m utility for parsing adc_data.bin, the erroneous adcData matrix is obtained with inserted zero columns.

    4)  In order to clarify my doubts mentioned in para 3 above, I tried another thing. I had an archived adc_data.bin file that was generated some days ago. I ran readDCA1000.m utility on it. Figure 5 shows the mmwave studio setup and figure 6 shows the adcData matrix MATLAB output. The number of chirps should be 256 ( 8 frames x 32 chirps / frame) as seen in figure 5 and in figure 6 adcData has correct number of 256 chirps.

    Figure 5

    Figure 6

    Note that there are no alternate redundant zero columns in figure 6 when compared with figure 2. Here lies the problem, It is not related with 4 byte size of adc sample (2x complex). Both the adc_data.bin files (for figure 2 and for figure 6) have been processed on same computer using same readDCA1000.m MATLAB utility provided by TI and same mmwave Studio 2.0.0.2 and same DCA1000 FPGA version 2.7 was used in both cases.

    Please note that, as mentioned earlier, I cannot upgrade to mmwave studio 2.1.0.0 and / or DCA1000 FPGA version 2.8.

    5)  Can you please advise what is causing this error of insertion of redundant alternate zero columns in adcData matirx  AND how this problem can be solved ?

    Please note that, earlier I was not having this problem as exemplified with figure 6. Only a few days ago, this problem arose i.e. insertion of zero columns.

    6)  Further more, I have managed to delete the extra POSSIBLY ERRONEOUSLY added zero columns in the adcData Matrix using MATLAB. 

    However, the whole episode is now casting doubts on the reliability and authenticity of the whole raw adc data acquired through DCA1000.

    After replying my above queries, please also do comment that can I be confident that the raw adc data (after deleting the added erroneous zero columns) is fairly authentic, accurate, correct and reliable ?

    Best regards

  • Alper,

    I attempted to recreate your setup this morning. It looks like when you enable only 1 TX and 2 RX antennas in the "StaticConfig" tab, mmWave Studio defaults to enabling only 1 LVDS lane.

    Based on your screenshots, it looks like you have kept the number of LVDS lanes in the MATLAB processing script set to 2. You should change this to 1 since only one LVDS lane is enabled in mmWave Studio. This would address the issue of why your data is twice the expected size and why you have alternating columns of zeroed out data since the second LVDS lane is not enabled and would not have any data.

    Keeping your setup in mind, I verified on mmWave Studio v2.0.0.2. Update your MATLAB script so that

    numLanes = 1;

    This should hopefully resolve your issue and close out this thread.

    Regards,
    Kyle

  • Hi Kyle,

    Thank you for your above reply and my apologies for being able to respond earlier as I am working on another aspect of AWR1642BOOST.

    Please do not close this thread as I do not feel that the problem is resolved yet.

    I do not think that changing LVDS lanes will correct this, because the readDCA1000.m MATLAB script has the following line

    numLanes = 2 ; % do not change. number of lanes is always 2

    However, I will act upon your advice, and will get back to you within a week hopefully.

    Thanks and regards