tm1680

[dima-dav]

is there any hope for creating and publishing a library for tm1680?
Thank you

[maxint-rd]

Hi Dima, sorry for the late reply. Apparently I don't get notifications by e-mail.
I am certainly interested to make the library compatible for the TM1680. I had a short look at its datasheet. Especially the 52pin version that can drive 24x16 LEDs looks very interesting. Unfortunately I don't have any module featuring that chip and I couldn't find anything on AliExpress when I search for TM1680. Do you know of any supplier that ships a breakout board or a LED module I can use?

[Bolukan]

Just checked after few months: Oct 2019: USD 0,70 with LCSC and 10 for USD 5 + shipping at aliexpress

[maxint-rd]

Hello Bollie, good find! Thanks for the tip. When I was searching for TM1680 on AliExpress I could find none. As it seems now the "Best results" sorting order shows all kind of other items, but when I sort on price, they do appear.
Some months ago on LCSC they didn't have them on stock, Perhaps I will design a PCB that uses this chip and order them combined with the PCB.

[Bolukan]

Datasheets with translation

[designer2k2]

Hello,
i have a TM1680 board with 11x11 RGB LED´s, its sourced from a "Denver BTL - 350": https://denver.eu/products/audio/speakers/denver-btl-350/c-1024/c-1109/p-4322

any way to help to get the TM1680 supported?

There is also a new datasheet version 1.4:
TM1680.pdf
TM1680.zh-CN.en.pdf

[maxint-rd]

Hello Stephan, thank you for contributing the new datasheet and for providing me the context to your question.
At the moment I still don't have a TM1680 chip available. Occasionally I would browse AliExpress, trying to find some, but haven't ordered them yet. That was what mainly kept me from developing and testing support for this chip.

I have some questions for you:

• The device that you mention looks quite nice. It seems capable of showing some nice graphics in a compact format. Is it still connected to the LEDs in your device, or did you remove it from the PCB?
• Can you provide a photo showing the chip in its current context?
  Edit: (I'm interested to see how the LEDs are connected. 11x11x3 => 33x11? How?)
• Is the chip the 48pin (24x8) version or is it the larger 52-pin (32x8 or 24x16) version?
• I'm willing to begin developing support for this chip, but without having the chip, this would be a "try and see"" effort requiring your cooperation for frequent testing. Are you willing and able to do so?

In the mean while I'll do some searching to see if I can find a chip for development and testing. However, ordering from Ali usually takes 4-8 weeks.

Edit: fixed typo. LQFP52 chip is 32x8 - 24x16)

Kind regards.

[maxint-rd]

FYI: I just ordered 5 LQFP52 chips at Ali. I'm not sure if I also have a 13x4 breakout board. To be continued...
I really wonder how the 11x11 RGB LEDs are connected. (11x11x3 => 33x11? How???)

BTW. I also saw in the datasheet that this chip uses I2C. Recently I worked on support for the HT16K33 LED driver chip, which also uses I2C. (That chip is not by Titan Micro, but by Holtek. It supports 16x8 and I have a 15-segment x 4 character module, which I can now use with the TM16xx API to display alpha-numeric characters).

[designer2k2]

Hello,
yes i will help.
The TM1680 used is the 52pin version.
It´s a dedicated PCB with the TM1680, RGB led´s, some SMD parts and a connector.
So far i have not figured out how the led´s are connected, the white PCB makes it a bit tricky following the traces.

The connector has 6 pins, whereby 2 are used for ground, 2 for 5V and then 1 for SDA and 1 for SCL

I connected my old LA into it and recorded some startups / fancy blinking:

Its recorded with Salea Logic2 and Sigrock PulseView:
tm1680_records.zip

In both the I2C decoder shows something:

[maxint-rd]

Hi Stephan, thank you for your efforts to support this development. Thank you also for providing these pictures. That helps a lot. I will have a further look at your I2C capture one of these days.

