- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I'm using WICED SDK 3.5.2 on a board with a BCM943341 WiFi/BT combo chip.
I have previously been using the conn_id in the event_data's connection_status and attribute_request to distinguish between different clients, mostly Android. The code is pretty similar to the ble_hello_sensor example, and this has been working fine, until recently.
I have tried to revert the code to a previous git commit, both on the server and client sides, but I can't get it work any more.
What happens is that the first client connects ok, I get a GATT_CONNECTION_STATUS_EVT about the first connection and usually with the conn_id 2.
Then, when the 2nd client connects, it will sometimes cause a new GATT_CONNECTION_STATUS_EVT, this time often with conn_id 258, but more often, it will not cause a GATT_CONNECTION_STATUS_EVT at all, but simply hi-jack the old connection and read/write data using conn_id 2.
Anyone knows what's going on?
Solved! Go to Solution.
- Tags:
- ble connection
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello magnusb,
The BLE LL protocol does not support a slave to have multiple masters simultaneously. This is referred to as a scatternet in BT Classic, but not supported in BLE.
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello magnusb,
The BLE LL protocol does not support a slave to have multiple masters simultaneously. This is referred to as a scatternet in BT Classic, but not supported in BLE.
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, and thanks for replying.
Yes, I've read that too, but it doesn't explain why it works some of the time, or even the presence of the conn_id member in the structures I mentioned.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If BCM943341 is running BLE 4.1, it should support a slave to have multiple masters simultaneously.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting!
And how do I make sure it's running BLE 4.1?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Heng Lou wrote:
If BCM943341 is running BLE 4.1, it should support a slave to have multiple masters simultaneously.
As indicated in the datasheet, this is a 4.0 device.
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But it shows here as BLE 4.1. Is this a mistake or?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's also the fact that every other time I reboot the device, it will accept several (at least 2) different connections and keep them apart with different conn_id:s. But then, some of the time I reboot it, it will mix them up.
I very much doubt there's a HW limitation that kicks in, it rather feels like a SW initialization problem.
I guess I should try 3.7.0? Is there a good reason it could work better than 3,5,2? I thought the same when upgrading to 3.5.2 but found no improvements there. One glimmer of hope is that the Bluetooth docs are back in 3.7.0. They were mysteriously gone in 3.3.1 I think.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, per the Bluetooth SIG listing for the 43341 device: https://www.bluetooth.org/tpg/QLI_viewQDL.cfm?qid=19989
The 43341 Bluetooth v4.0 based device does not fully support scatternet (multiple masters)
Also note that under Bluetooth 4.1, many features are listed as optional, yet the SIG still allows the OEM to clam 4.1 compatibility.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is, in fact, a large amount of conflicting information in other documents. However, at this point the datasheet is the ruling factor; other documents undergo far less scrutiny before release, making errors more likely. I will get back to you with a firm answer and ensure amendments are made to whichever documents are incorrect.
Unless I find that the chip is supposed to support 4.1, we will not attempt to address use-cases for which the chip was never supposed to provide functionality.
Jacob