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.

AWRL1432: AWRL1432 waveform configuration - 2 different chirp configure in a single frame

Part Number: AWRL1432

Tool/software:

Dear there,

We reviewed current 1432 BSD demo, and find the waveform is configured as 2 types - Fast & Slow, and each type is one frame, and only one chirp parameter is available within the frame. We would like to configure 2 different chirp parameters within a single frame, but don't know how.

The following table lists the required configurations:

Chirp id

0

1

2

3

4

5

6

7

8

Chirp config

A

B

A

B

A

B

A

B

A

Tx1 phase

0

0

0

0

0

0

0

0

0

Tx2 phase

0

X

1

X

0

X

1

X

0

In the table, AB indicates two chirp parameters (the main difference is idle time), and X indicates that Tx is disabled. In general, 0,2,4,... For BPM mode, 1,3,5,... Indicates the Tx1 single-channel transmission mode.

Could you please kindly help? Look forward for your reply and thanks in advance.

  • Hi, 

    Thanks for reaching out. We'll need to check if the firmware can support this. Let me look into this and get back to you by next Thursday. 

  • Hi,

    Do you plan to update the processing chain as well? The BSD demo would not work with the configuration described.

  • Dear Lee, we found a number of incorrect target velocity by current BSD demo configuration, that would cause faulse moving objects and then false BSD warning, which cannot meet our function application. Yes we plan to update process chain and 1st step is to configure 2 different chirp in a single frame.

  • Hi,

    Could you provide more details on the false detection happening in the processing chain? Is this happening with stationary objects, at a specific velocity, etc.?

    I am looking into the chirp configuration question and will get back to you by Thursday.

  • below 2 cases we found false moving point/target (but no moving objects in FOV), we suspect this maybe caused by surrounding trees, grounding, or sometimes stationary vehicle.

    Case 1: ego car moving at a certain speed; occurence: occasionally

    case 2: when ego car rapidly accelerating or decelerating; occurence: high frequency

    BTW, the tracking module is designed by ourselves.

  • Dear Lee, another waveform configuration request - two bursts configured in a single frame, and each burst corresponds to a chirp configuration. Thanks in advance.

    Chirp id

    0

    1

    N

    0

    1

    N

     

    0

    1

    N

    0

    1

    N

     

    Chirp config

    A

    B

    B

    A

    Burst

    0

    1

    0

    1

    Frame

    0

    1

  • Hi,

    Thanks for your patience. Regarding the configuration of 2 different chirp parameters in a frame, the Sensor per-chip configuration API can be used to change the idle time and certain other parameters each chirp. 

    The API basically stores the variable parameter values for each chirp in a dedicated LUT in memory, which is used to automatically update the parameters during runtime. This per-chirp configuration API overrides the configurations from the Sensor chirp profile time configuration API, which is used in the default BSD demo. Please refer to the Interface Control Document for more details on the API: (C:\ti\MMWAVE_L_SDK_05_04_00_01\firmware\mmwave_dfp\docs\mmwave_dfp_interface_control_document.pdf), and an example of its implementation in (C:\ti\MMWAVE_L_SDK_05_04_00_01\firmware\mmwave_dfp\examples\source\rlexample_perchirplut.c)

    Please note that the BSD demo differs from typical OOB demos in that the RF front end is reconfigured and triggered to run one frame at a time. This reconfiguration is done in TimerExampleISR(), in mmwave_demo.c. After configuring the LUT and enabling per-chirp control in initialization, rl_sensPerChirpCfg() should be used in the ISR to update the per chirp parameters. 

    Regarding two bursts, z_sensFrameCfg should be updated with the desired configuration, but please note that this has not been tested with the Vmax extension.

    Thank you very much for the feedback on false detections. We will try to recreate this issue and look into it.

    Thank you,

    Jin

  • Thanks Jin for your timely feedback. We will try the configuration and get back to you if any progress.

  • Dear Jin, so far we have completed the first configuration. Based on our understanding, for relatively static targets, the Tx1 target signal phase of A and B waveforms should be consistent, but we found the phase has a large deviation, which can not meet our needs. Have you ever met this issue or any ideas of solution?

  • Hi,

    Could you provide some more details on the testing you did? What targets were tested, and in what environment? How does the phase compare with moving targets?

    Thank you,

    Jin