I’m working to understand how to control the LCD on the handset of an AT&T CL84209 landline phone system, and I started by observing the behavior of its eight IO pins (plus one pin already established to be ground) using the analog mode of my Saleae Logic 8 analyzer. Two pins were immediate candidates for a serial data pin and its corresponding clock pin, so I switched my analyzer to digital mode observing those two pins specifically.
Mouse hovering over the clock line, the analyzer software told me it started at a frequency of 7.2kHz and then sped up to 100kHz during the startup sequence. 100kHz is very promising, because it matches “Standard Mode” speed of I2C. The previous LCD controller I played with used a proprietary Sanyo protocol called CCB, but I’m hopeful this unknown chip uses Philips I2C. So in the spirit of “be sure to check the easy thing first” I activated I2C protocol analyzer built in to Saleae’s software. This presented a stream of decoded bytes and no sign of error.
Good news: it is indeed I2C!
Bad news: within less than ten seconds of powerup, there are 2569 captured and decoded messages. That is a lot of raw data to wade through when I don’t datasheets to make sense of it all. But the situation isn’t quite as bad as it initially looked. While I’ve tapped pins directly connected to the LCD, that doesn’t mean all the data we see on those lines are relevant. I2C is a data bus for multiple devices to communicate, and I see multiple addresses listed in the I2C decoder output.
I wanted to filter messages by address, but I failed to find such an option in Saleae software. Instead, I copied the data output into a Jupyter notebook and wrote a bit of quick-and-dirty Python to parse them. There were ten unique I2C addresses in this output:
{'0x52', '0x51', '0x50', '0x56', '0x3E', '0x53', '0x54', '0x55', '0x4B', '0x57'}Scrolling through the decoder output, traffic to address 0x3E stood out because they were the longest. Many of these I2C messages had only one or two bytes, but some messages to 0x3E were much longer. The long messages have a pattern, they come in sets of three: two 18-byte messages followed by one with 19 bytes.
write to 0x3E ack data: 0x80 0x81 0x40 0x20 0x43 0x4F 0x4E 0x4E 0x45 0x43 0x54 0x49 0x4E 0x47 0x2E 0x2E 0x2E 0x20
write to 0x3E ack data: 0x80 0xC1 0x40 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
write to 0x3E ack data: 0x80 0x40 0x40 0x00 0x00 0x10 0x02 0x01 0x04 0x00 0x10 0x00 0x04 0x01 0x00 0x02 0x10 0x04 0x00 These messages won’t have enough bits to control individual dots on the dot-matrix display. However, they might contain alphanumeric data for the LCD controller to use a font lookup table. Again, in the spirit of trying the easy thing first, I compared the first line of data against an ASCII chart.
| 0x80 | 0x81 | 0x40 | 0x20 | 0x43 | 0x4F | 0x4E | 0x4E | 0x45 | 0x43 | 0x54 | 0x49 | ox4E | 0x47 | 0x2E | 0x2E | ox2E | 0x20 |
| [?] | [?] | @ | [space] | C | O | N | N | E | C | T | I | N | G | . | . | . | [space] |
“CONNECTING…” is the first line displayed on the LCD! We have a winner, time to dig into traffic addressed 0x3E for this I2C LCD.
New Screwdriver 
Hi, there,
I found that my handset has eight I2C addresses:
{‘0x52’, ‘0x51’, ‘0x50’, ‘0x56’, ‘0x53’, ‘0x54’, ‘0x55’, ‘0x57’}
There are no ‘0x3E’ and ‘0x4B’ showing up as yours. Does it means that my handset LCD is not I2C , or the one in the 8 addresses may be the I2C address?
I’d appreciate your help.
LikeLike
Well, one thing is certain: data has to get to the LCD somehow. Beyond that… I don’t know enough to speculate about your handset. (I barely know enough to poke around my own!)
LikeLike
my handset is also AT&T handset, and the LCD is very similar to yours. I see that you talk to your handset LCD using Arduino and wire library. Can we talk to the handset LCD using Raspberry PI 3b+ and python library? Did you ever try that?
LikeLike
I have not tried to talk to that LCD with a Raspberry Pi.
LikeLike
Another question: I see that you have unsoldered the LCD from the board. When you talk to the LCD, do you need to replicate the circuit of pin 6, pin 7 and pin 8, so that the LCD can still get the square waves? If yes, could you show the circuit diagram? thanks.
LikeLike
Yes. See pinout information here: https://newscrewdriver.com/2022/06/13/pinout-of-lcd-salvaged-from-att-cl84209/
LikeLike
thanks for the answers. do you know if the handset LCD has a driver with it? if yes, where is the LCD driver at? is it on the LCD itself or on the handset PCB board? also, where is the character set stored? is it stored on a memory of LCD driver itself or some place, like EEPROM, on the handset PCB board?
LikeLike
Under epoxy blob at edge of LCD module. For font see: https://newscrewdriver.com/2022/06/06/cl84209-base-station-lcd-character-set/
LikeLike
so, you mean that all the DDRAM, CGRAM, and display drivers of the handset LCD module are integrated under the tiny epoxy blob, but not on the PCB board, correct?
LikeLike
It can run off a breadboard as pictured here: https://newscrewdriver.com/2022/06/10/lcd-driver-has-own-voltage-boost-converter-after-all/
LikeLike
the wiring looks complicated. there are ESP8266, capacitors, resistors, and Arduino. the wiring picture is not clear, and it looks that you only connected 8 LCD pins but not 9. could you send me a clear circuit diagram, so that I may replicate the wiring connections?
LikeLike
Pinout information is here: https://newscrewdriver.com/2022/06/13/pinout-of-lcd-salvaged-from-att-cl84209/
LikeLike
I see that you captured the 18-byte message to 0x3E:
write to 0x3E ack data: 0x80 0x81 0x40 0x20 0x43 0x4F 0x4E 0x4E 0x45 0x43 0x54 0x49 0x4E 0x47 0x2E 0x2E 0x2E 0x20
what does the first three-byte sequence, 0x80 0x81 0x40, mean? it looks like that 0x80 means “write to”, 0x81 means “start from first line”, and 0x40 means “show a 15 bytes of alphanumeric data on the LCD. what do you think the guess?
LikeLike