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

sd_ble_gatts_hvx cache

1、how long will it take for me to cache?

Once I call sd_ble_gatts_hvx, assuming tx_queue is large enough, how long can I cache data to softdeivce?

For example, I called sd_ble_gatts_hvx once, and then called again after 5ms. Can I cache successfully,Or the data has been sent out? Why?

2、Cached data and the size of the actual packet sent

If ATT_MTU is set to 247, LL payload = 251, tx_queue = 2, should I get NO_RESOURCE once if I call sd_ble_gatts_hvx(buffer, buffer len = 100) third times ?

This time actually sent the package which payload len = 200byte?

Thanks

Parents
    1. How long? Doesn't make sense. Tx queue size is partially configurable in Nordic Soft Device and how much time it takes to flush it over BLE that's impossible to say as it depends on how BLE connection link performs at that moment (what is the interval, what is packet loss etc.) So forget about time, there is no guaranteed time when it comes to radio like BLE.
    2. Tx queue size in Nordic Soft Device should have "slots" so on (G)ATT layer it can hold certain number of packets regardless the size. So you can get BLE_ERROR_NO_TX_BUFFERS error code in response if you try to push some more outgoing packets but there is no available Tx slot on (G)ATT layer in the SD. The size doesn't matter.
  • Yes, you are closer. The SD with link management lives in its own time and you as application have only indirect evidence about what is happening and when. You should think from opposite side: your APP wants to send some data so you provision as many Tx packets (depending on what role you have it might be WRITE or HVX or something else) as possible to SD and wait. They should go out in time frame of 0 to +-2 connection intervals but you are not sure where exactly in that time sequence you are (because precise timing of the link is known only to lower layers). As soon as stack frees some buffers (= they are acknowledged by LL from the other side as successfully transferred) and as soon as it has time to let APP to do some processing you get asynchronous event call-back to your even t handler with TX_COMPLETE class of events (which one depends on which methods you use).

    (1/3)

Reply
  • Yes, you are closer. The SD with link management lives in its own time and you as application have only indirect evidence about what is happening and when. You should think from opposite side: your APP wants to send some data so you provision as many Tx packets (depending on what role you have it might be WRITE or HVX or something else) as possible to SD and wait. They should go out in time frame of 0 to +-2 connection intervals but you are not sure where exactly in that time sequence you are (because precise timing of the link is known only to lower layers). As soon as stack frees some buffers (= they are acknowledged by LL from the other side as successfully transferred) and as soon as it has time to let APP to do some processing you get asynchronous event call-back to your even t handler with TX_COMPLETE class of events (which one depends on which methods you use).

    (1/3)

Children
No Data
Related