Electronics > Repair
Figuring out signaling for (yet another) VFD panel
(1/1)
akasaka:
While waiting for the driver PCB manufacturing for that other half meter long VFD, I've decided to turn my attention to another childhood dream project of mine of building my own compact stereo — or at least a CD player.

Needless to say, for the UI side of things I've decided to use a VFD as well. This time it's a Futaba GP1232A02. While they are not really super common, among the circles of my other hobby there's plenty of them being binned from teardowns of (modern!) Sega arcade cabinets :-)

However, this gives another problem — while they come on an easy to use, 5V-powered module, that module uses RS232 at a measly 115200 baud. With a 160x32 px resolution, plus 8 bytes for the command, that means 160*32+8*8=5184 bits per frame plus 1 start and 1 stop bit, and 115200/5186 is... oops, roughly 22.2 FPS, nowhere near enough for a buttery smooth user interface!

Given that the glass tube itself only has 20 pins exposed, there must be some drive chip inside it, thus I want to drive it directly from my MCU. The tube is labeled GP1232AI, no datasheet online of course.

So then I traced out the pins for power and lo and behold:
1-2 ~ 41-42 — Filament (AC 3V)
5, 6, 39, 40 — GND
7 — Grid voltage (+44V)
38 — Anode voltage (+94V, huh! I've always thought VFDs operate in the range of 30-40V)
13, 32 — NC
9, 10, 11, 12, 35, 36 — ?
33 — Data, 34 — Clock
(other pin numbers not listed are not present on the tube at all)

All the "?" pins were in the range of 3.3V so I hooked up my analyzer to them. Then I brought up the display while shorting the test pin for the ease of benching (rather than finding where RS232 port went) and it shows a test pattern indeed:



Looking at them in PulseView, there seems to be no specific protocol — just a sequential number from 0x00 to 0x35 and then the bitmap data staggered in some way.



The data seems to be groups of three 1's except for the batch number 00, which has singular 1's in a layout that makes not much sense, but indeed this test pattern has every fourth dot dimmed, so it seems to be just sending 24 bytes = 192 dots per row and 53 rows, which then gets cropped in hardware.



There is no initialization sequence too, it just starts looping like this after reset no matter if I'm in the test mode or not. So I presume the controller on the PCB acts as a framebuffer and does all the legwork in terms of font rendering and whatnot.

However, attempting to just cut those tracks (D4/D5 in the pulseview grab) and wire them into an ESP32 constantly sending out an incrementing number followed by 24 of 0xFF yielded nothing but noise. In case they were some sort of reset signal I've cut them off altogether but then, somewhat obviously, no image at all anymore.

So I presume the other pulses are also somehow important, but I have no idea to what they might be or how to generate them.

Here is their timings, and I will also attach a pulseview file (ZIP file attached — you can use the free PulseViewprogram to view it):


Does anybody happen to know any similar display interface bus that could be needed here?

Thanks and best regards
Navigation
Message Index
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod