Vacuum Fluorescent Display Driver

[bostonman]

I have an Agilent 53132A counter with a slightly messed up 12-digit display.

The odd part:

The display is fine during different stages. If I inject 10MHz, the display is fine except the 12th digit, segment C (right bottom vertical segment), remains on (something I could live with), however, if I access a menu, the segment is fine.

Injecting around 15MHz sometimes (I emphasize that word) causes digits four and five to have extra segments illuminated; and the same if I access menu options (AUTO TRIG is displayed as AUTOOTRIG). Other times extra commas and/or periods are displayed in multiple locations (hard to tell if it's trying to show a comma or it's just a bright period) Usually the wrong commas and/or periods are also in the fourth and fifth digit.

I'm not asking for help diagnosing the issue (unless someone has repaired a similar issue), but mainly I suspect the display driver IC (SN75518FN) because the frequencies seem to be correct if I watch the fourth and fifth digit change from correct to incorrect.

The driver chip datasheet (see attached) isn't exactly helpful because I'm unfamiliar with fluorescent displays. The circuit (see attached) uses 32 of the output pins on the chip which correlates to the datasheet. Unfortunately I can't locate the datasheet for the fluorescent display.

My initial assumption was this is similar to a seven-segment display and would be 84 driver lines (7 * 12), but this isn't the case since it's only using 32. My next thought is this is scanning using the internal shift register, but this still doesn't mathematically add.

The reason(s) I'd like to understand this: obviously to learn, but also maybe to use a logic analyzer (I have a 16-channel unit) to confirm the output isn't matching the input data.

Update: looking more, maybe I understood this a bit more than I thought. I'm assuming G1 through G12 activate each digit as the chip scans left to right (or right to left?). Since the chip also outputs SEG-A thru SEG-Q (17 outputs), looking at the display closer reveals each digit is comprised of 14 segments (rather than 7 like I thought), a comma, period, and a dot, this would add to 17.

If this is accurate, can I still measure this on a logic analyzer to confirm the chip is bad, and, how are other things on the display shown such as MHz, freq, per, Ch1, Ch2, etc...?

[pqass]

The display looks (see attached) to multiplex 12 digits with each digit consisting of 18 segments:
  8 line segments (standard a..g) with a split g segment,
  4 diagonals,
  2 center verticals,
  3 colon dots and comma (rightmost digit replaces the dots and comma with annunciators)
  1 annunciator.
I can't explain where two additional driver (SN75518FN) lines are used on the display.

How to drive VFDs can be found here. 

In summary, one digit (grid) line is energized (to +38VDC) along with selected segments of that digit (also to +38VDC); all other lines grounded. Then the next digit (grid) + segments are lit, etc.  Since the driver is just a SPI consumer, expect a stream of 32 bits * 12 * Hz refresh rate.

There is a low AC voltage across the FIL1+FIL2 lines providing a stream of electrons, with the mid-point (split) AC voltage biased (via zener) a few volts above ground so that any grounded driver lines keep that segment or grid off completely (no bleeding from adjacent segments).

I'm not sure which (display or driver) is causing the misfiring segments that you're seeing. This is a known problem and has been documented with other HP VFD products such as the 34401A on this forum. 

You could use your LA to compare the SPI stream with the driver output but be wary of the +38VDC so use a divider.  ie. an unchanging SPI stream should produce a unchanging output line state. If not, the driver is bad.  If true, and the display shows changing segments, then the display is bad.

[floobydust]

