[BK7321N] Generic USB powered thermostat and humidity sensor with LED display - CBU module

Question

Here is another device with Tuya CBU module, here is the AliExpress listing for it - It is based around CHT8305 sensor but it has a GN6932 a multi 7 segment display driver. This is a fast teardown with some basic info, more to come soon. Also attached is the dump from the working device if that...

p.kaczmarek2 · Accepted Answer

I will add a calibration function today. I confused drivers. CHT8305 indeed lacks calibration.

DeDaMrAz · Answer

Here is the capture from the cold boot from PulseView (aka Sigrok) from the 3 data lines, DIN, CLK and STB.

6 DIN Data Input Serial data input on clock rising edge, low bit first.
7 CLK Clock input Input/output serial data on the rising edge of the clock
8 STB Chip select Initializes serial interface on rising or falling edge

DeDaMrAz · Answer

Just a quick translation from the datasheet of the LED driver:

GN6932 is a special circuit for LED (Light Emitting Diode Display) drive control, which integrates MCU digital interface, data lock
memory, LED high voltage drive. This product has excellent performance and reliable quality. Mainly used in multi-segment display driver.
Its main features are as follows:
● Using power CMOS technology
● Display mode (8 segments×16 bits)
● Brightness adjustment circuit (8-level adjustable duty cycle)
● Serial interface (CLK, STB, DIN)
● Oscillation mode: RC oscillation (450KHz±5%)
● Built-in power-on reset circuit
● Package form: SOP32

p.kaczmarek2 · Answer

This is a very interesting device. I'd rather expect it to be TuyaMCU based, but it doesn't look like it. Are you able to check where is the CHT8305 connected?

CHT8305 driver is already in OpenBeken, is it working on this device well?

The 2MB backup can be restored anytime, although for the new flash tool you may need to rename the dump and put it into the "firmware" directory.

DeDaMrAz · Answer

Yes I can: CHT pin 1 (SDA) -> CBU pin 4 (P22) CHT pin 6 (SCL) -> CBU pin 3 (P20) Alert pin is NC(?!?) And the CHT is working, Added after 14 [minutes]:Just to confirm renamed backup written and working. In my case I renamed it to OpenBK7231N_QIO_1.15.xxx and the flasher did write and device is in the original state. BTW consider adding backup naming and writing option to flasher.

p.kaczmarek2 · Answer

That's good news. So we need a GN6932 driver. Here's an English translation of GN6932 datasheet: GN-Semic-G...-CN.en.pdf Download (841.94 kB) Maybe we could use previous drivers as a reference and write a new one:

DeDaMrAz · Answer

I can provide you with the HW info that you need as the SW is the more time consuming for me (because work), as you can notice I write usually after midnight

I'll update the first post for CHT config and if you need anything more from me let me know.

p.kaczmarek2 · Answer

Which GPIO are used for GN6932? I will give you the initial test code tomorrow so we can check if the GN6932 reacts in any way. I haven't looked at your capture yet, only datasheet.

DeDaMrAz · Answer

CBU P15 -> DIN (GN69320)
CBU P17 -> CLK (GN69320)
CBU P28 -> STB (GN69320)

As I understand DIN is the data sent from CBU, STB is something like chipselects pin, everything else I would have to read the datasheet a bit better.

Added after 2 [minutes]:

From Tuya datasheet:

20 P17 I/O Common GPIO, which can be reused as SPI_MISO (Correspond to Pin 14 of the IC)
21 P15 I/O Common GPIO, which can be reused as SPI_CS (Correspond to Pin 13 of the IC)

I'll try tomorrow to get some captures form logic analyzer and parse data as SPI and give you the results.

p.kaczmarek2 · Answer

Thank you, the basic protocol is the following:

Log in, to see the code

but one can write multiple bytes if STB does not go high:

Log in, to see the code

The flowchart requires sending 3 commands: setup command, cmd +data, turn on command.

first setup command, single byte, 0x40 is 100 0000:

Second command has multiple bytes, it's address command + data bytes:

0b1100 0000 is 0xC0.
Third command is 0x8F which is 1000 1111:

Here is what I come up so far:

Log in, to see the code

I will push it to the source in the morning so you can get binaries and test. Curent version just sends random segments data.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

DeDaMrAz · Answer

Some more info from observing the HW, which can possibly influence the data format set.

Added after 12 [minutes]:

The data sheet and the data transfer on the board corelate, but configuration depending not all bytes (my guess GRID registers) are used.

Here is the short snippet of the data capture from the logic analyzer and decoded as MAX7219. You can load the previously attached capture into PulseView and have a clearer picture about the data transfer structure that is based on this specific configuration.

p.kaczmarek2 · Answer

I haven't loaded it yet, but your text file looks very interesting.

But it seems that bit order is swapped!

