I am using CC2541 on a control board for a non-parking barrier, which is named: ‘parking lock’. It’s designed to function as follow:
When the car owner drives away from the parking space, he uses his cellphone (with Bluetooth on) to rise the lock’s arm to 90 degree, in case other people parks on his space while it is empty. Then he comes back to park in, the arm will be put down by his cellphone again.
The CC2541 is used as BLE interface with cellphone (include Android and iOS) at the same time processor chip on board. So it is connected with :
1 LED and 1 buzzer to blink and beep while the arm is moving or other defined situation occurs;
2 pairs of photoelectric correlated cells as arm position detector;
1 motor to drive the arm;
The system is powered by lead acid battery, 6V-7AHr.
Under normal situation after powered up, the slave device (CC2541) start advertising immediately, master device (cellphone) can scan, find slave device and initiate connection, to manipulate the arm. When the connection is terminated, the slave device should continue advertising in case any master device initiates connection. While the arm is risen (in lock position), if any external force changes it’s position, the arm would automatically return to the lock position. The logic decision is made by the CC2541, too.
However, odd thing happened during application in different projects, the slave devices were found stopped advertising unexpectedly. The scenario is:
No master device (iPhone or Android phones) could not scan and find the slave, therefore no connection could be initiated or established. At this point, if the arm is pushed down, it still returns to the lock position. This concludes the system is still running, only the Bluetooth interface is malfunctioning.
When the advertising stops, power off the system and restore the power, the CC2541 advertising comes back immediately, that is when power on again, master devices could scan & find the slave device, connection could be established and the arm could be operated as designed. Or, if we leave the slave device untreated when it stops advertising, after an uncertain time, it will restore advertising by itself.
It is difficult to reproduce the scenario, as we put 30 devices under surveillance, only one piece was found stops and re-advertising. It was found stop advertising 3 times, the gap between each time is different, but the period of no advertising is precisely 2hr55min04sec.
Although just 1 was found stops advertising in the 30 devices under surveillance, the problem still exists on the devices applied on site. The frequency is not steady, only some of the devices comes across the problem more often than others. The environment is outdoor and underground parking lot, temperature is -10 to 20 degree Celsius.
We are using BLE stack ver1.4.0, 32M and 32K external OSC for power saving mode. At first, we doubt about power saving mode could leads to the problem, however after we disabled it, problem remains. Later, we doubt about the 32K OSC is not precise, and changed to RC inside, even weld the 32K OSC off, no good. Then, we doubt about the PCB route, changed the PCB design, move the 32K OSC closer to the CC2541, no good.
This problem is really kicking nuts. Hope someone could reach out hands here.