The display is multiplexed, 14 segments plus colon (DP2), decimal pt (DP1), comma (SEG-COM), annunciators (SEG-COM) and a few others Freq, Gate, Ch1. as simply extra segments per digit.
Segments go positive voltage wrt cathode to light them but digit (screen) grids must also go positive to enable a digit, so the segments can light.
Note the directly-heated cathode (filaments) are biased at 6.2V up. Not to be confused with end-end voltage which is the filament heater voltage. VFD power supply DC-DC converter U30-A outputs +38V and the filament bias I think done by VR1 or VR2 zeners on the main board.
So the VFD sees +31.8V (when '75518 is outputting +38V) at the grid and segments, or -6.2V (relative) (when '75518 is outputting 0V) to bias the VFD into cutoff.
If you get segment or digit overlap or smearing, I would suspect the 75518 but also confirm the cathode bias is OK at +6.2V and the anode supply is around +38V. I'm not sure how that Endcott DC-DC converter module is, what's inside.
Careful the logic analyzer can handle high voltage +38V signals.
You can use a scope and look for the signal swing say 36 to 5V low (@1mA) it has push-pull outputs and can source+sink current.
You can force the issue with the '75518, if it has weak outputs by stressing an output pin by adding load resistor and seeing what the output voltage does. Say a 20k to a VFD pin should not cause much change, either to GND or +38V - if the IC is OK.
Or the IC is switching slow and overlap between digits is what you are seeing.

HV518PJ is in production.

[bostonman]

I'm not sure which (display or driver) is causing the misfiring segments that you're seeing. This is a known problem and has been documented with other HP VFD products such as the 34401A on this forum.

Prior I did some research and found exactly what you referred to. I was trying not to guess and just swap without measuring and tried to understand the datasheet.

The explanations are helpful, but wow, still a bit confusing. Does each digit turn on and off rapidly? If I'm thinking about this correctly, let's say it's a four-digit display and 1, 2, 3, and 4, come into the serial input. Is '1' sent on all 17 output lines and the associated Gx output selects which digit to light (the far left digit in this example)? After '2' is received, the '1' digit is turned off, and '2' is shown in the second far left digit? It's done rapidly, so to the human eye it's not noticed?

My logic analyzer (Kingst 16-channel model LA2016 I believe) shows it can handle +/-50v. I'm uncertain how easy this will be to look at the serial data, figure out which bit is the fourth and fifth digit, and then see that it's outputting something other than the bit in the serial data.

[pqass]

The SN75518FN is a 32-bit serial-in shift register with latched outputs. This is similar to a cascade of 4, 74HC595s.

This means that it can receive, via SPI, 32 bits to fill its shift register WHILE the output lines still holds the previous 32 bits steady. The MCU then toggles the LATCH EN pin which moves the serial shift register [internal] outputs into the output latches which will now show a new state on the output lines (all at once). The STROBE input just briefly blanks all outputs (sets to GND) during the transition when the output latches are loaded with new serial-in data (since STROBE is tied to LATCH EN in the schematic).

So, as for your example display, the MCU sends 32 CLKs and DATA, then LATCH EN is toggled (LOW-HIGH-LOW) which causes those 32 bits to now appear on the output lines.  The MCU waits 4.2ms then outputs the next 32 bit digit data stream. After 4, 32bit streams+4.2ms waits, it cycles back to digit 1.  Only 1 grid output is ever enabled at a time otherwise the same segment data will be on in multiple digits.

Why a 4.2ms wait? A: You'll want to refresh each digit at least 60 times per second, so for your 4 digit example that's 4 * 60 = 240Hz or 1/240s = 4.2ms.  In the 53132A with 12 digits, you'll need at least 12 * 60 = 720Hz or 1/720s = 1.4ms wait.  The 32 bit stream needs to be fast enough to complete within one wait, obviously.

See attached Noritake diagram. The serial stream of grids and segments appears as a column (say T1). During T1 time, a new 32 bit stream is sent then transitioned to the output latches during the dotted vertical lines time where all output lines are blanked (GNDed) momentarily before showing T2 state on the output lines.  I think the reason for the blanking is to make sure all digits and segments are completely off so your eye won't perceive a dim segment that was on in the previous digit.

[bostonman]

Only 1 grid output is ever enabled at a time otherwise the same segment data will be on in multiple digits.

So as I assumed, each Gx selects the associated digit? Since 1, 2, 3, and 4, arrive as serial data, 1 is placed on the output, a blank pulse, Gx selects digit one, and a 1 is shown.

The diagram you provided definitely simplifies things.

Unfortunately my 16-channel logic analyzer doesn't have enough channels to look at all 32-bits and the input serial line simultaneously; or 17-bits if I ignore the Gx lines. Maybe I can look at 15-bits and see something obvious that will point to the output data being wrong whereas the input serial data is correct confirming the chip is bad.

