• State Verified Answer
  • Replies 4 replies
  • Subscribers 67 subscribers
  • Views 3767 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 106788
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE_GAP_EVT_CONNECTED when not connected. too early?

Wojtek

I am using S110 v8, But I am having this problem since the very first stage of developement, so earlier versions of S110 also.

The problem is that sometimes I am advertising (connectable) by my peripheral -> I try to connect by central -> I receive CONNECTED event on central but I don't receive any events at all at S110 (just like there was no connection attempt) -> I receive immediate disconnect on central.

I am not using any device manager, bonding etc. Just simple scanning and connecting. It works fine at 90% of attempts, but sometimes this situation just happens.

I don't think this is central (s120) problem, because I am having that problem with other Bluetooth Smart device + bluez linux driver also.

It looks like SoftDevice S110 sends some BLE_GAP_EVT_CONNECTED to central too early or something like that.

Is any of you observing similar problems?

Parents
  • 0

    When central device is in Initializing state it is waiting for the advertisement packet to time correctly to send a connect request. After the central has sent this connect packet, it will immediately switch to connected state irrespective of what has happened to that packet (that is if peripheral received that packet or not). This event is propagated up to the application, but in the case the connect request packet got corrupted or lost, then there will be no connected packets arriving from peripheral to central and eventually the central would have connection timeout and disconnect (and hence your subsequent disconnect on central).

    If this is not consistently happening and if it is happening with other devices too, then I would suspect that you probably are working in a lot of noise with respect to bandwidth in which BLE operates.

Reply
  • 0

    When central device is in Initializing state it is waiting for the advertisement packet to time correctly to send a connect request. After the central has sent this connect packet, it will immediately switch to connected state irrespective of what has happened to that packet (that is if peripheral received that packet or not). This event is propagated up to the application, but in the case the connect request packet got corrupted or lost, then there will be no connected packets arriving from peripheral to central and eventually the central would have connection timeout and disconnect (and hence your subsequent disconnect on central).

    If this is not consistently happening and if it is happening with other devices too, then I would suspect that you probably are working in a lot of noise with respect to bandwidth in which BLE operates.

Children
No Data
Related