Reading a VFD...

(crossposted from http://arduino.cc/forum/index.php/topic,102167.0.html - seems like i should have put it here to begin with)

Here's a problem that's been presented to me this week, and I'm looking for ideas:

We have a device controller with a VFD display in which seven particular digits and two annunciators are very important. It would be extremely convenient to be able to monitor them from across the lab either visually or aurally (giving me an opportunity to use a http://www.magnevation.com/SpeakJet.swf !). Each digit has its own cathode, and the segment anodes are all properly chained-together making a nice little multiplexed display.

The controller does a multitude of things with various sensors and signals, and I don't feel like doing more than I have to - so monitoring/processing all those signals is out of the question. The controller has no output lines I could tie-into which would help me.

MY thought was to connect a 74165 (8->1 shift register) to the anode lines (don't know the operating voltages of the VFD yet, but whatever they are I'm not worried about getting them down to TTL levels), and use a 74595 (1->8 shift register) with logic gates (ANDs and ORs - again I'm not worried about level shifting) to the cathodes…

When I set a particular cathode's corresponding shift register bit on the '595 it would be ANDed with that (level-shifted) cathode's signal. All the resultant signals from the cathode position AND gates would be OR'ed onto the LOAD line of the '165. Long-story-short: one-by-one I could latch/capture the anode states for each digit and read them into the Uno and properly decode them. Then I could either drive another display -or- maybe use the SpeakJet to 'read' them out loud (which would be a LOT of fun).

Everything I've seen in the [displays] forum relates to using VFDs as (obviously) output devices; has anyone here any experience in, essentially, treating the VFD's signals as an INPUT device? Or is there already an existing chip that DOES this and I'd be 'reinventing the wheel'?

I crave your comments and suggestions.

Sounds like a plan. Use the common line for each digit to capture the unique segment info.
Might have to put a scope on the pins to see the timing:
Is it segments on, then common on/off? Or common on, segments on/ off, common off?
Something different?

Aren't these displays high voltage? Keep a good supply of magic smoke on hand, to replace what you let out.

It might be easier to tap the digital interface to the display and see what's happening there. If it's something as simple as RS232 between the VFD and the source, you could tap it there more easily that reverse engineering the display contents.

-j

Crossroads: correct. Whichever digit line I'm holding, it will only load the shift register with the segment pattern for that digit, and a small array is my lookup table to determine the value of that digit.

As for the multiplexing cadence, my previous experience with VFDs always established the segment pattern before grounding the particular grid, then grid-high, new anode pattern, next grid low, etc... While it's not impossible for this one to be different I'm HOPING this one works the same way or else I'll have to do a BIT more thinking. :smiley:

I suppose I could use two shifters in series and successively 'snapshot' the anodes and grids at the same instant - it'd then become a matter of ORing the segments relative to each digit and essentially doing a 'peak hold' until I get a valid number pattern for each digit, then maybe I wouldn't have to worry about cadence so much(?)...

Thanks for bringing cadence to mind.


kg4wsv: no, not really. VFD phosphors aren't like CRT phosphors - a typical display probably doesn't use a filament voltage more than about 3v-5v with 10v-20v for the anodes/grids. My plan was to connect each anode & grid through a sufficiently high resistor to a 2N2222 as an isolator. I should be able to determine a decent resistance once I start measuring voltages.

Everything's all on one board with one big VLSI chip, so as I can see it there's not a lot of choice other than deconstructing the display voltages.