There is basically that:


17130098-17130262 SPI: MOSI transfers: 02
17130279-17132867 SPI: MOSI transfers: 03 66 60 DA F2 60 FC FC FC 60 F1 C0 00 00 00 00 00
17132885-17133038 SPI: MOSI transfers: F1

0x02 is a first command. It sets the normal mode and auto increment.

This fragment:


17130279-17132867 SPI: MOSI transfers: 03 66 60 DA F2 60 FC FC FC 60 F1 C0 00 00 00 00 00

it's first 0x03, the address setting, it sets address 0x00

The next part of the data is the segments/grids data. They are using auto address increment and set all in one batch, within single STB tick.
The last part is that:


17132885-17133038 SPI: MOSI transfers: F1

0xF1 hex is binary 1111 0001, but as I said, you have swapped endiannes, so it is in fact this:

It sets the brightness and enables the display.

Your packet dumps are very helpful, I will try to push the test driver code to repository today so you can flash OBK and try it. For the start, we will set random segments.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

DeDaMrAz · Answer

Sorry that decoding was done as MSB-first, I changed to LSB-first and the message is clear. 40 C0 66 3F 5B 6D 6F 3F 3F 3F 3F 8F 0F 00 00 00 00 00 8F

p.kaczmarek2 · Answer

Suprisingly enough, it matches well what I've written yesterday, just by basing on the datasheet:

Ok, I will push that test driver in a hour or two, I am looking into door sensors protocol now:
https://www.elektroda.com/rtvforum/topic3937723-90.html#20535974

Added after 55 [minutes]:

This protocol looks the same as TM1637, except the addition of the STB pin and lack of the ACK. One could say that GN6932 is SPI version of TM1637 ?

Anyway, I added test code:
https://github.com/openshwprojects/OpenBK7231...mmit/0b8a78fa2b6420cf1a2af3cc629b15c603681c97
It assumes pin indices:


int g_clk = 17;
int g_stb = 28;
int g_din = 15;

Usage:
1. enter command startDriver GN6932
2. enter command GN6932_TestAddressIncreaseMode , random segments should lit up.

DeDaMrAz · Answer

It does work, there is a changing pattern with every GN6932_TestAddressIncreaseMode command, here is the analyzer screenshot (sorry decoding is wrong by my mistake it is MSB first should be the other way around)

tested with 680 build.

EDIT:
corrected byte order

p.kaczmarek2 · Answer

For anyone reading, here's the code from example above: I will add ability to change dimmer level (3 bits can determine brightness) soon.

DeDaMrAz · Answer

Brightness control does work!

Build 681

Enter in command line:

1) GN6932_TestAddressIncreaseMode
2) GN6932_Dimmer 1 3 - syntax is GN6932_Dimmer [bOn] [brightness], (bOn is 0 for OFF and 1 for ON, brightness level 0-7)
3) GN6932_TestAddressIncreaseMode - to apply changes (also lit characters will change)

p.kaczmarek2 · Answer

I have pushed merged TM1637 + GN6932 driver.
https://github.com/openshwprojects/OpenBK7231...mmit/3b25aee97370775559e279f879bb016c0f1304fd
It currently uses your pins by default.


		i2c.pin_clk = 17;// PIN_FindPinIndexForRole(IOR_TM1637_CLK, 16);
		i2c.pin_data = 15;// PIN_FindPinIndexForRole(IOR_TM1637_DIO, 14);
		i2c.pin_stb = 28;// PIN_FindPinIndexForRole(IOR_TM1637_DIO, 14);

