BlueNRG Maximum Realized Payload data rate?

[Scott Löhr]

Posted on December 18, 2014 at 23:39

We are evaluating the BlueNRG module as a candidate for our next generation h/w and need to verify the actual payload data rate that can be achieved as a BLE Peripheral using Notification (i.e. unacknowledged server packets) with the maximum user payload size of 20 bytes. Our current h/w solution succeeds in sending Notifications to our proprietary iOS application, using our proprietary 128-bit profile, at > 250-Hz.

I recently attended the ST seminar deomonstrating the Nucleo M0-to-BlueNRG solution, and a very ambitious data throughput was quoted, but I did not write it down. Nevertheless, the seminar and the demo boards attracted this evaluation by our company and I have implemented out proprietary profile on the Nucleo M0 host of the BlueNRG using the sample project from the seminar as a template: STM32Cube_FW_L0_V1.1.0\Projects\STM32L053R8-Nucleo\Bluetooth_LE\SampleApp\EWARM This implementation can only achieve ~10-Hz (i.e. sending a 20-byte Notification every 100-msec). At 20-Hz the call to aci_gatt_update_char_value() fails more than 1 out of 4, and at 100-Hz, it fails more than 1 out of 2 calls. I noted that the implementation of modules like hci.c seem more mature in the code in BlueNRG DK 1.6.0 So I ported all of that infrastructure to the sample app from the seminar, and still the same throughput. I also note that this sensor sample app in the BlueNRG DK 1.6.0 BlueNRG DK 1.6.0\Projects\Project\SensorDemo\EWARM In the above example, the Accel data is only sent at 5-Hz. So is the BlueNRG only capable of sending a Notification at only 5-10-Hz? If not, then where can I find an example that proves the maximum payload data rate? In the current demo that I am using, the Nucleo M0-to-BlueNRG, where should I look for the choke point? Is there a faster way to drive the SPI link for example? Note that not only does our current h/w achieve > 250-Hz success sending Notification to the same iOS App using the same proprietary profile being attempted on the Nucleo, but many articles on BTLE payload throughput indicate that it should be possible to achieve 100-Kbps --> 12.5-KBps --> 640 20-byte Notifications per second. Please advise with any input or suggestions...   #bluenrg-payload-throughput

[Scott Löhr]

Posted on January 07, 2015 at 23:54

Hello - Are there any data specifying the max payload data rate for this X-NUCLEO-IDB04A1 BlueNRG part? Perhaps a sample app demonstrating how to achieve a max payload rate using 20-byte, unacknowledged Notifications?

In an attempt to squeeze out more throughput than mentioned previously, I bought the NUCLEO-F401RE to drive the BlueNRG (instead of what I had been using, the free

NUCLEO-L053R8

that I received in the ST seminar). It seems to do a little better, perhaps as good as the current solution that we are using, but definitely not the huge boost in throughput that I thought I heard mentioned in the seminar. On a side-note, in an additional step to try to get more throughput, I tried upgrading the image in the IDB04A1 from what it had, FW v6.3, to v6.4 by trying both of these images: bluenrg_6_4_Mode_2-16MHz-XO32K.img bluenrg_6_4_Mode_2-32MHz-XO32K.img The BlueNRG now does not even advertise over the air or connect by BLE. I suspect that I need some images built for this part. Any advice on how to just go back to v6.3? Thanks,

[Scott Löhr]

Posted on March 25, 2015 at 05:45

Hello - driving the BlueNRG with a

NUCLEO-F411RE does not help either. Just trying to send a 20-byte Notification at 200-Hz starts to get failures in bluenrg_gatt_aci.c:

 tBleStatus aci_gatt_update_char_value(...) The error is caught here:  if (status) {      asm(''NOP'');  //ggg     return status;   } And the bad status is this: #define BLE_STATUS_INSUFFICIENT_RESOURCES   (0x64) Is it possible that the BlueNRG keeps automatically going back to sleep (if so, is there a command to force it into always awake/high-throughput mode)? Is there some other way to get max throughput out of this BlueNRG? Thanks,

[sal]

Posted on July 22, 2015 at 05:25

I am also seeing low data rates, particularly when using aci_gatt_update_char_value() as well, but I can see that it is returning BLE_STATUS_TIMEOUT after it calls hci_send_req(), but the char is still getting updated correctly even with that timeout. That timeout might be causing the low data rate, but I can't seem to find out why it is timing out.