Doesn't stay connected

[almostlunatic]

Hi,

I OTA-flashed the thermometer but used the act1441 web flasher. It works but cannot stay connected to the phone. Paired it with nRF Connect or act1441's web flasher or pvvx web flasher, it disconnects in 6-10 seconds. Cannot reflash it too 'cause if it disconnects while flashing (and for sure it does) it'll become bricked... Maybe some advices what to do?

[pvvx]

Use TelinkMiFlasher.html

3. Disable - reload html and flash with original version.

[pvvx]

Incomplete OTA does not kill the device.

[almostlunatic]

It's really hard to be able to send a setting within 6 seconds but I did it. Nothing changed, it still disconnects.

[almostlunatic]

Sorry for the very large screenshot, don't know how to limit the size. As I expected, the step 3 isn't possible: the device disconnects while flashing and gives, of course, the GATT error. Any idea, why this hapapens?

[almostlunatic]

It's not possible to send any settings, I tried with a smily. In the log it says that "Settings xxx was send successful" but nothing happens. So, the latency cannot be changed either. And, it doesn't stay connected more than 10-11 seconds max. No matter what app or utility has paired the device.

[ralf-e]

Phone restarted?
Is there any other Bluetooth app running in the background or on another device that connects to the sensors?
Just started flashing during the connection?

[almostlunatic]

I tried with several phones, but 1 minute ago, I succeeded with my laptop! So, it stayed connected and I reflashed the original FW! Good!

[almostlunatic]

Thank you, Viktor for that amazing FW and Aaron, of course, at the first place!

[skyjet18]

I had exact the same problem. It wasn't possible to save config. For all with the same problem: Just pull out and reinsert the battery. After that it was possible to save config and update connection latency as shown on pictures above. Now everything works as expected without disconnectiong after few seconds.

[almostlunatic]

I reopened the issue because I found the problem, but a question has arisen. I have 3 sensors and sometimes each of them has the same connectivity problem - after exactly 10 seconds it disconnects while paired, no FW update is possible. I researched the issue with nRF Connect a lot, but the gatt connection timeout error 8 (133) is very common on Android smartphones. Suddenly, one of the thermometers stayed connected and I could reflash the act1441 FW. So, after that, the thermometer begun to be able to stay connected! What??? After hours of thinking and trying, I found that all the batteries were (a little) bad! I had changed a lot of batteries, some of them were bought directly from a store (Duracell) and many had been stored for a year or more. I went through 20+ batteries. One that I measured 3.102V dropped to 2.601V while connected and trying to flash. The best one that helped me to reflash all of the sensors, showed in the device 2.852V but dropped only to 2.822V while connected and for some milliseconds to 2.695V while flashing. This was the only battery that kept each of the devices paired without disconnecting.

Now, there comes a wonder (and this is my question). After reflashing the sensors from the pvvx FW to the atc1441 FW, all 3 devices could stay connected with poorer batteries (but not with very poor ones). These were the batteries that for sure haven't let a device to stay connected. I read that pvvx' FW drained a lot less of power than that of atc1441, have I misunderstood something?

Well, I'm happy that with good batteries all devices work good with both of FW! So, for those who are battling with a disconnecting issue after flashing a custom FW, try to replace the battery with a good one at first! Every battery that is below the 50% can work for displaying and advertising the data, but couldn't work in connected mode or flashing! And a new battery that shows 3 - 3.2 volts out of the circuit, could drop to a critical (or below!) value when put into the circuit (sold half-dead, and lots of them are).

[pvvx]

Average consumption is the sum of the consumption per pulse and during the pause between beacons.
RF TX consumption depends on the power supplied to the antenna.
This is a short impulse and does not greatly affect the overall consumption.
But xiaomi saved one cent on tens of thousands of devices and didn't put a capacitor into the PCB.

It also affects the measurement accuracy of the sensor. Apparently, the savings on elements from xiaomi are above all.

Expired CR2032s differ in internal resistance and cannot provide the declared current. After impulse loading, many old elements come back to life...

For tests I use a lot of CR2032s that have been stored for over 10 years. :) All ok.

CR2032 do not like storage at elevated temperatures.
Also, in Russia they sometimes die completely when transported in high negative temperatures...

[pvvx]

I had changed a lot of batteries, some of them were bought directly from a store (Duracell) and many had been stored for a year or more.

The chip runs at 1.8V. LCD is very dim.

Connect and any operations - ok.

[bentolor]

Hello @pvvx ! Thanks for you great improvement to @atc1441 work. Esp. love the improved flasher UI.

Unfortunately I share the same issue like @almostlunatic, but in a different environment. Here are my key points

• I have similar connection stability issues on two PCs:
  • One with a Cambridge Silicon Bluetooth Dongle
  • and one on a Lenovo Laptop
• Batter replacement or restart did not help.
• Connection always gets lost after 5-20s (latest).
• I had hard time to flash ATC Firmware back.: I tried to play with RF TX Power and Advertising Interval and finally was able to flash ATC firmware back again.

Might my issue arise from some over-conversative default settings regarding the energy management in your version?

[eddydeniro]

Hello @pvvx , thank you for this custom firmware! Great work ! I love every customization, esp. the clock.

