Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 50 subscribers
  • Views 1847 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

L2CAP packet sent several times

Gregory POIRIER
Prodigy 60 points
Other Parts Discussed in Thread: CC2540

Hi,

I am using the SensorTag hardware with the sample SensorTag application modified with the Data throughput examples:

http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput

I am sniffing the BLE packets with TI's SmartRF packet sniffer.

The setup is then:

- 1 SensorTag as BLE peripheral

- 1 CC2540 USB dongle as BLE Central

- 1 CC2540 USB dongle as sniffer

During the transfer, I can that L2CAP packets are transmitted several times (0x1EE data packet in next picture)  without seeing any problem in the packets. Can anybody explain me why these packets are retransmitted?

Best regards,

Greg

  • 0
    TI__Genius 10955 points

    The L2CAP packet from the slave has been retransmitted because the master requested it, as can be seen by the NESN number in the packet with P.nbr. = 1519. In this case, I believe the retransmission was done because the master had gone out of storage space the first time the packet was received. This can be seen by SN in Packet 1519 being 0, while SN in packet 1517 was 1. If packet 1518 had been lost by the master because of a CRC error or sync failure, packet 1519 would have had the same SN as packet 1517.

    You may also observe retransmissions because of errors in the received packets, even if you don't see any errors reported in the packet sniffer, as the transmission path between the devices is not the same as the transmission path from a device to the packet sniffer.

  • 0 in reply to hec
    Prodigy 60 points

    Hi,

    Thank you for your answers

    The peripheral and the central are in close proximity (2cm).

    I understand that the retransmission may be due to the master firmware (not enough memory) and not only due to air loss. It does mean that the 5.6Kbytes/s transfer rate that I see could be higher if the central firmware was better.

    And effectively, I control the central USB dongle with BTool which is lost and just can't get all messages in its log window.

    Do you know how we could change the HostTestRelease firmware to avoid these storage problems?

    Best regards,

    Greg

  • 0 in reply to Gregory POIRIER
    TI__Genius 10955 points

    I am not that familiar with the user interface of the stack, but I don't think you can change this. It has to do with processing time in the 8051 as well as buffer space.

  • 0 in reply to hec
    Prodigy 60 points

    I was able to modify the HostTestRelease firmware (in the processEventsGATT function). The packets are received by the BLE stack but not sent through USB to BTool shortening then the USB dongle processing time.

    No more packet loss are seen and I was able to get a 6.8kbytes/s data rate.

    Thank you for your answer.

    Greg