sensor based on PHY6252 / V1.5

[FrankyGT]

Hi, I bought some temperature sensors last week, which , from the display image, look like a TH05 V1.4. But inside is a PHY6252 chip as well as a VKL060 LCD driver chip. And there is only one marking under the LCD panel :

QC0000_L11_PHY6252_TEMP_HUM_V1.5

So it looks like V1.5 has been rolled out...

[pvvx]

I don't have any thermometers with PHY6252.

[gmag11]

I attach a few pictures of this model:

Design is very simple. Just a few discrete components. No battery included :(

SOC is PHY6252

Datasheet is here

LCD display driver is VKL060. I haven't found any info about it

This is the only reference in the board

Sensor seems to be a clone of AHT20

These seem to be GND, TX, RX and Vcc test points for flashing.

[pvvx]

The PHY6252 is a stripped-down, cheaper version of the PHY6222.
It consumes a lot of battery power - there is no onboard DC-DC to power the CPU core.
The PHY6252's sleep current consumption is 13 µA. Plus the LCD driver chip and sensor. That's over 20 µA in total (sleep mode).

Combined with BLE, sensor and screen processing, the consumption will be too high for the CR2032.

I wouldn't use a thermometer like that. These chips (PHY6252) are used in light bulbs and other devices powered by the mains.

[pvvx]

The data in the PDF is incorrect and depends on many conditions.
Real measurements show a significant increase in consumption.
I have had PB-03F modules with PHY6252 chips for a long time.
Depending on the version of the PHY documentation, different parameters are specified. It's a complete mess.

[pvvx]

In sleep mode, DC-DC is disabled.
It is possible that in packages without DC-DC pins, the PHY installs chips crystal with higher leakage.
Leaks for RAM support and RC generator operation in normal PHY6222 crystals are at the level of 2..5 µA. Depends on the quality of the crystal.

Additionally, without DC-DC in SoC activity mode, consumption will be 2..3 times higher. (3.3V -> DC-DC -> 1.2V)

Accordingly, when CR2032 is discharged (increasing internal resistance), we get a voltage drop of 2.5 times greater. Chemically, the CR2032 element produces 3V at +25C. Discharge of the CR2032 battery = increase in internal resistance. And the current of PHY6252 during active operation is 2+ times higher. As a result, we get a limitation of battery use to different levels of discharge and large voltage surges when switching from work to sleep.

With a pulse load of 8..10 mA, the average CR2032 battery gives only 100 mAh.
That is, with an internal voltage of 3V and a current of 5 mA, the CR2032 battery will produce 2.2V. The internal resistance of the battery will be 160 Ohm (voltage drop of 0.8V).
The active mode of the SoC for BLE (for PHY chips) operation cannot be less than 5 ms.
When using a CRxxx battery with a large mAh, the dependencies are completely different and non-linear. Current BLE SoC technologies use CR2032 at the limit of maximum pulse currents. For a CR2450 battery, the pulse discharge dependence will be completely different, significantly different from the ratio of the capacity in mAh given by the manufacturer.
Then you can calculate everything yourself.

You were sold a cheap dummy thermometer. There is no point in wasting time on such things from the Chinese market.

[gabbla]

Just for fun (and because I didn't find this thread sooner) I ported the fw on such device. It took a while to map the LCD but I have a working porting. I see around 18 uA drained from a CR2032 battery (without any link). @pvvx should I take the time to clean stuff out and open a PR?

[pvvx]

The ST17H66 chip is almost an analogue of Phy6252.
Current in sleep mode with active RAM 11..12 uA at 3.3 V. (Deep-sleep < 2 uA)
Since there is no built-in DC-DC, RF transmission has a larger current of 2..3 times than that of PHY6222.
At RF TX +0 dBm the pulse current is 13 mA. An example of what voltage will be on a partially discharged CR2032, but still quite functional:

On the new CR2032:

And 2xAAA batteries in the BTH01:

Now the market is filled with cheaper devices that work only if you constantly change batteries...
If you are satisfied with the replacement of batteries more than once every six months, you can publish the firmware. Let users suffer :)

---

An acceptable maximum average current from the CR2032 I think 15 μA. With a pulsed current of not more than 10 mA. This already reduces the maximum energy CR2032 to 100 mA/h and works in the maximum of up to 1 year.
Everything exceeding these values ​​is the trash.

Another example of trash: ZSS-ZK-THL - E-ink Moes ZigBee "Smart Brightness Thermometer".
The chip during the transfer can consume 200 mA in accordance with the specification. At the same time, in sleep mode, the device has a current of less than 7 μA.
That is, voltage failures from CR2032 are guaranteed. For this reason, it is impossible to ensure the work of this garbage with standard Zigbee coordinators. Constant rebooting occurs ...

[sjoram]

the fw on such device. It took a while to map the LCD but I ha

I too have been duped into a box of these devices and have been scouring the web for days. Any help with loading something up would be great otherwise they are for the bin which would be a shame :(

[mpolak77]

unfortunately I have also bought a few of those, before I realized that "not so good" clones do exist. @gabbla I would like to give it try at least.

[gmag11]

May you share a build that may be tested on these devices?

[gabbla]

I'm out of office these days, I'll try to share a binary asap and then I'll submit a pr with changes

[sjoram]

So it worked! And is being picked up immediately in HA.

The clue was to use the GND and not Vcc though. Many thanks for that tip.

I did also set ttcl to a longer value in the py script to give me a bit more time to faff with the power.

[sjoram]

@gabbla the battery level is reporting 0.007V. Did you look at this for your devices? If as PVVX says the battery life is a bit crap it would be great if this worked! I'm happy enough now though so many thanks

[gabbla]

There is no adc pin connect to the battery vcc rail. I think it's possible to monitor the internal vcc, but I still have to look into that

[pvvx]

Many thermometers do not have a GPIO pin to +Bat. This is not necessary at all.
Any GPIO can output "1" and PullUp. This will be Vcc.
And the best GPIO is the one that is not routed from the crystal to an external contact on the chip package.
Otherwise, if you select the wrong firmware - upload via OTA to another thermometer, where this GPIO is connected to something, the program will switch the chip to deep-sleep. And the connection for OTA will be impossible. That is, when choosing GPIO, it is advisable to take into account all the options for chips and circuits of existing thermometers on PHY62x2.

The GPIO in the PHY62x2 that is not connected to anything causes increased power consumption - it receives interference and the internal circuit switches, creating additional current. On an empty GPIO, PullUp or PullDown must be enabled.

PowerProfiler is a must for debugging (!) Suddenly PullUp/PullDown or something else got mixed up. Then it will cause additional consumption from the battery. Without PowerProfiler you will notice this only after several months of using the thermometer...
Of the ready-made ones, not the best, but possible for use with BLE - Power Profiler Kit II (PPK2). There are no cheaper ready-made options.

[Taxom]

Edit: the project author asked to remove the binary since it's not possible to inspect what's shown on display (see the replays below)

Here is the firmware: [deleted] Note that the PHY6252 does not have an hardware reset pin, so you need to power the device at the right moment. During my test I used the script provided in this repo as

python3 rdwr_phy62x2.py -p /dev/ttyUSB0 -e -r wh bthome_phy6222/build/bthome_phy6222.hex

And powered the board when the tool printed "Connecting..". It takes several tries before succeeding.

cc @mpolak77

can I get the hex file? Thanks.

[pvvx]

I see around 18 uA drained from a CR2032 battery (without any link).

Here is the data for reference.
PHY6252 is an analog of ST17H66B (the crystal is the same), without taking into account the display and sensor.
With a supply voltage of 3.0 V and a transmission period of 10 sec, the average consumption should be about 7.17 µA:

In sleep mode, between transmissions - 3.45 µA:

The dependence of the average current on the transmission period is given here - #94 (comment)

Compared to TLSR825x (sleep current is 1.8 µA), average consumption at 2.5 sec transmission period is equal to average current of PHY62x2 at 5 sec interval.

As a result, such intervals are selected by default, since from a cheap CR2032 it is about 8 months of work. And from a good CR2032 - a year. This is an average current of about 14 μA with a pulse of up to 10 mA. And this is taking into account the consumption of a good LCD driver and a sensor of the SHT4x type. Other sensors, LCD, E-Ink consume significantly more.

The PHY6252 has a higher current pulse during operation and transmission, and even with an average current of 14 μA, the battery life will be 20-30% shorter than with the PHY6222.

[FrankyGT]

Well I guess you were right Victor, I was sold cheap junk. Yesterday I flashed all 10 devices and also found out that 6 of them had duplicate addresses. So I can only use 4 of them... Luckily I only paid 2 euro a piece...

[pvvx]

MAC address changes in the program.
Any firmware uses 3 random bytes for MAC. The first three are usually fixed and assigned to the manufacturer.
If you erase the entire Flash, then a new MAC will be generated anew.
When copying FullFlash to another device, the MAC will match.

The probability of getting devices with the same MAC is very high.