Connection Issues with SDK 2.2.3

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

cross mob
PhGi_2174146
Level 3
Level 3
First like received First like given

We have BLE devices that were originally programmed using SDK 2.2.0 and we have seen around 5% of devices exhibit a behavior where they will no longer advertise on the correct Bluetooth frequencies after some period of time.  They shift to different frequencies (consistently, as measured by spectrum analyzer) and remain there until the power is reset.  We have been informed that this is a known issues with SDK version 2.2.0 and that we should move to 2.2.3 where the issue is supposed to be fixed.

Since then, we’ve been working to build a stable firmware release using WICED SDK 2.2.3 and what we are finding is that with the newer SDK connection persistence is much worse than with 2.2.0.  We are using exactly the same code, but devices that were stable and would remain connected indefinitely now don’t stay connected for more than a few seconds.  We are using connection intervals of around 330ms, but everything is well within spec even with that value (slave latency is 0 and supervision timeout is 4s).  When we shorten the connection interval to 240ms, the connection duration improves but still does not persist for more than a few minutes.  We need the high interval values to preserve battery life on our devices.  We have not even been able to confirm if the frequency shift problem has been fixed due to this connection issue.

The devices with firmware from SDK 2.2.0 have been in production for many months without any issues other than the frequency shifting.  I also should mention that we use Macs for our work and the 2.2.0 version are built using a Mac version.  The 2.2.3 version is being done using a PC (not a virtual instance but a Windows PC).

Has anyone seen any similar issue with WICED SDK 2.2.3 or have thoughts on what is different between the SDK versions that may be causing this issue?

0 Likes
3 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

1) Did you upgrade the crystal warmup to 5000?

2) Can you do a clean recompilation on SDK 2.2.3 on a Windows 7 (preferred) or 10, 32-bit (preferred), PC environment?

This drifting issue in the advertising frequencies should have been resolved from 2.2.2.

BLE radio frequencies incorrect (BCM20736S)

boont thank you for responding.

I should point out that we are using 6S modules which should not be subject to the crystal warmup issue.  Having said that we have tried setting the warmup time to 5000 as well as setting it back to 2800 and we have done clean builds repeatedly.  These have had no impact on the problem.

We are using Windows 10 and the 32 bit WICED IDE.  This is the only software installed on the machine, it was a clean install of the OS then the WICED environment.

0 Likes
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I have some suggestions:

1) load the hello_sensor app onto those problematic modules, using sdk223 on your win10 pc. Observe

whether does the issue occur again.

2) since you have access to an SA, you may want to invoke "manufacturing-bluetooth-test-tool (MBT)" to

put the device into test mode and perform Tx test on it. It's available in "Tools" and the app note in "Doc".

And do continue to bump up the crystal warmup to 5000.

From whom are you sourcing your SIP module?

0 Likes