1 of 1 people found this helpful
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;
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 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."
They are using the BCM20737S SiP module, not the BCM20732S module, so why would the crystal issue be relevant to this problem?
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.
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.
1 of 1 people found this helpful
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.
Thanks for the update.
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!!!!