Does making this capture mean that your device is still working? What was the reason for you to take it apart? Is the bluetooth defective or do you just want to reuse an obsolete yet working device?

The fact that the device has a dedicated LED module is very promising. The datasheet mentions separate power for the LEDs, so that explains the dual power lines.

As soon as I have time, I will take a closer look at your material and let you know my findings (need to do other things first). Bye for now...

[maxint-rd]

Hi Stephan, I took a closer look at your pictures of the PCB and at the datasheet:

• The title MGM128_LED V1.0 yields no further information. This doesn't seem to be a generic module, but rather custom made for this device.
• I see no transistors, the sole use of resistors points to the Low power LED circuit displayed in figure 20 of the datasheet.
• Note that the chip marking is rotated. Opposed to the picture in the datasheet, the pin 1 indicator is in the bottom left.
• The resistors on the left and the bottom (R19-R42, 24pcs) would then be connected between the ROW lines and the RGB LEDS, limiting the LED current. (I can't quite read their value).
• The capacitors C16 and C26 on the right are probably to decouple the chip power i.e. provide local power supply (VDD on pin 21 and VSS on pin 14).
• The capacitors C27, C28 and resistors R43, R44 could be connected to the I2C pins 16,17 SDA, SCL,, for filtering and external pull-up.
• unpopulated capacitors C1 and C2 could be intended for stabilizing LED power. Their orientation matches a connection to the LED_VDD pins 36, 7 . The other side would be connected to LED_VSS pins 25, 36.

As for the LED layout; the resistors used suggest 24/3=8 rows by 16 columns. That would then allow for 128 RGB LEDs max. The PCB title matches that number. 11 x 11 LEDs is a total of 121 LEDs, Mapping those to the available 128 positions may have required some creative PCB skills and associated software translation in the device firmware.

BTW. Is your device is still working? What was the reason for you to take it apart? Is the Bluetooth function defective or do you just want to reuse an unused yet working device?

[maxint-rd]

Hi again,

Next I looked at your I2C captures, I used the PulseView captures, as my version of Logic is outdated.
Referencing the command table on page 15 of the datasheet, these captures are very informational:

• The clock frequency is not very precise and a bit off-standard: 80-90 kHz
• Although commands are shown in PulseView as read commands (read address 73), these are actually write commands with address E7. While the read/write bit is indeed set to 1 (=read according I2C standards), the chip interprets everything as a write command
• The initialization in both startup captures is the same: init+clear (see below)
• The crazy pattern writes are basically 10 FPS frames of setting RAM address 0 and writing 48 bytes of data.
• 48 bytes corresponds to the the 96*4 bits layout for 24ROWx16COM mode, mentioned on page 5

Initialisation sequence:

data	command	action
E7	Address	write the I2C address (E7=>0x73)
80	SYS_DIS	turn off clock oscillator
A4	COM opt	set 16COM mode
9A	RC master 1	set internal oscillator
81	SYS_EN	turn on internal oscillator
83	LED_ON	turn on LED cyle
BF	PWM Duty	set PWM duty cycle full 16/16
88	BLINK_OFF	turn of LED blinking mode

Edit: fixed A4=16COM mode, matching PCB layout and data RAM size.

Clearing display sequence:

data	command	action
E7	Address	write the I2C address (E7=>0x73)
00	RAM	write RAM address 0
00 * 48	Data	write 48 zero bytes

Image writing sequence:

data	command	action
E7	Address	write the I2C address (E7=>0x73)
00	RAM	write RAM address 0
xx * 48	Data	write 48 data bytes

---

The startup RAM write capture may come to be quite useful to figure out the LED layout. As the device starts up, it always shows these images:

• Heart in red with blue outline
• BT in blue; two 3x5 characters
• 11x2 line at bottom in varying colors while waiting for Bluetooth connection (always same sequence: green, yellow, blue, purple, red, aqua)
  As the chip offers no individual LED PWM, the device is restricted to the three primary RGB colors and four combined colors (including white, although white seems not used in any of the animations)

[designer2k2]

Hello,
wow thats a lot from just pictures and a capture!

The device still works as it should, but the "sound" from it is not what i expected and therefore i want to re-use it as a display.

Yes its running in 24x16 mode and the smd resistors are 20 Ohm.

On your startup sequence the A4 is 16COM, besides this i can confirm it!

I went ahead and hooked a arduino to it, but just found that the write bit is crucial.

This is with the write bit 0, there is a NACK and the code halts:

  // Init the TM1680, same sequence as captured by logic analyczer:
  Wire.beginTransmission(0x73);  // transmit to device 73
  Wire.write(0x80);              // SYS DIS
  Wire.write(0xA4);              // COM option 01
  Wire.write(0x9A);              // RC Master Mode 1
  Wire.write(0x81);              // SYS EN
  Wire.write(0x83);              // LED ON
  Wire.write(0xBF);              // PWM Duty Max
  Wire.write(0x88);              // Blink Off
  Wire.endTransmission();        // stop transmitting

When i request, write bit 1, it sends a ACK, but then the arduino polls endless as the TM1680 not actually sends:

  // Init the TM1680, same sequence as captured by logic analyczer:
  Wire.requestFrom(0x73, 0);  // "request" to device 73
  Wire.write(0x80);           // SYS DIS
  Wire.write(0xA4);           // COM option 01
  Wire.write(0x9A);           // RC Master Mode 1
  Wire.write(0x81);           // SYS EN
  Wire.write(0x83);           // LED ON
  Wire.write(0xBF);           // PWM Duty Max
  Wire.write(0x88);           // Blink Off
  Wire.endTransmission();     // stop transmitting

How can this write bit set to 1? Can the official wire lib even do this?

[maxint-rd]

Hi Stephan,

Thank you for your correction on the A4 command being 16COM mode. Earlier I did mention 16COM and this matches the resistor count and the size of the RAM data sent. (I edited my earlier post to avoid confusion).

As your Arduino captures illustrates, in the I2C standard the r/w bit in the address is 1 for a read command. This would suggest that unshifted 0x73 is write, whereas unshifted 0xE7 is read, The shifted 7-bit address would always read as 0x73 (see shift option in PulseView). In some forumpost I read that the Arduino wire library always uses 7-bit addresses.

However; the speaker device sends 1, even when writing. I was assuming the TM1680 simply ignores this bit and interprets it all as a write. That assumption may be wrong. Perhaps the TM1680 requires that bit to be 1.
The datasheet shows using address E7 (1110-01A1A0) on page 15 and 8/9, i.e. the unshifted 8-bit address value with A1 and A0 set to 1, and A0 at the r/w bit. The I2C diagrams on page 8 and 9 seem to specify ACK between every single byte written.

I'm not quite sure how exactly I2C is implemented in the Arduino library and how you can send the full 8-bit address 0xE7 while still writing data. I would need to do some experimenting first.
BTW. If I remember well from other projects, Arduino has a limited write buffer (8 or 16 bytes or something similar), which isn't transmitted until endTransmission() is called. This may mean sending the RAM might need to be chunked in multiple parts.
As an alternative to using the Arduino I2C functions, one can always implement some bit-banging as I've done for other TM16xx chips and in another project. Correctly implementing I2C with all its features is quite some work though, so I'd prefer to use the Arduino wire library (as I've done for the HT16K33).

So I think I need to do some experiments on my own to be able to give you definite answers.
On that note I would like to announce that I seem to have fully embarked on your project:

I found a local supplier for the Denver BTL-350 and bought myself a brand new device!
Question for you: How do I best open this speaker without causing damage? Does the front easily pop off or are there hidden screws?

BTW: I personally liked the sound which is much better than that from my tablet, but I was disappointed to see they used this matte-black plasti-dip finish all over the back-cover. Brand new it has a satin look that is very susceptible to greasy fingerprints and in a few years that stuff gunks up and transforms into a sticky messy material that requires nasty chemicals to remove...

I'll see if I can collect some more info on I2C. Some time ago I had some promising results on making an I2C bridge for the TM16xx family, based on the Atmel ATtiny13A MCU, which has some challenging limitations on RAM and flash size.

Edit: In the mean time, here are some links to articles that may be interesting:

• 7-bit, 8-bit, and 10-bit I2C Slave Addressing
• NXP application note AN10216-01 I2C MANUAL
• NXP I2C specification and manual UM10204.pdf

To be continued...

[designer2k2]

Hello
oh another BTL-350 thats great :-)

I plan to use a ESP32 in the end, so there is a bit of RAM and CPU power there if needed.

You need to get the front diffusor off, i startet at the bottom (to have the worst scratches then not visible) with a flat screwdriver and worked my way around. It takes quite some force to get it going...

Once the diffusor is off you just unscrew everything, no hidden latch or anything.

[designer2k2]

Hello,

is the teardown going well?

Based on your input on the I2C Addressing i went now a another route, i pulled A0 low to make it match with the write command:

And now it reacts to the init sequence:

And shure enough, leds can be turned on 😊

i wrote a loop that pushes 1 bit through all places, but it does light up looking a bit random, and some do not light up at all. So there is more to be found on how to control it.

The test code: https://gist.github.com/designer2k2/9d62e085ca3b069f6fb57de772c8d489

And a LA record in PulseView from the init and first bit of the code from above running:
arduino_sending_pattern.zip

[maxint-rd]

Hi Stephan, this is excellent! Great idea to use A0 to match the write command! Creative thinking out of the box.... Nice job on soldering this pull-down directly to the chip.
Very good to see you're able to address the leds! As expected they must have an interesting order that will probably require a translation table of some sort. When you mention lighting-up random, do you mean random order? Or do you also see individual leds giving random response?

Past days I had other things to work at, but this weekend I hope to progress on this project. I will try to replicate your setup and try your code.

What MCU are you using now?
You mentioned you wanted to use an ESP32. In the past years I have experimented with plenty TM16xx chips using various MCU's. While the datasheets usually mention 5V compatibility, I found most TM16xx chips to work fine on 3.3v, wihout level shifter. If I remember well, sometimes data lines needed proper external pullup. Sometimes 5V worked better when using higher voltage LED colors (white, blue). Sometimes I needed to add a capacitor to stabalize power supply. Sometimes I needed to use short cables or to get rid of faulty breadboard connections.

[maxint-rd]

BTW. I did manage to open the speaker without too much damage (thank you for telling me how), but have not done any soldering yet...

[maxint-rd]

Further more: I read that the Arduino wire library uses a 32-byte buffer. This means the total bytes send upon endTransmission() should be no more than 32 bytes, I guess including address. Every time you send data to the RAM, you should first send the I2C-address (using beginTransmission), followed by a write of the RAM address command, and then maximum of 30 bytes of display data. I haven't looked at your sketch, so I don't now if you took that into account.
To be continued...

[maxint-rd]

Hi Stephan, Today I did some soldering and have some interesting results. I'll keep it to some main points as I'm still testing:

• The I2C scanner sketch correctly reports address 0x73
• Your sketch gave blinking lights. Hooray! Your trick to pull A0 down is excellent.
• Sending a whole frame needs to be chunked due to Arduino I2C buffer size
• LED order seems kind of random. Addressing is weird indeed, I'm still figuring out if there's some logic behind it, using both multimeter continuity and Arduino code
• The addresses seems to have some repetition: e.g. sending 0x0001 for LED12R is the same as 0x0110. Some other addresses give no result or result in a whole block being faintly lit (e.g. try sending 0x0208 or 0x0380). This is associated with 4-bit nibble organisation of the RAM.
• Although the speaker sends 48 bytes, the addressing has a particular layout. In COM16 mode 01 there are 94 4-bit nibbles. Their address is from 0x00 up to 0x5F. See figure 6 on page 5. Using addresses or nibbles out of bounds gives undefined result.

FYI: I'm using a LGT8F328P 5V, 32MHz, 100k i2c. I haven't used my Logical Analyzer yet.

[designer2k2]

Hello,
yeah its working also on your side!

The 32byte limit had me on my initial code, the link from above is now updated to take care of it. It shows now a fully white panel, and then every led is driven ☀️

Yes the 3.3V from the ESP32 i will check later, i hope i can get away with modifying the resistors. If not i will use a level shifter and supply it with 5V. Right now im using a Duemilanove.

[maxint-rd]

Hi Stephan,

I just tested your second version. Very nice result! I like how you changed your code to send the frame in two parts. My own attempt was much more complicated. I delayed your loop to be able to see for myself that indeed each and every LED got lit once and only once. (In my own code I was kind-of messing the nibbles around only to create a greater mess...)

FYI: my ATtiny13A I2C slave configuration tool came in handy to send test sequences (such as the blink command) as well as to test the speed of the TM1680. It tested a maximum speed of above 600kHz. That's quite nice. The datasheet mentions max 400 kz at 3.0V-5.5V, (The ATtiny runs at 9.6MHz, barely enough to implement 100kHz I2C in software as it has no USI) . If your ESP32 doesn't work properly at 3,3v, I suggest you to first try 100kHz I2C and make sure to use short connections with minimal contact points.

Due to the not-very-standard led layout, it will probably take some time to make a TM16xx compatible library. Usually I start with simple 7-segment support, upgrade then to 15 segment support and finally do the matrix support. For the 7-segment I wait for Ali to deliver the bare chips. RGB matrix is not supported yet by the base class so that requires some changes.

I guess a more practical next step for this display would be to make a library to support some graphics. To make it compatible with Adafruit GFX the main thing to implement is a setpixel function, which probably requires a bit more fiddling to derive a proper mapping table.

[maxint-rd]

BTW, this is where I soldered my Dupont connector. I used the unpopulated capacitor spot C1 (for Vcc and Gnd) and some magnet wire plus kapton tape. The A0 pulldown connects to the GND-side off capacitor C16 right above:

[maxint-rd]

Hi Stephan, just a short message to let you know that I'm working on a setPixel function. My progress so far is promising I've mapped about half of the pixels and can display them in proper order. My code is probably a bit clumsy and making the conversion table is a lot of work (121*3 bit positions). Once working there will probably a lot of room for optimization. I'll keep on dragging in a compile/edit/test loop until the sun rises I guess....

Edit: finished before sunrise. Time to get some sleep...
(Will send some code soon)

[designer2k2]

Wow, that is very good! And the speed you got this is impressive! 👍

I did try to make sense of the addressing for some time now, but something was wrong as i got so many duplicated entrys.

To break the compile/edit/test loop i wrote a serial command receiver into the arduino code and a python gui that sends the bytes. But in the end i spend more time debugging this than the actual addressing 😕

So im looking forward to give your code a testrun!

[maxint-rd]

I have removed some clutter and made a trimmed down example sketch (testing now, uploading soon...).

Once done, the addressing makes slightly more sense, but getting there was quite painful, cumbersome and time-consuming. Nevertheless, I like the result for now, although I'm sure there are many clever ways to optimize this code and perhaps do much better using a different approach.

[maxint-rd]

Here is my setPixel test sketch:
https://gist.github.com/maxint-rd/e3abafc315e5b578b79cc0bb75641ef2
I used your code as base and added some functions and comments.
Hope it works for you. (Use at your own risk! :-)

Note: code is not optimized in any way, I wasn't even bothered to use PROGMEM for the ridiculously large conversion table....

[maxint-rd]

For completeness here are some findings (also mentioned in the comments of the setPixel tryout sketch):

• We need to map 11 x 11 x 3 pixel-leds to a proper bit position in our frame array
• The bit position is somewhere between 0 and 48*8 (=384)
• Each pixel is a combination of three LEDs, some LEDs within the same pixel are at different RAM positions
• Some logic in the wiring: columns of five pixels, rows of 5 and 6 pixels
• Each column of 5 pixels uses 15 bits, bit 0xB is skipped. Using skipped positions results in faintly lit block.
• Using hexadecimal bit locations helps to show the organisation
• RAM is 48 bytes, ie. 384 bits. Bits can be numbered 0x00-0x17F.
• Last row (row 10) has some peculiar wiring to fill up the 11x11 matrix
• Pixel 10,10 uses some skipped bits to complete the matrix (0x16B,0x17B,0x15B))

