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
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
Hi there,
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.
Yes, as mentioned there is an issue with the current MCP and throughput. This has been communicated to the developers.
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.
Even earlier versions of the MCP sometimes do not quite manage to give full throughput, due to limitations on the USB transport layer. Have you tried with other central devices?
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?
This is actually expected and normal: The additional packet is there so that the app can queue up an extra packet ahead of the next connection interval, therefore achieving the full 6 packets/event throughput.
Regards,
Carles
Hi there,
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.
Yes, as mentioned there is an issue with the current MCP and throughput. This has been communicated to the developers.
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.
Even earlier versions of the MCP sometimes do not quite manage to give full throughput, due to limitations on the USB transport layer. Have you tried with other central devices?
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?
This is actually expected and normal: The additional packet is there so that the app can queue up an extra packet ahead of the next connection interval, therefore achieving the full 6 packets/event throughput.
Regards,
Carles
