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.

DCA1000EVM: Format of raw data sent over ethernet? What does ar1.PacketReorderZeroFill() do?

Part Number: DCA1000EVM
Other Parts Discussed in Thread: IWR1443BOOST,

Hello,

I am using the IWR1443BOOST and DCA1000EVM to capture data. I can successfully record the raw data captured over ethernet; however, passing in my recorded data to the ar1.PacketReorderZeroFill() function causes a 0kB file to be produced. I dump all packets received to my own .bin file, and have confirmed that it is not empty. At a high level, can the operations performed within that function be explained so that I can assure that my recorded data is compatible with the ar1.StartMatlabPostProc() function used to visualize the data in Matlab?

Thank you,

Pawel

  • Hi Pawel,

    Could you post your .bin file here? We'd like to take a look to see what causes the PacketReorderZeroFill to fail.

    I'll also try and dig up documentation on the data format and share here.

    Best Regards,

    Anand

  • My .bin file consists of many packets saved from reading the data transferred over Ethernet with a Python script. I found that each packet is of length 1466 bytes, where the first four bytes are the sequence number, the next six are the byte counts, and the remaining bytes in each packet contain the raw data, as described here, on page 19:  www.ti.com/.../spruij4a.pdf

    This is my raw .bin file after running the demo script:, where I just save each packet seen to a .bin file. I had to zip it because I was given errors about .bin files not being allowed: 

    test_raw.zip

    Reordering these packets by the sequence number, and then creating a file with only the raw data in the correct order does work with the Matlab script, and produces good looking visualizations (meaning they look like what they would look like if the entire demo script was ran).

    I tried to look at the contents of adc_data_RAW_0.bin and have trouble seeing what format this data is in. It does not seem to be made up of 1466 byte chunks like what I see over Ethernet and it is slightly larger than my raw .bin file. Do you happen to know the format of this .bin file?

    Also, another question: how does the reorder utility work. I know that the sequence number is 4 bytes long and the byte count is 6 bytes long. But what if I need to continuously capture data such that the sequence number or byte count overflow? And is this denoted anywhere in the packets sent so that I know that the data comes next?

    Thank you,

    Pawel

  • Hi Pawel,

    Looking at your .bin file, it looks like the first packet is missing the length for some reason and that's probably why the PacketReorder tool fails to process it. Bytes 5-10 of the .bin file are all 0.

    At offset 0x5BE, you see the second packet and at offset 0x5BE + 4 you see the length correctly set to 0x0005B0.

    Is this a bug in the code you are using to generate the .bin files?

    I see the packet length missing at other locations in the .bin file too, but the sequence number does appear to be present at close to the expected locations (minus the missing 6 bytes each for the length).

    Could you review your script again?

    Best Regards,

    Anand

  • The script used to record those files simply listened on a socket for packets and recorded them to a .bin file. This is the code for reference:

    import socket
    import sys
    import os
    
    sock = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
    sock.bind(("192.168.33.30",4098))
    sock.settimeout(2.5e-5)
    
    try:
        os.remove('test_raw.bin')
    except OSError:
        pass
    file = open('test_raw.bin', 'ab')
    
    while True:
        try:
            msg, server = sock.recvfrom(2048)
            file.write(msg)
        except KeyboardInterrupt:
            file.close()
            sys.exit()
        except socket.timeout:
            continue

  • Hi Pawel,

    We were unable to replicate this.

    Would you be able to run wireshark and check the packets being sent on the bus directly to compare them against your .bin file?

    Best Regards,

    Anand

  • Hello,

    I just ran my script with wireshark running and can confirm that the packets captured in my .bin file appear to match up with those seen on wireshark. Could different configuration settings be the cause of this discrepancy?

    Furthermore, I think I have a good sense of what the packetReorderZeroFill() utility is supposed to do. What I do is scan my raw binary file for each packet, and reorder them based on the sequence number. I use the number of bytes in the packet (packet[4:10]) to determine how many bytes I am missing and must therefore fill in with 0's.

    My only question is what happens when the number of packets overflows the maximum sequence number? Does it just wrap around to a sequence number of 0, or does the hardware do anything to deal with this?

    Best,

    Pawel

  • Hi Pawel,

    The sequence number wraps around to 0. The hardware does not do anything special to do with this.

    I will try again to replicate this issue. Could you let me know the version of mmWave Studio that you are using? Also, the DFP firmware version would be useful.

    Best Regards,

    Anand

  • Hello,

    I am using mmWave Studio 2.00.00. I do not know what firmware version, how can I check?

    Best,

    Pawel

  • Hi Pawel,


    We could replicate the issue when using your script with mmWave Studio 2.0.0.2.

    Looking into the code responsible for recording, the packet size is not sent out by the DCA1000 over ethernet but added to the bin file by the DCA1000 DLL during recording.

    That explains why your .bin file is missing those offsets and why post-processing manually works for you.

    Best Regards,

    Anand

  • Hello,

    So currently I have the sequence number and the number of bytes in my packets, and am missing the packet size. What is the utility of having both number of bytes and packet size? Isn't packet size just the size in bytes of the header plus the number of bytes specified in the header?

    Thanks,

    Pawel

  • Hi Pawel,

    The FPGA sends out only the sequence number, byte count and data, while the DLL appears to add the data size into the raw file while saving it.

    We agree this is redundant - you could just be using the byte count. However that's how the data file structure has been coded and the corresponding PacketReorderZerofill utility has been written accoringly.

    Best Regards,

    Anand