• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 422 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.

IWR6843ISK: 3D people counting / Sense and Direct Demo faster frame rate / CAN bus

Mary Raullette Solomo
Intellectual 600 points
Part Number: IWR6843ISK
Other Parts Discussed in Thread: IWR6843

Hello,

We would like to enable a faster than 50ms frame periodicity for IWR6843 demo. I believe that the UART speed is limiting the frame periodicity. Is this correct? What are other factors limiting the frame period?

If we use CAN bus instead of UART in data transfer, will this help in shortening the frame period? If yes, do you have a guide on how to enable CAN communications for 3D People Counting / Sense and direct demo?

Can you suggest other ways for us to shorten the frame period without significantly affecting the performance? 

  • 0
    TI__Mastermind 23725 points

    Hello

    We would recommend starting with the Chirp design to get the required update rate.   Current People counting demos are designed based on specific detection parameters and as you change the frame rate these would change.

    After this the post processing would have to be adjusted to accommodate these changes.

    Sending the data over usart or CAN peripheral would not typically restrict the frame rate.

    THnak you

    Vaibhav

  • 0 in reply to Vaibhav Mahimkar
    TI__Mastermind 28055 points

    Hi Mary,

    Adding on to Vaibhav's answer,

    Frame time is made up of the following:

    1. Active Frame TIme - radar is active here, this time is dependent on chirp design - changing this has the biggest effect on performance
    2. Post Processing - time required for software to process data
    3. Data output - time required to output data on UART

    #1 will be fixed based on chirp config. #2 and #3 will have upper bounds based on chirp config and detected points limit.

    Changing data output is the only way to modify the upper bound on frame time without effecting performance, so moving to CAN could save time. You can see the CAN driver documentation in the SDK if you want to switch output interfaces.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 600 points

    I understand.

    I will take a look at the CAN bus driver.

    Anyway, is this stool applicable for IWR6843 People counting? https://dev.ti.com/gallery/view/1792614/mmWaveSensingEstimator/ver/1.3.0/

    So basically I will just replace profileCfg line according to the chirp config it calculates, right? Or do you have any other tool that can help in modifying profileCfg?

  • 0 in reply to Justin Curewitz
    Intellectual 600 points

    Hi Justin,

    Thanks for this explanation.

    The reason why we wanted to decrease the frame period to less than 50mS is because we want to have lesser "blind spot" which happens during step 2 and 3 in your frame time above.

    Another way is, instead of decreasing the total frame period, we keep it at 50mS but we increase the Active Frame Time in step 1 by increasing the number of chirps. Right now, for the sense and direct demo, the chirp loops is 128. When I tried to increase it, it will not work. I'm guessing it's because of memory limitation.  Is this correct? 

    Is the 128 chirps already the limit? I tried using 256 loops and 64 samples (other parameters remain default) and the demo would not run. I think this should result to the same active frame time as the 128 loops and 128 samples, so I don't understand why it didn't run. Is it because we can never use >128 chips? I'm using the mmwaveSensingEstimatorTool to calculate for the profileCfg and frameCfg parameters however, mostly by trial and error. If use less chirp loops than 128, it may run. If I use more than that, it will never run. 

    Also, for sense and direct demo default cfg, do we know how long is the Active Frame Time in the 50mS total frame period?

  • 0 in reply to Mary Raullette Solomo
    TI__Mastermind 28055 points

    Hi Mary,

    Yes, you are running into a memory limitation. What is your reason for minimizing the "blind spot" you described. At the very least, you can increase the idle time, but this will lower max velocity and provide finer velocity resolution.

    Update: The active frame time in Sense and Direct is 25.5 ms. You can determine this by:

    1. Find total chirp time = <idle time> + <ramp end time>
    2. Active time = <number of chirps> * <total chirp time>

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 600 points

    Hi Justin,

    For the sense and direct demo, I'm only getting half of the 25.5ms that you said if I use (30us+69.72us) * 128 loops = 12.8mS. Do we need to multiply it by two because of the two ChirpCfg?

    profileCfg 0 62.00 30 10 69.72 0 0 28.42 1 128 2180 0 0 24
    chirpCfg 0 0 0 0 0 0 0 1
    chirpCfg 1 1 0 0 0 0 0 4
    frameCfg 0 1 128 0 50 1 0

  • 0 in reply to Mary Raullette Solomo
    TI__Mastermind 28055 points

    Hi Mary,

    That is correct, there are two chirps per chirp loop so their are 256 chirps total.

    Regards,
    Justin