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.

IWR6243: Cascade Transmit Beamforming at a Higher Frame Rate

Part Number: IWR6243

Tool/software:

Hi all,

I’m trying to develop a transmit beamforming configuration on a cascade of IWR6243. I am using currently Lua scripts and mmWaveStudio to interact with the device. I am trying to use a configuration that places all chirps for a single beam adjacent in time.  Since the hardware only supports 4 subframes, and I will be needing more than 4 different scan angles, I decided the most likely possible route is to dynamically change the phase shifter values between frames using ar1.DynPerChirpPhShifterCfgSet_mult() and ar1.DynamicChirpEnableCfgSet_mult(). The problem I’m running into is I don’t know how to consistently run these commands during the frame before those phase shift values are needed to cause the reconfiguring to happen in a frame’s idle time.

The reason I decided to do it this way rather than the method described in the example transmit beamforming scripts in the mmWaveStudio 3.0.1.9 file structure is to achieve a higher frame rate. Those scripts collect a few frames for one angle then reconfigure the profile and frame parameters for the next angle, requiring a pause of 500 ms before starting the frames again. This means the frame time for the transmission of all angles is a minimum of 500 ms times the number of angles in the scan.

Programming the chirps all in one frame is impossible because I am currently trying to program 15 scan angles with 256 chirps per angle.  This is more chirps than ar1.ChirpConfig_mult allows to be programmed (limit 512 per profile).

So this is my question. Is there a method to tell when individual frames begin to use as a trigger for the dynamic chirp configuration functions? If not, how might I solve the problem of programming transmit beamforming with more than 4 scan angles and the chirps for each angle adjacent in time to keep velocity estimation untouched?

  • Hi,

    An expert will comment shortly. Thank you for your patience.

    Best,

    Nate

  • Hello.

    I think it may be easier to approach this from a frame-by-frame perspective, and at the end of every frame, dynamically reconfigure the chirp and start the next frame.  You can configure the trigger to only trigger one frame of data collection, and then reconfigure, and contain that within a loop in the lua script.

    Sincerely,

    Santosh

  • This sounds like it would work. I don't know how to trigger a single frame without having to run again functions like ar1.TDACaptureCard_StartRecord_mult() or ar1.FrameConfig_mult() which I believe are the functions that use up the most time making it impractical to view moving targets with many beam angles. I've mainly used ar1.StartFrame_mult() to trigger the frames, but it runs frames until it is stopped by the StopFrame command. How do I configure it to trigger only one frame?

  • I believe you can control this from the frame configuration, if you set the number of frames parameter to 1 it will do a single frame, if you set it to 0 it will do infinite frames.  For more information you can refer to the API list in mmwave studio.

    Sincerely,

    Santosh

  • Thanks! Just in case I can't get the frame rate up to the speeds I want, I have one more question. Is there a way to know when each frame starts if they're not being triggered one at a time? Something like a quick function to see if the device is framing or in an idle state, or a way to view a pulse signaling the start of a frame?

    Sincerely,

    Adam

  • Hello.

    If the frame is software triggered, then the only way to tell that a frame started is with the ar1.StartFrame api.  I would suggest referring to the help command on mmwave studio to get more information the commands you may want to use.

    Sincerely,

    Santosh