[maxint-rd]

The coming week I won't have much time for further work on this. Thank you for your cooperation. I think that working together, we reached some nice results in a fairly short timeframe.

Eventually I would like to put an ESP32 (or ESP8266) in the speaker and have it control the buttons to switch off the BTL-display after powering up, while still supporting the Bluetooth speaker functionality. That will probably require some more connections, eg. to the speaker buttons and the powersupply.

The ESP then would take control of the display, enabling me to use it and show text and bitmaps, such as time and other info.
In one of my YouTube videos you can see how I added a 24x16 LED matrix to Brian Lough's ESP clock and merged in some cool time animations of the DotKlok project.

Another nice addition would include an I2S decoder, connected to the audio circuit, to allow the ESP to make sound, eg. for internet radio or use as a streaming server.

[designer2k2]

It works! I have all the color X´s showing up 🤩

The code is cool, and well commented so its good to catch the idea behind!

This is more than i have hoped for, thank you!

With 1270bytes memory its not easy, but even a the Duemilanove (ATmega328) is only 62% filled, a ESP32 even less, just 4%. I would not spend a lot of time to reduce the footprint...

I will continue with the ESP32 integration. My rough plan is to "cut out" the logic from the existing board but keep the power handling part. Maybe even drive the speaker from it as there are ESP32 audio libs: https://github.com/pschatzmann/ESP32-A2DP

