HP 34401a DMM with leaking segments

[floobydust]

would be nice to have another type of display adapted  ...

It's the dozen annunciators that are a PITA, and sometimes multiple ones are lit.
A new display board that supports the VFD (as these are still available), or supports a graphic LCD/OLED display is about all you can do.

[free_electron]

its the driver.
the adjacent pins in the chip leak signals. they ALL go bad sooner or later.
simply replace the driver chip.

[qu1ck]

@free_electron
If you read my first post you would have seen that I linked to your earlier equivalent statement. And later in the thread I disproved it, at least in my particular case.

[floobydust]

It's a difficult problem to troubleshoot. Everything is level-shifted, there's six different rails/bias voltages and VFD's are uncommon knowledge. A troubleshooting mistake is too costly for these gems.

The NEC MCU VFD driver stage could age and go leaky from ion migration on the die.
I thought this was the root cause of ghosting segments, but xemax replaced the VFD which fixed the problem 


My understanding is OP disconnected a VFD segment from the driver IC and the segment remained lit, ghosting. He then added a very strong pull-down of 2k7 (to -18V? GND would not go to cutoff) before the segments went out. The driver MCU output stage has internal ~140k ohm pulldowns to -18V, there should be very little current in VFD cutoff. This implicated the VFD display as being leaky.

I do not know of any current-leakage path inside a VDF other than a gassy tube (partial air ingress), or stray capacitance causing ghosting due to mux frequency.

Measuring voltage (to GND) on a disconnected segment or digit control grid will give a -ve voltage reading, as electrons flow from the cathode to the anode or grid then multimeter (+). You can have grid current flow, it is not always high-impedance if near or above the anode potential.

This is the problem troubleshooting- if the VFD+driver IC pin stays too +ve and the segment ghosts, it could be the IC or the VFD it seems.

edit: fixed URL

[qu1ck]

My understanding is OP disconnected a VFD segment from the driver IC and the segment remained lit, ghosting. He then added a very strong pull-down of 2k7 (to -18V? GND would not go to cutoff) before the segments went out. The driver MCU output stage has internal ~140k ohm pulldowns to -18V, there should be very little current in VFD cutoff. This implicated the VFD display as being leaky.

Exactly. To reiterate my experiments more clearly:
Segment connected to driver: ghosting.
Segment disconnected completely: ghosting.
Segment pulled to -18v with 100k: ghosting.
Segment pulled to -18v with 2k7: no ghosting.
Waveform observed on the driver output when it's connected to ghosting segment: fuzzy +2v when nearby segment is high instead of expected -18v.
Waveform observed on the driver output when it's not connected to the ghosting segment: proper square +-18v.
Waveforms on signal repeater using 2 bjts between driver and vfd segment: clean square wave on repeater input, output is same fuzzy +2v when it should be low (repeater uses 100k pull down to -18v).

By fuzzy +2v I mean it varies from 0 to 2v on sort of randomly, but it does not look like capacitive charge/discharge exponent so I don't think it's some stray capacitance, but it's hard to tell.

[qu1ck]

[free_electron]

@free_electron
If you read my first post you would have seen that I linked to your earlier equivalent statement. And later in the thread I disproved it, at least in my particular case.

I still say it is the driver chip.
Leaving segment pins floating capacitively couples them to adjacent ones and they 'ghost'. Thats why the pulldown was able to switch em off.
The high voltage driver is a push pull type.  The display lines are supposed to be driven hard high or hard low. if one of the transistors in the totem pole output dies the display line is left floating during one phase and it capacitively picks up the adjacent lines. These things are mulitplexed so the signals couple if they ar enot hard tied high or low by the driver.

i have repaired at least 6 or 7 by replcing the drivers. i have never seen a bad display , apart from an aged one where the heaters have gone bad. pumping up the heater voltage briefly to burn off the cruft solves that ( temporarily )

[floobydust]

Wait- I think we're confusing the 34401a two different VFD display boards.

Front Panel board 34401-66502 (for S/N 3146A59641 and below) used NEC 4-bit MCU uPD7527a which has HV VFD driver built in.
Second Gen board 34401-66512 uses 80C51 MCU with TI SN75518 VFD driver IC, replaced by Microchip (Supertex) HV518PJ

The TI driver has push-pull output stage, while the NEC FIP output stage is PMOS with weak pull-down.

[bitseeker]

@qu1ck: For not having much time to work on it, this is really awesome progress!

@floobydust: Yeah, there's been quite an upswing in prices over the past year or two. Pretty interesting. Although they're discontinued, it's not like there aren't many available. I wonder what's been driving the steady rise.

[coromonadalix]

ther popularity maybe ?   they seem's to be easily repairable with all the threads and common knowledge about them, once they work, they are reliable ...

[qu1ck]

The SSD1322 based OLED display came in the mail today.
Started reading up on the docs to figure out connections and protocol. Should be fairly simple to adapt my ili9481 code to it, except for the 4 pixels per column addressing. To write individual pixel you have to either read gram, modify and write or keep a frame buffer in sram.
Ugh.