I had once the same disconnection issue as @almostlunatic described.
After flashing with my laptop, everything worked as expected. Tried every setting on your flasher page, including the pincode. Then I decided to disable pincode. After one undisconnected session, suddenly this issue came. Tried with changing the battery, restart the device, turned off and on the bluetooth, nothing worked. Connection only stayed for around 2 - 5s.
I convinced myself there should be something that interrupted the connection as it worked normally before.
So I turned off all bluetooth around, leaving only my laptop to connect to. I checked the BL settings and there I found the culprit. Everytime I turned on the BL, the laptop was connected to my device, not only paired. So I removed it.
Tried several connecting sessions, the issue never happened again. Everything works normally like before.
So I think nothin's wrong with your firmware. Only my settings.

[pvvx]

The CGG1 "Qingping Temp & RH Monitor" has tantalum capacitors in the power circuit and works when disconnected for a few seconds without a battery.
https://pvvx.github.io/CGG1
There are no capacitors installed in Xiaomi LYWSD03MMC - Xiaomi's greed...

---

Conducted an experiment with LYWSD03MMC and a dead CR2032 battery, which immediately dropped the voltage at low load (<1mA) below 2 V.
When included in LYWSD03MMC, the custom firmware for it says:

1969 mV and falls into a deep sleep for twenty minutes, then again checks what is wrong with the battery ... The second time it shows 1880 mV, etc.

I switched on the electrolyte to the battery - it has been working amazingly for several days...

[xjustbmw]

anybody added the capacitor to LYWSD03MMC ? what specs is it ?
thanks :)

[Rongronggg9]

@xjustbmw

TI released an application note concerning voltage drop of CR2032 w/ or w/o capacitors in 2017 and the object of study is also a BLE chip. This research used a 22uF or 32uF capacitor as a power supply capacitor in the case where the max impulse current is 6.1mA.

Consider that the max impulse current of LYWSD03MMC is < 8mA in most cases according to @pvvx 's research, a 32 or 47uF capacitor should be enough for extending battery life and reducing voltage drop. Up to hundreds of uF is also OK and usually without any disadvantages (except prices). In my case, I decided to add a 100uF capacitor.
As for case codes, C24 should be 1206 and C25 should be 0603 (both in inch)¹. They are in parallel, which means that you just need to add a capacitor to one of them. However, since dozens or hundreds of uF is a huge capacitance, 1206 would be cheaper.

MLCC does not have polarity and you should choose it in most cases. However, if you decided to use a tantalum capacitor, or any other type of capacitor that has a polarity, DO NOT REVERSE THEM! Next to the "C24" or "C25" sign is the positive pole.

Footnotes

1. Consider buying a bit smaller one to make soldering easier. The solder pads are too short! ↩

[bartoszwalicki]

I have noticed that disconnecting problem occurs when there is a low battery. After replacing battery to the new one everything working as expected.

[pvvx]

Now, there comes a wonder (and this is my question). After reflashing the sensors from the pvvx FW to the atc1441 FW, all 3 devices could stay connected with poorer batteries (but not with very poor ones). These were the batteries that for sure haven't let a device to stay connected. I read that pvvx' FW drained a lot less of power than that of atc1441, have I misunderstood something?

The initial “connection interval” selects an external adapter. Consumption is highly dependent on the "connection interval".
Immediately upon connection, the external system reads all BLE services from the device. In ATC, the firmware - fewer services.
Next, the thermometer sends a request to a new interval, and consumption is reduced, if the external adapter confirmed new interval ...

[chatziko]

For anyone affected by this: I couldn't easily find a large SMD capacitor, so I thought to try a normal one that I have plenty lying around. A 32uF electrolytic cap, mounted as shown it the picture below, is just small enough to fit in the cavity of the enclosure. And mounting it was quite easy (just cut and bend the legs, and apply solder to both the pads and the legs before joining them together).

Not sure whether it's the best solution, but it seems to work fine. The flash page used to disconnect almost immediately after connecting, now it stays connected consistently.

[pvvx]

Such electrolytic capacitors have a leakage volume comparable to the flow rate of the device.

[chatziko]

Such electrolytic capacitors have a leakage volume comparable to the flow rate of the device.

So I guess battery life should be affected a lot? I'll monitor it and maybe replace the cap with a ceramic.

For the moment, after adding the capacitor the battery reading became much higher but fluctuates a lot. The same battery that was around 45% now fluctuates wildly between 52% and 63%. Not sure how to interpret this 😄

[pvvx]

Fluctuates if different load. And it can be different from the included "active scanning" that increases the consumption of the device for the transmission of additional responses...

[chatziko]

Not sure I understand. I didn't change anything in the code/settings, just added the capacitor.
The difference can be seen in the image below, big jump and fluctuation (light blue color) after the change.
It's not a problem, just interesting behaviour (the important for me is that the pairing is now very stable and I can upload new settings easily).

PS. thanks a lot for your awesome work, it's amazing what one can do with these little devices.

[shyney7]

Is there any recommendation for the two capacitors that should be added to those pads?

[pvvx]

The first CGDK2 installed the following capacitor:

• Doesn't stay connected #11 (comment)

[shyney7]

Ah thank you for the link to this informative comment 👍

[Rongronggg9]

I guess JJ8E means 220uF 6.3V, manufactured in May 2017.

After searching for tantalum capacitors with case code 1411 (note: this may be the case of CGDK2. Read my previous reply if you are using LYWSD03MMC), I found this:

Oh, J8, similar code formatting and similar appearance.