Also, what is the purpose of the serial output pin? I'm guessing it's to feed the selected menu options back to the main board so it knows which settings were selected such as 'Auto Trig'.

On a side note, during my initial investigating, I discovered the Microsemi/Microchip replacement IC part number. I need to confirm mine is surface mount, but I was happy to see the chips (or replacement chip in this case) exist.

[pqass]

Yes, each Gx corresponds to one digit.  Both the segment data and grid (digit) to enable appear on the driver output lines at the same time.  The total display blanking (STROBE=HIGH) only lasts for the duration of the LATCH EN=HIGH toggle (LOW-HIGH-LOW); about 10-50 usecs as per section 4.2 in the Noritake docs.

You don't have to monitor all driver output lines.  If you know a particular anomaly happens on one digit, then just monitor the segments when that grid pin is enabled.  We know the first SPI bit out of the MCU corresponds to Q32 (pin 3) output line which is G1, the next bit is G2, ... bit 12 is G12.  The segments bits 13..32 are not readily obvious so you could decode them if you ramp up a frequency input while you monitor a particuar digit.  Once all bit positions are decoded to which segment they enable, you can monitor your problem digit while watching the display. If the bit stream doesn't change but the output lines do, that means: bad chip.

I'm not sure why they route the serial out of the driver back to the MCU.  The MCU knows what it sent.  Serial out is used to cascade to the next 75518.  Maybe there is another serial-in shift register elsewhere? ie. more than 32 bits are sent before LATCH EN is toggled.   The keyboard input is another set of 6 RnCm+READRLC+LKBD lines.

[bostonman]

Hopefully I'll have time this weekend to take some measurements. To be safe, maybe I'll use a voltage divider to avoid stressing the inputs to the logic analyzer (although it's a bit of work since I'll have to make one for all the channels).

Briefly looking at the board tonight to confirm it's a surface mount chip (although the BOM did confirm and it also shows the part number of HV518PJ which I didn't realize - I was looking at the part number next to the IC on the schematic), trying to connect to pins will not be easy without soldering fly leads; something I'm uncertain about since I'd like to avoid damaging anything.

The other unfortunate part: the display needs to be removed to access the chip.

I didn't see another 75518 for the serial out pin, but did trace it to pin 3 of a 74AC251; seems to be the only location it connects.

The schematics seem to have a few errors and/or some weird designs. The first error is in the attached, 5v into a LM317 and 5v out? The other weird thing is the 50ohm input option. Channel 1 uses 51ohms 1W, Ch2 uses two 100ohms 0.25W in parallel.

Although some weird things and/or errors, I'll take having schematics so I can repair my electronics than not having them.

[floobydust]

I think it's most likely an analog problem so the logic analyzer may not be useful. Just scope the display pins - that will reveal plenty.
If the '75518 outputs are weak and instead of say +36V/+3V signal swings, you get +35V/+8V the VFD could nuisance glow weak, not be blanked (for that seg/digit).
Is that a "1" or a "0" to the logic analyzer?

What complicates working on this problem is the VFD has different transconductance depending on its overall age and the seg/digit age. So the same voltages on a commonly used segment/digit verses a rarely lit segment/digit can make a difference between it working or staying stuck on dimly.

It's not a fun repair - the IC is stashed underneath the VFD. I had to remove the metal shields, all the while not smashing the glass or nipple around too much. Need extra care and patience. To desolder VFD Kovar pins, I will heat the pin on the board top-side using a soldering iron, and then vac desolder on the back-side. It works fast. The VFD pin and hole size is large.

[pqass]

I don't think you need to take apart anything just yet.  You have access to the VFD leads so it's just a question of understanding the VFD pinout. Once the pinout is identified and you've done some preliminary 'scope probing (below), you can then use your LA (via a divider).

The filament pins are almost always the outer pair which, according to the schematic, are pins 1 and 18. Start with an assumption (see attached). It could be numbered according to the white set or the red set. Or bottom white and top red or vice versa.  Or 1 to 18 on top and 19 to 36 on bottom.   The pinout is right in the service docs board layout (page 3). DUH!

