Massimiliano-solutiontech
commented
6 months ago The issue still persists with v5.2-beta2
Open Massimiliano-solutiontech opened 6 months ago
Massimiliano-solutiontech
commented
6 months ago The issue still persists with v5.2-beta2
cmorganBE
commented
5 months ago I'm seeing similar behavior here with extended advertisements on esp32-s3 with a very close copy of bleprph example. Sometimes it will retry and join, other times it looks like the stack is locked up and the device stops showing up in lightblue.
luomanruo
commented
5 months ago Hi, I conducted tests under the following conditions and did not encounter the same issue. Could you provide more information, such as the version of iOS phone: Iphone 13 mini ios version: 16.3.1 IDF branch: v5.1.2 and v5.2-beta2 example: bleprph app: nRF Connect and LightBlue
luomanruo
commented
5 months ago This issue can be reproduced under the following conditions: ios version: 17.1.2 app: nRF Connect and LightBlue It is likely introduced by the iOS version upgrade.
Massimiliano-solutiontech
commented
5 months ago I have problems with:
Massimiliano-solutiontech
commented
3 months ago @luomanruo now I have problems even with Android:
Massimiliano-solutiontech
commented
3 months ago @luomanruo v5.2.1 doesn't solve the issue
Massimiliano-solutiontech
commented
3 months ago @luomanruo by disabling the extended advertising the connection is successful
zhaoweiliang2021
commented
3 months ago @Massimiliano-solutiontech Hi, We have reproduced this issue under the following conditions: iOS version: 17.3.1 Application: nRF Connect Apk.
We captured the air interface information and found that the problem was actually a problem with the 17.3.1 iOS version. The reason is that the iPhone did not continue TX LL data within the 28.75-32.5ms time range after sending the AUX_CONNECT_REQ PDU, and did not send data packets in the subsequent interval, which caused the slave disconnected with 0x3e reason. We checked the correctness and sending time of the aux_conn_rsp pdu responded by the ESP32C6 chip, and its behavior complies with the Bluetooth Spec requirements. So we believe this is an issue on this version of iOS.
zhaoweiliang2021
commented
3 months ago @Massimiliano-solutiontech Since there are currently no Motorola G14 (Android 13) phone for retesting, the cause of this problem cannot be known for the time being. We have not reproduced it using other mobile phones, so I would like to ask if you can provide the air interface information of this problem? According to the debug log you provided, the reason for the failure is still 0x3e.
Massimiliano-solutiontech
commented
3 months ago @zhaoweiliang2021 what kind of tool are you using? Since I haven’t anything to debug Bluetooth I have to buy it
Thanks
Massimiliano-solutiontech
commented
3 months ago @zhaoweiliang2021 since it’s a timing problem, at least on iOS, can I adjust that range (28.75-32.5ms) in esp-idf?
zhaoweiliang2021
commented
3 months ago @Massimiliano-solutiontech The device I used is an Ellisys Vanguard Bluetooth Protocol Analyzer. There are other devices on the market that can capture over-the-air packet information, such as the Frontline X240 Wireless Protocol Analyzer, Frontline Sodera, and other Bluetooth protocol analyzers. You can decide whether to buy based on the function description.
zhaoweiliang2021
commented
3 months ago @Massimiliano-solutiontech Hi, This time range is determined by aux_connect_req, which is determined by the iPhone, so we cannot adjust it in esp-idf and need to wait for the new ios version to fix it.
Massimiliano-solutiontech
commented
3 months ago @zhaoweiliang2021 thanks I'll look into those tools. As of now there is a workaround? The phones with these issue are increasing. The only reason why I'm using Bluetooth 5.0 is for the EXT ADV the 31 bytes of the 4.1 are too small for my purposes (I need to advertise the service UUID, name (variable min 10 max 15), VID and another UUID as PID)
Massimiliano-solutiontech
commented
3 months ago @zhaoweiliang2021, I will attend the Embedded World Fair from April 9th through April 11th. Can we arrange a one-on-one session with you or some of your colleagues?
Thanks.
zhaoweiliang2021
commented
3 months ago @Massimiliano-solutiontech According to the application description and later expansion, using 5.0 adv is indeed the best solution, but some old mobile phones do not support 5.0 adv, or new versions of mobile phones may have some compatibility issues. For your application scenario, a workaround solution is provided for your reference: On the basis of using 5.0 adv, add an additional legacy adv, and put the address information of the legacy adv in the 5.0 adv data. Based on the scanned address information, the mobile phone establishes a connection with the legacy adv of the corresponding address if the filtering conditions are met. If the connection is successful, stop 5.0 adv.
zhaoweiliang2021
commented
3 months ago @Massimiliano-solutiontech Kindly reach out to sales@espressif.com via email. Our sales team will get in touch with you as soon as possible.
Massimiliano-solutiontech
commented
3 months ago @zhaoweiliang2021 thanks for the fast reply and the comprehensive support that you are giving to me, I wrote an email to the sales (let's wait). I took a look on the tools that you suggested and are quite expensive to just address a bug, what about the HackRF One R9?
Also I wrote a sample iOS app and I can successfully connect to the ESP32-C6 using the EXT ADV (I don't know why though) but the nRF Connect still not working
Regarding the Motorola G14 even with a custom app I can't connect to it
On the basis of using 5.0 adv, add an additional legacy adv, and put the address information of the legacy adv in the 5.0 adv data. Based on the scanned address information, the mobile phone establishes a connection with the legacy adv of the corresponding address if the filtering conditions are met. If the connection is successful, stop 5.0 adv.
I don't know how to do that, can you provide me a code example starting from the bleprh example?
lisir233
commented
3 months ago Hi, @Massimiliano-solutiontech please refer to this patch for modification, in this patch I added an additional legacy adv, and put the address information of the legacy adv in the 5.0 adv data. bleprph_multi_adv.patch.If you have any questions, feel free to leave a comment!
Massimiliano-solutiontech
commented
2 months ago @lisir233 by doing so I'm limited to 31 bytes of adv data. I don't understand if this whole issue is related to Apple and some Android vendors or to the esp Bluetooth stack. I need to solve this as soon as possibile, I have IoT products that can't be configured
lisir233
commented
2 months ago Hi, @Massimiliano-solutiontech Analyzing the packet capture data, we believe this is an IOS 17.1.2 issue. We have also reproduced this issue when connecting to IOS devices using other BLE chips, so all we can do is try to turn on an additional legacy adv to bypass this issue.Can you tell more details about the application? For example, is it necessary to send more than 31 bytes of ADV data in the application scenario?
Massimiliano-solutiontech
commented
2 months ago @lisir233 thanks for the quick reply, I'm also facing issues with iOS 16.7. Yes I need more than 31 bytes, currently I'm advertising:
lisir233
commented
2 months ago Thank you for your answer, in the above provided example, we can put the broadcast data in the 5.0 ADV, the 5.0 ADV can put up to 1650 bytes of data, the 4.2 legacy ADV is only used to establish a connection with the Iphone.
Massimiliano-solutiontech
commented
2 months ago @lisir233 I tried to put more data in connectable_legacy_adv_pattern but then an assert is failing. Where I’m supposed to put that data?
Massimiliano-solutiontech
commented
1 month ago Hi @lisir233 can you give me the hint to solve the issue of the above comment? Thanks
lisir233
commented
1 month ago HI, @Massimiliano-solutiontech due to the limitations of the Bluetooth specification, legacy ADV packets can only carry a maximum of 32 bytes of data, if you need to include more than 31 bytes of data in a broadcast packet, please use the 5.0 ADV, which can be configured in the nimble stack using the API ble_gap_ext_adv_configure interface.
With the above multi-broadcast example, we can finally realize the following effect:
ESP32 initiates both an extended ADV and a legacy ADV . The extended ADV is used to carry the data and the legacy ADV is used to establish a connection.
zhaoweiliang2021
commented
1 month ago @Massimiliano-solutiontech Hi, Thank you for providing the motorola G14 phone for us to reproduce the issue.
We captured the air interface information and found that the problem is a Bluetooth issue on the Motorola G14 phone. The reason is that after sending the AUX_CONNECT_REQ PDU, the iPhone did not continue to send TX LL data within the 17.5ms to 22.5ms time range and did not send data packets in the subsequent interval, causing the slave to disconnect with reason 0x3e. We checked the correctness and sending time of the aux_conn_rsp pdu responded by the ESP32C6 chip, and its behavior complies with the Bluetooth Spec requirements. Therefore, we believe this is an issue with the Motorola phone. The solution for the BLE 5.0 connection issue on the Motorola G14 phone is the same as the solution provided earlier for the iOS (17.3) connection issue.
Massimiliano-solutiontech
commented
1 month ago @zhaoweiliang2021 It’s a pleasure to help you, the community, and Espressif to make even better products. Thanks also for the detailed explanation. I understand that it’s not a problem with the ESP-IDF Bluetooth stack, but right now I have several customers facing this issue. Is it possible to create a patch with an option to make the ESP more tolerant of timing issues? Is it also possible to contact vendors like Motorola, Lenovo, Apple, and Samsung to inform them of the issue with their stack?
It’s very important for us to resolve this, as we sell worldwide more than 60k products per year, all powered by your chips
(we can continue this discussion via email if you prefer)
Thanks for understanding
zhaoweiliang2021
commented
1 month ago @Massimiliano-solutiontech Does the example my colleague provided earlier work for you? We believe it is the quickest way to bypass this issue. If it does not meet your needs, could you provide more specific requirements for the patch you want? This will help us review and evaluate it further.
Massimiliano-solutiontech
commented
1 month ago @zhaoweiliang2021 unfortunately not, I need to put more than 32 bytes in the adv data. I would like to know if it’s possibile to have a patch in which the esp-idf Bluetooth stack doesn’t respect the correct timings (so the phones with bad Bluetooth implementation can connect too). Of course it must be an opt-in option. I don’t have such experience with Bluetooth so please suggest me what’s the best way to solve this
zhaoweiliang2021
commented
1 month ago @Massimiliano-solutiontech Hi,
"I would like to know if it’s possibile to have a patch in which the esp-idf Bluetooth stack doesn’t respect the correct timings (so the phones with bad Bluetooth implementation can connect too). " Since the phone acts as the central role and has the initiative, the chip cannot affect the behavior of the phone by modifying its own behavior, so we cannot provide the patch you want.
I don’t have such experience with Bluetooth so please suggest me what’s the best way to solve this For your use case, the previously provided patch demonstrates how to place data into a 5.0 advertisement while still using legacy advertising for the connection. This indirect method aims to resolve the phone connection issue. Does the provided patch still not meet your requirements? If so, could you further explain the reasons?
Answers checklist.
IDF version.
v5.1.2
Espressif SoC revision.
ESP32-C6
Operating System used.
macOS
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-C6-DevKitM-1
Power Supply used.
USB
What is the expected behavior?
iOS to immediately connect to the ESP32-C6 as Android does
What is the actual behavior?
ESP32-C6 keeps disconnecting with error
574and after a while (20 to 40 seconds) successfully connectsSteps to reproduce.
bleprphexamplenRF ConnectandLightBlue)Debug Logs.
More Information.
With Android it connects immediately