(yes, I know, that's not I2C...)

usage:
1. start and try to print something:


backlog startDriver GN6932 ; TMGN_Print 0 0 123456
// NOTE: TMGN_Print [Ofs] [MaxLen]
// If MaxLen=0, then no lenght limit

Is it printing anything?

2. check brightness changes:


backlog TMGN_Brightness 5; TMGN_Print 0 0 123456
// NOTE: TMGN_Brightness [Brightness0to8] [bOn]
// The bOn is optional, default is 1


backlog TMGN_Brightness 2; TMGN_Print 0 0 123456


backlog TMGN_Brightness 7; TMGN_Print 0 0 123456

Are they working?

3. try to create character codes


TMGN_Char 0x00 123
// Note: TMGN_Char CharIndex CharCode

This is 7 segment display, I assume.
So we can display: 0, 1, 2, etc etc 9, A, B, C, etc F.
But we need to know which segments are displayed for each letter.
That function can set code for given index.
For example, TMGN_Char 0 123 sets code for 0.
The TMGN_Char 10 33 sets code for A (A is 10)
etc etc.

You can play around it by:
- first use TMGN_Char 0 33 , replace 33 with anything
- then use TMGN_Print 0 0 00000 - does it print proper 0?

You can also do a tricky way and just use character codes from your capture


40
C0 66 3F 5B 6D 6F 3F 3F 3F 3F 8F 0F 00 00 00 00 00
8F

ok so 3F most likely is 0 here? What was the display showing when you captured that data?
Try:


TMGN_Char 0 0x3F
TMGN_Print 0 0 00000 - does it print proper 0?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

DeDaMrAz · Answer

Some observations that may help in the future: Also mask for the front of the unit:

p.kaczmarek2 · Answer

Following script should work with both GN6932 and TM1637 and create a simple clock.


//startDriver GN6932
startDriver TM1637
startDriver NTP
TMGN_Clear

again:
// TMGN_Print  offset len value bPadToLenWithZeros
TMGN_Print 4 2 $second 1
TMGN_Print 2 2 $minute 1
TMGN_Print 0 2 $hour 1
delay_s 0.1
goto again

DeDaMrAz · Answer

Build 688. Just to confirm, this is the script that is working for the clock (refer to previous picture explaining GRID placement index starts from 0-8 not 1-9) and seconds are where humidity should be (GRID1 or index 0) for now. //startDriver GN6932 startDriver TM1637 startDriver NTP TMGN_Clear again: // TMGN_Print offset len value bPadToLenWithZeros //GRID1_2digits_seconds TMGN_Print 0 2 $second 1 //GRID8_2digits_minutes TMGN_Print 7 2 $minute 1 //GRID6_2digits_hours TMGN_Print 5 2 $hour 1 delay_s 0.1 goto again

p.kaczmarek2 · Answer

We can use the same approach to map any values from channels to the display. For example, if channel 1 is humidity, then you should be able to do:


TMGN_Print 7 2 $CH1 1

I am not sure about the scaled values yet. This is because we may have a temperature value like 21.5C stored as 215... I will think about it, but maybe it will just work as is.

I am attaching a C source code for hybrid TM1263/GN6932 driver.
drv_tm_gn_...230412.zip Download (3.26 kB)

DeDaMrAz · Answer

Got it working, that approach worked. Here is the pictures and the script that worked for me. All that is left is the always on LED's.

Script that works for me now on build 688.

 startDriver GN6932
startDriver NTP
ntp_timeZoneOfs  +2:00
TMGN_Clear

again:
// TMGN_Print  offset len value bPadToLenWithZeros
//TMGN_Print 0 2 $second 1
TMGN_Print 7 2 $minute 1
TMGN_Print 5 2 $hour 1
TMGN_Print 2 3 $CH1 1
TMGN_Print 0 2 $CH0 1
delay_s 0.1
goto again

EDIT: confirmed working with Build 691.

Added after 1 [hours] 36 [minutes]:

To conclude this is the working script, I created autoexec.bat and it works as intended.

 startDriver GN6932
startDriver NTP
ntp_timeZoneOfs  +2:00
TMGN_Clear
//adjust brightness if needed (0-7) - default is 7
TMGN_Brightness 7
TMGN_SetBit 9 1 1
TMGN_SetBit 9 2 1
TMGN_SetBit 9 3 1
TMGN_SetBit 9 7 1
TMGN_SetBit 9 0 1
TMGN_SetBit 10 2 1
TMGN_SetBit 10 3 1

again:
// TMGN_Print  offset len value bPadToLenWithZeros
//TMGN_Print 0 2 $second 1
TMGN_Print 7 2 $minute 1
TMGN_Print 5 2 $hour 1
TMGN_Print 2 3 $CH1 1
TMGN_Print 0 2 $CH0 1
delay_s 0.1
//blinking : on the clock
TMGN_SetBit 10 0 0
TMGN_SetBit 10 1 0
delay_s 1
TMGN_SetBit 10 0 1
TMGN_SetBit 10 1 1
delay_s 1
goto again

And a picture to prove it

p.kaczmarek2 · Answer

Very nice progress! This device seems almost fully supported.

We could try to convert C to F somehow. Maybe use extra channel as a variable. Is temperature in channel 0?


setChannel 10 $CH0*1.8+32
TMGN_Print 0 2 $CH10 1

Math expressions are supported already, but we also would need to support that extra '1' digit first? Or maybe not... 100F is not a common temperature.

DeDaMrAz · Answer

This script works up to 100'F, there is also a provision to convert to 'C in the script. Measurement above 100'F requires some logic and multiple changes to work due to current temp reading (without decimal point). Attached are the scripts that you can load to your device.

 startDriver GN6932
startDriver NTP
ntp_timeZoneOfs  +2:00
TMGN_Clear
//adjust brightness if needed (0-7) - default is 7
TMGN_Brightness 7
TMGN_SetBit 9 1 1
TMGN_SetBit 9 2 1
TMGN_SetBit 9 3 1
TMGN_SetBit 9 7 1
TMGN_SetBit 9 0 1
TMGN_SetBit 10 2 1
TMGN_SetBit 10 3 1

again:
// TMGN_Print  offset len value bPadToLenWithZeros
//TMGN_Print 0 2 $second 1
TMGN_Print 7 2 $minute 1
TMGN_Print 5 2 $hour 1
//TMGN_Print 2 3 $CH1 1
//comment upper one line and uncomment the next 4 linet to convert to F and vice versa for C
setChannel 10 $CH1*1.8+320
TMGN_Print 2 3 $CH10 1
TMGN_SetBit 9 7 0
TMGN_SetBit 9 4 1
TMGN_Print 0 2 $CH0 1
delay_s 0.1
//blinking : on the clock
TMGN_SetBit 10 0 0
TMGN_SetBit 10 1 0
delay_s 1
TMGN_SetBit 10 0 1
TMGN_SetBit 10 1 1
delay_s 1
goto again

DeDaMrAz · Answer

It would be good if somebody else can confirm this but I noticed that the CHT sensors are having +2'C offset on them - on at least 3 converted devices. Here is a picture of temperature comparison after more then 3 hours of measurements and stabilizing (k Type probe is inside the housing very close to the CHT)

p.kaczmarek2 · Answer

It seems that the driver contributor, @dheenhasty , has added a calibrate function already: SHT_Calibrate

DeDaMrAz · Answer

That command doesn't work on CHT8305 tried already Code: text Expand Select all Copy to clipboardInfo:SENSOR:DRV_CHT8304_readEnv: Temperature:27.354543C Humidity:19.824522% Info:MAIN:Time 87358, idle 184978/s, free 73208, MQTT 0(5460), bWifi 1, secondsWithNoPing 1, socks 2/38  Error:CMD:cmd SHT_Calibrate NOT found (args -2 10) Info:CMD:[WebApp Cmd 'SHT_Calibrate -2 10' Result] Unknown command Info:GEN:CHANNEL_Set channel 1 has changed to 274 (flags 0) Code: text Expand Select all Copy to clipboardInfo:SENSOR:DRV_CHT8304_readEnv: Temperature:27.384756C Humidity:19.848936% Info:MAIN:Time 87447, idle 186866/s, free 61512, MQTT 0(5465), bWifi 1, secondsWithNoPing 1, socks 3/38  Error:CMD:cmd SHT3X_Calibrate NOT found (args -2 10) Info:CMD:[WebApp Cmd 'SHT3X_Calibrate -2 10' Result] Unknown command Info:GEN:No change in channel 1 (still set to 273) - ignoring

DeDaMrAz · Answer

Build 701, CHT_Calibrate is working!!!

Info:SENSOR:DRV_CHT8304_readEnv: Temperature:27.505607C Humidity:17.523460%
Info:MAIN:Time 101, idle 181167/s, free 72976, MQTT 0(6), bWifi 1, secondsWithNoPing 1, socks 2/38 
Info:SENSOR:Calibrate SHT: Calibration done temp -2.000000 and humidity 10.000000 
Info:CMD:[WebApp Cmd 'CHT_Calibrate -2 10' Result] OK
Info:GEN:CHANNEL_Set channel 1 has changed to 255 (flags 0)

this is the final script with everything working (for me)

startDriver GN6932
startDriver NTP
ntp_timeZoneOfs  +2:00
//check the reading of you sensor against a good known and calibrate in this case -2
CHT_Calibrate -2 10 
TMGN_Clear
//adjust brightness if needed (0-7) - default is 7 max
TMGN_Brightness 7
TMGN_SetBit 9 1 1
TMGN_SetBit 9 2 1
TMGN_SetBit 9 3 1
TMGN_SetBit 9 7 1
TMGN_SetBit 9 0 1
TMGN_SetBit 10 2 1
TMGN_SetBit 10 3 1

again:
// TMGN_Print  offset len value bPadToLenWithZeros
//TMGN_Print 0 2 $second 1
TMGN_Print 7 2 $minute 1
TMGN_Print 5 2 $hour 1
TMGN_Print 2 3 $CH1 1
TMGN_Print 0 2 $CH0 1
delay_s 0.1
//blinking : on the clock
TMGN_SetBit 10 0 0
TMGN_SetBit 10 1 0
delay_s 1
TMGN_SetBit 10 0 1
TMGN_SetBit 10 1 1
delay_s 1
goto again

For other users syntax is:
CHT_calibrate [+/- temperature value] [+/- humidity value] you can omit + symbol as that is the default so:
CHT_calibrate -2 10 = change temp-2 and humidity+10 in this case.
(SHT_Calibrate works exactly the same)

Attached are the files that you can uplaod to your LFS

[BK7321N] Generic USB powered thermostat and humidity sensor with LED display - CBU module

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary