[Qeustion] data send delay error

RE: [Qeustion] data send delay error

seungwooWoo — Wed, 05 Dec 2018 06:55:55 GMT

I will contact you with further inquiries.

I tested with another device.

SAME = MTU 256 , packet 1534

1. Nexus5(central) -> Nexus5(BleUARTPeripheral)

- https://github.com/thejeshgn/BleUARTPeripheral/tree/v1.0(source code)

12-05 15:47:15.609 W 8770 lbs_tag_service woo onCharacteristicWrite = 340total = 1543 status = 0
12-05 15:47:15.610 E 2940 bt_att gatt_act_write() failed op_code=0x52 rt=143
12-05 15:47:16.252 W 8770 lbs_tag_service woo onCharacteristicWrite = 341total = 1543 status = 0

The same congested error occurs.
But it only takes 0.7 seconds to send the next pack.

2. Nexus5(central) -> nrf52810(ble_app_uart)

11-27 17:24:24.416 W 15138 lbs_tag_service woo send4 packetInteration = 212total = 1543
11-27 17:24:24.418 E 2945 bt_att gatt_act_write() failed op_code=0x52 rt=143
11-27 17:24:26.236 W 15138 lbs_tag_service woo send4 packetInteration = 213total = 1543

The same congested error occurs.

But it only takes 2 seconds to send the next pack.

Can you tell why this difference appears?

Thanks you

RE: [Qeustion] data send delay error

seungwooWoo — Tue, 04 Dec 2018 10:22:41 GMT

Hi, Aleksander Nowakowski

Thank you very much for your quick reply.

I am currently testing through nexus5.
The phone supports DLE.
Therefore, even if the MTU size exceeds 200 bytes, it operates normally.

I think it is the fastest way to use Write Without Response.

However, there is a delay due to GATT_CONNECTION_CONGESTED, which occurs when the queue is full on the bluetooth bleed stack.

I say precisely

GATT_CONNECTION_CONGESTED does not occur, and we ask if we can send packet continuously.

Even if MTU size and interval are modified, the same GATT_CONNECTION_CONGESTED occurs.

https://issuetracker.google.com/issues/37121017

And above, it seems that the android queue is full.

How can I fix this?

Thank you

RE: [Qeustion] data send delay error

Aleksander Nowakowski — Mon, 03 Dec 2018 09:23:14 GMT

What phone are you using for testing?

The 2nd approach you mentioned:

> 1 ~ 100 packet (WRITE_TYPE_NO_RESPONSE) ->101 packet (Write type default) -> 102 ~ 200 (WRITE_TYPE_NO_RESPONSE)

should not increase the transfer time a lot. When you send the data with WRITE_TYPE_NO_RESPONSE, the onCharacteristicWrite callback is called when the data are written to the outgoing queue, not when they were sent. That's why it may seem as they were send super fast, while you just have filled the buffer, which is then processed much slower. The delay, which you get by putting the WRITE_TYPE_DEFAULT in the middle, or also at the end, is just to ensure that he buffer gets empty before you put more data into it. So the transfer indeed would be a bit slower, as the Write With Response takes the whole connection interval (1 packet instead of 6 is sent), but prevents from overflowing the buffer.

To increase the speed you may experiment with different connection intervals, MTU, try phones supporting DLE (Data Length Extension, Android 6+ required, but not all phones support it). In longer connection interval you may fit more data if they are send without response.

Also, the slowest connection interval supported by Android is 11.25 ms (until Lollipop it was 7.5ms).

And remember, that you may send only MTU-3 bytes using Write Without Response in a single write. For example, the default MTU is 23, which is 20 bytes of data available.

RE: [Qeustion] data send delay error

Hung Bui — Mon, 03 Dec 2018 09:17:40 GMT

Hi,

Could you let me know what was your actual speed you achieved in your test ?

Note that there is no guarantee that you will have 6 packets per connection at interval 12ms. It's depends on the phone and the size of your MTU. We need to have a sniffer trace to see what exactly happened over the air.

When writing with response, you can't achieve highest throughput because that command can't be stacked, you need to wait for the first one to finish be fore you send the next one.

RE: [Qeustion] data send delay error

seungwooWoo — Mon, 03 Dec 2018 08:06:04 GMT

Hi, Aleksander Nowakowski

Answer Thank you very much.

If I look at the speed I currently calculate

Number of packets sent per second

1packet (MTU byte) * 6(Number of packets sent per Android 1 interval, nexus5 6) * 83(interval 12ms) = 500 packet

However, as mentioned above, there are about 200 GATT_CONNECTION_CONGESTED problems.

So I have two questions.

1. Does Nordic chip affect processing speed?

- I use nrf52810, ble_app_uart ( default , interval 12ms, buffer 256)

2. Can you improve on android side?

- I tried the test in the following way.

1 ~ 100 packet (WRITE_TYPE_NO_RESPONSE) ->101 packet (Write type default) -> 102 ~ 200 (WRITE_TYPE_NO_RESPONSE)

In this case, the same problem does not occur.

However, it takes longer to transfer.

In my opinion, the best way is to send data continuously with WRITE_TYPE_NO_RESPONSE with an MTU of 244 bytes.

But this causes GATT_CONNECTION_CONGESTED to be a problem.

Can you tell me in detail what you need to fix or fix to improve?

Thanks

RE: [Qeustion] data send delay error

Aleksander Nowakowski — Fri, 30 Nov 2018 13:47:46 GMT

Hi seungwooWoo,

On Android, after calling writeCharacteristic, you have to wait for onCharacteristcWrite callback before you may call next operation, e.x. next writeCharacteristic. We recommend using our BLE Library (https://github.com/NordicSemiconductor/Android-BLE-Library/), which handles all the queueing for you + handles most common problems. There is alternative, for example RxAndroidBLE etc.

If you are sending data from the Android without response, on Android 5 and older you also have to ensure that the buffer doesn't get overflown. To do this you may either send each n-th (n=~200) packet as Write With Response (Write type default), or use some other synchronization mechanizm. In DFU we were using notifications, which we called PRN (Packet Receipt Notification). They had to be sent every n packets from the peripheral when the device has received all n packets. Since Marshmallow the Android handles buffer overflow on it's own and it just postpones the onCharacteristicWrite callback until the buffer is available again.

Best Regards,

Aleksander