I had a awesome trouble with the ble when update my firmware, with the same code in app and firmware, the samsung s10(android 10) and s7edge(android 8.0) can send 510+K files in about one minute, but the honor V20(android 10) and xiaomi cc9(android 10) need about five minute!! the Connection Event is already to fill the Connection Interval(11.5ms) .
Hello,
Is it possible to capture a sniffer trace of one of the "fast" phones and one of the "slow" phones and upload the traces here? (I don't need the entire 5 minute trace of the slow one. Only until it has started transferring the packets for a while, but feel free to capture all 5 minutes if you want to).
I suspect that there isn't actually anything wrong. Perhaps some of the phones actively request an increased MTU, while others do not. A sniffer trace would be able to tell whether this is the case).
Are you able to tell from debugging what payload size you are able to transfer in one packet with each of the phones?
How do you determine that the connection interval is actually 11.5ms in each case? Remember that it is the central that has the final saying on the connection interval. What application do you use to transfer these files? Is it something you wrote? If so, is it possible to share some snippets on how you actually transfer the files?
Best regards,
Edvin
Hi,
I'm sorry to reply you so late! when i try to capture a sniffer trace, i have a trouble with that, now i don't known what happens. if there is any progress, i will tell you at once !!
Best regards,
Jack
For sniffer traces you can use nRF Connect. It is fairly easy to set up and use, and it only requires an extra nRF5 DK. Please check the readme file in the download, and the documentation for the nRF Sniffer on Infocenter.
Another thing you can check is the process where you send the files. Try to log some info on the packets that are queued. What is the length of the packets, and how often are they queued. What is the difference between the two scenarios?
Hi,
I have got the sniffer traces details. 5554.Samsung.cfa3302.honor.cfa
Is it useful ?
Best regards,
Jack
Hi,
I have got the sniffer traces details. 5554.Samsung.cfa3302.honor.cfa
Is it useful ?
Best regards,
Jack
Actually, not really. I am not that good at this sniffer tool (.cfa). The nRF Sniffer is easier to read (probably because I am familiar with it).
However, this is a very open question. You say that it takes more time with some phones to transfer a certain file. I assume the application that is transferring this file, which is running on the nRF is something that you wrote. Is that correct? If so, where do you send the actual packets (notifications)? How do you determine:
1: How often to send the packets?
2: The length of the packets?
Best regards,
Edvin
Hi,
Actually，I have find the key issues , but I can't explain that .
1: The Connection Interval set in firmware is 7.5-11.5ms and the phone likely accept this according to the log . But in one Connection Event ,the samsung can send 3 packets, the honor send 1 packets only.
If i increase the Connection Interval , the samsung can send more , the honor still send 1 packets.
2: The length of the packets I used is 64bits.
would you give me some ideas?
Best regards,
Jack
You can try to increase the MTU size, and use longer packets, if you are limited to one packet per connection interval.
Longer packets is overall a good thing for throughput, because the payload/header ratio will increase with longer packets.
Best regards,
Edvin
I think increase the MTU size isn't a good idea for me, because we would support many communication way through the same logic. Is there any other way?
I am still not sure whats going on. I guess you are queuing the packets equally fast whatever mobile phone it is connected to. Based on the logging information, is there a difference in MTU/packet size based on what mobile you connect to?