[maxint-rd]

Cool! Thank you for letting me know.

The conversion table should definitely move to PROGMEM to save 3x11x11x2 bytes of RAM. Having a static table in RAM is just wasteful and moving it to PROGMEM Flash memory is not too hard. I think I'll do that when I make it into an Adafruit GFX compatible library, which I will use in my ESP speaker project. Other than that your framebuffer uses some RAM. Only 48 bytes though, so that's just fine. (The framebuffer is essential to be able to combine/split-up different pixel LEDs).

If I have more progress, I'll post it here (the original issue is a bit hijacked by this project, so once I received the bare chips from Ali, I'll probably return to the original subject...)
Once I have a separate GFX library, I'll publish it as a new repository as it is quite specific to the BTL-350 display. I wonder if there will then ever be more than two users... :-)

[designer2k2]

Yes the TM1680 support is for here, but the specific BTL-350 should really be somewhere else.

With the default wire libs A0 must be low, thats the only limitation for the support. With only A1 just 2 can be on the same bus, but who will do this? Not many...

Official supplier link: http://www.titanmec.com/product/display-drivers/led-panel-display-driver-chip/20220817109.html

Im looking forward for the GFX lib :-)

[Polyphe]

Hello,
For your information, this chip is also used in the thermostat MH3901-Z from MCO HOME (10x19 LEDs).

