1

I am developping an application on the STM32 SPBTLE-1S module (BLE 4.2). The module connects to a Raspberry Pi.

When the connection quality is low, a disconnection will sometimes occur with error code 0x28 (Reason: Instant Passed) before the connection timeout is reached.

Current connection settings are:

Conn_Interval_Min: 10

Conn_Interval_Max: 20

Slave_latency: 5

Timeout_Multiplier: 3200

Reading more on this type of error, it seems to happen when "an LMP PDU or LL PDU that includes an instant cannot be performed because the instant when this would have occurred has passed." These paquets are typically used for frequency hopping or for connection updates. In my case, they must be frequency hoping paquets.

Any idea on how to prevent these disconnections caused by "Instant Passed" errors? Or are they simply a consequence of the BLE technology?

Xavier B
  • 13
  • 3
  • Which side here is master and which device is slave? Do you perform any connection parameter update? Have you used a BLE sniffer do catch the packets? – Emil Feb 28 '20 at 21:19
  • The configuration consists of 5 SPBTLE-1S slaves connected to the Raspberry Pi master. Only one connection update is made from each device 2 seconds after they have connected. The disconnections occur minutes or hours after the connection parameter updates. I have not used a BLE sniffer to catch the packets. Would it be useful in this case? – Xavier B Mar 01 '20 at 16:43
  • The most likely issue is that the Bluetooth controller of the Raspberry Pi (since it is master), sends out spontaneous `LL_CHANNEL_MAP_IND` packets, with the instant field maybe a bit too soon in time. Then some packet losses happen past the instant. Since you can't modify the BT firmware (it's closed source), the only thing you could try is different connection parameters. You could try increase slave latency. – Emil Mar 01 '20 at 21:37

1 Answers1

1

Your question sounds similar to this one

In a nutshell, there's only two possible link layer requests that can result in this type of disconnect (referred to as LL_CONNECTION_UPDATE_IND & LL_CHANNEL_MAP_IND in the latest v5.2 Bluetooth Core Spec)

If you have access to the low level firmware for the bluetooth stack on the embedded device, what I've done in the past is increase the number of slots in the future the switch "Instant" is at so there's more time for the packet to go through in a noisy environment.

Otherwise the best you can do is try to limit the amount of times you change connection parameters to make that style of disconnect less likely to occur. (The disconnect could still be triggered by channel map change but I haven't seen many BLE stacks expose a lot of configuration over when those take place.)

chrisc11
  • 814
  • 7
  • 7
  • I don't think I have the ability to do that on the SPBTLE-1S's side since the BlueNRG stack only gives access to the function's prototypes. Would it be possible on the Raspberry Pi through Bluez? – Xavier B Mar 01 '20 at 16:47
  • Unfortunately you'd probably run into the same issue on that side. Bluez is usually just talking to actual radio using the Host Controller Interface (HCI) socket and fiddling with these settings is not exposed over any of the standard commands in the core spec. – chrisc11 Mar 01 '20 at 17:39
  • 1
    Well, `LL_PHY_UPDATE_IND` could probably also cause it. – Emil Mar 01 '20 at 21:41
  • True, good point! But that's a bluetooth 5.x feature so shouldn't be the cause on the SPBTLE-1S which only supports 4.2 – chrisc11 Mar 01 '20 at 22:36