BLE // Central_HR + Peripheral_HR, possible bug in subscribe process?

[Dermiste]

Hi all,

I am trying to get Central_HR to work with Peripheral_HR, I'm on windows and my board is efr32xg24_dk2601b.

Using 2 actors I tried the following configurations:

• Actor 1&2= Bluetooth Shell. Follow GATT documentation, Actor 1 register test services, Actor 1 can connect to it and see data when Actor 2 uses "notify"
• Actor 1=Peripheral_HR , Actor 2 =custom python central using [Bleak](https://github.com/hbldh/bleak). Actor 2 can connect to Actor 1 and see heart beat readings.
• Actor 1=Peripheral_HR, Actor 2 =Central_HR. Actor 2 can connect to Actor 1 but then disconnection occurs with error code 0x08, it then all repeats in a loop:
  
• Lastly, Actor 1=Peripheral_HR, Actor 2= Bluetooth Shell. Actor 2 can properly connect to Actor 1, subscribe to notification and see heartbeat going through

So, it seems it should all work properly since main components works fine appart as well as with various subparty scripts, why would they not work together? Any idea much appreciated.

[Dermiste]

After intense digging and comparing .config with the pristine one of Bluetooth Shell it seems that enabling BT_REMOTE_VERSION does the trick, should this be included in the default config for the board somewhere?

@jhedberg any suggestions? :)

[jhedberg]

After intense digging and comparing .config with the pristine one of Bluetooth Shell it seems that enabling BT_REMOTE_VERSION does the trick, should this be included in the default config for the board somewhere?

@jhedberg any suggestions? :)

I don't see the remote version being used for anything special in the Bluetooth host code (which is why it's not enabled by default), so it seems like this might be some incompatibility or bug on a lower layer. 0x08 is the code for "Connection Timeout", btw. If you have access to an air sniffer, that might give some more information. @cvinayak @jori-nordic FYI

[Dermiste]

I wish I had that kind of equipment but that's not the case unforunately, I hope that behaviour will help you make things more robust though

[cvinayak]

Enabling or disabling version exchange should not impact connection stability. I suspect an inherent issue in the controller being masked due to change in data transfer sequence by the introduction of the version exchange.

Enabling version exchange by default will be a overhead and will introduce latencies in completing connection setup by host and subsequent data transfer.