6 Replies Latest reply on May 15, 2014 11:45 AM by legic_1490776

    How best to implement bulk data transport

    legic_1490776

      For our application we want to be able to download a larger amount of data from the tag upon request (>>22 bytes).

      Is there a suggested best approach to doing this?

       

      We're looking at designing the protocol based on the tag sending 4 notifications per connection event, with acks returned in a writable characteristic.

       

      For this purpose it would be great to be gain more insight on how notifications work within the stack.

       

      How large is the queue of unsent notifications in the stack?  Is there any way to find out how many unsent notifications are currently pending?  What happens if there is no room in the queue?


      Is there any way to receive a callback to trigger after a notify is sent?

      Is there any way to receive a callback when a connection event is over?


        • 1. Re: How best to implement bulk data transport
          MichaelF_56

          Lewis,

           

          Is this still an issue, or was it answered in another post?

          • 2. Re: How best to implement bulk data transport
            legic_1490776

            This has never been answered to my knowledge.

             

            Based on our experiments it appears that after sending 4 notifications, further notifications are silently dropped.

            If there is only buffer space for 4 notifications, is that a global limit or per-characteristic?

             

            It would be great to have confirmation on exactly what happens in this case, and if there is a recommended way to avoid it. Because of the need for some sort of flow control via responses from the master, it's very difficult to put 4 packets in each connection interval.

             

            It would also be nice if there was a way to query the stack to find out how much buffer space remains (i.e. if 1 notify has been sent and there are 3 more slots, assuming that is how it works).

             

            Is there any way to receive a callback after a connection interval has passed?

            In that case we might be able to queue up 4 more notify packets so they are ready to go on the next interval.

            • 3. Re: How best to implement bulk data transport
              VictorZ_46

              If you are using SDK 2.x, please check speed_test application.  There are several modes/tests, but in

               

              TEST_NOTIFICATIONS mode the device sends notifications as fast as possible.

               

              You can check number of available buffers using blecm_getAvailableTxBuffers() function.  I think it is 14.  And you are right, if you try to send a notification when there are no buffers, it will silently fail.

              • 4. Re: How best to implement bulk data transport
                legic_1490776

                Thanks, victor.

                 

                Unfortunately as I am using the 20732S module, I cannot use SDK 2.0.  (Is this correct?)

                However perhaps the example from the 2.0 SDK might still work if it does not rely on new API calls.

                 

                I'll try blecm_getAvailableTxBuffers() and see what it reports.

                 

                Any idea whether there's a callback after a connection interval completes?

                • 5. Re: How best to implement bulk data transport
                  ArvindS_76

                  > Any idea whether there's a callback after a connection interval completes?

                  Not in SDK 1.1.0. There is an optional API available with SDK 2.0 where you can register a callback that will be invoked either right before or right after the connection event. However, this is not available in SDK 1.1.0.

                   

                  > In that case we might be able to queue up 4 more notify packets so they are ready to go on the next interval.

                  When a slave, there is no guarantee that the master will poll multiple times in a connection interval, even when the MD bit in the header of the notification packet is set because the master could have other tasks (scans/advertisements/other connections - classic or low energy). So the best way is to check with the stack using blecm_getAvailableTxBuffers().

                   

                  > However perhaps the example from the 2.0 SDK might still work if it does not rely on new API calls.

                  Yes, you should be able to port most of the speed_test sample app to SDK 1.1.0, except the part where it stuffs the notifications with using ulp_getRand(), which is not available in SDK 1.1.0. But you should be able to generate some other sequence of data in its place.

                  1 of 1 people found this helpful
                  • 6. Re: How best to implement bulk data transport
                    legic_1490776

                    THanks, this answers my questions.