6 Replies Latest reply on Apr 9, 2014 7:30 PM by ArvindS_76

    Waiting for an event using API

      Does the API possess a "wait for object" or "wait for event" type of fucntion in lieu of using a flag in a while loop?


      For example if we are waiting for all data to transfer over a peripheral uart communication with attached sensor but do not want to proceed until all data is received/parsed AND we are using a uart callback versus polling is there some type of system event/wait object we can use besides using a flag in a while loop .. also does this wait mechanism provide a bailout timeout if too much time has passed?







        • 1. Re: Waiting for an event using API

          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.

          • 2. Re: Waiting for an event using API

            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

            • 3. Re: Waiting for an event using API

              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?

              • 4. Re: Waiting for an event using API

                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.

                • 5. Re: Waiting for an event using API

                  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?

                  • 6. Re: Waiting for an event using API

                    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.