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.