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,
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?
You will get an BLE_EVT_TX_COMPLETE every time a packet you have queued for transmission using one of the GATTC/GATTS/L2CAP APIs has been successfully transmitted to the peer. If you keep pulling events from the SoftDevice fast enough, you should get a BLE_EVT_TX_COMPLETE at the end of each connection interval informing you of the user packets that have been sent over the air.
However, that "count" field only counts user packets, and not system packets, meaning that it won't always correspond to the actual packets that have been sent over the link, depending on the type of protocol activity.
Carles
I am queuing 20-bytes notification pkt via sd_ble_gatts_hvx() until it returns BLE_ERROR_NO_TX_BUFFERS.
Testing using PCA10000 with MCP as central, i am not able to get BLE_EVT_TX_COMPLETE count of more than 1.
With the softdevice document describing upto 6 packets per interval, i was expecting to see a larger complete count given that the queue has been maximized (check'd that sd_ble_tx_buffer_count_get() returns 7). Unless, the central device used can only support 1?
Up to how many packets per connection interval can the PCA10000 with MEFW_nRF51822_0.9.0_firmware support?
By the way, i am using s110_nrf51822_5.2.1_softdevice.
thank you jing
I am queuing 20-bytes notification pkt via sd_ble_gatts_hvx() until it returns BLE_ERROR_NO_TX_BUFFERS.
Testing using PCA10000 with MCP as central, i am not able to get BLE_EVT_TX_COMPLETE count of more than 1.
With the softdevice document describing upto 6 packets per interval, i was expecting to see a larger complete count given that the queue has been maximized (check'd that sd_ble_tx_buffer_count_get() returns 7). Unless, the central device used can only support 1?
Up to how many packets per connection interval can the PCA10000 with MEFW_nRF51822_0.9.0_firmware support?
By the way, i am using s110_nrf51822_5.2.1_softdevice.
Sounds like the issue is indeed the MCP and not the SoftDevice. I have been told the latest MCP firmware severely limits the amount of data that can be transferred.
Could you try with another central? MEFW 0.8.0, A smartphone or a PC should do.
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?
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
