nRF51822 BLE - Android and iOS app development

RE: nRF51822 BLE - Android and iOS app development

Stefan Birnir Sverrisson — Thu, 22 May 2014 13:06:47 GMT

Hi Paul

What kind of phone are you using? With Android, you should be able to send 4 packets per connection interval. Normally, the connection interval should be 7.5 ms for Android phones, but for Samsung phones, this could be different.

Are you feeding the android stack with packets fast enough to test the connection?

I attach an example UART code that tests the throughput from Android to nRF51822. Perhaps you can try it and see what you find out. I also add the nRF51 UART example which should be the same as in the SDK.

Please be noted that this is a very simple and ugly speed test, just to prove that we can send and receive up to 4 packets per conn interval both way. Sometimes you have to click send on the phone app twice, I don't know why the call back never arrived. Also if you change the number of packet to 1000 instead of 300, strange thing also happens on the phone, that not all 1000 packet was transfered (the call back was lost after a while). The easiest way to verify is to use a sniffer to see what is transfered on air.

ble_app_uart - TestThroughPut.zip

nRFUART_TestThroughPut.zip

RE: nRF51822 BLE - Android and iOS app development

Paul Tay — Thu, 22 May 2014 09:52:13 GMT

Hi Stefan,

I have tried writeCharacteristic method with WRITE_TYPE_NO_RESPONSE option. But it didn't do what I am looking for.

To pack 4 packages of 20 bytes within the connection interval (says 40ms) and transmit them out from Android to nRF51822. (See the attached image)

I wonder if can it be done on Android?

RE: nRF51822 BLE - Android and iOS app development

Stefan Birnir Sverrisson — Thu, 22 May 2014 07:12:42 GMT

Hi Paul

Looking at the Android BLE API, I suspect you can send write commands by calling BluetoothGattCharacteristic.setWriteType method and choose the WRITE_TYPE_NO_RESPONSE option before calling writeCharacteristic method.

RE: nRF51822 BLE - Android and iOS app development

Paul Tay — Thu, 22 May 2014 06:44:52 GMT

Hi Stefan,

In our project, we want to maximize throughput of sending large size data from smart phone devices (Android/iOS) to nRF51822. We have not find a suitable method yet.

But in your last paragraph, you mentioned write command which does not include acknowledgement that can boost the throughput. Can this be done on Android?

I can only see writeRXCharacteristic, BluetoothGatt API - writeCharacteristic function and its corresponding callback.

Thanks.

Regards, Paul

RE: nRF51822 BLE - Android and iOS app development

Stefan Birnir Sverrisson — Wed, 21 May 2014 12:53:37 GMT

Hi Paul

Q1: I am not aware of that you can get notification on when the Android stack has sent buffered packets, see Q2.

Q2: I am not aware of that you can read the status of the connection from the Android BLE stack. After you call writeRXCharacteristic, you will receive a callback from the Android stack if the packet has been queued up for transmission in the BLE stack. If the callback is positive, there is buffer space available and you can just go ahead and give another packet to the BLE stack. If the callback is negative, it means that the stack buffer is full and you must try again later to buffer up the same packet. I could recommend to start a timer before suspending the thread and let the timer wake up the thread again later in order to retry.

Q3: Which direction do you transfer this data, from the nRF51822 to the Android, or in the opposite direction. You can realize expected data rate on this thread when sending data with notifications.

Write requests from the central will not give you much throughput, see data througput section in the S110 Softdevice Specification, available on our web site. Write commands will however give you higher througput.

If you use write request from the central you can only send one packet in every second connection interval. This is because there is an acknowledgement required for each packet from the slave before another packet is sent. You can boost your throughput from the central by sending write command instead which does not include acknowledgement. You can also choose to have a GATT server residing on the central device instead of the peripheral device, enabling the central to send notifications.