This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

understanding BLE_EVT_TX_COMPLETE

Can we use the tx_complete.count given with BLE_EVT_TX_COMPLETE as an indication on how many packets were sent out from the last ended connection interval?

thank you jing

Parents
  • I can confirm that the latest MCP and SD application TX buffers are not working at all. The window size seems to be limited to only 1 packet, which maybe indicates that the new MCP is not acknowledging all outstanding packets.

    I've messed around with this all night, and then came by this thread. I've now downgraded the MCP, and everything is working as expected.

    My test is simply setting the connection interval at 1000ms and send a handle value notification every 250ms (20 byte payloads). I also use an internal queue of 20 packets in case where the connection is interrupted, which happens now and then - a little to often maybe, as the high water mark of this buffer is peaking at 14 (plus 6 in the TX buffers) every few minutes. This corresponds to 5 times the connection interval, which is not quite as good as I would like. The only explanation I can think of, is that I'm only connecting every 1000ms, which might be harder for the MCP and SD to sync on.

    One final note is that, the call to get the available TX buffers is returning 7, but I've never seen a BLE_EVT_TX_COMPLETE event report a count of more than 6. What about the last one?

Reply
  • I can confirm that the latest MCP and SD application TX buffers are not working at all. The window size seems to be limited to only 1 packet, which maybe indicates that the new MCP is not acknowledging all outstanding packets.

    I've messed around with this all night, and then came by this thread. I've now downgraded the MCP, and everything is working as expected.

    My test is simply setting the connection interval at 1000ms and send a handle value notification every 250ms (20 byte payloads). I also use an internal queue of 20 packets in case where the connection is interrupted, which happens now and then - a little to often maybe, as the high water mark of this buffer is peaking at 14 (plus 6 in the TX buffers) every few minutes. This corresponds to 5 times the connection interval, which is not quite as good as I would like. The only explanation I can think of, is that I'm only connecting every 1000ms, which might be harder for the MCP and SD to sync on.

    One final note is that, the call to get the available TX buffers is returning 7, but I've never seen a BLE_EVT_TX_COMPLETE event report a count of more than 6. What about the last one?

Children
No Data
Related