2

My application is able to connect to the BLE peripheral(which is an OBDII/J1939 device) device successfully.

2018-01-24 14:58:38,413 INFO  LogUtil -     GATT Server Status = (0) : BLE_HCI_STATUS_CODE_SUCCESS(0x00)
2018-01-24 14:58:38,414 INFO  LogUtil -     GATT Server New State = (2) : STATE_CONNECTED
2018-01-24 14:58:38,414 INFO  LogUtil - Connected to GATT server.

Application started communication with the device but after some time it received GATT server disconnection message in onConnectionStateChange in callback implementation of BluetoothGattCallback . Below are the logs from application:

2018-01-24 15:07:46,396 INFO  LogUtil -     GATT Server Status = (40) : BLE_HCI_INSTANT_PASSED(0x28)
2018-01-24 15:07:46,397 INFO  LogUtil -     GATT Server New State = (0) : STATE_DISCONNECTED
2018-01-24 15:07:46,398 INFO  LogUtil - Disconnected from GATT server.

Not able to find any reason behind BLE_HCI_INSTANT_PASSED status code.

Any help on this will be helpful.

Ravi Sharma
  • 873
  • 7
  • 24
  • Does this happen all the time or has it happened only once? If you read the link layer specification in Bluetooth Core spec, you can see that they may happen during connection parameter updates and channel map updates if the connection is unstable. – Emil Jan 26 '18 at 00:12
  • @Emil No this is not happening all the time. Sometimes connection is not stable. Connection breaks with HCI error code like BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT. We are not changing connection parameters after connection is established. – Ravi Sharma Jan 29 '18 at 04:44
  • I think the best way to debug this is to use an air sniffer. Then you see each packet and why it fails. – Emil Jan 29 '18 at 07:24

1 Answers1

7

When data is being transmitted over BLE, data transfers can only start at sync points in time known as "connection events". At the BLE link layer there are couple special requests that can be made which are relative to these sync points. They are:

  • LL_CHANNEL_MAP_REQ - A request to change the BLE channels being transmitted on. Bluetooth chips will change the channel map based on the noise in the environment to try to limit packet drop.
  • LL_CONNECTION_UPDATE_REQ - A request to change the frequency of "connection events" (known as the "connection interval"). This is done to achieve better throughput/latency or save more power.

Each of these Link Layer requests when sent over the air contains an "Instant" to change. The "Instant" is the "connection event" in the future to apply the change.

At the Link Layer, BLE is reliable. This means each Link Layer packet must be ack'd by the other side. In a noisy RF environment, it's possible a link layer packet may require a couple retries to actually send. This means the packet could arrive many "connection events" after originally intended.

If one of the packets mentioned above is received after the "Instant" the changes were supposed to be applied, by definition the BLE chip must disconnect with reason 0x28 (Instant Passed)

For additional details on the topic, the Bluetooth Core Specification available from the Bluetooth SIG website is a good reference:

chrisc11
  • 814
  • 7
  • 7