On the bright side documentation is really good (kudos to buydisplay.com). Even though driver chip datasheet that they have on their page is preproduction version with huge watermarks and some TBDs in important characteristics (wanna know timing generator frequency? TBD, supply current? TBD, segment output current? tough cookies! TBD!) full final version is easily googleable. Other docs like their panel characteristics and code example are useful. Sadly no electric diagram of the panel. I'll email them just in case, maybe they will share it.

I'll try to code support for this screen in the upcoming days.

Also I have a great idea to enhance the usefulness of this mod, won't spoil it just yet (I don't know if it will work out).

[bitseeker]

Oh, the suspense!

[coromonadalix]

maybe this datasheet may help : https://www.newhavendisplay.com/app_notes/SSD1322.pdf

[qu1ck]

coromonadalix thanks, found that link as well.

Seller replied, no schematic for us
But it's easy to identify the switching IC (sot23-5, top marking looks like 1b3gc, could not find anything in online smt code databases). It has a big tantalum and an inductor next to it. I think just ripping that one out and supplying 12v directly will do fine. But that's a later step, for debug and prototyping simply powering everything from external usb works fine.

[coromonadalix]

an future competitor to the 6 1/2 digit meter thread here  lolll

[floobydust]

Are you making a product out of this VFD->OLED conversion, is that your goal?

I have lots of ideas but maybe another thread is a better place to discuss and get the community to collaborate.
But I understand if you want to do this on your own. While open source is a wonderful notion, I don't think it's at all realistic.

[qu1ck]

I'm not an EE, i'm just a software engineer tinkering with hardware on his own time. I don't plan to make a commercial product out of it, I don't think it would viable for production anyway because of too limited target audience. And the money I would make off it would be peanuts compared to what I'm paid to write software for the big leagues (wink, wink ).
I will just open source everything when it's ready.

Progress pic of the day, made new display work:


Starting on secret feature now

[bitseeker]

So cool. I see you've got annunciators (at least one in the pic) and the sampling indicator, too.

Oh, the suspense...

[coromonadalix]

Homer Simpson  drooling  loll

[wictor]

Hi, nice to see that someone else has done this with same parts that I planned. I have E3634A with broken VFD. I reversed the protocol with sigrok earlier during the winter and ordered 3,2" OLED and stm32f103. But then I got some other things to do and this project is not proceeding...
If I recall correctly, some settings and dimming some digits is done inside the cpu in front panel and those are not visible in SPI communication. So it seems that I would need to spy signals between front panel cpu and display driver to get full functionality of the original display.
Wictor

[qu1ck]

wictor
Yep, dimming and flashing is done in front panel but cpu does send a special control character in the message to instruct FP to do it. At least that's the case in 34401a.

[Cyberdragon]

@free_electron
If you read my first post you would have seen that I linked to your earlier equivalent statement. And later in the thread I disproved it, at least in my particular case.

I still say it is the driver chip.
Leaving segment pins floating capacitively couples them to adjacent ones and they 'ghost'. Thats why the pulldown was able to switch em off.
The high voltage driver is a push pull type.  The display lines are supposed to be driven hard high or hard low. if one of the transistors in the totem pole output dies the display line is left floating during one phase and it capacitively picks up the adjacent lines. These things are mulitplexed so the signals couple if they ar enot hard tied high or low by the driver.

i have repaired at least 6 or 7 by replcing the drivers. i have never seen a bad display , apart from an aged one where the heaters have gone bad. pumping up the heater voltage briefly to burn off the cruft solves that ( temporarily )

It's most likely bad blanking timing or something from the driver. As can be seen here, the timing is relatively tight so it wouldn't have to be off by much to cause a problem.

https://www.noritake-elec.com/technology/general-technical-information/vfd-operation

EDIT: I would think a VFD that's ionized badly and leaking would be somewhat blackened.

[bitseeker]

@wictor, that's interesting. Is the protocol for the E3631A/E364xA power supply front panels the same as either generation of 34401A? It'd be great to have a configurable front panel replacement for many/all the HP VFD modules.

[wictor]

@wictor, that's interesting. Is the protocol for the E3631A/E364xA power supply front panels the same as either generation of 34401A? It'd be great to have a configurable front panel replacement for many/all the HP VFD modules.

Hi,
I'm confident that it would be possible to have configurable replacement for at least E3631A and E3634A. I have swapped the panels between these models and they work, but of course annunciators are different. Annunciators are sent as bitmask, so you just would need to know used model, and then you could display correct annunciators. I think that front panel in E363xA and 34401 are using same FW, so I'm pretty sure that you could have general replacement for most of that era Hp/agilent models. Some day I'll check the 34401 model for the used protocol, but now I don't have the need or time for that job.
Wictor

[qu1ck]

I will publish 34401 protocol.
It is substantially different from 34970a though, that one uses uart for bidirectional data transfers instead of spi like protocol in 34401. Even control frame markers are different, let alone annunciator bitmasks or button press events.

Sent from my moto g(6) using Tapatalk