No, there is no API to wait or put the application thread to sleep. This is because some of the stack layers (L2CAP, GATT, ATT, SMP) run in the same thread context as the application and putting the app thread to sleep will affect profile layers. I suggest you use state machines to implement the same functionality.
OK. Fair enough …
I am receiving and parsing all data correctly from the sensor side and then I attempt to send out the notifications and code appears to think the same number of records received from the sensor are the same number of notifications that were sent out … but when I look at data using an nRF Utility I don’t see that it received ALL the data .. does Broadcom have some sort of iOS app or Android app that can be used to verify data is making it to a smartphone?
I am not sure if this is a BLE issue or something else
So I see in cases where data seems to be lost that the output of blecm_getAvailableTxBuffers is either 0 or -1
So as a refresher …
I send 501 results from the meter both received over uart and parsed correctly for checksum errors
Then, this data is sent over BLE by sendNotification method and it appears that is also gets here 501 times
But I see the blecm_getAvailableTxBuffers going to 0 or -1 …
Could this be my issue?
There are only a limited number of buffers in the system. You must first check if there are buffers available before sending out notifications. blecm_getAvailableTxBuffers() is the right function to call to check if there are buffers available in the lower layers.
The rate at which data will go out over the air depends on the connection interval and the number of retransmissions due to interference. If you overwhelm the TX buffers, then packets will be dropped.
Is there a MAX number of TX buffers?
I always see the number 15 as a start point … is there a way to increase this also?
The default is 15 and there is no API to increase this number. Since the device will always use all transmit opportunities (there may be multiple RX/TX pairs every connection interval depending on whether there are more packets to transmit or not) available to it, if you run out of TX buffers, it generally means that you may be generating more data than the max throughput possible with that connection interval. Given that the minimum connection interval is 7.5mS, the max throughput you will get at the GATT layer is ~90kbits/s. SDK 2.0.1 has a sample speed_test application and a corresponding peer application that runs on Windows that can be used to test the max throughput at different connection intervals.