6 Replies Latest reply on Oct 29, 2015 2:25 AM by llynch Branched from an earlier discussion.

    Hello_Sensor modification (con't)



      Hello Jake.

      Per this discussion: Hello_Sensor modification

      You say you can send up to 20 bytes at once (20*8=160bits).

      I have a sensor giving out 14 bit data. If i store the lower 8 bits as a UINT8 and store the upper 8 bits as another UINT8 (16 bits per data sample).

      160/16=10, I could send 10 data samples (16 bits long) or 20 UINT8 composing of 8 MSB and 8 LSB of each data sample at one time.


      db_pdu.pdu[0] = byte_1_MSB;

      db_pdu.pdu[1] = byte_2_LSB;

      db_pdu.pdu[2] = byte_3_MSB;

      db_pdu.pdu[3] = byte_4_LSB;

      db_pdu.pdu[4] = byte_5_MSB;

      db_pdu.pdu[5] = byte_6_LSB;

      db_pdu.pdu[6] = byte_7_MSB;

      db_pdu.pdu[7] = byte_8_LSB;

      db_pdu.pdu[8] = byte_9_MSB;

      db_pdu.pdu[9] = byte_10_LSB;

      db_pdu.pdu[10] = byte_11_MSB;

      db_pdu.pdu[11] = byte_12_LSB;

      db_pdu.pdu[12] = byte_13_MSB;

      db_pdu.pdu[13] = byte_14_LSB;

      db_pdu.pdu[14] = byte_15_MSB;

      db_pdu.pdu[15] = byte_16_LSB;

      db_pdu.pdu[16] = byte_17_MSB;

      db_pdu.pdu[17] = byte_18_LSB;

      db_pdu.pdu[18] = byte_19_MSB;

      db_pdu.pdu[19] = byte_20_LSB;

      All i need to do is call the below function then and it will send of 20 bytes from db_pdu.pdu?

      bleprofile_sendNotification(HANDLE_HELLO_SENSOR_VALUE_NOTIFY, (UINT8 *)db_pdu.pdu, db_pdu.len);


      if i need to send 500 samples(16 bits long) i will need the repeat the above 50 times to send all 500 samples (500samples/10bytes at a time=50)?



        • 1. Re: Hello_Sensor modification (con't)

          What you're saying sounds correct, with one caveat. When you need to repeat the sending 50 times, you cannot call this function faster than the notifications are being sent. Notifications are sent at fixed intervals that the client and slave agree on. If you call the function to send a notification twice within one interval, only the most recent push will be sent.


          There is a way to register for a callback some ms before a connection event. This rules out loss of information and ensures that you will only call the function once per interval. Please see wiced_sense.c for an example of this callback (blecm_connectionEventNotificationEnable(...)).



          • 2. Re: Hello_Sensor modification (con't)

            I think it is more  subtle than that.  There is a xmit queue with about 15 entries available when nothing is on it.  You can call sendNotification()  multiple times and each time will add a xmit packet to the queue.  There is a function you can call to tell you how many entries are available in the queue at any instant in time.  Using this function you can avoid overflowing the queue by calling sendNotification too frequently.  I don't know what happens when you overflow the queue, but most likely the send packet is dropped in the bit bucket if the queue is full.  At that data rate you really aren't getting much benefit from BLE and you might want to switch to regular Bluetooth for higher throughput and it will probably use about the same amount of power.  The power savings in BLE comes when you connect only infrequently... not really designed for streaming but you can do it.  Probably best to use a 20 byte characteristic and send 5 samples per packet..  or send 4 samples and a counter (the counter would be to make sure you are not dropping packets).  There is a 'Long Characteristic' feature in the recent SDK version, but I have not tried it and anyway it just breaks the long characteristic into multiple packets of smaller (20 some bytes) length which you can easily do yourself.


            At 500 Hz you are pushing the limit of what can be accomplished with BLE.  I'm not sure you will be able to stream that much.  Make your connection interval as small as possible.  I think Android smart phones allow a shorter connection interval than the iOS does which won't go below 20 or 30 msec connection intervals if I recall correctly... whereas I hear Android goes down to 7.5 msec.

            • 3. Re: Hello_Sensor modification (con't)

              Thanks for the very detailed help userc_7511

              • 4. Re: Hello_Sensor modification (con't)

                Thank you for the reply. I am not continuously running the module at 500hz.


                It will need to take a sample for 2 seconds (500hz per second) so i will end up with 1000 16 bit words. Once i am then finished sampling i would like to send the 1000 samples. There is no extreme rush sending all the data, when the module is ready will do.


                This may need to be repeated once per minute for up to 30 mins. Its all down to user really.


                At the moment I am able to use the interrupt to record 1000 samples each of which are 16 bits. I can display the results over the uart.


                But when i send them over bluetooth i could be missing up to 100 samples. I am guessing i can calling the bleprofile_sendNotification to frequently.

                i get the message "lel2cap fail to allocate buffer".


                Could you help me with setting up the correct wait to ensure all my samples are sent correctly?

                • 5. Re: Hello_Sensor modification (con't)

                  The best approach to take on this is to sync your _sendNotification calls with your connection interval. This way you call it once per connection interval and you are able to rule out contention. To do this please see the following two posts where it is described in detail:


                  Receiving notification without content and without sendNotification


                  Re: Can you sync the connection interval with the fine timer?



                  • 6. Re: Hello_Sensor modification (con't)



                    Hello Jake,


                    I had a look through the following links and couldn't see a straight forward answer.