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.

AWR6843ISK: Antenna coupling algorithm implementation in rangeprochwa.c

Part Number: AWR6843ISK

Hi team,

I referred MMWAVESDK(Ver3.5) regarding CalibDCRangeSig comand. Here, there is single restriction over <numAvg> argument that is it should be in power of 2 and greater than doppler bins.

Can you please explain the relation with dopplerbins in antenna coupling which is applied on doppler chirps? I guess It should be doppler chirps. Please correct me if I am wrong

But in rangeprochwa.c code . the implementation is slightly different.

In our confirutation, we are firing 104 chirps in a frame and we gave <numAvg> as 256(which is in power of 2 and greater than Doppler bins). For this configuration, the mean is not being calculated at all. 

Mean will be calculated only when <numAvg> is in multiple of dopplerchirps. 

Is this knowingly introduced or is it a bug? If it is knowingly introduced can you please explain us the reason.

Thanks in advance

M Girish Veerendra

  • Hello,

    How do you know that it is not getting computed? Is there an error at some point? The CLI driver only checks for a power of 2. Can you see a difference if you set the number of chirps to 128 or 64?

    Regards,

    Jackson

  • Hi Jackson,

    This query is regarding C code/implementation rather than output.

    Please check from your side and let me know if I was correct or not?

  • Hello,

    It will help to understand how you have verified the difference in behavior when issuing the command. Did you step through the code where this is applied to see if it gets calculated and applied?

    I do not see any limitation other than the check for a power of two. Please allow me a little more time to consult with my team if there are other requirements.

    Regards,

    Jackson

  • Hi Jackson,

    What Girish is trying to say is that we have not seen any change in antenna coupling peaks as in our hardware & setup we do not see antenna coupling peaks even when disabled. Hence our setup is not an ideal case for validating the code based on peaks.

    But as Girish mentions, our concern is that the implementation approach is not the same as what is described in the SDK user guide. If we set the number of chirps to be averaged in antenna coupling to be 32 (power to two) and the frame has 128 chirps. In this case, the averaging is not performed correctly.

    Thanks in advance,

    Santhana Raj

  • Understood,

    I will investigate a little more and get back to you soon. But if you don't see antenna coupling, and don't have issues with close range errors, what are you hoping this calibration will change?

    Also I forgot to ask, which demo are you starting from? You mentioned SDK3.5 but not if you were using one of the demos from the industrial toolbox.

    Regards,

    Jackson

  • Hello, 

    Sorry for the delay. Because this average should be computed for entire frames, it also needs to be an integer multiple of the number of chirps per frame, in addition to being a power of 2. 

    Regards,

    Jackson

  • Hi Jackson,

    As per the documentation, the constraint on the chirp number being a multiple of a total number of chirps in a frame is not mentioned anywhere, as far as I know.

    This constraint also puts a strict limitation on the usage of antenna coupling for chirp/frame designs which doesn't have the number of chirps in a frame to be in the form of power of 2. (In our case it's 104).

    Additionally, I do not think this constraint is logical as the code can work without this also and the parameter should have been the number of frames instead of the number of chirps.

    Thanks in Advance,

    Santhana Raj

  • Hello Samantha,

    Yes this is missing in the documentation. Probably using number of frames also works, except since there is a right shift operation the number of chirps has to be a power of 2. This measurement is performed at the end of a frame, which is why it needs to be a multiple of chirps/frame. You can likely go in and update the function to split the chirps from the last frame, or perform a different division so you don't need a power of 2 Navg chirps. There should be no fundamental limit on these values, but the code will likely need to be updated if they are changed.

    Regards,

    Jackson