Here’s How To Sniff Out An LCD Protocol, But How Do You Look Up The Controller?

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!

10 thoughts on “Here’s How To Sniff Out An LCD Protocol, But How Do You Look Up The Controller?

  1. 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 :^)

  2. >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.

    1. 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.

    2. > 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.

  3. 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.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.