IWR1443: question on the recommend parameter from Ramp Timing Calculator in Radar studio

Chris Meng

Part Number: IWR1443

Hi,

My customer tried to get the min chirp period based on the recommend parameter from Ramp Timing Calculator in Radar studio. But they found the recommend idle time and ADC start time from Ramp Timing Calculator is too small sometimes and the ADC data has unexpected overshoot at the first several bins. They need to try several times to get the right idle time and ADC start time.

Why the recommend idle time and ADC start time from Ramp Timing Calculator is too small sometimes? Is there any other way or suggestion for customer to get the min workable idle time/ADC start time more easier, not just try again and again?

Below are tests which can reproduce customer's problem. All tests are based on xWR1443 EVM (ES2.0) , capture demo in mmWave SDK 1.0 and radar studio 1.7.4.0.From below snapshot, you will find the recommend idle time/ADC start time for Slop=10Mhz/us, ADC Samples=256, sample rate =10Msps is 2us/3.78us.

The left figures in below shows the abs of the complex first chirp ADC sample data.

frame = rad_in(1:K,1) + i*rad_in(1:K,2);
abs_radar=abs(frame);

The right figures in below shows the real part of the complex first chirp ADC sample data. The ADC data is saved from L3 (start address 0x51020000). I uses the idle time =2us and ADC start time =4us and you can see overshoot in both figures.

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 2 4 31 0 0 10 1 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

Then I increased the idle time/ADC time by 1us. I still see the overshoot.

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 3 5 31 0 0 10 1 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

Then I increased again. Now I think the ADC data is normal.

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 4 6 35 0 0 10 1 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

Thanks,

over 8 years ago

0 Vaibhav Mahimkar over 8 years ago

TI__Mastermind 23665 points

Hi Chris,

We have noticed these and idle time. Seems like the Radar Studio recommended idle times/Start times might need to be increased. We will get back to you on this.

Thank you,
Vaibhav

0 Vivek Dham over 8 years ago in reply to Vaibhav Mahimkar

TI__Guru 58035 points

Hello Chris,
This settling is due to the TX turn ON during the start of the chirp. You can advance the TX turn on by reducing the TX start time value if needed. But this settling is mostly related to DC , hence when you look at the FFT it would be around the DC bin, which is typically not used , but depends on the end application.

The ADC start time an idle time recommended value does not account for this since in most cases it can be handled in the fft rather than changing the ADC start time or idle time.

Regards,
Vivek

0 Chris Meng over 8 years ago in reply to Vivek Dham

TI__Mastermind 36825 points

Vivek,

Reducing the TX start time can reduce the overshoot, but not much. Pls find my test result below.

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 2 4 31 0 0 10 0 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 2 4 31 0 0 10 -1 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 2 4 31 0 0 10 -2 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

flushCfg
dfeDataOutputMode 1
channelCfg 2 1 0
adcCfg 2 1
adcbufCfg 0 0 1 1
lowPower 0 0
profileCfg 0 77 2 4 31 0 0 10 -5 256 10000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 1
frameCfg 0 1 128 1 50 1 0
sensorStart

0 Chris Meng over 8 years ago in reply to Vivek Dham

TI__Mastermind 36825 points

Vivek Dham said:
But this settling is mostly related to DC , hence when you look at the FFT it would be around the DC bin, which is typically not used , but depends on the end application.

Customer thought the overshoot in the first several bins in time domain data will increase the noise floor in frequency domain (after FFT) which will effect the later process result. So they still want to remove these overshoot.

Thanks,

0 Vivek Dham over 8 years ago in reply to Chris Meng

TI__Guru 58035 points

Hello Chris,
I think in the demo application the value would be restricted to positive numbers , so 0 would be the min you can try.
There would be a noise floor increase but mostly around the DC bin only. If the customer would like to avoid that then they can increase the ADC start time. Idle time need not be changed.

Regards,
Vivek

0 Chris Meng over 8 years ago in reply to Vivek Dham

TI__Mastermind 36825 points

Vivek,

I changed below code in C:\ti\mmwave_sdk_01_00_00_05\packages\ti\utils\cli\src\cli_mmwave.c to let the tx start time work ok with negative value.

from: profileCfg.txStartTime = (uint32_t)((float)atof (argv[9]) * 1000 / 10);
to: profileCfg.txStartTime = (int16_t)((float)atof (argv[9]) * 1000 / 10);

Then I tested the tx start time with 0, -1, -2 and I found when tx start time=-2us, the overshoot is gone. What's the limitation for tx start time value setting? I think if the value of tx start time is negative, the abs of the tx start time should less or equal to idle time. If I miss anything, pls kindly correct.

0 Vivek Dham over 8 years ago in reply to Chris Meng

TI__Guru 58035 points

Hello Chris,
Yes , if you are using negative TX start time its value cannot be larger than the Idle time .
But please note that using negative TX start times means the PA out be ON even when the chirping is not ongoing. So this could imply unwanted emissions during this period. If this is to be avoided , instead of using negative TX start times you can increase the ADC start time to avoid the initial settling issue.

Regards,
Vivek

0 Chris Meng over 8 years ago in reply to Vivek Dham

TI__Mastermind 36825 points

Vivek,

Customer still complained that they need to try to get the result. And they don't know which setting is best (shortest without overshoot). Is there any theory to help customer to find the best setting? Or customer must try to get a better one as the best setting is different based on chirp config or based on HW board?

Thanks,

0 Vivek Dham over 8 years ago in reply to Chris Meng

TI__Guru 58035 points

Hello Chris,
All the parameters like idle time, ADC start time, ramp end time can be got from the ramp timing calculator.
The TX start time is not mentioned there because its mostly driven by the customer requirements. If they do not care much about the DC bins then the initial "jump" that they see should not impact the FFT in the desired region (away from the DC bins) and they can keep the TX start time 0 or 1 usec. This is the case in most applications.
Incase they do care about the region close to the DC bin then they can either use negative TX start time to make sure the DC is settled by the time the ADC starts sampling (DC settling may take 5-6 usec). If they cannot use negative TX start time due to emission requirements they can increase the ADC start time by that much amount (5- 6 usec after TX start time).

So basically they need to make sure the ADC start time is 5-6 usec after the TX start time, by either using negative TX start time or using a larger ADC start time.

Regards,
Vivek

0 Kevin Ortiz over 8 years ago

TI__Expert 3525 points

Hi Chris,

Has your issue been resolved? If so, please verify the answer. If not, what else can we clarify for you?

Thank you,
Kevin

0 Chris Meng over 8 years ago in reply to Kevin Ortiz

TI__Mastermind 36825 points

Kevin,

I have double checked with customer and we can close this issue now. I just verified the answer.

Thanks,

Sensors

Sensors forum

IWR1443: question on the recommend parameter from Ramp Timing Calculator in Radar studio