• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 387 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Transforming mmwave demo visualizer embedded software and GUI into test bench

Maaz Awan
Prodigy 155 points
Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1642

Greetings forum!

I hope this post finds everyone in the best of their health.

I am using AWR1642 with intended application of using it as a platform for testing.

I am conversant with CCS, its debugging methodoloy and fairly proficient with embedded C and TI RTOS. I have worked for many years on Simplelink devices prior to working on mmwave sensors.

I came accros the mmwave demo visualizer, i was able to run the out of box demo on the hardware and test various scene configurations successfully. However to explore the practical capabilities of the device against, i would like to explore custom profile, chirp and frame configurations to meet various application requirements. The demo visualizer offers a rich interface for displaying real time object detection both in range and doppler domains. My application requirements mainly demand range profiling of objects with a wide dynamic range of RCS values. I tried loading custom configurations using the "Load Config from PC and send" but for some reason it does not take the file and gives different errors " xxxxxx is not a valid CLI command". The type of error keeps changing on every successive configuration attempt.

At this point, i am willing to modify the source code for mmwave demo visualizer GUI which is written in JavaScript as well as the embedded C code running on MSS and DSS inside the chip to achieve the following:

1. Bypass the validation and intialization requirement to configure the sensor before it starts sending processed information on "Data" Port, the sensor will load hardcoded configuration on startup and start sending data automatically. It will validate those hardcoded settings in the embedded software but it will not wait for initialization packet from GUI. The rationale behind doing this that the sensor is being installed on a movable platform and the sensor data shall be fetched using wireless radio in realtime. The software should retain the provision to be configured over CLI interface if test engineer wants to change the profile, chirp and frame configuration in runtime.

2.The GUI source code to be modified to incorporate capability of having custom configurations. As per my understanding as much as i have been able to fathom to this point from the source code of GUI, the input validation.js file only allows sending CLI packets to sensor after validation checks. What is the point of these validations? to avoid unexpected behaviour from the device in case of user generating a packet which is not possible for device to handle.? For example, it makes complete sense that if the product of slope and ramp end time is more than 4GHz frequency sweep, the device will reject the configuration command. If ths user is aware of such limitations, can the software in both GUI and sensor being modified to achieve the capability of having a fully customizable chirp?

3. Increase the frames per second limit to a dynamic range of 50-100 Hz provided velocity and angle of arrival information is discounted from the packet and the only information is apropos range profile.

Please guide me through this problem statement and provide a roadmap that may lead to effective development.

I am willing to learn javascript to a level that may allow me to modify an already written code since i dont intend to be write a code from scratch.

I have full understanding apropos flow of the code running on MSS but DSS is a black box for me right now.

Best Regards

