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(...)).
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.
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?
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: