0

I am reading raw hex data from a TI IWR1843BOOST radar module through pyserial. The radar is configured with a measurement rate of 35 fps, so the python code is expected to receive a single packet every 29 ms. However, pyserial seems to be receiving two packets (occasionally three packets) consistently at one shot every 60 ms or so, therefore data is coming in at 17 fps despite the radar is measuring at 35 fps. I am not sure if it's the inherent issue of the radar where it will hold on to the first packet and send together with the second packet when the second one is ready because these procedures are already hard coded to the radar chip. So could it be the way I am waiting and reading for data wrong? Attached is the pyserial code and the output I obtained.

def read_data_from_sensor(port, baudrate):
try:
    with serial.Serial(port, baudrate, timeout=0.1) as ser:
        print(f"[INFO] Listening to {port}...")
        while True:
            data = ser.read(ser.in_waiting)
            # Find the beginning of the data
            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)

except Exception as e:
    print(f"[ERROR] Failed to read data: {e}")

#####OUTPUT EXAMPLE#####
Packet 1:
{'header': {'magic0': 258, 'magic1': 772, 'magic2': 1286, 'magic3': 1800, 'version': 50725376, 'packet_len': 128, 'platform': 661571, 'frame_num': 80, 'cpu_cycles': 1159072654, 'num_obj': 0, 'num_tlvs': 3, 'subframe_num': 0}, 'objects': [], 'snr': [], 'noise': [], 'statsinfo': [{'interFrameProcessingTime': 2998, 'transmitOutputTime': 632, 'interFrameProcessingMargin': 24202, 'interChirpProcessingMargin': 0, 'activeFrameCPULoad': 1, 'interFrameCPULoad': 10}]}
   
Packet 2:
{'header': {'magic0': 258, 'magic1': 772, 'magic2': 1286, 'magic3': 1800, 'version': 50725376, 'packet_len': 160, 'platform': 661571, 'frame_num': 81, 'cpu_cycles': 1164801812, 'num_obj': 1, 'num_tlvs': 4, 'subframe_num': 0}, 'objects': [{'x': 1.038146734237671, 'y': 1.6446927785873413, 'z': -0.18966545164585114, 'v': 1.7290256023406982}], 'snr': [136], 'noise': [471], 'statsinfo': [{'interFrameProcessingTime': 3069, 'transmitOutputTime': 523, 'interFrameProcessingMargin': 24416, 'interChirpProcessingMargin': 0, 'activeFrameCPULoad': 1, 'interFrameCPULoad': 9}]}
4
  • The code you show will only work right if each call to ser.read() returns an exact integer number of packets - but there's absolutely no reason to expect that to be true. You need to keep the data after the last full packet, and prepend that to the next block of data you read from the port - rather than simply throwing it away, as you are currently doing. Commented Jul 14 at 1:59
  • I don't see any indication of timing in there. Is that "cpu cycles" value in units of 10ns? If so, that would be 58ms. HOWEVER, the frame numbers are sequential -- 80 and 81 -- which suggests that it came from the chip that way, so it was not something "lost in transit". Also, remember that serial is slow. What is the baud rate? That second message is 568 characters long. or 5,680 bits. If you're running 115k baud, it would take longer than 29ms to transmit that much. Commented Jul 14 at 2:00
  • The cpu cycles has no unit. So to find out the interval between the packet. We have to take 1164801812-1159072654=5729158, and take the result multiply with 1/200Mhz that is the clock speed of Cortex R4F which equals to around 28ms. The baud rate is 3125000 which is the maximum baud rate supported by the radar, so it should be sufficient to transmit long messages. Commented Jul 14 at 2:22
  • And yes, the frame numbers are sequential every time, so it might be possible that the chip is sending it that way at the first place. Commented Jul 14 at 2:26

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.