You should be able to measure with a multimeter (in VAC mode) about 5.5Vrms between the FIL stubs and either the upper outer leads or lower outer leads. Identifying the filament leads will identify which row the grids are located in, therefore, the opposite row will have most of the segments.

Using an oscilloscope, you should be able to probe any lead other than the filaments. You should see square waves from GND to +38V; fast rise/fall-time edges, no runts. I think it's safe to attach your probe GND clip to the chassis which is likely connected to board ground (labelled as DCOM) though I couldn't find any connection between DCOM and PE/chassis in the schematics.  If you want to probe between filament leads only do so in differential mode; ie. using two 'scope channels, NO GND CLIPS, math set to A-B channel. That way you won't accidentally short one filament to ground (via GND clip) and possibly kill the DC-DC.

FYI: I found an earlier post of mine which identified a datasheet for the DC-DC converter. The schematic pinout for the part is off by one. The converter actually produces up to 44V which is lowered to 38V via 6.2V zener VR1.

As for the 75518 data out going back to the MCU...  on further inspection, the SPI topology used isn't the usual MISO/MOSI/SCLK common bus with individual SS per slave. Nooooo.... lets use a star topology where every MOSI/SCLK/SS has it's own 74AC138 and MISO is funnelled through a MUX.  The MCU then only needs MISO, MOSI, SCLK, PCS0..2 to select 1 of 8, and PCS3 to the enable pins on the '138s.  I still can't explain why it needs to re-read its own output. Display failure detection? Completeness?

[bostonman]

FYI: I found an earlier post of mine which identified a datasheet for the DC-DC converter. The schematic pinout for the part is off by one. The converter actually produces up to 44V which is lowered to 38V via 6.2V zener VR1.

The link doesn't appear to work, however, I probably already downloaded the same datasheet earlier this week; or maybe the weekend. Is this the one that supplies the FL1 and FL2 (?) power? If so, yes, I got that datasheet.

Also, I read through the thread from the link you provided. The second last message, or one of the last messages, provides an eBay link to "new" VFD's sold out of China. I'm wondering whether to buy a backup (assuming I repair this unit) should mine eventually burn out, dim, or I break it while replacing the driver chip.

Last night I had to place a DigiKey order and ordered a few driver chips. It seemed worth the gamble for $7.xx cost of the part. At least this way I'll have the chip on hand should I confirm the driver is bad, suspect, or be unable to get an adequate amount of measurements.

[pqass]

Yes. This one (attached).

[bostonman]

Yes, that's the datasheet I found the other night. Thanks for sending the corrected link regardless.

[bostonman]

I took some quick measurements. While the displayed was showing “AUTOOTRIG”, the G5 pin was snowing a high.

This tells me the chip is feeding the wrong data to the display.

Just wanted to ask this question before I take more measurements this weekend.

[pqass]

I took some quick measurements. While the displayed was showing “AUTOOTRIG”, the G5 pin was snowing a high.

This tells me the chip is feeding the wrong data to the display.

Just wanted to ask this question before I take more measurements this weekend.

Sure seems like G4 and G5 are both on as witnessed by the double "O" character. That shouldn't happen.  Although you didn't describe double/superimposed characters in your original post; just extra segments.  Since it's doubtful that the serial stream has both G4 bit and G5 bit on, I'd say it's a bad VFD driver.

[bostonman]

Sorry…. Unless I’m wrong, I discovered the double O after my initial post; but mentioned it  in another follow up.

Ideally, just for my own interest, I’d like to see the incoming data and individual digit data for educational purposes, so I’ll take more measurements. I believe the replacement chips are arriving Monday or so, however, I won’t have time mid week to replace it, so updates may be delayed.

[bostonman]

I'm slightly confused.

Attached are two scope measurements. The first one named 'All Hyphens' is the display showing all hyphens and not changing (I set auto trig to 'external' without having an external trigger, so it froze the display). The other is measuring the pins on the VFD (not the IC) - file named accordingly showing which channel is connected to which pin and ('AUTOOTRIG' displayed on the screen).

