Advertisement seems to be flakey

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

   I am finding some weird issues with the Advertisement on the 20737 chip.

Using hello_sensor and a TI RF sniffer I can see the adv packets being transmitted, however sometimes if I reset or power cycle the sensor I only seem to get adv packets for around 5 - 10 seconds and then the RF stops......packet sniffer does not see any RF data.

When the module does work I have left it to run without access to a client to see what would happen.  What I have noticed is that the HIGH ADV stops and then the LOW ADV starts and runs as expected (300 seconds). The ADV Interrupt Stopped interrupt handler is then called and the module is instructed to start advertising LOW....sometimes it continues to advertise for 5 - 10 seconds and other times the advertisement does not start at all.  The application does not appear to have crashed as the background messages continue to be transmitted on the uart.

This appeared as I have tried to control when advertisements are started, stopped, etc...using commands through the puart.

When I spotted this problem I reverted back to the default hello_sensor and noticed exactly the same problem.

So my question, has anyone else seen this problem, is it a problem, and does anyone have a solution.

p.s. I did see a thread where the sleep_enable = 0 and setting the crystal time to 5000.....I tried that and it actually made things worse.

I am using SDK 2.1.1

Thanks

Lloyd

0 Likes
1 Solution
Anonymous
Not applicable

Hi All,

     Thanks for all of your replies and suggestions, I eventually found out what the problem was, a faulty tag module.

I received another TAG module and tested my software on it and everything worked as expected. The faulty unit is on it's way back to the distributors and hopefully on to Broadcom to find out what is wrong with it.

Again thanks for all you suggestions and help.

Lloyd

View solution in original post

10 Replies
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

What scan parameters are you using on the TI sniffer? I would suggest you use Frontline or Ellisys sniffers (and I have seen other/less expensive recommendations from some community members). Or if you have another 2073x, use its hello_client sample app and change its scan parameters to something like this:

blecen_cen_cfg.high_scan_duration   = 300;  // seconds
blecen_cen_cfg.low_scan_duration    = 300;  // seconds

blecen_cen_cfg.high_scan_interval   = 16;
blecen_cen_cfg.high_scan_window     = 16;  
blecen_cen_cfg.low_scan_interval    = 16;
blecen_cen_cfg.low_scan_window      = 16;  
Anonymous
Not applicable

Hi,

   Thanks for the quick response.

I do not think that the problem is with the RF sniffer as I have reset it and re-started it to see if the RF was visible and it is not.

My question is regarding the apparent shutdown of RF from the module, I have asked it to advertise, it sometimes runs for 5 - 10 seconds and then stops.  If I then power up a client to connect, it never connects...however if I then power cycle the peripheral it will connect immediately, and the RF sniffer captures this without any restarting of the sniffer hardware or software.

The other problem is when the full cycle of advertisement has completed, for example using hell_sensor, the HIGH advertisements run for 30 seconds, then low advertisements for 300 seconds, then the advertisement stopped handler is called,  the advertisements should be restarted, but sometimes it does and runs for about 5 - 10 seconds and then stops, other times it does not run at all, and there is no way to re-start the advertisements without power cycling.

I have tested this with hello_sensor and a modified version on three different boards and still get the same problem.

The modified software uses the puart to send and receive ascii commands, that allow me to stop adv, start HIGH adv and start LOW adv, and these operations work correctly when the unit is powered up.

However when the sequence at the start has completed and no RF is transmitting, these commands have no effect at all, I cannot re-start the advertisements  I know that the module is still running as the debug/status messages are  transmitted on the puart every second.

Again the only way to get a client to connect to the peripheral is to power cycle the module.

A different question ......is there a call that can be used to see if the RF section of the module is active/powered up/transmitting/etc.

Thanks

Lloyd

0 Likes

This sounds like the Crystal Warm Up issue described here: Re: BCM20732S module keeps crashing

Try disabling sleep to see if it continues.

arvinds j.t vauser

0 Likes
Anonymous
Not applicable

Thanks for the reply,

     I did try to disable sleep see first part of thread.

"p.s. I did see a thread where the sleep_enable = 0 and setting the crystal time to 5000.....I tried that and it actually made things worse."

Regards

Lloyd

0 Likes
Anonymous
Not applicable

They are using the BCM20737S SiP module, not the BCM20732S module, so why would the crystal issue be relevant to this problem?

0 Likes

This issue applies to all 2073XS based modules.

This should not be a problem on the TAG2/3 Development Boards as those use the SOC vs module.

0 Likes
Anonymous
Not applicable

Hi,

I have seen a similar problem, and I had blocked sleep by using the lp callback. I tried sending Advertisments for say 200 or 600ms by switching them on and off based on the fine timer by using bleprofile_Discoverable(). This worked for a while but after around a minute Advertisments stopped. I also use puart to control the 20737S and use the TI Sniffer.

I decided to go with a 1 second delay for now and only start advertisments by using bleprofile_Discoverable() and wait for them to finish on their own. This works more stably.

Regards,

Kilian

0 Likes
Anonymous
Not applicable

Hi All,

     Thanks for all of your replies and suggestions, I eventually found out what the problem was, a faulty tag module.

I received another TAG module and tested my software on it and everything worked as expected. The faulty unit is on it's way back to the distributors and hopefully on to Broadcom to find out what is wrong with it.

Again thanks for all you suggestions and help.

Lloyd

Thanks for the update. 

0 Likes
Anonymous
Not applicable

Ours apparently is SDK related.

SDK 2.2.3 on Windows caused very strange errors to occur.  LEDs blinking erratically, resets, etc.  We think there~s something wrong with the fine timer in this SDK version for Windows.

We finally went back to SDK 2.2.2 on Mac.  Now the downloaded code works fine, but the initial problem of about 10% of the boards STOPPING ADVERTISEMENT is back.

How can we solve this problem?  It's always the same boards that fail; it's not random.  For example, if you have 70 boards and about 7 fail, then if you reset/restart all 70, the same 7 will fail again.

This is not a manufacturing issue, because we have used 4 different manufacturers, and different versions of the PCB layout (which follows your guidelines) and always get the same identical problem.

We need to solve this problem badly!!!!

Thanks,

Gil

0 Likes