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.

AWR1843BOOST: Medium Range Radar Lab Output Latency

Part Number: AWR1843BOOST

Tool/software:

Hi I am using the MRR Lab configured to use MRR subframes only. But it seems that the radar module are sending two MRR subframes every 60ms at one go, instead of sending one MRR subframe every 30ms, so even though each subframe duration is 30ms, I did not get 30 fps because the radar module is holding onto the first subframe to wait for the second subframe to complete before sending it out. Below is the python code I used to decode the incoming raw data, and as you can see, the message I received at each time has two headers in it, meaning two subframes. How can I change the MRR code so that it sends out subframe every 30ms, perhaps it is the MRR_DSS_DataPathOutputLogging function in dss_main.c?

import serial
from mrr_structs import MRR_session

magic_word = b"\x02\x01\x04\x03\x06\x05\x08\x07"
ser = serial.Serial('COM5', 921600, timeout=0.1)
buffer = b""

def update():
    global buffer
    if ser.in_waiting:
        buffer += ser.read(ser.in_waiting)
        ptr = buffer.find(magic_word)
        count = buffer.count(magic_word)
        print(count)

        if ptr != -1:
            try:
                session = MRR_session(buffer, ptr)
                messages = session.get_dict()
                print(messages)
                ##OUTPUT##
                #{'messages': [{'header': {'magic_word_0': 258, 'magic_word_1': 772, 'magic_word_2': 1286, 'magic_word_3': 1800, 'version': 50725376, 'totalPacketLen': 64, 'platform': 661058, 'frameNumber': 93315, 'timeCpuCycles': 389067100, 'numDetectedObj': 0, 'numTLVs': 0, 'subFrameNumber': 0}, 'body': []}, 
                #              {'header': {'magic_word_0': 258, 'magic_word_1': 772, 'magic_word_2': 1286, 'magic_word_3': 1800, 'version': 50725376, 'totalPacketLen': 64, 'platform': 661058, 'frameNumber': 93316, 'timeCpuCycles': 407057434, 'numDetectedObj': 0, 'numTLVs': 0, 'subFrameNumber': 0}, 'body': []}]}
                ##########
                buffer = b""
            except Exception as e:
                print("Incomplete or corrupt message:", e)

