IWR1642BOOST: Max update rate

Hi, Venkatesh:

The frame period need to include the total chirping time in a frame and the post processing time needed by the DSP.    If you want to have 10ms frame period, you probably need to have all the post processing (after range FFT) done outside the radar sensor (in another processor).   Can you explain why you need a high frame rate?   It will be helpful if you explain the use case some more.  

The range estimation will be always accurate as long as the target results in a good enough SNR.  The SNR depends on radar output power, antenna gain, target RCS, target distance, sensor noise figure and post processing gain.   Given the sensor and target, the chirp configuration can change the processing gain.   For static object, if we increase total chirping time in one frame, then the SNR will be improved.   On the other hand, if the object moves very fast, and it moves to different range bin during one frame, then the SNR will not be improved as much, therefore, it makes sense to have a shorter frame period.    But if you have a strong target to start with, you will have enough SNR even in a very dynamic scenario.   

Can you provide more information about max range, desired range resolution, max velocity you want to support?  

Best,

Zigang

Hi Zigang,

Thanks for a quick reply.

I'm trying to decide on a sensor that can be used for high dynamics range measurement - so that the end platform can be used either as for collision avoidance or proximity detector. The typical dynamics that I envisage is upwards of 2Mach. To handle decisions at this speed a frame rate of 30fps would not be sufficient. Therefore the requirement of 100Hz update rate. 

Given that the dynamics are high, the RCS is also quite high. The range requirement is around 100m and the resolution is 1m. I dont foresee a problem with SNR, but am more worried about the effect of Doppler on the range measurement. The primary aim is to use this as a range sensor and then augment it with other sensors to get velocity and direction of arrival. 

The other option that I was interested was the OPTO3101 based EVM, but that has a max range of only 15m. 

Thanks

Venkatesh

PS: I did see in another thread that the max vel supported is around 100m/s - but I suppose this is for detection and measurement and should not affect the range computation. Am I right?

HI, Venkatesh:

It is true that it is very hard to exceed a maximum Velocity of 100m/s.  However, in your case, it should be OK to have velocity ambiguity.   Since you only care about range estimation.    

If you use MIMO, then to get angle estimation we will need to do Doppler compensation which will be little challenge with velocity ambiguity.   But for SIMO, you can get away with it.   

You can use only SIMO mode, which is one TX and 4 RX antenna.   Then you will be able to estimate range and angle without much problem.    

The chirp details are listed below :

Slope: 8Mhz/us

ADC sampling rate: 6.25Msps

number ADC samples per chirp: 128

number of chirp per frame:   32

ramp end time: 25.5us

idle time: 2us

adc start time: 4us

active chirp duration: 0.88ms

max range: 105m

range resolution 91cm

max velocity: 35.3m/s

The RCS required to detect up to 100m with this chirp design is about 70 assuming detection SNR is 12dB.  

But I am not sure whether the rest of the current demo code will finish on time to get you the desired 100Hz frame rate. 

Best,

Zigang

Hi Zigang,

Thanks for update. After digging a little bit deeper, I have a question -  

For the ease of computation, I'm assuming a user velocity of 300m/s and initial range of 75m. The Ramp rate assumed is 15MHz/us and ramp is active for 40us. 

To start off, taking a static scenario, wherein both the radar and the target are stationary, the delay in time observed will be 500ns (= 2*75/c), the frequency offset will be 7.5MHz. This is the base Doppler that the radar will see if there is no relative velocity.

Now if the relative velocity if 300m/s, the Doppler that it generates will be 154KHz (=2*300m/s*77GHz/c, 2 because the radar will measure the reflection off the target). This will add to the base Doppler of 7.5MHz and will give a range of 76.54m. I see that this error of 1.54m will be a constant bias as long as the velocity is the same. 

The question that I have is - a large relative velocity will result in a constant offset in range estimation as long as the velocity is constant. Is this understanding correct?

Thanks

Venkatesh

Hi Zigang,

Apologies for a hiatus due to holidays..

Thanks for the confirmation. On a related note, I see that if I increase the ramp rate to the limit of 100MHz/uS, then the range error will be 0.231m instead of 1.54m when using a 15MHz/uS ramp rate. Can you please suggest if there are any limitations using this ramp rate and also if possible generate a chirp configuration for the same?

I was going thru the OOB demo code and was wondering if you could give me code pointers to remove the velocity and Azimuth Angle computation?

Thanks

Venkatesh

Hi, Venkatesh:

When you increase the ramp slope, the range resolution will be smaller. However your maximum range will be reduced given the same number of ADC samples per chirp.   So to reach the same max range, you will have to increase the number of ADC samples per chirp a lot.   However, you can not increase the number of ADC sample and total number of chirp unlimited due to the memory limitation.   So at the end, you will be limited by memory (we have about 512KByte to save Doppler FFT output).    But if you plan to process the radar data outside the radar chip, then you will not be limited by radar L3 memory.  

Best,

Zigang

You can find the doxygen documentation about xwr16xx here. 

file:///C:/ti/mmwave_sdk_02_01_00_04/packages/ti/demo/xwr16xx/mmw/docs/doxygen/html/index.html 

To understand the angle of arrival estimation, you can search for " Data Path - Direction of Arrival FFT Calculation" 

To understand the velocity ambiguity, You can also search for "Velocity disambiguation"

But we did not implement the Doppler compensation from the range estimation because we have been targeted much slower velocity.

Best,

Zigang

Hi Zigang,

Thanks for the links and info. Few follow up questions  - 

1. I'm right now seeing that with 1Tx and 4 Rx configuration and disabling some plots, I'm able to go up to 50Hz update rate. The CPU load is being shown as around 6/15 (active and inter frame load). So this essentially means that the main bottleneck appears to be the UART thru put. From the .dat file logged from the demo visualizer I'm seeing that the data sent by the device is around 1KB/ frame. This translates to 50KB /s. This is around 50% of the UART thru put with the UART baud being 920Kbps. Am I missing something here or does the demo visualizer not log all the messages coming out of the demo?

2. From the code overview, I'm seeing that Angle of Arrival and velocity estimation are tied. Even the X,Y and Range computation seems to be dependent on the velocity estimation. How do I disable velocity computation from a config file command so that neither the Angle of Arrival nor the Range is affected?

Thanks

Venkatesh