Ali Awan

  • 0
    TI__Guru*** 148804 points

    Hi,

    Please try first the provided profile configurations. For AWR1642 I recommend using the mmWave SDK 2.1

    C:\ti\mmwave_sdk_02_01_00_04\packages\ti\demo\xwr16xx\mmw\profiles

    Maaz Awan said:
    I tried loading custom configurations using the "Load Config from PC and send" but for some reason it does not take the file and gives different errors " xxxxxx is not a valid CLI command". The type of error keeps changing on every successive configuration attempt.

    If there is an error, please power off/on the EVM before trying again.

    After you are able to run the provided profile configurations, you can start modifying the configurations and customizing them.

    For your experimentation it is important to understand that demo that runs on the EVM does not support all possible configurations. The demo was designed to be generic however there are limitations due to implementation decisions.

    So, it is possible that there will be custom profiles that will not run on this demo. This does not mean that the device does not support them. It only means that this particular demo does not support them.

    thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 155 points

    Thank you for you response Mr Cesar!

    I did take a look at the profiles but i am targetting different profiles.

    Why are you recommending SDK 2.1? i am working on SDK 3.6 without any issues so far.

    Besides, regarding my roadmap, please suggest course of action to achieve the objectives

    Best Regards

  • 0 in reply to Maaz Awan
    TI__Guru*** 148804 points

    Hi,

    Using SDK 3.6 is fine. I feel that the documentation in SDK 2.1 is better for AWR16xx.

    Regarding the custom profiles, you would need to try them with the demo. This is the easiest way

    Modifying the visualizer will not help. The limitation is with the target code.

    Maaz Awan said:
    1. Bypass the validation and intialization requirement to configure the sensor before it starts sending processed information on "Data" Port, the sensor will load hardcoded configuration on startup and start sending data automatically. It will validate those hardcoded settings in the embedded software but it will not wait for initialization packet from GUI. The rationale behind doing this that the sensor is being installed on a movable platform and the sensor data shall be fetched using wireless radio in realtime. The software should retain the provision to be configured over CLI interface if test engineer wants to change the profile, chirp and frame configuration in runtime.

    Yes, this is possible in the mmWave SDK demo. Please see

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/899453/ccs-iwr6843isk-bypass-cli-in-mmwave-demo

    Maaz Awan said:
    2.The GUI source code to be modified to incorporate capability of having custom configurations. As per my understanding as much as i have been able to fathom to this point from the source code of GUI, the input validation.js file only allows sending CLI packets to sensor after validation checks. What is the point of these validations? to avoid unexpected behaviour from the device in case of user generating a packet which is not possible for device to handle.? For example, it makes complete sense that if the product of slope and ramp end time is more than 4GHz frequency sweep, the device will reject the configuration command. If ths user is aware of such limitations, can the software in both GUI and sensor being modified to achieve the capability of having a fully customizable chirp?

    The demo supports a large variety of chirps. However there are limitations due to memory and processing speed.

    The limitation is not with the GUI but with the target code.

    Maaz Awan said:
    3. Increase the frames per second limit to a dynamic range of 50-100 Hz provided velocity and angle of arrival information is discounted from the packet and the only information is apropos range profile.

    The mmWave SDK demo does not support this use case. The demo will compute the velocity and the angle of arrival.

    So, the demo would have to be updated to support this use case.

    I think it should be possible to support 50 frames/sec.

    Thank you
    Cesar

    Thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 155 points

    Greetings!

    Using SDK 3.6 is fine. I feel that the documentation in SDK 2.1 is better for AWR16xx.

    Thank You.I will check the SDK 2.1 for better documentation on 1642. Actually I need to understand a ton of concepts apropos procesisng in DSP sub system.

    Regarding the custom profiles, you would need to try them with the demo. This is the easiest way.

    I tried the custom profiles of my choice and was able to virtually generate configuration to detect surface of ground from a height of 300 meters for instrument landing system of commercial airplanes . Since i dont have a drone to test my waveform, I just saw the performance on my office table and observed the range profile. I noticed that the FFT response over range looked jagged, I have attributed this as per my understanding to be happening due to the following reasons:

    1. I increased the max range which is a function of IF Bandwidth and chirp slope. Since 1642 has a poor cap on IF BW so I had to reduce the slope to as low as 5 MHz/us.

    2. I reduced the slope but wanted to mantain decent range resolution(10 cm), so I kept the chirp duration high, around 900us. To get a sharp FFT response, i need more ADC samples per chirp but that limit is 512 for no apparent reason.

    Please suggest if reducing the code to just range profiling will relieve unwanted processing overhead and allow increasing adc samples to 2048 or beyond.

    Yes, this is possible in the mmWave SDK demo. Please see

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/899453/ccs-iwr6843isk-bypass-cli-in-mmwave-demo

    Yes I read the discussion and I found another very good sample code to bypass the configuration and hardcode the parameters inside the target code. However I will still need to comment the function in GUI responsible to sending configuration packet to target and expecting a response. Reduce the GUI to just listening over the data port and display data received from target. I know enough javascript after watching a few video lectures to be able to edit the code. 

    The demo supports a large variety of chirps. However there are limitations due to memory and processing speed.

    The limitation is not with the GUI but with the target code.

    Yes, I tested a variety of chirp configurations and tested the limits with software crashing beyond a certain threshold of ADC samples, number of chirp loops or fast frame periodicity.

    The mmWave SDK demo does not support this use case. The demo will compute the velocity and the angle of arrival.

    So, the demo would have to be updated to support this use case.

    I dont want to use the target code for doppler and angle of arrival. I want to reduce the target code to just range profiling FFT or at max zoom FFT if need be.

    Please suggest if it is possible.

    I think it should be possible to support 50 frames/sec.

    Yes, I was able to achieve 50 Hz with some compromised performance in terms of FFT shape.

    Summary

    1.I am convinced that the effort to change the GUI to exempt configuration packet and only display range FFT is miniscule and easy. 

    2.Hard coding the parameters is possible and also not a problem.

    3. My understanding of complex ADC samples and their advantage over real ADC needs to be improved. Please suggest the appropriate ADC mode for my target application. Also I lack some theoretical insight on FFT processing, please suggest some reading material if available.

    4. My application requires accurate altitude measurement, is my understaning to consider range resolution as measurement accuracy correct if i do not have to discern one object from another but just measure the range accurately(10 cm accuracy).

    5.Will removing the functionality of  Doppler and AoA allow me to profile range at even higher rates say 100 Hz and increase ADC Samples?

    6. Can the target platform achieve the application under discussion? As per my working, from a height of 300m, the RCS of ground terrain is around 1300m2 considering reflectivity index of grass from an antenna having 60 degrees HPBW in azimuth and 30 degrees in elevation.

    7. Possible ways to increase the range budget and performance include switching to 1843 for double the IF bandwidth and redesigning the antenna layout for a gain of >20dBi with same HPBW. Please suggest other ways of increasing budget.

    I am aware that the current discussion has taken a different tangent from the original discussion.

    Best Regards

  • 0 in reply to Maaz Awan
    TI__Guru*** 148804 points

    Hi,

    I think the Range of 300m will not be achievable with the AWR1642.

    Usually the AWR1642 is used for a maximum range 80-100m.

    We think you should re-consider the use of AWR1642 for this long range application.

    thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 155 points

    sir kindly go through my idea to increasing antenna gain to fulfill the range budget

    Besides, i have no requirement of calculating doppler so there is no problem with setting a chirp for long duration...

    I have theoretical evidence on my side but your comment just discouraged me a lot... I was expecting a comment based on some engineering rationale.

    Best Regards

  • 0 in reply to Maaz Awan
    TI__Guru*** 148804 points

    Hi,

    Unfortunately the AWR1642 device does not have sufficient power to reach this performance.

    We recommend you work with a partner that has more experience with radar sensors.

    Usually we have seen this type of performance only when using 12TX powered at the same time.

    Thank you

    Cesar

  • +1 in reply to Cesar
    Prodigy 155 points

    ok i will see to it as how i can increase power and achieve the target range.
    Thank you for your time and efforts.

    Best Regards