Nothing feels better than getting a salvaged component to do your bidding. But in the land of electronic displays, the process can quickly become a quagmire. For more complex displays, the secret incantation necessary just to get the things to turn on can be a non-starter. Today’s exercise targets a much simpler character display and has the added benefit of being able to sniff the data from a functioning radio unit.
When [Amen] upgraded his DAB radio he eyed the 16×2 character display for salvage. With three traces between the display and the controller it didn’t take long to trace out the two data lines using an oscilloscope. Turing on the scope’s decoding function verified his hunch that it was using I2C, and gave him plenty of data to work from. This included a device address, initialization string, and that each character was drawn on screen using two bytes on the data bus.
He says that some searching turned up the most likely hardware: a Winstar WO1602I-TFH- AT derived from an ST7032 controller. What we’re wondering is if there is a good resource for searching this kind of info? Our go-to is the LCD display and controller reference we covered here back in March. It’s a great resource, but turns up bupkis on this particular display. Are we relegated to using DuckDuckGo for initialization strings and hoping someone’s published a driver or a logic dump of these parts in the past, or is there a better way to go about this? Let us know in the comments!
11 thoughts on “Here’s How To Sniff Out An LCD Protocol, But How Do You Look Up The Controller?”
This is something, after months of procrastinating I’m back at sniffing HD44780 signals for a PCB with a dead and unobtainium LCD and HaD just run this article.
I’m really eager to read all your comments now :^)
I’m curious as to what exactly you’re looking for. The HD44780 is definitely obtainable. Is that what you’re expecting to find?
I’m not sure it is HD44780, and the LCD datasheet is nowhere to be found. I’m more interested in seeing how people RE LCD, especially graphic ones.
This should be of interest: https://tim.cexx.org/?page_id=342
The authors methods are impressive.
I have used these displays in several projects – alas no longer available.
It smells a little like using a PCF8574 to interface with a HD44780, thus saving some valuable pins for other purposes :)
>using DuckDuckGo for initialization strings
If you now the init string and can sniff out the data sequence, you already know enough to program the LCD.
BTW I have done that previously and found the init string in a product is a lot shorter than the one used by usual Arduino one. This is one case that your search engine would fail.
BTW I stick with the factory one as they would know the LCD parameter better. The Arduino code shows that the person merely trying things until it works without understanding what the commands means.
funny, i was gonna recommend the same, but i meant it as an endorsement of “trying things until it works without understanding what the command means” :)
It really depends on context, a lot of arduino libraries use the shot gun approach. Just spam as much as possible to support as many slightly different display implementations to increase compatibility. The manufacturer though is more like a sniper, is optimized to that one specific display under a narrower set of operating conditions. Neither case is 100% the best choice for every given situation, and downplaying one approach as not understanding commands attributes your assumption to ignorance when it may in fact be intentional.
> If you now the init string and can sniff out the data sequence, you already know enough to program the LCD.
You know enough to get it to work, but the init string sniffed may only set up the display for a particular use. Being able to access the datasheet would give insight into whether other init sequences could suit the end use better.
I have some time ago identified controller on LCD (COG) measuring it’s dimension’s chip and comparing to datasheets , rest was easy (interface &init). But I’ve know the manufacturer of the display so i could dig their web for all controllers they’ve been using – I knew they would use something that they’re familiar with.
This is so timely! I’m currently evaluating if I can “read out” the signals from a board that drives a custom TIAMNA LCD:
And connect it to a RPi for automation purposes (instead of fronting the LCD with a camera, doing OCR, etc..). After a brief oscilloscope probing, I’m convinced that it’s not I2C:
Which complicates things a bit, but we’ll see if I can figure it out…
Please be kind and respectful to help make the comments section excellent. (Comment Policy)