My confusion is not knowing which segment data line lights which display segment (this is something I should and can figure out on my own since my goal is to measure the data lines). Excluding not knowing which data line lights which segment, when a particular G line is activated and shows on the scope, the other channel on the scope should have that segment lit showing 40v. I'm getting confused over seeing a G line go high and then the data just jumps around (obviously different data for different digits), but how do I capture the particular bit for that G line?

The other confusion is having all hyphens on the screen. Even though every digit had a hyphen, channel 1 on the scope doesn't show the G line being activated. How can every digit display a hyphen if the G line isn't activated? This would imply that particular digit shouldn't have anything displayed, however, it has a hyphen.

The more I thought about things tonight, the more I realized maybe trying to take measurements with a logic analyzer is too involved. If I make voltage dividers for all 16-channels (even though my logic analyzer can handle up to 50v - I'd rather not chance damaging it due to any voltage spikes), I need to connect each divider to each data line - seems I'm increasing my chances of shorting something.

My initial concern was to confirm the incoming data to the VFD driver chip was correct. I'm sure the VFD driver chip is the culprit, but I was trying to confirm with seeing the data in versus out. Maybe I may rethink things and just replace the chip.

[pqass]

"I'm getting confused over seeing a G line go high and then the data just jumps around..."
"... but how do I capture the particular bit for that G line?"

As for the "All Hyphens - Ch1 Pin 28 Ch2 Pin 6-1.pdf" file, you're capturing SEG-A (pin 28) which as expected, is 0V.  You should be probing SEG-G (pin 35) or SEG-H  (pin 36) assuming SEG-A thru SEG-G mean the same segments as the typical 7-segment display; with SEG-H being left or right-half of the center horiz. segment.   As to why you're seeing other segment info, try using normal trigger mode, not auto, or lower your trigger voltage to say, 10V. See auto/normal explained.

"The other confusion is having all hyphens on the screen. Even though every digit had a hyphen, ... doesn't show the G line being activated."

Maybe SEG-H isn't the other half of the center horiz. line segment.  Maybe there is some multiplexing activity that outputs segment data temporarily without any Gx enabled (which won't be visible to the user). MCU funny business.

To determine which pin corresponds to which SEG-x, I'd put channel 1 on, say, G2 (pin 6), set trigger to normal on channel 1 to <10V, then use channel 2 to probe around pins 19-36, 3, 4.  Then change the value on the G2 digit (2nd from left) and re-probe to confirm the lit segments again.

[bostonman]

As for the "All Hyphens - Ch1 Pin 28 Ch2 Pin 6-1.pdf" file, you're capturing SEG-A (pin 28) which as expected, is 0V.  You should be probing SEG-G (pin 35) or SEG-H  (pin 36) assuming SEG-A thru SEG-G mean the same segments as the typical 7-segment display; with SEG-H being left or right-half of the center horiz. segment.

Wow..... one thing I can't understand about myself is how I dive into these projects more than some, yet, I miss the obvious. You are absolutely correct, I should have considered the fact I was on a data line that was blank.

Per your suggestion on probing the other pins to determine the segment order, I somewhat did that. My scope captures unfortunately have both channel 1 and 2 on the same 0v point, so seeing individual pulses is difficult. Ideally I'd like to determine which data lines control which segments so I can provide the information to this forum (assuming it hasn't already been done) to help others who experience the same issues.

The annoying part is I'm dealing with too much fluctuations with the unit. Sometimes the display is correct, other times it doesn't. By the time I try capturing the screen with incorrect displays, it changes again. Due to having the cover off, I use the lead of a resistor to short the pads so I can change menu options in attempt to "freeze" the counter (much like I did by setting it to 'external' trigger).