[Polyphe]

This is the picture of this chip inside MH3901-Z.

[maxint-rd]

Hello, For your information, this chip is also used in the thermostat MH3901-Z from MCO HOME (10x19 LEDs).

Hi @Polyphe , thank you for your contribution! Nice to know of other use cases.
That thermostat features a nice white LED array of decent size. Your photo shows the LQFP52-version with plenty resistors located near the ROW pins, suggesting a low power implementation. At first it looked like they only connected rows 0-14 on that side of the PCB, but then I saw a few more resistors connected to via's going to the other side. On a googled screenshot I also counted the display to have 10x19 leds, plus a few solo LEDs below the matrix. I'm guessing the matrix layout is a bit simpler than that of the bluetooth speaker...

I see that thermostat priced at 120 euro's and up, It probably has more interesting components. Not something to just throw away when it breaks. Is yours broken too or did you just pull it of the wall to see what's inside? ;-)

BTW. I got some bare LQFP52 chips from China, capable of driving 24x16 or 32x8 LEDs. As soon as I find time to build my own massive matrix, I intend to add support for this chip to the library. Might take a while though...

[Polyphe]

Hi @maxint-rd, Thank you for your feedback. To reply at your question, and after my analyse, there are several interesting components (BS816A for the three capacitive touch, L9110 for the relay, one input for 9-24V DC or AC, one input battery 3xAAA (buck power supply), STM8L151-C8 (8bit microcontroller), SD3502 (Z-wave microcontroller based 8051), SHT20 temperature and humidity sensor.

In fact, my pcb is not broken, but I am curious by nature ;), and more I would like to improve this thermostat because I found this one has not been used to its real potential (matrix, thermostat functions, and so on).

