nRF51822 BLE - Android and iOS app development

[Paul Tay]

Hi Nordic,

We are working on Android and iOS apps. Currently using S3 with Android 4.3 and Note to communicate with nRF51822. Baud rate of 19200bps for our serial communication.

Reference to Kristin post dated Nov 20, 2013 on topic: 51822 BLUETOOTH

Q1. How can we synchronize the transmission of 4 packets per connection interval? Based on sample code nRFUART, do we send out consecutively packet of 20 bytes after previous packet was sent out using writeRXCharacteristic ? Or should it pause for 10ms before sending out the next packet?

Q2. We have encountered abnormal behavior on S3 and Note after using writeRXCharacteristic at time interval of 20ms or lower. Is there a way to read transmission status in Android app before using writeRXCharacteristic to send out 20 bytes?

Q3. In our project, data size transmitted can be more than 100kbytes. Is there any further recommendation on Android and iOS app that we need to take note in order to increase data rate and avoid abnormal behavior on devices?

Thank you.

Regards, Paul

[Stefan Birnir Sverrisson]

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.

[Paul Tay]

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

[Stefan Birnir Sverrisson]

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.

[Paul Tay]

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?

[Stefan Birnir Sverrisson]

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