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.
Hi,
I am using a AWR1642BOOST (ES2.0) + DCA1000 EVM.
1) What is the minimum value of frame periodicity in mmwave Studio. I suppose that specifications mentioned in mmwave SDK user guide apply to mmwave Studio also. Please comment if my understanding is correct. If I am wrong then please indicate a document for frame periodicity setting for mmwave studio.
If I am right, then the mmwave SDK 3.3.0.3 user guide (for example) states under heading 3.4 for framecfg / frame periodicity :
" any value as per mmwavelink doxgen and represented in msec. However frame should not have more than 50% duty cycle (i.e. active chirp time should be <= 50% of frame period). "
I found that file titled structrl_frame_cfg_t located at address C:\ti\mmwave_sdk_03_03_00_03\packages\ti\control\mmwavelink\docs\doxygen\html gives info about frame periodicity. Please confirm if I am correct. If not, then please indicate correct location for frame periodicity information in mmwavelink doxygen.
If I am correct then, structrl_frame_cfg_t reads :
rlUInt32_t | framePeriodicity |
Frame repitition period 1 LSB = 5 ns Typical range 1 ms to 1000 ms |
My basic and naive question is that what does " 1 LSB = 5 ns " imply here and how does it relate to and affect frame periodicity ?
2) 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) :
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,
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
Hello,
1) You can refer to section 5.5.3 of the mmwave radar Interface Control document (ICD) to know about the specifications and limitations of the frame config API. This document will help you know about the exact structure of all the APIs used in mmwave studio. Please find it attached. Here the minimum frame periodicity corresponds to (40000*5) ns + 1 chirp duration = 0.2ms + 1 chirp
mmWave-Radar-Interface-Control (10).pdf
3a) You can either refer to the ICD or you can use the help function in the mmwave studio to know more about a specific API.
For eg. Type "help ar1.FrameConfig()" in the lua shell, and you'll get a detailed byte wise description of this API.
3b) The "adc_data_LogFile" is in the form of a config file. The number "8000000" corresponds to your programmed frame periodicity. 1 LSB = 5ns. That means, 8000000 corresponds to (8000000 * 5 ns) = 40ms (as verified by your screenshot). 512 corresponds to the the number of ADC samples, but they're a dummy one in the frame config, and not used anywhere. ADC samples that comes with the profile config is used.
3c) On a low level, Yes, the APIs used in SDK and mmwave studio are a bit different (because in SDK, they're in the form of a config file, while in mmwave studio, it is lua scripting).The various configurable parameters are arranged in a different fashion and units to describe them, but on a High level, both of them are configuring the same parameters.
I hope you got answers to all your questions.
Regards,
Ishita
Hi,
Thank you very much for your elaborate, yet concise reply. It was very helpful. It has almost replied all my questions. But there are still a few minor issues and I request your guidance on that. I have replied in red text against you individual replies from above text :
1) You can refer to section 5.5.3 of the mmwave radar Interface Control document (ICD) to know about the specifications and limitations of the frame config API. This document will help you know about the exact structure of all the APIs used in mmwave studio. Please find it attached. Here the minimum frame periodicity corresponds to (40000*5) ns + 1 chirp duration = 0.2ms + 1 chirp
A) I refer Frame Periodicity in section 5.5.3 of Radar ICD
while you wrote (40000*5) ns + 1 chirp duration = 0.2ms + 1 chirp. I might be asking a very naive and basic question but I need to. Why you are multiplying by 5ns (1 LSB) when it is not written in line 2 of above screen shot. Moreover, as I asked earlier, what does 1 LSB = 5ns , imply here. I am familiar with basic concept of LSB (least significant bit), but please elaborate how does that relate here, or, simply, what does 1 LSB = 5ns mean here and why you multiply it with 40000. This 1 LSB = 5ns is also used in your reply to 3b down further so it concerns me there as well.
3a) You can either refer to the ICD or you can use the help function in the mmwave studio to know more about a specific API.
For eg. Type "help ar1.FrameConfig()" in the lua shell, and you'll get a detailed byte wise description of this API.
B) Your above information is really valuable. However, I am a complete novice to this lua thing and I really wish if I can continue to work on mmwave studio without learning it and so far it is working and I am able to use mmwave studio. I tried to open help and find the EXACT bit wise description of frame config API but as you can see from following screenshot, the help does not have such link. Then I entered the command help ar1.FrameConfig() (without inverted commas " " ) in the command line in lower left corner of screenshot as shown.
However, I got the following error :
(Note that I have not connected mmwave studio with radar device (AWR1642BOOST + DCA1000 ) , but i hope that does not matter here. Or does it ?
Can you please indicate exactly how can I use the help function in the mmwave studio to know more about a specific API to get a detailed byte wise description of this (and other) APIs.
3b) The "adc_data_LogFile" is in the form of a config file. The number "8000000" corresponds to your programmed frame periodicity. 1 LSB = 5ns. That means, 8000000 corresponds to (8000000 * 5 ns) = 40ms (as verified by your screenshot). 512 corresponds to the the number of ADC samples, but they're a dummy one in the frame config, and not used anywhere. ADC samples that comes with the profile config is used.
C) Understood. Your reply to my query A) above will finally resolve this.
3c) On a low level, Yes, the APIs used in SDK and mmwave studio are a bit different (because in SDK, they're in the form of a config file, while in mmwave studio, it is lua scripting).The various configurable parameters are arranged in a different fashion and units to describe them, but on a High level, both of them are configuring the same parameters.
D) Understood. But there remains an issue. I hoped that the Radar Interface Control document will give me the exact bit wise sequence of the particular API (frame config in this case). However, I see differences, as I mentioned earlier. I am getting the following line in output shell of mmwave studio :
09-May-2020 16:52:43: API:FrameConfig,0,0,200,32,8000000,0,512,0,
Seemingly, the structure does not exactly tally with section 5.5.3 of Radar Interface Control document (Rev 1.7) (forwarded by you).
D1) The position of frames (200) and chirps per frame (loops) (32) is interchanged.
D2) Your requested reply to B) above will hopefully resolve this query as well.
Thanks and regards
Hello Alper,
I understand you're new to this, I would love to help you out. Please find my answers below:
A) 1 LSB in this context means that one unit of frame period would correspond to a time of 5ns. Hence, suppose if you program this field as 100, it would correspond to a time of 500ns and 40000 would mean 40000*5 = 200000ns. This is just a way to program values for the API.
B) For the help feature, click on the option "lua shell" in the view tab. Once you reach there, just type "help ar1.FrameConfig()". I have attached a screenshot below for your convenience.
D) Actually, the log file from which you have produced the API commands is basically used for MATLAB processing. It is dealing with the same parameters, but arranged in a different fashion (much similar to the config file). For your own purpose, I would recommend you to just use the ICD and the help function.
I hope I was able to clarify things for you, if not, please feel free to ask again.
Regards,
Ishita
Hi Ishita,
Thanks again for your to-the-point guidance. This is among one of the best supports I have received from TI.
Just an added suggestion that I earlier gave a few times in my TI posts :
TI really needs to improve its support documentation. I would not have bothered you if many of these issues were addressed in mmwave User Guide etc and if links to all supportive connected documents were given in one consolidated master document.
A such major re-visit and re-vamp of User documentation will help the TI customers a lot and it will also remove a significant work-load from TI support team.
Regards
Thanks Alper,
We're continuously working on making our customer's experience better each day. Your feedback would definitely be taken into consideration.
Have a good day!
Regards,
Ishita