Samsung ble data speed

[hanglee]

Hello,

We are using nrf52832 and SDK15.3 in our product, which sends about 7.4K bytes data every second to an Android phone.

4 ble devices are connected to the phone and we tested the data speed on Samsung phone A51 (Android 12), A71 (Android 10) and Samsung Tab S8 (Android 12). 

In A51 and A71, the phone can receive all the data from 4 devices in full speed. However,  in tablet S8 it cannot receive all the data from 4 devices and the data rate in some devices drops to 2~3K data per second. 

Any ideas about why data speed in S8 is lower than that in A71 / A51, where S8 is a newer model and using a better processor when compared to A71 / A51. 

On the other hand, is there any suggestions to increase the data rate in S8?

Thank you for all your assistance.

Regards,

Hang

[Karl Ylvisaker]

Hello Hang,

Are you familiar with the nRF Sniffer tool? It would be very helpful if you could capture a sniffer trace of the communication with a phone that is working as expected, and another sniffer trace of the communication to the A8 device.
This way, we can see exactly what is being sent between the devices, and why one is much slower than the other.

This could likely be caused by a difference in the connection parameters that are being used in the connection, which is determined by the central (phone) device. The phone could choose longer connection intervals as a power saving measure, for example.

in tablet S8 it cannot receive all the data from 4 devices

Could you elaborate on what you mean by this? Are you not able to receive the data at all from some devices, or is it only that it is received slowly?

Best regards,
Karl

[hanglee]

Hello Karl,

Thanks a lot for your help. I haven't use nRF sniffer tool before, is there any tutorial we can refer to?

For the S8 problem, when I connect 4 devices, S8 can only receive 2K ~ 3K bytes data from each device per second (the expected data rate is 7K bytes/second).

In Nordic side, we only send next data packet when we receive BLE_NUS_EVT_TX_RDY event in nus_data_handler. I guess S8 is not fast enough to receive the data so the data rate is decreased.

Best regards,

Hang

[Karl Ylvisaker]

Hello again, Hang

hanglee said:

Thanks a lot for your help.

No problem at all, I am happy to help! :)

hanglee said:

I haven't use nRF sniffer tool before, is there any tutorial we can refer to?

You can read more about how to install and use the sniffer in the nRF Tools section on Infocenter.

hanglee said:

In Nordic side, we only send next data packet when we receive BLE_NUS_EVT_TX_RDY event in nus_data_handler. I guess S8 is not fast enough to receive the data so the data rate is decreased.

That could be the case here, yes. Or that the S8 is limiting the throughput as a powersaving measure when connected to multiple devices concurrently.
Since the connection parameters are determined by the central, and the central alone, there really is not a lot you can do on the peripheral side to increase this other than to have the data available at all times.
Are you writing the application that will be running on the S8? Is there any way you can set the priority of the connection to LOW LATENCY, for example?

Best regards,
Karl

[hanglee]

Hello Karl,

Yes, we want our Android application can run in S8 (hopefully can run in other Android device).

Karl Ylvisaker said:

Is there any way you can set the priority of the connection to LOW LATENCY, for example?

Is the priority of connection can be set in Android application only? If yes, which Android API can be used to set the connection to low latency? 

Thanks again for your help.

Best regards,

Hang

[Karl Ylvisaker]

Hello again, Hang

I unfortunately do not have any personal experience in developing Android applications, but I recall having spoken to somebody who worked with this that mentioned an Android API to request a more resources for the connection through the use of a LOW LATENCY descriptor during the initiation of the connection.

hanglee said:

Is the priority of connection can be set in Android application only?

Yes, as mentioned it is the central device that must decide which connection parameters that will be used, and this is usually also limited by the device OS in order to save power - i.e it does not matter if your peripheral requests a lower connection interval, because the phone OS might not allow it.

Best regards,
Karl

[hanglee]

Hello Karl,

I've installed the nRF Sniffer tool and tried to check the ble communication. However, only advertisement messages are captured and no packet can be captured after the device is connected to the phone. Could you give us some suggestion about how to capture the ble packet after connection?

Thanks again for your kindly help.   

Here is the log:

Best regards,

Hang

[Karl Ylvisaker]

Hello Hang,

Glad to see that you have the sniffer up and running!

When you have selected the device in the device dropdown menu (like you have), the sniffer will follow this specific device. If this device then enters into a connection the sniffer will sniff the key, and also follow into the connection.
However, if the device is already bonded with the central it will not exchange keys on air, and so the sniffer can not follow them.
These different cases are also mentioned in the Sniffer documentation on the Infocenter - please have a look to see which case that aligne with your application, and use the described procedure to make the sniffer follow into the connection.

Which type of encryption / pairing process are you using for your EMGS device?

For future reference, please share the sniffer trace files directly, instead of screenshots. Screenshots inhibits us from properly looking through the trace on our end.

Best regards,
Karl

[hanglee]

Hello Karl,

I've selected the device in dropdown menu before connecting the device to the phone, the sniffer can finally capture the packets after connection established.

Thanks again for your help.

Best regards,

Hang

[Karl Ylvisaker]

Fantastic - great to hear that you now are able sniff the communication between your devices.

Please let me know if you have any questions to the interpretation of the trace, and don't hesitate to open another ticket if you should have any other questions or issues in the future! :) 

Best regards,
Karl