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.

CCS/IWR6843ISK: Attempt to increase fps with range-doppler turned on

Part Number: IWR6843ISK


Tool/software: Code Composer Studio

Hey TI community,

I'm trying to get a higher framerate with GUI option - range-doppler enabled. In the application that I'm building, I'm only interested in objects that are very close to the radar. So I figured to have the sensor only send the first few numbers of the range-doppler profile.

I managed to get it working on 30 FPS (with some problems), here's what I did:

There are only two places that changed. In mss_main.c,

MmwDemo_transmitProcessedOutput(...) {

    ... 
    if (pGuiMonSel->rangeDopplerHeatMap)
    {
        tl[tlvIdx].type = MMWDEMO_OUTPUT_MSG_RANGE_DOPPLER_HEAT_MAP;
        // divide the tlv length by the rd_denom (first place changed)
        tl[tlvIdx].length = (subFrameCfg->numRangeBins * subFrameCfg->numDopplerBins * sizeof(uint16_t)) / 2; // set the rd profile length to be half of what's given (first place changed)
        packetLen += sizeof(MmwDemo_output_message_tl) + tl[tlvIdx].length;
        tlvIdx++;
    }
   ...

    if (pGuiMonSel->rangeDopplerHeatMap == 1)
    {
        // only send out half of the message
        UART_writePolling (uartHandle,
                           (uint8_t*)&tl[tlvIdx],  // we have changed the tlv length above
                           sizeof(MmwDemo_output_message_tl));

        UART_writePolling (uartHandle,
                (uint8_t*)detMatrix,
                tl[tlvIdx].length / 2);  // only send out half of the data (second place changed)
        tlvIdx++;
    }
}

The lines I changed have comments showing what the change does. In the above code, it only sends half what's in the detobj buffer, so we're dividing the length by 2. 

By increase the denominator to 16, it can work at fps =  30.

However, the range-profile I'm getting this way seems to be broken with this method.

This figure is the range-doppler heatmap I got without changing the sensor's code, and I cropped only the top section, the section that captures objects closer to the radar.

So the above figure is the desired output. Now with the change aforementioned, here's what I get:

, which is obviously not right.

It is clear that the way I'm chunking the information is not right in

        UART_writePolling (uartHandle,
                (uint8_t*)detMatrix,
                tl[tlvIdx].length / 2); 

I suspect that it may due to the order of sending out bytes. Perhaps the data is in different endianness in memory that it is over UART. Simply taking the first half chunk of memory helped in reducing the data transmitting time. But the data it sends is not correct ...

Can someone help me with this?

Many thanks in advance!

Best regards,

Ziheng

  • Former Member
    0 Former Member

    Ziheng,

    What is the max range of your chirp? If you used a short range chirp then you would perhaps not need to modify the demo and throw away unnecessary range bins.

    Amanda

  • Amanda,

    Thank you for your reply, and sorry for the delayed response.

    My team is, in fact, using and ISK, ODS, and AoP, and we figured that the demo code is different for each one of them.

    The code in my original message is from the DSP version of IWR6843ISK in the Industrial Toolbox version 4.2.0.

    As aforementioned, the goal is to get the range-doppler heatmap at near 30 FPS. And this cannot be done with the short-range radar such as ODS or AoP. Besides, real-time tuning in the visualizer can set the maximum range, but it only affects the detected points TLV, and heatmap still yields result covering the entire range.

    Therefore, I think the problem still stands: what is the proper way to slice the range-doppler data as it is being sent over the UART.

            UART_writePolling (uartHandle,
                    (uint8_t*)detMatrix,
                    tl[tlvIdx].length / 2);

    Here, the last argument of UART_writePolling seems to be the size of the data to be sent starting at the pointer location designated by the second argument. My approach is just having it send half as much data, but it did not turned out working and I got the weird-looking heatmap as shown in the last message. Could you provide some insight as to what might be causing the issue?

    Best,

    Ziheng