• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 451 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.

IWRL6432BOOST: Regarding chirp accumulation & velocity resolution(dopplerStep)

Youngjae Ho
Prodigy 10 points
Part Number: IWRL6432BOOST

Tool/software:

Hi,

While working on different chirp configurations to improve SNR, I came across "numOfChirpsAccum" in frameCfg.

The description states "the number of chirps to be accumulated before sending the ADC data out in DFE".

Thus, to my understanding, If I use numOfChirpsAccum set to 2, the device will send 2 chirps to create 1 chirp.

 

Now consider the following example,

chirpComnCfg 10 0 0 256 4 30.8 0

chirpTimingCfg 24 32 0 58.6 57

frameCfg 128 0 7130 1 200 0

In the above example, I calculated the velocity resolution to be around 0.3m/s.

IF the numOfChirpsAccum is set to 2, I expect the velocity resolution to double since 2 chirps are used to create a single chirp.

However, when I debugged through code, I found out that the dopplerStep value was still set to 0.3m/s despite the change in numOfChirpsAccum.

To summarize my question -

Does increasing "numOfChirpsAccum" have no affect in velocity at all? or Is the dopplerStep calculation in SDK wrong? 

Thanks,

Jacob

  • 0
    TI__Expert 4180 points

    Hi,

    We are looking into your query. Please allow us a couple of days to respond.

    Regards,

    Sharan

  • 0 in reply to Sharan S S
    TI__Mastermind 37805 points

    Hi,

    Increasing the number of accumulated chirps does not improve velocity estimation. Accumulated chirps essentially average the results from multiple chirps into a single chirp to improve SNR. If you do 64 chirps/frame, but set chirp accumulation to say 4, then the device will chirp 256 times (64 X 4), but it will average the chirps together in groups of 4, so the data processing only sees 64 total chirps.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 10 points

    Hi Nate, 

    Thanks for the reply.

    I understand that at 64 chirps/frame & accumulation set to 4, then the device chirps 256 total (64 x 4) but only the averaged 64 would be processed.

    The point I would like to be further clarified is how is it that velocity estimation have no affect when the interval between final 64 chirps have changed due to accumulation? 

    (Assuming Normal Mode) For instance, in the no accumulation case, chirp interval is 54.8us.

    Velocity estimation as to my understanding is related with chirp interval where Vmax = C / (4 * Fc * Chirp Interval).

    If we set the accumulation to 4, it will average the chirps in groups of 4 as you mentioned.

    However, due to time needed to send a single chirp(58.4us) I believe sending of 4 chirps to average into a single averaged chirp would lead to a chirp interval of 58.4 x 4 = 233.6us. Since the chirp Interval has quadrupled, Vmax should also be 1/4 of the original value.

    Am I misunderstanding something?

    Thanks,

    Jacob

  • +1 in reply to Youngjae Ho
    TI__Mastermind 37805 points

    Hi Jacob,

    You are correct - the Vmax will diminish and the V resolution will improve (finer resolution) due to the longer chirping window.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 10 points

    Thank you Nate for the clarification.

    Just as a note, when I checked the dopplerStep value in MMWAVE L SDK, it did not seem to take the accumulation factor into consideration.

    Will it be possible to have this confirmed as well? 

    ''' MMWAVE_L_SDK_05_05_02_00, dpc.c

        if (gMmwMssMCB.frameCfg.h_NumOfBurstsInFrame > 1)
        {
            /* Burst mode: h_NumOfBurstsInFrame > 1, h_NumOfChirpsInBurst = 2 */
            params->dopplerStep          =   MMWDEMO_RFPARSER_SPEED_OF_LIGHT_IN_METERS_PER_SEC /
                                                (2.f * params->numDopplerBins *
                                                centerFreq * (gMmwMssMCB.burstPeriod * 1e-6));
        }
        else
        {
            /* Normal mode: h_NumOfBurstsInFrame = 1, h_NumOfChirpsInBurst >= 2 */
            params->dopplerStep          =   MMWDEMO_RFPARSER_SPEED_OF_LIGHT_IN_METERS_PER_SEC /
                                                (2.f * gMmwMssMCB.frameCfg.h_NumOfChirpsInBurst *
                                                centerFreq * ((gMmwMssMCB.profileTimeCfg.h_ChirpIdleTime + gMmwMssMCB.profileComCfg.h_ChirpRampEndTime) * 1e-1 * 1e-6));
        }
    '''
  • +1 in reply to Youngjae Ho
    TI__Mastermind 37805 points

    Thank you for the catch! I will file this as a bug. For now, can you simply divide the dopplerStep by the chirp accumulation value? I think that should be sufficient.

    Best,

    Nate