while True:
    update()

  • I’m experiencing the same issue with the Out-of-Box demo. I configured the radar using the Sensing Estimator to operate at 35 FPS, and I tried to use maximum supported baud rate of 3,125,000 bps. However, when I run the Python script to receive and parse the data, I consistently observe that two packets are received together every ~60ms, resulting in an effective frame rate of just 17 FPS.

    I’d like to confirm:

    • Is this a limitation of the radar hardware, or

    • Could there be a bottleneck in the Python script for data reception and parsing?

    I’ve attached both the configuration file and the Python code I'm using for data parsing.

    drive.google.com/.../15qiu0v_lNgurTJebSu7IRy0RoA5Q7kw-

  • Hi Fong,

    Configured baudrate of data port is 921600 in OOB demo. Did you change the baudrate?

    Can you confirm if the processing of ADC data is completed in the given frame time? Can you share the configuration that you are using to run OOB demo?

    Is this a limitation of the radar hardware

    This is not a device limitation. Below is a screenshot from "C:\ti\mmwave_dfp_01_02_06_03\docs\mmWave-Radar-Interface-Control.pdf" showing the minimum and maximum frame periodicity that can be configured.

    Regards,

    Samhitha

  • Hi. Attached is the configuration file I used and output example after parsing.
    frameCfg is 0 2 88 0 30 1 0. So 30 ms periodicity, about 33 fps. I am receiving two packets at one go still using 921600 baud rate. I tried to add configDataPort 3125000 1 to the configuration file but it is still the same.

    sensorStop
    flushCfg
    dfeDataOutputMode 1
    channelCfg 15 7 0
    adcCfg 2 1
    adcbufCfg -1 0 1 1 1
    profileCfg 0 76 2 3.9 16.11 0 0 19.55 1 128 11414 0 0 30
    chirpCfg 0 0 0 0 0 0 0 1
    chirpCfg 1 1 0 0 0 0 0 2
    chirpCfg 2 2 0 0 0 0 0 4
    frameCfg 0 2 88 0 30 1 0
    lowPower 0 0
    guiMonitor -1 1 0 0 0 0 1
    cfarCfg -1 0 2 8 4 3 0 15 1
    cfarCfg -1 1 0 4 2 3 1 15 1
    multiObjBeamForming -1 1 0.5
    clutterRemoval -1 1
    calibDcRangeSig -1 0 -5 8 256
    extendedMaxVelocity -1 0
    lvdsStreamCfg -1 0 0 0
    compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
    measureRangeBiasAndRxChanPhase 0 1.5 0.2
    CQRxSatMonitor 0 3 4 23 0
    CQSigImgMonitor 0 47 4
    analogMonitor 0 0
    aoaFovCfg -1 -90 90 -90 90
    cfarFovCfg -1 0 0 49.99
    cfarFovCfg -1 1 -13.89 13.89
    calibData 0 0 0
    sensorStart


    Output example after parsing:

    Packet 1:
    {'header': {'magic0': 258, 'magic1': 772, 'magic2': 1286, 'magic3': 1800, 'version': 50725376, 'packet_len': 192, 'platform': 661571, 'frame_num': 70, 'cpu_cycles': 1501060051, 'num_obj': 3, 'num_tlvs': 4, 'subframe_num': 0}, 'objects': [{'x': 0.04286005347967148, 'y': 0.5945236086845398, 'z': -0.33907610177993774, 'v': 0.2831193506717682}, {'x': 0.02143002673983574, 'y': 0.5683829188346863, 'z': -0.38307902216911316, 'v': -0.2831193506717682}, {'x': 0.06429007649421692, 'y': 0.583331286907196, 'z': -0.3547665774822235, 'v': -0.2831193506717682}], 'snr': [122, 114, 114], 'noise': [424, 423, 423], 'statsinfo': [{'interFrameProcessingTime': 6159, 'transmitOutputTime': 2248, 'interFrameProcessingMargin': 19047, 'interChirpProcessingMargin': 0, 'activeFrameCPULoad': 0, 'interFrameCPULoad': 13}]}

    Packet 2:
    {'header': {'magic0': 258, 'magic1': 772, 'magic2': 1286, 'magic3': 1800, 'version': 50725376, 'packet_len': 192, 'platform': 661571, 'frame_num': 71, 'cpu_cycles': 1507059929, 'num_obj': 3, 'num_tlvs': 4, 'subframe_num': 0}, 'objects': [{'x': 0.107150137424469, 'y': 0.45845332741737366, 'z': -0.4986053705215454, 'v': 0.2831193506717682}, {'x': 0.15001018345355988, 'y': 0.42576974630355835, 'z': -0.5162218809127808, 'v': -0.2831193506717682}, {'x': 0.08572010695934296, 'y': 0.4647745192050934, 'z': -0.4968950152397156, 'v': -0.2831193506717682}], 'snr': [139, 148, 148], 'noise': [424, 405, 405], 'statsinfo': [{'interFrameProcessingTime': 6157, 'transmitOutputTime': 2249, 'interFrameProcessingMargin': 19038, 'interChirpProcessingMargin': 0, 'activeFrameCPULoad': 0, 'interFrameCPULoad': 13}]}

  • My Python code to read the data from radar for reference:

    def read_data_from_sensor(port, baudrate):
        try:
            with serial.Serial(port, baudrate, timeout=0.001) as ser:
                print(f"[INFO] Listening to {port}...")
                while True:
                    data = ser.read(ser.in_waiting)
                    magic_indices = find_magic_indices(data)
                    packets = []
                    for i in range(len(magic_indices)):
                        start = magic_indices[i]
                        end = magic_indices[i+1] if i+1 < len(magic_indices) else len(data)
                        packet = data[start:end]
                        parsed = decode_packet(packet)
                        packets.append(parsed)
                    for i, pkt in enumerate(packets):
                        print(f"\nPacket {i+1}:")
                        print(pkt)

  • Fong,

    It's out of the scope of E2E to debug the custom code. I think the issue is with the parser script and not the demo application as the application is running without any assert and transmitting the UART data. With the configured frame periodicity, the frame will be triggered for every 30ms, ADC data is processed and the object data is also transmitted over UART. 

    Regards,

    Samhitha

  • Hi, thanks for your reply. I noticed that when I increase the measurement rate (i.e., decrease the frame periodicity to 15ms), I receive four consecutive frames in one go, likely because 15ms × 4 = 60ms, which matches the polling interval. If I set the frame periodicity to 60ms, I only receive one frame.

    Perhaps it's related to how pyserial reads buffered data or timing mismatches in the read loop. If any other engineers have encountered this behavior or have insights, I’d appreciate your input. Thanks!

  • Fong,

    I suggest you to check C:\ti\radar_toolbox_<ver>\tools\visualizers\Applications_Visualizer\Industrial_Visualizer or any python visualizer in C:\ti\radar_toolbox\tools\visualizers.

    If you are still facing issues, please search about this issue online as this query is related to python library.

    Regards,

    Samhitha