IWR6843: Q17 fixed point format

HI Alex,

Can you tell me the toolbox version you're using and the path to mathutils.c? In general, the Q format can be explained here

https://en.wikipedia.org/wiki/Q_(number_format)

If pWinBuf is a Q17 number, then you might It looks to me like you're assigning a uint32_t to a fixed point decimal number, which may not be correct at first glance.

If you give me more context to what you're doing though I can probably give you more insight. 

Best,

Nate

Oh okay -- so the wiki article is a good representation. I saw that but I just wanted some confirmation. Q17 does appear to support negative numbers. 

I am just trying to implement a new window to use before applying the range FFT in the rangeProcHWA DPU.  I am just copying the standard TI format here in mathUtils_genWindow from mathutils.c :

void mathUtils_genWindow(uint32_t *win, uint32_t winLen,
                         uint32_t winGenLen, uint32_t winType, uint32_t qFormat)
{
    uint32_t  oneQFormat = (1U << qFormat);
    uint32_t    winIndx;
    float       phi;
    uint32_t    *pWinBuf;

    pWinBuf = win;

    phi = 2 * PI_ / ((float) winLen - 1);

    for(winIndx = 0; winIndx < winGenLen; winIndx++)
    {
        if(winType == MATHUTILS_WIN_BLACKMAN)
        {
            //Blackman window
            float a0 = 0.42;
            float a1 = 0.5;
            float a2 = 0.08;
            *pWinBuf = (uint32_t) ((oneQFormat * (a0 - a1*cos(phi * winIndx) +
                a2*cos(2 * phi * winIndx))) + 0.5);
            if(*pWinBuf >= oneQFormat)
            {
                *pWinBuf = oneQFormat - 1;
            }
        }
        else if(...){
        ...
        }
...
}

Should I be doing something different?

Context:

In ti/datapath/dpc/objectdetection/objdethwa/src/objectdetection.c, we see DPC_ObjDet_GenRangeWindow(...) called from DPC_ObjDet_rangeConfig(...), so I am just replacing the standard Blackman window with a Flattop. I made sure to add a new macro for the new window.

The ultimate reason is because we are trying to reduce scalloping loss in our range fft amplitude measurements. We have other mitigations in place as well, for example adjusting the range resolution and applying phase bias calibration, but a higher dynamic range window may be needed. At this point, I am just using standard coeffs for the new window since I am not sure if the firmware modification will work or not! I am pretty sure it will though now...