- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
===
SDK: 2.1.1
Tag: 920737.
app: hello-sensor based customer app.
OTA firmware size ~ 20KB.
===
Problem:
We enable only 1-slave BT connection with client handset and also this slave device can
broadcast with ADV which includes some sensor values of device during connection was established. However we find sometimes when 2nd connection attempt with client,
sometimes it can let 2nd device to connect with client (why? coz it's 1 only configured) and also if disconnecting 2nd link, the ADV broadcast is gone at handset scan? I try this one hello-sensor example, it can get same failed result, any help?
What I modify is,
- in hello_sensor_connection_up(),
disable "stop adv" and call blecm_setAdvDuringConnEnable(TRUE) to
activate ADV during connection phase.
- in hello_sensor_create();
add 2 line below,
blecm_ConMuxInit(1);
//blecm_enableConMux(); //mark it coz we dont need multi-connection.
to sum up,
after configuration with only 1 slave connection ability and add with ADV during
BT-link, sometimes 2nd device can also be connected and after it disconnects,
ADV is gone. Don't know why.
- Labels:
-
BTWi-Fi Bridging
-
Debug
-
MasterSlave
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A little confuse here. So you have two devices trying to connect to the phone?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Leo,
You definitely need to upgrade to SDK 2.2.1:
WICED-Smart-SDK-2.2.1-IDE-Installer (Windows)
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont and J.t,
- Try SDK 2.2.1 and get same failed results at our app and hello-sensor example.
- Our device is designed with 1-1 with client only, but device can still broadcast with ADV during connection.
current hello-sensor in func hello_sensor_connection_up() has a mechanism that
once BT-link is connected; it will call as below,
// Stop advertising
bleprofile_Discoverable(NO_DISCOVERABLE, NULL);
this action means no ADV after connection this means after device is connected,
other handset can not scan this device owing to NO ADV, so it reaches to 1-1 implementation. However, I am afraid in lower-layer, it can still provide mulit-BT-link;
this is why I disable like that
// Stop advertising
//bleprofile_Discoverable(NO_DISCOVERABLE, NULL);
I can find 2nd handset can connect with this device; if so, it's 1(slave)-2(master).
To sum up,
my question is, in hello-sensor example, if we want to do ADV during slave BT connection but it support only 1(slave)-1(master); how to disable the lower-layer
BT link if 2nd handset try to connect with device?
somehow like in hello-client, if we set
//enable multi connection
blecm_ConMuxInit(1);
blecm_enableConMux();
but i try this, not useful; same result.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
have an example for more clear description.
- device is power-on, and handset1 to scan BT device and find this one.
- handset1 connect with this device.
- handset2 try to scan BT device and find this device and also can find ADV
packet which includes device sensor data coz it is still broadcasting
during connection for our requirement spec.
Above steps are what we want.
Test below,
- handset2 try to connect to this device owing to it can see this device.
- handset2 sometimes connect failure but sometimes connection without problem.
(we dont allow 2nd handset to connect)
- Then if handset2 connects with device successfully, try to disconnect handset2,
and then use handset2 to scan BT device, it can not find this device anymore.
(problem happens)
so my way is to prevent 2nd handset to connect with device; then there is no
ADV gone issue after 2nd link is disconnected. it can be reproduced in hello-sensor example code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you consider a whitelist?
Adding and removing master nodes to a whitelist running on a peripheral device
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont
it seems to edit whitelist is more complicated to our implementation currently.
Coz our requirement is just to let only 1 slave BT connection in hello sensor.
Coz adding ADV available during connection. So is any mechanism
like hello-client to configure below,
// HELLO_CLIENT_MAX_SLAVES = 1 now
blecm_ConMuxInit(HELLO_CLIENT_MAX_SLAVES);
but it doesn't work now and maybe need some API calls.
Currently in hello-sensor pure sample code, it seems connection available when number >= 2 but due to no ADV broadcast after number = 1, so there is no extra client
to be connected with it. But if we need it's still ADV broadcasting, how can we do that?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe the issue is that a slave cannot connect to two masters.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont,
It should be but how to prevent 2nd master BT-link attempt when it scans for ADV by user while another client is connected with device already?.
I found once 2nd is trying to connect with BT; it will cause 1st BT-link drop or
cannot get ADV of device anymore.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did a check... I had one tag3 advertising (in hello-sensor app). With one phone (HTC E8), I made a connection to the tag via wiced explorer. On another phone (S4), I could see the adv but I cannot connect to it.
Is this what you want to achieve?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont,
Yes, but in hello-sensor, do u modify some for ur test result.
Coz as i know in connection-up func, there is code line as below,
// Stop advertising
bleprofile_Discoverable(NO_DISCOVERABLE, NULL);
U need to mark it and then ur S4 can see ADV, right or once connection is established
with ADV off, other handset can not find the ADV.
From my test, i find sometimes 2nd handset can be connected. However,
it should not be like that owing to multi-master.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used the sensor code as it is with no modification. After a disconnection with HTC, I can proceed to establish connection with S4.
Now I comment out the following code as below:
// Stop advertising
//bleprofile_Discoverable(NO_DISCOVERABLE, NULL);
My HTC can still scan and connect to "Hello", my S4 cannot detect the presence of "Hello" at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Leo,
You may look into non-connectable advertisement. A good reference point is an extraction from "my_beacon.c". Let me know if it helps.
// Start advertisements
blecm_startAdv(
HCIULP_ADV_NONCONNECTABLE_EVENT, // non-connectable undirected advertisement
160, // adv interval 100 msec, N*0.625ms
HCIULP_ADV_CHANNEL_MAP_MASK, // all channels
HCIULP_PUBLIC_ADDRESS, // int advAdrType,
HCIULP_ADV_FILTER_POLICY_WHITE_LIST_NOT_USED, // int advFilterPolicy,
HCIULP_PUBLIC_ADDRESS, // int initiatorAdrType,
NULL); // UINT8* initiatorAdr
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont,
it seems not working... coz this API is used during sample create function.
our design scheme is
if device is in idle state without connection,
ADV with uni-direction for all handsets.
if device is connected, device is also broadcasting to let other
client to get broadcast info. So is any API is called dynamically,
during device connection state and reset to default ADV after
connection is dis-linked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this still an issue? Otherwise I would like to refer you to hello_client.c
if (hello_client.dev_info[con_index].role == SLAVE)
{
hello_client.handle_to_master = 0;
// restart scan
blecm_setAdvDuringConnEnable (TRUE);
}
else
{
blecli_ClientHandleReset();
blecen_connDown();
}
You may want to set it to FALSE. Let me know if it helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Leo,
1. Make sure you are calling the function below:
2. That will enable advertisements when you are connected.
3. Because you are doing an connectable advertisement, anyone can connect to you.
4. You need to use the call disconnect
Hope this helps,
Thanks
JT
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Still same problem,
handset 1 is connected with slave device and handset 2 can scan for this device.
When handset 2 is trying to connect with this device, sometimes it can not connect it successfully; sometimes it can connect to this device and disconnect the original link with handset 1.
i am trying to avoid the result " handset 2 can connect with device once this device has been connected by other handset already.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't quite understand the protocol you are trying to implement in your application, but it sounds as though "Directed Advertising" might be what you need. For example, when the slave starts up it can use general advertising, so that any master can connect to it, but any reconnection after that the Slave would want to use Directed Advertising so that only the original master can re-connect.