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

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

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