android Android-nRF-UART app connection interval/bandwidth configuration

[Vala]

Hi,

I hope is not a double post. I am doing a throughput evaluation with my custom board and an app that is based on the Nordic's Android UART app through NUS service and wanted to make sure that this app is capable of handling the requirements for a fast data transfer: connection interval, bandwidth connection event extension. Please let me know if there are other parameters that matters.

Vala

Edit: I guess the bandwidth, which defines the number of packets per connection interval, is basically defined and restricted by the Android OS. Am I right?

[Hung Bui]

Hi Vala,

Correct, requestConnectionPriority() is used to update connection parameters, connection interval in particular.

You can force the peripheral to send connection parameter request at the start of the connection but accepting that request or not is up to the central. And different phones will behave differently on this. So requestConnectionPriority() should be called, just to ensure the phone will give more priority for the connection.

Yes, you should use buffer, and also you should implement a packet notification the same way that we implemented on our DFU OTA protocol. So that the central after sending a number of packets say 20 packets, will stop and wait for a notification from the peripheral telling it's ready to continue to receive.

I assume "bandwidth" you mentioned here is related to the "mid" "high" "low" bandwidth we set with the opt API ? If it is then it's the Nordic's term only related to configuration in the softdevice.

I don't think there is an equivalent "bandwidth" on Android, except for the "priority" in the requestConnectionPriority(). But I am not 100% sure if the requestConnectionPriority() only to set the connection interval or it also does something with the number of packets per connection event.

[Hung Bui]

If you use write command to send data from peripheral to central, then the server is on the central. The central will send notification as ACK for packet it receives.

If the central get an overflow, it can not process the data, it can simply send the notification back telling at which packet number it has processed and the peripheral will have to resend packet starting from there. It's important that the sender have to wait for that packet receipt notification on every X packets.

I don't think a disconnection is neccessary .