• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 441 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1310: Empty Packets in response to Data Request

Eugene Peng
Intellectual 620 points
Part Number: CC1310

Hi,

I am seeking explanation and insight in a strange behavior.

The coordinator is sometimes responding to a Data Request from an end device by sending a data packet with empty payload.

This data packet with empty load is not a message that was queued by the application in the transmit buffer.

Please see attached wireshark file. See the empty data at packet number 99 (also marked in the file). This is in contrast to a valid data at packet number 958 (also marked)

It is a busy network with 28 nodes, all sending data once per 10 seconds.

TI 15.4 Stack version: 2.20

The coordinator is a TI COP firmware, interfaced with Linux application.

Appreciate any insight you can share.

Eugene

Please rename the file extension to .pcapng. This forum does not allow uploading file with that extension.

sniffer_capture2.txt

  • 0
    TI__Genius 12415 points
    This is normal behavior of the stack. this is being done due to the fact that in sub1GHz we cannot support ACKs done automatically by the radio and instead we have to do them in software and they take longer.
    To give you a bit more detail this happens because once you schedule data to be sent out from the collector to a sleepy node then the "pending frame" bit gets set for the ACKs to all devices(which forces them to poll again and open their receiver since they assume there is pending data for them) because we are forced to process the ack in software and there is not enough time to keep a list of all devices in the network and keep track which device has pending data or not and at the same time send the data over the air on time. Basically this will cause all devices to open their receiver thinking that there is pending data for them and we send the NULL data packet to make these sensor turn their receivers off as soon as possible.
  • 0 in reply to Hector_r
    Intellectual 620 points

    This is helpful. Thank you.

    Why is it that in sub 1GHz, you must process ACK in software? Is this different for 2.4 GHz?

  • 0 in reply to Eugene Peng
    TI__Genius 12415 points
    Yes this is different in 2.4GHz, there the radio handles the acks automatically and you will not see NULL data packets unless the collector is sending a broadcast to sleepy nodes or if there are too many packets queued for many sleepy devices.

    If I remember correctly in sub1GHz this limitation appears because we support a later version of the IEEE 802.15.4 specification which defines enhanced acks and this acks cannot be handled by the radio and also the radio has no way of differentiating between enhanced and not enhanced acks therefore they need to be handled in software.