Fastest peripheral to central small packet transfer (nRF52)

RE: Fastest peripheral to central small packet transfer (nRF52)

endnode — Thu, 24 Aug 2017 11:02:06 GMT

No, sd_ble_gatts_hvx is the only way how to issue GATT Notify method from GATT Server role so that is correct. Do you check return value (error code)? How do you handle when SD has no free Tx buffer left? Do you have any log from radio analyzer/sniffer to see how exactly is transfer achieved on link layer? Without that you are just guessing and dancing around the black box.

RE: Fastest peripheral to central small packet transfer (nRF52)

Colt — Thu, 24 Aug 2017 10:57:38 GMT

Thank you for the answer. When you say "calling HVX transport" what function are you referring to exactly? We are currently using return "sd_ble_gatts_hvx(p_nus->conn_handle, &hvx_params);" Is there a better set of functions to use?

RE: Fastest peripheral to central small packet transfer (nRF52)

run_ar — Thu, 24 Aug 2017 08:41:02 GMT

Could you be using indications? Try to use notifications instead, it should be possible to send multiple packets in each connection event also at 7.5 ms events.

RE: Fastest peripheral to central small packet transfer (nRF52)

endnode — Thu, 24 Aug 2017 07:06:48 GMT

You won't get anything much better then Nordic throughput examples I'm afraid. If you care about "latency" then you should go for 7.5ms connection interval (as you did) and simply try to play with throughput and MTU extension parameters to fine the best experimentally. If you group data to longer streams and then cut into packets of MTU-3 size it should be close to "ideal" throughput over GATT, also calling HVX transport each time you have packet ready (whatever timing it is) and simply doing it until you get error code back and then restart the same state machine on TX_COMPLETE event works well for me, hard to say what are you doing differently without seeing the code, debug log from the BLE FW and log from BLE radio...