LAUNCHXL-CC1352R1: TI 15.4 Packets on Wireshark

KArtik,

Let me run some tests and contact one of the engineers that works with this tool to get a better understanding of what is going on.

Regards,

AB

Hey Kartik,

My apologies for the late response.

Kartik 3 said:

When I checked the bytes transferred over the air to the Collector in Wireshark, it showed 148 bytes, more than double of what was being sent at the reporting interval. I understand that the formation of the packet and the Protocol's overhead will add a few more bytes to the data, but does that add another 70 odd bytes? 

It looks like the 148 bytes you are referring to are not relevant to what's being sent over the air. This number looks like it represents the number of bits capture over the UART terminal (i.e. sent from our sniffer to Wireshark via the SmartRF Sniffer 2 software).

Kartik 3 said:

Also, in the packet segregation in Wireshark, under TI Packet Info, I can see that the Payload length is 104 Bytes. What length is that?

This length represents the length of the sensor message plus the metadata used to send the packet over the air (i.e. security headers, panIDs, channel info, power info.. etc). If you'd like a more detailed look at the packet being sent over the air, take a look at api_mac.h and find the variable:

/*! MCPS data request type */
typedef struct _apimac_mcpsdatareq

Kartik 3 said:

Can anyone help me out with the packet segregation or point out to any specific document that will provide the details on how the 15.4 packets are formed and sent?

Here's a screenshot of my sniffer log, showing the Data in a separate drop-down. Note that this matches the length seen in sendSensorMessage(). Under the Info column, make sure you're selecting the Data packet and not an Ack.

Please let me or AB know if you have any follow up questions!

Hi Ammar,

Thank you for your detailed explanation. I will mark this thread as resolved.

But I have a a couple of quick follow up questions,

1) I can see UDP section in the screenshot, what exactly is that?

2) Does the mode of operation(FH mode/Beacon mode etc) vary the protocol overhead(metadata) or is it fixed for 15.4 protocol?

Thanks,

Kartik

Hey Kartik,

Kartik 3 said:

1) I can see UDP section in the screenshot, what exactly is that?

I'm not familiar with the UDP protocol unfortunately. It is a networking protocol that lies on top of the Internet Protocol, like TCP. The UDP section in the screenshot is likely being displayed because of my Wireshark settings (similar to why we see the Internet Protocol v4 section).

Kartik 3 said:

2) Does the mode of operation(FH mode/Beacon mode etc) vary the protocol overhead(metadata) or is it fixed for 15.4 protocol?

The protocol overhead does vary depending on which mode you're in. For example, FH mode uses different frame formats, as you can see in api_mac.h. These overheads are not directly related to individual sensor messages you send (i.e., your sensor message packet size should be the same out of box in each mode). The difference here is in the overall throughput of each mode, if that makes sense.