- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
===
SDK: 2.2.
Tag: 920737.
app: our application based on hello-sensor sample code.
firmware size ~ 29KB.
===
Problem:
Use one handset to connect with sensor device for 2~3 days, and take handset
back home and device still stays in office; after back office, handset can not scan
it for connection. Then check the trace, device had ever called with plan_air_connection_down()
for disconnection and during idle, it will periodically call plan_air_advertisement_stopped() to broadcast
by bleprofile_Discoverable(). But handset still cannot find this MAC; is there any similar issue happened before?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont,
Thanks for the update. We will based on it for the verification.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i tried to reproduce your issue but to no avail. i pair and connect to a standard hello-sensor with wiced explorer on a samsung s4. i walked away with the phone for like 10min and back. i was still able to initiate connection from my phone... an air trace could be more meaningful in such cases...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I did have similar issue before, but not yet resolved. Trying reset to device to recover it for now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
what is the app you guys are using on your phone?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi boont,
I'm not using APP on handheld device, I am working on bluez on Linux system.
And as I described in other thread, such issue at my side was not in specific pattern in reproducing it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hardy,
thx.
Hi, Boont,
I use our own APK at handset side and env. is easier than Hardy's. (only 1 slave + 1 handset).
I also test with if leaving far from sensor device, and then come back, it can complete auto-connect
right away. But it seems if device is power-on for a long time and handset is off from device for a long time,
it can be reproducible but randomly. I try to mark this function plan_air_advertisement_stopped()
when in idle state, handset will not scan the device out. But in this case, even call plan_air_advertisement_stopped(),
the handset can not find it. Dont know if our firmware APP causes this problem or not. Besides if meet with
this situation, is SDK 2.2 has auto-reset function once it detects some problems? And does current SDK 2.2
enable watchdog timer or not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Leo,
This is quite similar to my previous finding in post 'Unable to advertise after shutdown of all connection'
I tried to add test code for hooking the button interrupt to *re-enable* the advertising by calling 'bleprofile_Discoverable' with parameter 'HIGH_UNDIRECTED_DISCOVERABLE', but it still failed to advertise.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By default, Hello_Sensor should continue to send advertisements. It does slow down after 30S or so, but should continue nonetheless.
Can you take a look at the traces. Every several minutes you should see a "ADV start" and "ADV stop".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes, we observe that after disconnection, it will periodically show "ADV start" and "ADV stop"
but a fewer time, we can reproduce even device show "ADV start" and "ADV stop" but
handset can not find the device by scanning either. It seems to be a strange symptom.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe you can verify with different phone if at the time your handset cannot connect to the sensor advertisements are still being sent. Just to eliminate problem on another side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, all
This problem is now still happened in our product.
Problem symptom:
- There is no handset connected with sensor device and from trace we can see
device periodically call hello_sensor_advertisement_stopped() to have
bleprofile_Discoverable(LOW_UNDIRECTED_DISCOVERABLE, hello_sensor_hostinfo.bdaddr);
But no handset can scan this device so no connection opportunity
Handset :
(IOS/android all have ever been found with this problem)
Possible reproducing approach:
- keep handset low-battery or keep connection/disconnection action.
There is one target which is happened same as this problem; is it ok to have air-capture in BCM site?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Let me revise this:
You are running your own customized app on your own HW product, and now you observed that no handset can ever connect to it. Is this correct?
Can you run hello sensor app on your HW product and confirm that the issue still exist?
Are you working with a brcm rep in Taiwan?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont,
This problem is also found before in hello-sensor sample but not easy to reproduce.
In app layer, it's a little bit related with connection stuff, i.e. connection up/ connection down
and advisement broadcast handle. So we now make sure after link is disconnected and
see the broadcast, handset should find the device. However, in this case, it seems there is
no MAC to broadcast. So it's suggested to have capture view.
It seems, this problem is related to some power-saving mechanism of certain handset;
i.e., if handset is low-battery entering power-saving mode or power-saving setting by user phone.
It is much easier to let link drop and maybe the next result will be like this problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am getting Frank from Avnet to contact you on this issue. Hopefully some logs could be captured, as it could be vexing to reproduce such intermittent issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any new findings to the issue? I heard Frank is quite busy...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not sure of this matters but i hear android generates a new MAC address each time WiFi PR Bluetooth is enabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, all,
From Frank, will book a time to capture log next week in BCM lab.
don't know everyone has ever tried one test action, in Android phone, try to use a free APP
like BLE scanner to connect/disconnect the link quickly and repeatedly to reproduce the problem
as that phone can get device MAC broadcast but handset can not link with it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used LightBlue in iOS and Smart Explorer in Android, although I have never tried to connect and disconnect quickly before.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After Frank's help,
we did some tests below,
- RF spectrum can not find the carrier channel of failed target.
- Wireless sniffer log seems find, lower layer did broadcast but no signal out from RF.
- Have updated tier2 folders (libraries and code update) to see whether we can reproduce this
case or not and now under testing.
- Will update any result soon.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It will give us a better idea if you can in parallel do this with a hello_sensor loaded tag3. This will give us a sort of comparison against a golden sample.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont/JT
As for the connection patch that Avnet Frank gave me, it seems its working after our DQA testing.
It seems it can solve this problem. But we didnt apply this patch for our firmware release yet coz
we may need BrCM formal release (ur internal testing) like SDK2.3 for the usage.
Dont know if BrCM will release next SDK version with this patch in or it's ok we can especially use
this patch for our firmware without any other side-effect? TKS.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is this patch all about? Is it something he write or gotten from us? He has the means to open a CSP case with us for review.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This patch has being deployed in the current SDK 2.2.1. Please update to the latest version and you are good to go with no side effect.
And please help to close this case if the issue has been addressed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Boont,
Thanks for the update. We will based on it for the verification.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Leo,
We performed stress testing on hello_sensor application connection/disconnection.
We don’t see any issues from hello_sensor side
Steps followed:
- We configured both hello_client and hello_sensor.
- Hello_Client will discover that particular hello_sensor server based on the name and raises a connect request.
- After this, pairing is done between client and server for the first time connection only
- After connection, it stays in connection for 10 seconds and disconnects, but the pairing is not removed.
- After disconnection, we wait for 100 seconds and again raises a connect request to the same device after performing discovery
- From there it waits for 10 seconds and the process repeats.
- We left the scripts running for more than 200 connections/disconnections, which covers more than 24 hours.
- hello_sensor should restart advertisements after advertising period expires
Hope this helps,
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is difficult to follow your problem scenario, and hard to troubleshoot without knowing your advertising and connection strategy...
But it sounds vaguely familiar to a problem we experienced with our Wiced Smart peripheral interacting with a iPhone host.
We were able to instigate short term disconnects and the advertising and reconnection were always as expected...
However.... if the disconnect was long term (hours) it was found that after some period of inactivity the iPhone would put the app into a suspended state of some kind and subsequently would not reconnect with the peripheral until it was restarted. Our iPhone guy solved this somehow, but I bring this up because you mention in your original post that you had a long disconnect (left in office and came back next day?).. and I think you should look at the phone App as the most likely cause of the problem.