Then the data on the scope is jumping around, so I can't tell if I'm not triggering (although I'll try your suggestion on triggering) or if the data line is jumping.

Finally, I don't want to accidentally short anything, so I turn off the counter when I move the probe to another pin.

I'm either being too cautious, or over thinking.

[bostonman]

After building a voltage divider and setting up for measuring with the logic analyzer, I finally had time earlier, however, I think more questions than answers came out of it.

My logic analyzer is 16-channels, but the chip has seventeen outputs (not including two additional outputs for decimal places). I made the error of accidentally connecting one of my logic analyzer channels to DP2 meaning two of my logic analyzer channels weren't connected to two of the SEG outputs (one accidentally connected to DP2 and unable to connect to the seventeenth data line due to my logic analyzer being sixteen channels).

The logic analyzer results was not what I expected. Attached are four CSV files (they may not be worth assembling to show the logic because it contains many data points). The CSV files are named accordingly and I'll also upload some pictures of the display which will show the display at the time of the logic analyzer capture (give me a few minutes).

The reason the results weren't as expected: if I kept the logic analyzer set to keep polling, the pulses changed. I expected different because when the display showed (as in one file) all 1's and I removed the input so the display remained frozen, the logic analyzer (as I expected) shouldn't show different pulses each time it polled.

If the entire display is twelve digits, and each digit has fourteen (?) segments, and two decimal places, that uses sixteen out of the seventeen data lines (not sure where the seventeenth is used). The G lines are twelve total (for twelve digits?).

Due to the display having 'period', 'frequency', 'ch1', etc... and assuming each G line is for each digit, that leaves the question of how does the other stuff get lit? My guess is that more than one G line is on so the data lights MHz, CH1, etc...

Unfortunately I didn't have time to investigate this. If my assumption is wrong, then I should see the logic analyzer output to have each channel in sequential order (or no two G lines on simultaneously).

Due to the complexity of trying to not damage anything, I'm close to pulling the trigger and just swapping the IC.

[floobydust]

It's very difficult to fully troubleshoot the problem because it's likely inside an IC - the '518 or MCU that has crosstalk.
In the pics I can see right-most digit has "C" segment stuck on, is that the only malfunction in the pics?
I would scope that pin on the VFD to see if the '518's output driver has a problem like a weird weak voltage. But it is odd that segment prefers that digit. I was thinking of DRAM/SRAM stuck bits.
If you are pulling the VFD, I suggest putting a soft piece of tubing over the nipple, it is extremely fragile and easy to bang. Or scotch tape something maybe.
Getting the shields off does take a bit of extra heat, as I mentioned my technique is to use a soldering iron heating on the pin topside, and vac desolder on the other side. A two-handed affair. The VFD holes on the PCB are large though.

Some notes I found on the '518 protocol, to help you out if you are still digging:

Code: [Select]

For 53131A

The protocol is similar to SPI. It is clocked at ~1 MHz, with 4 byte word bursts at about 1 kHz rate. It is 5 V logic.

The lines and their SPI equivalents are:
VFDSCLK - Clock, data sampling on rising edge
VFDSOUT - Data, from MCU to display
VFDSIN  - Data, from display to MCU, 32 bit shift register
VFDSEN  - Enable, active high, inverted compared to a SPI /SS

VFDSCLK:
____   _   _   _       _   _   _____
    \_/ \_/ \_/  ... _/ \_/ \_/
VFDSOUT:
________________     _______________
    \___X___X___ ... ___X___X___/
VFDSEN:
   _____________     ___________
__/              ...            \___
Bit: (MSB first)
      0   1   2  ...  29  30  31

Every ~976 us (~1024 Hz), there is a 32 bit word, with bits clocked at ~934 kHz. After the first 16 bits, the clock makes a small pause of about 0.5 bit cycle.

Each 32 bit word enables one gate (character position) and any combination of segments for that position. The first 12 bits are gate enablers, the first/highest bit enabling the leftmost/most significant character. The segments are 14 bits for the segments of the digit/character display, 3 bits for the separator segments for ".",
",", ":" and ";" and 1 bit for the text label under each character. The rightmost character is special; instead of separators the bits enable the "u" (mu) and "s" unit indicators and the "Gate" text label, and it has two extra bits for the "M" and "Hz" unit indicators.

A frame has 16 words - 1 for each of the 12 characters, and 4 extra that can be highlighted, x0-x3 below. The frame rate is ~1024 / 16 = ~64 Hz.

Below data is shown as big endian, first byte leftmost, and with first bit on SPI as most significant.

Bits:
0xfff00000 - gate enablers (character position)
0x0000fcff - 14 segment character
0x00070000 - separators, on rightmost position "u", "s" and "Gate"
0x00080000 - text label
0x00000300 - on rightmost position units "M", "Hz"

Examples:

Text: "FREQUENCY 1 "; Labels: "Freq", "Ch1"
1000CC8C # char 8 "Q"
  100000 # char 0 empty
2000C087 # char 9 "E"
  202040 # char 1 "1"
4008888F # char 10 "R", label: "Freq"
  400000 # char 2 empty (space)
80008087 # char 11 "F"
  802030 # char 3 "Y"
80000000 # x3 - no highlighting
 108C084 # char 4 "C", label: "Ch1"
80000000 # x2 - no highlighting
 2008C2C # char 5 "N"
80000000 # x1 - no highlighting
 400C087 # char 6 "E"
80000000 # x0 - no highlighting
 800C40C # char 7 "U"

When a character is blinking, it changes between being normally displayed and being highlighted. The character is powered an extra time per frame using word x0-x3 which makes it brighter. The flashing, changing between the character and empty, is done in the normal word for that character. Only the 14 segments of the character seems to be
flashing and highlighted, not the indicators or the text labels.
As there are only 4 words x0-x3, only 4 characters can be highlighted using this mechanism, and it seems also never more than 4 characters are highlighted and blinking.

"LIM TEST: OFF", where "OFF" is highlighted and blinking
10000000 # char 8 space
  108087 # char 0 "F"
2000843C # char 9 "M"
  208087 # char 1 "F"
400860C0 # char 10 "I", label: "Freq"
  40C48C # char 2 "O"
8000C004 # char 11 "L"
  800000 # char 3 space
80000000 # x3 - empty, no highlight
 10B20C0 # char 4 "T", separator ":", label "Ch1"
  108087 # x2 - highlight char 0 "F"
 20044A1 # char 5 "S"
  208087 # x1 - highlight char 1 "F"
 400C087 # char 6 "E"
  40C48C # x0 - highlight char 2 "O"
 80020C0 # char 7 "T

10000000 # char 8 space
  100000 # char 0 empty ***
2000843C # char 9 "M"
  200000 # char 1 empty ***
400860C0 # char 10 "I", label: "Freq"
  400000 # char 2 empty ***
8000C004 # char 11 "L"
  800000 # char 3 space
80000000 # x3 - empty, no highlight
 10B20C0 # char 4 "T", separator ":", label "Ch1"
  108087 # x2 - highlight char 0 "F"
 20044A1 # char 5 "S"
  208087 # x1 - highlight char 1 "F"
 400C087 # char 6 "E"
  40C48C # x0 - highlight char 2 "O"
 80020C0 # char 7 "T


[bostonman]

In the pics I can see right-most digit has "C" segment stuck on, is that the only malfunction in the pics?

In the pics I posted, if I'm not mistaking, the commas and/or periods are wrong, and it's not showing "MHz".

Sporadically, digits four and five are wrong, commas and/or periods are wrong, and, usually, in all cases (I believe) "AUTOOTRIG" is displayed.

Unfortunately I don't have a solder VAC just solder braid and a solder plunger (the manual pump and push button release type).

I think to save time and reduce the risk of damage, I may just move forward with replacing the HV518 chip.

I was hoping to figure out which data line and G line toggled which segment(s) in each digits, and not only gain some knowledge, but provide the information back to this thread for others to learn from and/or help diagnose issues on their end.

Since I have the logic analyzer out and the display sitting outside the unit, I'll probably measure the G lines on the logic analyzer; and then move forward with replacing the chip.

[floobydust]

If desoldering a few VFD pins doesn't go well, I'd suggest getting a decent handheld vac desoldering tool. I find braid is hard on boards, for heat and abrasion on larger TH pins. Unless you have a good technique.
We used Soldapullt back in the day they were good if greased well. The chinese ones I hear many are useless. The test was to see how much suction it had on your finger, the piston should move slow if the tip is blocked.

[bostonman]

The G lines are equally confusing. This is with a frozen 5MHz (5.0000000000) on the screen.

The data on the analyzer lines that are not labeled weren’t connected. For some reason they are picking up stray signals and showing on the captures.

[floobydust]

I don't see G12, G5, G2 being enabled at all and G1 signal looks scrambled with four extra pulses, offset in time as well. The shift-register looks defective