As I don't know this specific TM1680 device, and that the data sheet only seems in Chinese, it is difficult to find a solution versus all your excellent work for this universal library of TM16xx...

When I would find time to do some tries, I would inform you

Thank you again !

[maxint-rd]

Always nice to see such curiosity in action. I just uploaded a translation of the TM1680 datasheet for your pleasure. Perhaps not the best translation, but usable I guess. Good luck with it!

BTW. I also like to be able to improve my devices. Often it' a time-consuming endeavor, not always successful, but most often still interesting. At the moment the TM1680 Bluetooth speaker is on top of my device improvement wish-list. As i have plenty other projects and wishes it may become a work-in-progress forever sleeping on a shelf; who knows...

[Polyphe]

Hi @maxint-rd,
Great ! Thanks a lot ! I will keep you updated ;)

[Polyphe]

MH3901-Z_pattern_pulseview.zip

Hi @maxint-rd,
Here is the pattern of TM1680 ( I2C address 0x72 ) from MH3901-Z. The config seems to start in putting all the first 40 bytes of the RAM to 0, then the config of TM1680 with 0x80 (SYS DIS), 0xA4 COM option 1, 0x81, SYS EN, 0xBF PWM max and 0x83 LED ON. Again the same config without SYS DIS, and again the first 40 bytes of the RAM to 0.

After the 40 bytes of the display occurs 25.7 (all the 12ms).

The designer of the PCB only uses COM0 to 6 for the rows of 6, 5, 4, 3, 9, 8, 7 respectively, and COM12 to 14 for the rows 2, 1, 0 (10 rows, in considering the row 0 at the bottom, and row 9 at the top).
The real rows of TM1680 are used for the 19 columns, both first bytes of the 40 bytes of the frame is the last columns in fact, and therefore the byte 39 of the RAM, and the byte 40 of the RAM is the first column.

It is totally crazy...The computer scientist had to have fun programming numbers and drawings :D

The LEDs of the 3 buttons are independent of the TM1680 (6 LEDs, 2 by buttons).

Another application of the TM1680, where the program designer had to adapt his software in function the PCB designer (Haha).

What I didn't understand, why the frame is send all the 80Hz, the RAM normally keeps the pattern ?

[maxint-rd]

Sorry for the late reply. I didn't have time to look in more detail, so just a short answer: yes, the display does have RAM to hold the pattern. I think they update at 80Hz to show current status really often. Not needed I guess, but still they did...