You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a peripheral device which supports gatt over LE and gatt over BR/EDR. Various gatt services are registered in the sdp record for bluetooth classic.
nRF cannot use GATT over BR/EDR. In earlier versions this did work.
Using our own iOS app, GATT over BR/EDR just works fine.
To Reproduce
When doing:
1 bluetooth classic pairing and connect
2. Open nRF connect
3. scan and connect to my peripheral
Then nRF connect automatically uses gatt over BR/EDR. The display in nRF shows "Connecting ...." forever. On device side I can see that the connection was successful over gatt over BR/EDR and some characteristics are read. When I then swipe the screen to see the characteristics in nRF, the app crashes.
Versions (please complete the following information):
I am using iOS 13.2.3 and nRF 2.1 Build 270
Additional context
[Edit]
Meanwhile I did a bluetooth trace. When connecting the iPhone to our device, iOS seems to read some gatt characteristics right away.
Then I open nRF, scan and press connect. After 1 or 2 seconds I also see the gatt ping pong between the phone and our device. Everything seems to work fine. I can clearly see that for example the phone retrieves the device name from the device information service. But still, nRF shows "Connecting ..." and does not show the serivices.
Using our own app, I can also see the gatt message flow which looks pretty the same as before with nRF.
Sadly I am not allowed to send you the bluetooth trace files. If you have a question, do not hesitate to ask.
The text was updated successfully, but these errors were encountered:
some background informaton: support for GATT via BR/EDR was silently introduced by Apple in iOS 13.1 (and it was super-buggy...), with 13.2 it became a bit more stable.
From a developer's perspective it's completely transparent: you scan, connect, discover services as with BLE but iOS may choose to use the BR/EDR transport if available.
In the CB API there is no indication whatsoever that BR/EDR is used. Also, there's no way to specifiy which transport to use when calling connectPeripheral(). So it's a typical "supposed-to-just-work" approach.
As such, I agree that nRF Connect should work the same way, no matter if BLE or BR/EDR is used for GATT.
philips77
transferred this issue from NordicSemiconductor/Android-nRF-Connect
Dec 3, 2019
I have a peripheral device which supports gatt over LE and gatt over BR/EDR. Various gatt services are registered in the sdp record for bluetooth classic.
nRF cannot use GATT over BR/EDR. In earlier versions this did work.
Using our own iOS app, GATT over BR/EDR just works fine.
To Reproduce
When doing:
1 bluetooth classic pairing and connect
2. Open nRF connect
3. scan and connect to my peripheral
Then nRF connect automatically uses gatt over BR/EDR. The display in nRF shows "Connecting ...." forever. On device side I can see that the connection was successful over gatt over BR/EDR and some characteristics are read. When I then swipe the screen to see the characteristics in nRF, the app crashes.
Versions (please complete the following information):
I am using iOS 13.2.3 and nRF 2.1 Build 270
Additional context
[Edit]
Meanwhile I did a bluetooth trace. When connecting the iPhone to our device, iOS seems to read some gatt characteristics right away.
Then I open nRF, scan and press connect. After 1 or 2 seconds I also see the gatt ping pong between the phone and our device. Everything seems to work fine. I can clearly see that for example the phone retrieves the device name from the device information service. But still, nRF shows "Connecting ..." and does not show the serivices.
Using our own app, I can also see the gatt message flow which looks pretty the same as before with nRF.
Sadly I am not allowed to send you the bluetooth trace files. If you have a question, do not hesitate to ask.
The text was updated successfully, but these errors were encountered: