Author Topic: HP 34401a DMM with leaking segments (Read 72311 times)

qu1ck · « **on:** May 05, 2018, 07:11:27 am »

Hi all,

I recently became a happy owner of this used but in good condition DMM (see first pic) which seems to have only one issue that I could find so far: display shows dots where there shouldn't be any and some symbols (4w, buzzer) show up as well.

It is old (cal string says "feb 1996", revision 04-01-01) but perfectly clean on the inside and other than the display everything seems to be in good shape.

So I started searching the forum for similar symptoms and found https://www.eevblog.com/forum/buysellwanted/ebay-many-faulty-hpagilent-34401a-multimers/msg811170/#msg811170

It talks about leaky drivers with NEC part that are used in newer front panels but mine is the old one with unobtanium UPD7527. Is this issue relevant to old style panels too?

Either way I decided to take it apart and look at what the driver is sending to display. Like I imagined the dots and symbols are segment 14 and 15 and they are somehow linked together. See the scope screenshots. Both have the following setup: ch1 - chr11, ch2 - seg14, ch3 - seg15.
Whenever segment 14 is high (+18v) segment 15 goes to around ground, although when 14 is low (-18v), 15 can be driven both high and low successfully.
Btw I did not figure out which segment is 14, it seems to be the lower horizontal one (think underscore).

So here is what I am thinking.
1. Somehow "help" the driver with some outside circuit that will pull pin to -18v when driver outputs anything less than say 5v.
2. Much more involved but also should be great help to others: reverse engineer the protocol between main board and front panel, reimplement it on another MCU and output the display on a nice big OLED screen like this guy did for his 34970a:
https://www.eevblog.com/forum/repair/reverse-ingeeniring-hp-34xxx-display-panel-serial-protocol/

With multi layer board doing 1 may not be possible without splicing pins of the display itself. There may be other issues as well, I have not thought about this too much. Your ideas are welcome.

For option 2 looking at the schematic suggests that likely SPI is used in 34401 instead of usart as in 34970a so it can be completely different in terms of packet format, acks, etc. But should be still doable if it's SPI, would be much harder if it's something else. Protocol is referred to as "4 wire serial" in the service manual but the pins on UPD7527 are marked SCK, SO, SI, what else could it be? I'm not sure what is the purpose of INT(errupt?) pin though. Will have to take a scope to it under different modes and see whats going on there.

If I succeed than the display can be swapped for a 3.2" OLED with a blue pill on a side. Cheaper and more importantly much more accessible than replacement VFD display with UPD7527.

Thoughts?

UPD: segment 14 must be upper-left vertical segment. Deduced from both "V" and "4" having the dot next to it, that's the only segment they have in common.

DC1MC · « **Reply #1 on:** May 05, 2018, 08:38:36 am »

I've never had the opportunity to have such a nice instrument

, but if the display driver exhibits this behavior I think that a quad op amp, put in the most basic comparator mode, should be able to do the trick as long as there is still a way to analogically differentiate between signal levels of the driver output.
That is put an LM614 or similar (it has to accept >= than +/- 20V as supply, and be quad or more) to the most simple comparator mode, that is the [- Input] to ground or some reference voltage ( an 10k potentiometer also connected to the voltage supplies) and the [+ Input] to the driver output, the op amp [Output], of course to the display segment. Basically this is it, the not so rich man adjustable signal signal rejuvenator

.

I have no idea what is the logical interface to the display board (parallel input, SPI-like sync or actual async serial) but if you can hook a cheap LA to it and post some traces, I promise to have a look and try to decode the protocol, maybe the extra karma and sympathy bonus will allow me to get a similar device sometime.

Cheers,
DC1MC

qu1ck · « **Reply #2 on:** May 05, 2018, 10:31:37 am »

I will definitely hook it up to a logic analyzer but first I need to find any dip comparator

Everything I got is smt. Not ideal for experiments.

Interestingly the old front panel works with +13 to +18v digital logic levels while new one is on the low side -18v to -13v. The schematic shows that data out from front panel goes straight to an ASIC pin, with a pull up to +5v. It forms a voltage divider with a series resistor that is present in new panel so that logical 0 is around 0v on the ASIC instead of -18v. But on old panel there is no series resistor, are they sending +18v straight into logic board?

I'll have to measure that tomorrow, 3:30am right now, too tired to think

I'll come back with some experiment results soon.

Samogon · « **Reply #3 on:** May 05, 2018, 12:01:20 pm »

https://www.eevblog.com/forum/buysellwanted/ebay-many-faulty-hpagilent-34401a-multimers/msg811170/#msg811170

bitseeker · « **Reply #4 on:** May 05, 2018, 06:48:52 pm »

@Samogon: The OP already referred to that link near the beginning of his post.

@qu1ck: Interpreting the front panel communication with the motherboard in order to completely replace the old display would be interesting and useful for keeping alive the many old 34401A devices out there, if you're inclined to dive into that endeavor.

I had heard that some of the old driver ICs were out in the world, but I had never located any.

Samogon · « **Reply #5 on:** May 05, 2018, 10:39:24 pm »

I apologize

floobydust · « **Reply #6 on:** May 07, 2018, 04:33:27 am »

Anyone know the VFD size? Or the front PCB dimensions (width)?

Seeing what would fit....
For glass (no frame) OLED's standard 256x64 size:
3.12" are 88mm W x 28mm H
5.5" are 146mm W x 45mm H (but expensive ~$100)

Some mentioned if the main CPU firmware is changed, a second-generation front PCB works.
The old uPD7527 seems to use a different com protocol than the 80C51.

bitseeker · « **Reply #7 on:** May 07, 2018, 06:55:00 am »

The tinted lens in front of the VFD is about 153 x 36mm. The top 10mm or so is occupied by the model badging, so a display around 120 x 25mm would probably be OK. That 88 x 28 might work.

qu1ck · « **Reply #8 on:** May 07, 2018, 10:51:47 am »

I've got good news and bad news.

Bad news is that it's not the driver. Since I didn't have suitable comparator at hand I just quickly put together a simple signal repeater using 2 bjt's. It only outputs high when input is 20v or so above negative rail.

I tested it and it worked perfectly and produced expected square wave with no load.
So I cut the pin of the display, hooked my contraption in between the pin and it's pad and what do you know

No difference, zip, nada. Now the input was a clean square but output was the same mess, which means driver was doing it's best to begin with, it's something in the display pulling the pin up. Maybe stronger pull down resistor or push-pull output would have rectified it but at what cost? Increased current, more segments burned? I didn't want to risk it. So I soldered the pin back to it's place and switched to plan B, which brings me to the good news.

Protocol is definitely SPI:

I captured 4 seconds of traffic and with some bash-fu extracted ascii data:

Code: [Select]

$ sigrok-cli -i capture.sr -P "spi:mosi=SI:clk=SCK:miso=SO" -A spi=mosi-data | xxd -r -p
  000027 mVDC       ☺    000027 mVDC       ☺    000026 mVDC       ☺

Now we are getting somewhere

Sigrok capture file is attached for those playing along.

floobydust · « **Reply #9 on:** May 07, 2018, 06:21:15 pm »

The VFD drive for the older 34401a's is complicated to troubleshoot.

In the interest of science and keeping these workhorses out of landfill, I did analyze the circuit. It's kind of a bear because of PMOS and six different supplies.

It would be worthwhile to see if the VFD's grid-threshold voltage has just shifted due to aging, or the NEC uPD7527A 4-bit MCU HV output has gone leaky, keeping segments dimly on.

I would confirm:
VFD cathode (filament) -12V bias, from zener CR556/C559 at the Xfmer on the PSU.
VFD MCU IC pre-driver bias -10V, from zener CR600/C607.

Keep in mind you can get grid current flowing, it's not high impedance if the grid is +ve it acts like an anode.

I would be tempted to first vary the -12V cathode bias, carefully (use floating psu with zener removed) and see if the -12V/-18V = -6V cutoff is enough.
My present theory is the tube ages outside the circuit's cutoff voltages and segments stay dimly lit. Other threads said changing the VFD cured the problem, so this is the only explanation I could come up with.

bitseeker · « **Reply #10 on:** May 07, 2018, 11:46:59 pm »

@qu1ck: Good to see that it's SPI. Substituting the VFD is still an interesting solution in the long run.

@floobydust: Interesting. I hadn't seen before that replacing the VFD fixed the phantom dots.

floobydust · « **Reply #11 on:** May 08, 2018, 04:54:44 am »

This thread, member says it's the display: https://www.eevblog.com/forum/testgear/hp34401a-display-with-dots-after-every-digit/msg1228322/#msg1228322
This thread, member says it's the driver MCU: https://www.eevblog.com/forum/buysellwanted/ebay-many-faulty-hpagilent-34401a-multimers/msg811170/#msg811170

I was looking at what's involved making an OLED conversion, as this big VFD and driver scheme was used (at one time) across the HP/Agilent product line and is going obsolete for parts.

There are a few flavours of VFD's with special annunciators being the difference.
Universal counters: HP-58503, 53131A, 53132A, 53181A
Power Supplies: E3631A, E3649A, E3642A, E3643A etc.

It looks not bad to convert, but a big OLED display is as expensive as a replacement VFD ~$60 so I didn't think there would be interest.

qu1ck · « **Reply #12 on:** May 08, 2018, 05:13:38 am »

@floobydust
In my case it's 100% the display. When I disconnected that segment in my experiment it was still lighting up, with the pin flapping in the breeze. And driver was sending perfect square wave +-18v as expected, very different from what I was seeing on the scope before (see my first post). Connecting my bjt output stage which is similar to your schematic with fets did absolutely nothing.

You don't have to buy 5" oled, it won't even fit because it is higher. 3.2" oled is $30, add an mcu board and some mounting hardware, that's $35 tops. Half the price of a VFD, much more value in terms of longevity and repairability. I bet you can even make the digits the same size, just make the font more compact, VFD wastes a lot of space.

DC1MC · « **Reply #13 on:** May 08, 2018, 05:41:41 am »

@qu1ck:

IMHO I will still try first an "analogue repair", the segment has to have a cut-off voltage somewhere and if there is a little drive current more, it wont hurt. But if you try to go on the OLED display route, the message structure could be simpler maybe, but is hard to think how. The values are in nice ASCII and the non-printable chars have most likely the bit fields with the status of different aux indicators around. I can't think of a controller that will not be able to decode this message. What is the clock frequency, I'm too lazy to launch Sigrok now ?

Cheers,
DC1MC

qu1ck · « **Reply #14 on:** May 08, 2018, 06:34:44 am »

@DC1MC

The thing is to shut the segment off you just have to put it at low potential, there is no current. At least that is my understanding of how VFD works. Both grid and segment have to be at positive voltage relative to filament for segment to light up. If one or the other has low potential electrons won't flow to the segment.

Since in my display driving one segment high also induces high potential on another pin it leads me to believe there is some short in the tube itself. I don't want to force that segment low, that might increase the current significantly and those thin threads connecting the dots won't take much.

Maybe someone with old display that had similar issue will try it but I'm reluctant, at least until I have alternative solution in place.

SPI clock is around 93khz. Any controller will be able to decode, but you need something with at least full 8 pin port to quickly push image to the 8080 oled display. Blue pill stm32f103 is super cheap and has plenty of pins, I will likely use that one. Arduino pro mini should work as well and won't require level shifters.

DC1MC · « **Reply #15 on:** May 08, 2018, 01:09:56 pm »

No display has such a thin thread that will not take 1mA.

floobydust · « **Reply #16 on:** May 08, 2018, 04:54:04 pm »

If a row of segments stays lit with the VFD pin lifted, then there has to be some leakage current.
I don't know of any corrosion or ion migration mechanisms here, occurring inside a VFD. Only a gassy (some air ingress) tube shows leakage currents, the Getter can sometimes show that.

Instead, it might be the VFD stray capacitance to adjacent segment (internal) traces, that you are seeing with the pin lifted, enough to light a segment.

Normally the driver IC has weak current-sink ability to discharge the anode (capacitance and gas leakage current), and a small time delay with the mux driver between selecting digits, to prevent ghosting.

HighVoltage · « **Reply #17 on:** May 08, 2018, 05:14:15 pm »

You can test a VFD manually by applying power to the VFD and then apply a voltage to each segment and look what is lighting up.

bitseeker · « **Reply #18 on:** May 09, 2018, 03:20:54 am »

Quote from: floobydust on May 08, 2018, 04:54:44 am

I was looking at what's involved making an OLED conversion, as this big VFD and driver scheme was used (at one time) across the HP/Agilent product line and is going obsolete for parts.

...

It looks not bad to convert, but a big OLED display is as expensive as a replacement VFD ~$60 so I didn't think there would be interest.

In the long run, though, it may still be beneficial. As you said, with parts going obsolete, even if the price is the same for the VFD, it eventually may not be an option. On the other hand, with a custom front panel controller, one could use other available VFD, such as dot matrix, as well as other display technologies. Anyway, interesting stuff to explore.

qu1ck · « **Reply #19 on:** May 29, 2018, 06:52:14 am »

Update:

With a strong pull down (2.7k) I got the ghost segments to finally disappear. But I did it on the disconnected pin, I don't want to try it with pin connected to driver as well, I'm not sure the driver will take it and I don't want to kill the front panel driver because it does input processing too.

On the other front:

It's just a proof of concept at this stage. It doesn't decode lower symbols, it skips bytes sometimes and shows gibberish, but it kinda works.

floobydust · « **Reply #20 on:** May 29, 2018, 09:45:22 pm »

Did you measure the filament bias voltage, or try changing it? VFD cathode (filament) -12V bias, from zener CR556/C559 at the Xfmer on the PSU.
I keep thinking this problem is due to the VFD aging and cutoff voltage shifted, making the driver look like the culprit- but it's not.

For substituting the VFD with an LCD or OLED display, I realize radiated EMI is a big concern. It would actually be the hardest part I think.
You have to keep things as quiet as possible. There are no buck converters here, and the metal shield around the VFD is there for good reason.

The display and main cpu do talk back and forth as a self-check, so that might be the occasional garbage you see.

qu1ck · « **Reply #21 on:** May 29, 2018, 11:28:58 pm »

Filament bias looked fine on the scope, waveform was completely within -18 and 0v, which is all that is needed, I think. Did not do any more precise measurements.
Problem is that for ghost segments there appears fuzzy 0v to +2v potential on the display pin from some internal short (as I deduced from that potential appearing even on unconnected pin). Can't fix that with bias unless you shift it much higher than it is intended to be which will reduce contrast.

LCD I'm currently using does not have any converters, just a linear reg. Also it has a shield.
For final version with OLED I will have to rip out the 12v boost converter and supply it directly with linear regulator as well. It should be even better EMI-wise because much smaller voltages are involved here instead of +/-18v swings of VFD.

Regarding garbage I'm sure it's my code, I just don't have the interrupts and timings right (I'm doing software SPI to read both input and output at the same time).
I already reverse engineered main portions of the protocol and have a good idea of packet format, there is no meta info exchanged between front panel and main cpu, only "display this text", "display these symbols" and "button/combination pressed".

I will post everything in detail as I do the rest of the work. I don't have as much time as I would like to tinker with this, so updates may be slow

floobydust · « **Reply #22 on:** May 30, 2018, 06:01:10 pm »

The 3.12" OLED displays I looked at are about 0.6W-0.7W; 100% pixels lit is max. 50mA at 12-15VDC, and 33mA with 50% pixels on. I don't know the 34401a power budget for how much current is drawn for the VFD and its MCU.

Because the +18V rail goes right to the A/D and analog sections (after 3.3V zener to make +15V) I would not power a display from that rail, in order to keep it super quiet.
It may be the multimeter's limiting factor- noise on the analog +ve rail from the display. Gen2 of the display board also added RFI filtering.
Gen2 display board, if the main MCU does not get a response from the display MCU, the main MCU will reset the display MCU by asserting its reset, as I recall.

I hope the project bears fruit, the multimeters are commanding very high prices now on eBay.

qu1ck · « **Reply #23 on:** May 30, 2018, 07:37:39 pm »

We are only displaying some text on the OLED, it will never light up more than 30% of pixels. Power requirement is quite low, but I agree on the noise. I will look for a good place to tap power from.

I fixed the garbage glitch (turns out micros() in stm32duino is just not reliable) and reversed 99% of the protocol. I am not certain about purpose of couple control frames and characters but for all practical purposes I can show exact same information on the display and decode button presses. Unless there are some more special cases in the modes that are not accessible to me at the moment (remote control mainly) I think I am done with this part.
Now on to improving code to display all the annunciators properly.

coromonadalix · « **Reply #24 on:** May 31, 2018, 02:43:36 am »

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

floobydust · « **Reply #25 on:** May 31, 2018, 05:51:21 pm »

Quote from: coromonadalix on May 31, 2018, 02:43:36 am

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 · « **Reply #26 on:** May 31, 2018, 06:32:49 pm »

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

qu1ck · « **Reply #27 on:** May 31, 2018, 07:39:38 pm »

@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 · « **Reply #28 on:** May 31, 2018, 09:49:21 pm »

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 · « **Reply #29 on:** May 31, 2018, 10:06:57 pm »

Quote from: floobydust on May 31, 2018, 09:49:21 pm

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 · « **Reply #30 on:** June 01, 2018, 08:06:33 am »

free_electron · « **Reply #31 on:** June 01, 2018, 04:06:59 pm »

Quote from: qu1ck on May 31, 2018, 07:39:38 pm

@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 · « **Reply #32 on:** June 01, 2018, 08:48:51 pm »

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 · « **Reply #33 on:** June 02, 2018, 02:11:38 am »

@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 · « **Reply #34 on:** June 02, 2018, 02:33:52 am »

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 · « **Reply #35 on:** June 12, 2018, 08:46:05 am »

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 · « **Reply #36 on:** June 12, 2018, 09:11:39 pm »

Oh, the suspense!

coromonadalix · « **Reply #37 on:** June 13, 2018, 12:12:16 am »

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

qu1ck · « **Reply #38 on:** June 13, 2018, 06:58:37 am »

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 · « **Reply #39 on:** June 13, 2018, 10:24:35 pm »

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

floobydust · « **Reply #40 on:** June 16, 2018, 07:26:34 pm »

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 · « **Reply #41 on:** June 17, 2018, 10:32:55 pm »

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 · « **Reply #42 on:** June 18, 2018, 11:59:29 pm »

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

Oh, the suspense...

coromonadalix · « **Reply #43 on:** June 21, 2018, 12:48:42 am »

Homer Simpson drooling loll

wictor · « **Reply #44 on:** June 21, 2018, 04:46:37 am »

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 · « **Reply #45 on:** June 21, 2018, 05:09:07 am »

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 · « **Reply #46 on:** June 21, 2018, 06:45:56 am »

Quote from: free_electron on June 01, 2018, 04:06:59 pm

Quote from: qu1ck on May 31, 2018, 07:39:38 pm
@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 · « **Reply #47 on:** June 21, 2018, 11:40:05 pm »

@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 · « **Reply #48 on:** June 22, 2018, 04:16:43 am »

Quote from: bitseeker on June 21, 2018, 11:40:05 pm

@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 · « **Reply #49 on:** June 22, 2018, 04:53:15 am »

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

HighVoltage · « **Reply #50 on:** June 22, 2018, 12:00:42 pm »

Really nice job!
Looking forward to your final design.

bitseeker · « **Reply #51 on:** June 22, 2018, 09:03:21 pm »

I second what HV said.

Somewhere, I have some Noritake dot matrix VFDs. I think they're 40x2 or maybe 40x4; don't quite remember. If I find them, I'll have to see if they might fit on some of the HP devices I have (DMMs and power supplies). Although replacement isn't necessary now, eventually they might need them.

qu1ck · « **Reply #52 on:** June 25, 2018, 12:18:17 am »

All right, here it is. Behold: the secret feature unveiled

https://youtu.be/LWxOfaXVN3I

That's right. It's a 240 positions resolution, 20fps bar graph. Supports signed and unsigned measurements.
For high fps you have to switch to 4 digit mode. In 5 and 6 digit modes you get 2-3 fps. You can see fps counter in top right on the display.

Pic of an unsigned measurement:

wictor · « **Reply #53 on:** June 25, 2018, 06:54:31 pm »

Nice work!

bitseeker · « **Reply #54 on:** June 25, 2018, 10:45:56 pm »

I love it!

Makes me want to buy another 34401A, but with a bad display, to upgrade it.

Next secret features: graph and histogram?

HighVoltage · « **Reply #55 on:** June 26, 2018, 07:00:03 pm »

I have a broken 34401A with a bad VFD laying around, would be nice to test !

qu1ck · « **Reply #56 on:** June 26, 2018, 09:38:57 pm »

bitseeker
I considered a graph but decided against it (at least for now) because 1) 64 pixels vertical resolution makes a graph not that useful and 2) display does not support horizontal scrolling so I would have to refresh big poligon every time. I'm not sure if I have time budget between text refreshes for that.

HighVoltage
Are you asking for firmware? If you want to reproduce this experiment I can provide wiring diagram and a binary. Source is not ready for public yet.

bitseeker · « **Reply #57 on:** June 27, 2018, 01:49:08 am »

Quote from: qu1ck on June 26, 2018, 09:38:57 pm

bitseeker
I considered a graph but decided against it (at least for now) because 1) 64 pixels vertical resolution makes a graph not that useful and 2) display does not support horizontal scrolling so I would have to refresh big poligon every time. I'm not sure if I have time budget between text refreshes for that.

I was partly joking, but for future exploration, a higher resolution screen might make it feasible. The need for hardware scrolling is a good point. It's fun thinking about the possibilities.

qu1ck · « **Reply #58 on:** June 27, 2018, 02:58:35 am »

High resolution has drawbacks too, either big pixel density (single pixel line not visible from typical distance) or big size and definitely price. Also you will have to go back to lcd most likely so add low contrast to the list.

I even thought of doing the whole thing on esp8266 and stream data to any mobile device/pc. Then you can have any graphs you want. But that is also a lot of software to write and I'm in this business for the rosin smoke lol. When I publish the protocol maybe someone else will do it. Esp8266 has probably enough speed for it.
Although another reason I didnt start with esp is I didnt want a rf antenna inside the metal can that is 34401a generating lots of reflections and affecting measurements god knows how.

Sent from my moto g(6) using Tapatalk

TiN · « **Reply #59 on:** June 27, 2018, 04:39:52 am »

qu1ck
Awesome works, keep it up.
Extra thumbs-up for making (or planning) to make it open to community.
I'd love to have similar one for my Keithley 6485 and 2182A here, which use UART datalink to FP too.

Hate ugly single-line Keithley VFD.

bitseeker · « **Reply #60 on:** June 27, 2018, 05:32:50 am »

Quote from: qu1ck on June 27, 2018, 02:58:35 am

I even thought of doing the whole thing on esp8266 and stream data to any mobile device/pc. Then you can have any graphs you want. But that is also a lot of software to write and I'm in this business for the rosin smoke lol. When I publish the protocol maybe someone else will do it.

Yep, was just brainstorming, rather than intending for anyone in particular to implement. Thanks for making the project open.

qu1ck · « **Reply #61 on:** July 06, 2018, 11:05:50 am »

Had a productive couple of days on holidays.
Git log:
* b4a62e0 (HEAD -> master) Fix blink interrupt bug
* f16535b Hide bar in menus
* dbaedcc Implement blinking chars
* 016474b Overhaul decoder, separate event handler logic
* 9033e10 Improve init sequence
* 2e2d7ea Clean up display lib
* c055959 Wrap things in namespaces
* 531cf67 More main.cpp cleanup

I implemented one of the last main lacking features, blinking characters. The display is quite usable now. There are some niceties left like better fonts and correctly aligned glyphs but I'm really close now.
Time to start thinking of hardware. I think I'll just remove the filament voltage bias and use that winding of the transformer as power supply for my thingamabob. Haven't tried how the display and blue pill fits inside yet. Hopefully I won't have to do a custom board too, as much fun as that is.

bitseeker · « **Reply #62 on:** July 06, 2018, 06:01:09 pm »

Thanks for the update. Yeah, hopefully it all fits nicely inside. Keeping my fingers crossed.

qu1ck · « **Reply #63 on:** July 07, 2018, 08:04:20 am »

Wrote bmp file to binary convertor and now we have proper icon support. See debug image below with all annunciators lit (diode and continuity are icons).

Funny thing, MS paint is the only (free) program that still supports monochrome bmp that I could find. And it has a bug where you can't paint in white with pencil tool

HighVoltage · « **Reply #64 on:** July 07, 2018, 08:21:06 am »

Very nice and impressive work!

How does it show up, if you put the Agilent window in front of your display.
Is it still readable?
Or do you rather have to use a clear custom window?

qu1ck · « **Reply #65 on:** July 07, 2018, 09:14:03 am »

HighVoltage
I'm going to find that out tomorrow when I take the multimeter apart again to do the fitting of the display and mcu board. From what I remember when I disassembled front panel earlier that window is just light blue acrylic (or some kind of plastic) and it should just tint my display in light blue but that's it.

bitseeker · « **Reply #66 on:** July 07, 2018, 06:54:55 pm »

Quote from: qu1ck on July 07, 2018, 08:04:20 am

Wrote bmp file to binary convertor and now we have proper icon support. See debug image below with all annunciators lit (diode and continuity are icons).

Excellent work. I really like how this turned out. Yours is the first successful matrix screen (LCD or OLED) implementation I've seen.

Quote

Funny thing, MS paint is the only (free) program that still supports monochrome bmp that I could find. And it has a bug where you can't paint in white with pencil tool

You can make them with GIMP as well. In the current version, go to the Image menu, select Mode, then Indexed. In the Indexed Color Conversion dialog, select "Use black and white (1-bit) palette." When you're done, export the image in Windows BMP format (saving, on the other hand, uses GIMP's native format).

qu1ck · « **Reply #67 on:** July 08, 2018, 05:40:00 am »

bitseeker
Thanks for the tip, I found a plugin for paint.net can do it too so I'm using it now. GIMP's ux makes my skin crawl.

I took the multimeter apart and did a whole lot of measurements.
TLDR is I'll have to do a custom board.

All measurements in mm
Viewport dimensions (cutout in front panel plastic): 143.5x27
Useable width of the viewport (metal chassis takes away few mm on the left) ~137mm
OLED display board dimensions: 100.5x33.5
Blue Pill mcu board dimensions (without jtag header, board only): 53x23

In terms of height everything fits fine, the original display has a metal shroud that is 35mm, new display board will fit there easily.
Depth is tight but should be ok too. Old display has distance board to top of glass of 13.3mm but it sits in a little recess in the viewport. New display doesn't fit in that recess so I have to fit into 11.5mm of depth. And there is that fat DIP42 UPD7527 that takes 4-4.2mm of space under display. So there is ~7.3 left. New display is 6.5mm deep, including components on back side.
Problem is width. As you can see 53 + 100.5 > 137 by quite a bit. You can win 6-8mm by moving display to the right so that the board edge and part of display bezel edge is not in the viewport but it is still not enough.
If you overlap left part of display board with mcu board and chop off the jtag header part completely (may have to sacrifice LEDs too) then maaaybe it will fit. But that is too barbaric for my taste.

So next thing i'll focus on is designing custom board. It's a shame, many people are afraid of soldering 0.5mm pitch qfps so it will limit this mod's accessibility for a hobbyist. I just hope that the kind of people that have this type of instrument are advanced enough in the soldering department that it won't be much of a deterrent. With custom board I will be able to stick the USB out through a small cutout in the front window panel. That will make firmware updates so much easier.
And no, arduino pro mini while being smaller doesn't have the speed. 8bit AVRs suck these days, their only upside is availability in easily soldered packages.

On the bright side, the display is quite, well, bright

even behind the original tinted window. It doesnt even tint it blue, just decreases the contrast a bit.
Without the window both displays have approximately the same contrast and brightness.

HighVoltage · « **Reply #68 on:** July 08, 2018, 07:39:52 am »

It looks very nice readable behind the original window.
Very nice job!

bitseeker · « **Reply #69 on:** July 09, 2018, 05:13:29 am »

Quote from: qu1ck on July 08, 2018, 05:40:00 am

bitseeker
Thanks for the tip, I found a plugin for paint.net can do it too so I'm using it now. GIMP's ux makes my skin crawl.

Yep, always good to have options.

Quote

I took the multimeter apart and did a whole lot of measurements.
TLDR is I'll have to do a custom board.

I kind of figured that might happen. However, you can then get things just the way you want them.

Quote

So next thing i'll focus on is designing custom board. It's a shame, many people are afraid of soldering 0.5mm pitch qfps so it will limit this mod's accessibility for a hobbyist. I just hope that the kind of people that have this type of instrument are advanced enough in the soldering department that it won't be much of a deterrent.

Hopefully, they didn't blow their budget getting the 34401A and can get a hot air station, if they don't already have one.

Quote

On the bright side, the display is quite, well, bright even behind the original tinted window. It doesnt even tint it blue, just decreases the contrast a bit.
Without the window both displays have approximately the same contrast and brightness.

That's good news. I was afraid that the filter would be too dark. It looks fine.

Zucca · « **Reply #70 on:** July 09, 2018, 07:12:00 am »

qu1ck, impressive. Somebody should give you a Keithley 2xxx when you are done with the 34401a.

Congrats.

Quote from: qu1ck on July 08, 2018, 05:40:00 am

TLDR is I'll have to do a custom board.

Probably you will sell a truck of them. Please consider a group order.
Is it possible to squeeze in it a RS232-USB or Serial Bluetooth/WIFI Ethernet (for remote logging) adapter in it? I am thinking how to use the extra space in the front wisely. Also a bigger diplay with the opportunity to placing some fixed label on the side could be neat, with multiple 34401a on the bench knowing what is measuing what with display labels is nice to have. Don't know how to upgrade the labels, probably all my ideas are too complicated to realize.

Maybe creating a dedicated thread in the test&equipment is also a nice call, so other people could tip in.

bitseeker · « **Reply #71 on:** July 09, 2018, 05:42:15 pm »

Quote from: qu1ck on July 08, 2018, 05:40:00 am

With custom board I will be able to stick the USB out through a small cutout in the front window panel. That will make firmware updates so much easier.

Quote from: zucca on July 09, 2018, 07:12:00 am

Is it possible to squeeze in it a RS232-USB or Serial Bluetooth/WIFI Ethernet (for remote logging) adapter in it? I am thinking how to use the extra space in the front wisely.

It seems that these two USB ideas go well together conceptually. Having the port in the front only for updating firmware seemed unnecessary (could just have it inside), but if the port is available for logging, too, then that'd be great.

Quote from: zucca on July 09, 2018, 07:12:00 am

Also a bigger diplay with the opportunity to placing some fixed label on the side could be neat, with multiple 34401a on the bench knowing what is measuing what with display labels is nice to have. Don't know how to upgrade the labels, probably all my ideas are too complicated to realize.

qu1ck said that he's making this project open, so there may be lots of interesting things to come.

qu1ck · « **Reply #72 on:** July 09, 2018, 07:41:54 pm »

Quote from: zucca on July 09, 2018, 07:12:00 am

Probably you will sell a truck of them. Please consider a group order.

Doing logistics of group order and delivery is not worth it to me. Board designs as well as everything else will be open so anyone can do it.

Quote from: zucca on July 09, 2018, 07:12:00 am

Is it possible to squeeze in it a RS232-USB or Serial Bluetooth/WIFI Ethernet (for remote logging) adapter in it?

Yes, stm32f103 usb port works as a serial port. For now it is only used to upload firmware and monitor debug messages but it's entirely possible to send a properly formatted data out of it and/or send commands back. You won't be able to emulate button presses though, my board only listens on the data lines.

Quote from: zucca on July 09, 2018, 07:12:00 am

Also a bigger diplay with the opportunity to placing some fixed label on the side could be neat, with multiple 34401a on the bench knowing what is measuing what with display labels is nice to have. Don't know how to upgrade the labels, probably all my ideas are too complicated to realize.

Bigger display will likely not fit, they are a lot more expensive too. Labels are easy to do, I can display them instead of the bar graph below. I think I'll add that feature. You'll be able to set/update/unset label via usb serial command.

Quote from: bitseeker on July 09, 2018, 05:42:15 pm

Having the port in the front only for updating firmware seemed unnecessary (could just have it inside), but if the port is available for logging, too, then that'd be great.

Having port easily accessible is super useful for development. I upload firmware 10-20 times during each coding session. Having multimeter taken apart all the time would be PITA.
But yes, the port also streams display data.

floobydust · « **Reply #73 on:** July 09, 2018, 07:42:29 pm »

I reverse engineered the 34401-66502 front panel PCB mechanical a while ago, it was no fun. Many hours with calipers, lots of slots...

HP's mechanical engineering here has many innovations, actually very good engineering when you dig in.
The PCB sliding in and snapping into place (no fasteners) with a conductive rubber keypad, a complex difficult plastic mold to reduce costs- impressive work.

At the time I thought I had a failed uPD7527 and was designing a replacement front panel PCB that would still use the VFD but with a new MCU and VFD driver. This is for a simple Gen1 34401-66502 replacement. Not to be confused with Gen2 34401-66512 front panel PCB that uses 87C51 and SN75518's and requires different DMM firmware.
I have another 34401a to repair with the polka-dot problem, waiting for parts to arrive. If it is the NEC MCU then I will just finish the replica PCB.

bitseeker · « **Reply #74 on:** July 09, 2018, 11:38:56 pm »

It'd be nice to combine qu1ck's display with flooby's replica front panel PCB. However, handling of the buttons would still need to be added, right? I assume that's what's meant by "finish the replica PCB."

bitseeker · « **Reply #75 on:** July 09, 2018, 11:46:20 pm »

Quote from: qu1ck on July 09, 2018, 07:41:54 pm

Quote from: zucca on July 09, 2018, 07:12:00 am
Probably you will sell a truck of them. Please consider a group order.
Doing logistics of group order and delivery is not worth it to me. Board designs as well as everything else will be open so anyone can do it.

Yep. I might look into organizing a group buy for this. It may be OK in the form of kits (i.e., DIY soldering). Getting it completely manufactured might be too much of a project. We can revisit after qu1ck is done.

qu1ck · « **Reply #76 on:** July 10, 2018, 01:05:54 am »

Heh. I thought of completely replacing the front panel PCB too. It is doable but will need even more firmware development (I have button codes but I don't currently emit anything onto data lines). Also manufacturing that pcb will be quite costly.
As floobydust mentioned it has lots of cutouts and would need precision machining, as well as tight tolerance on thickness to fit snugly and gold plating for button pads and it's pretty big and... yeah it's gonna cost ya. Nowhere near the $2 for 10 bargain that I can get for tiny 2 layer mcu board.

bitseeker · « **Reply #77 on:** July 10, 2018, 01:23:34 am »

Yeah, it's another level for sure.

floobydust · « **Reply #78 on:** July 10, 2018, 06:29:14 am »

Quote from: bitseeker on July 09, 2018, 11:38:56 pm

... handling of the buttons would still need to be added, right? I assume that's what's meant by "finish the replica PCB."

At first I thought of making a small daughter board to replace only the NEC uPD7527 but not enough space.
Then I figured just replace the entire front panel PCB, keeping the VFD. New tubes are plentiful from China.
I started with the mechanical, including the keypad etc. Then the H/W and F/W design is how I usually go. Getting a PCB made to verify how it fits, it's on the list.

I don't want to compromise the instrument by having a noisy, high current MCU running off the +/-18VDC rails which run to the A/D converter. Designing for conducted EMI and keeping it quiet to keep life rosy at 6-1/2 digits is important.
I think an underclocked Bluepill would be OK, or Mega328PB- something with two SPI ports and under 12mA. The original uPD7527 is 3mA, and 12mA for 87C51.

To bring the multimeter up to date, adding wireless is tempting. WiFi needs a lot of TX current, so power would have to come off the 5VAC filament winding. ESP8266 is max. 170mA chirps but the second SPI port would have to be bit-banged I think. ESP32 seems like overkill? But only $5.

I haven't really nailed down what I'm doing.
This is the keypad drawing, one key needs vias moved but the slots and VFD and bracket crap I have also figured out.

I can try add qu1ck's OLED and see how that fits. The huge 5.5" OLED was too big.

qu1ck · « **Reply #79 on:** July 10, 2018, 07:17:29 am »

You have to bit bang SPI either way. In 34401a protocol FP notifies the master of readiness to receive next char or button press event by pulling MISO line low and waiting for the clock. I don't think that kind of shenanigans are normally supported in hardware SPI on most MCUs, but I may be wrong.

Thanks for the drawing, it will come handy.

qu1ck · « **Reply #80 on:** July 13, 2018, 09:56:43 am »

Did first pass on the board. I would appreciate feedback. I've done much more complex boards before but still, this is not my expertise.

Some notes: height, mounting holes and 16 pin header match the display board so that you solder it directly on top (maybe with a pin header as a strut, which you can cut off later). I noticed now that it should be 33.5mm high, not 35, that's an easy fix.
Data lines are short and nice, 5v data inputs are fed through 10k resistors to protect stm32 just in case. Those pins are supposed to be 5v tolerant.
UART header and boot state solder bridge are only there to make flashing bootloader easier. After that you will always use usb bootloader.
Power is supposed to be fed from unregulated U553 input on the dmm, that's the line that is feeding earth referenced 5v. I don't think that line is sensitive at all, correct me if I'm wrong. That power input will also go to display Vcc.
Voltage reg is placed on a big polygon, but I kinda eyeballed the power dissipation. Need to check the math on that.

Also ignore the pin headers on the render, they won't be there in end product.

HighVoltage · « **Reply #81 on:** July 13, 2018, 04:56:17 pm »

What PCB software are you using?

qu1ck · « **Reply #82 on:** July 13, 2018, 08:13:03 pm »

Kicad 5 rc3.

Sent from my moto g(6) using Tapatalk

qu1ck · « **Reply #83 on:** July 14, 2018, 08:36:06 am »

Added eeprom, cleaned up and annotated pcb, fixed height.

It's going to the fab! Even if I screwed something up, I'll be only out $10.

floobydust · « **Reply #84 on:** July 14, 2018, 10:21:20 pm »

I wasn't sure about the physical location, 12V power source etc.

The OLED modules I've looked at have a different pinout. Not sure what OLED part you are using, I'm thinking of the 3.12" offerings. The modules with on-board boost converter are 5V powered with 3.3V I/O to match the SSD1322, using around 150mA at 5V. I think 12V input will heat up the vreg too much.

10k series resistor on MISO is too high, consider R517 215R and R506 5k62 5V pullup on the main ASIC and CPU, I don't think you'll get a logic 0 there.

I use a series resistor between 5V outputs and 3.3V inputs, "5V tolerant" sometimes means the IC has diodes to +3.3V

qu1ck · « **Reply #85 on:** July 15, 2018, 12:53:14 am »

floobydust, thanks for reply. Display I'm using is this one, it has different pinout from one on your pic: https://www.buydisplay.com/download/manual/ER-OLEDM032-1_Series_Datasheet.pdf
It is powered the same way but I plan to rip out the boost converter from the display and feed 12v directly where boost output is to minimize switching noise. 3v3 from voltage reg will also go in on the standard pin to power ssd1322.
Re MISO resistor, what does it matter what the pullup is? All the pins on that 10k RN are configured as inputs. My board does not output any signals, only listens on what is going on the CPU->FP data lines. It's the front panel micro that will be fighting against the MISO pullup. (Or rather the comparator they use to shift voltage levels, but the point stands).

I calculated heat dissipation on voltage reg and assuming there is 0.5inch^2 of copper attached to it I can dissipate about 0.5 watt before it goes past ~60C. For 8-9 volt drop that's about 55-60mA. I am hoping that stm32 + ssd1322 - high voltage consumption of ssd1322 will fit into that. Some quick searching did not give any specific numbers for either of these chips, I guess it varies a lot depending on used peripherals and display update frequency.
As a backup I can always tap from regulated 5v of the DMM instead.

qu1ck · « **Reply #86 on:** July 17, 2018, 01:41:12 pm »

Poor chinese bastards have no weekends

I already got a tracking number yesterday.

While I'm still waiting for the boards I though I'll show Kicad bom generating script I wrote a year ago. Adapted it to Kicad 5 as a plugin now, here is result (it will be deleted after a day):
http://ibom-showcase.bitballoon.com/

It doesn't support arbitrary polygon shapes, rounded rectangle pads, other things, but it is still useful. I used it before on a much more complex board, highlighting similar components was very handy for hand soldering hundreds of smd components. Let me know what you think, if others like it too I might make an effort to support pcb format more fully and I'll open source it.

Zucca · « **Reply #87 on:** July 17, 2018, 02:54:21 pm »

Quote from: qu1ck on July 14, 2018, 08:36:06 am

It's going to the fab!

Sorry for asking, which one?

Kosmic · « **Reply #88 on:** July 17, 2018, 03:28:44 pm »

Quote from: qu1ck on July 17, 2018, 01:41:12 pm

While I'm still waiting for the boards I though I'll show Kicad bom generating script I wrote a year ago. Adapted it to Kicad 5 as a plugin now, here is result (it will be deleted after a day):
http://ibom-showcase.bitballoon.com/

Really cool, good job!

qu1ck · « **Reply #89 on:** July 17, 2018, 08:56:05 pm »

Quote from: zucca on July 17, 2018, 02:54:21 pm

Quote from: qu1ck on July 14, 2018, 08:36:06 am
It's going to the fab!

Sorry for asking, which one?

Allpcb
Their quality is good from my experience, although silkscreen is not highest resolution print. But nothing beats $10 prototype boards with express fabrication and free dhl shipping.

Sent from my moto g(6) using Tapatalk

bitseeker · « **Reply #90 on:** July 17, 2018, 09:01:20 pm »

Quote from: Kosmic on July 17, 2018, 03:28:44 pm

Quote from: qu1ck on July 17, 2018, 01:41:12 pm
While I'm still waiting for the boards I though I'll show Kicad bom generating script I wrote a year ago. Adapted it to Kicad 5 as a plugin now, here is result (it will be deleted after a day):
http://ibom-showcase.bitballoon.com/

Really cool, good job!

That is a very cool tool!

Zucca · « **Reply #91 on:** July 18, 2018, 07:15:43 am »

Quote from: bitseeker on July 17, 2018, 09:01:20 pm

Quote from: Kosmic on July 17, 2018, 03:28:44 pm
Really cool, good job!

That is a very cool tool!

Nice one, qu1ck is now in my buddies list.

qu1ck · « **Reply #92 on:** July 20, 2018, 07:08:04 am »

Well this is a hilarious fuckup (images clickable):

Do you see it?

How about now?

And yes, I double checked my gerber files, they are obviously correct

I'll try to scrape the solder mask off, maybe this batch is salvageable still.

How did they even manage to do this? Well, back to the fab with ya.

bitseeker · « **Reply #93 on:** July 20, 2018, 07:30:33 am »

Wow, not just one pad, but two of them. Maybe a bug in their software? Both cases were similar in that the trace to the pad continued straight through. However, there's a trace on the lower left that went through the pad to a via and that didn't get solder masked. Odd.

Zucca · « **Reply #94 on:** July 20, 2018, 07:39:42 am »

Quote from: qu1ck on July 20, 2018, 07:08:04 am

I'll try to scrape the solder mask off

Yes, it will be not pretty but it should work.

qu1ck · « **Reply #95 on:** July 20, 2018, 09:20:12 am »

Yeah, only ground plane pads got affected and only 2 of the 4.

Fret not, some elbow grease and good microscope to the rescue:

Also had some fun with recording video. I just might record the whole assembly process too.

https://youtu.be/ZoB_NMqq5YA

bitseeker · « **Reply #96 on:** July 21, 2018, 12:49:14 am »

Looks good, qu1ck. If you record the assembly, I'll watch.

qu1ck · « **Reply #97 on:** July 25, 2018, 12:03:40 pm »

I'm waiting on couple parts to arrive before I start the build. But in the meantime I published the Kicad BOM plugin I showed earlier.

Github

Better than earlier demo

Started a thread for it in KiCad section https://www.eevblog.com/forum/kicad/interactive-html-bom-plugin/

hillflyer · « **Reply #98 on:** July 27, 2018, 02:10:45 pm »

How about displaying the 1 or 2 extra digits that are available via GPIB or RS232?

Samogon · « **Reply #99 on:** July 27, 2018, 04:13:32 pm »

Quote from: hillflyer on July 27, 2018, 02:10:45 pm

How about displaying the 1 or 2 extra digits that are available via GPIB or RS232?

Since he is getting data given to front panel i think it is not possible.

qu1ck · « **Reply #100 on:** July 27, 2018, 07:44:43 pm »

Quote from: Samogon on July 27, 2018, 04:13:32 pm

Quote from: hillflyer on July 27, 2018, 02:10:45 pm
How about displaying the 1 or 2 extra digits that are available via GPIB or RS232?
Since he is getting data given to front panel i think it is not possible.

Correct. Also what's the point? I didn't know more digits are available on GPIB but they can't be meaningful digits, can they? At given sampling rate front panel already displays every digit of resolution the instrument has.

coromonadalix · « **Reply #101 on:** July 27, 2018, 08:29:16 pm »

Don't get too over complicated lolll

hillflyer · « **Reply #102 on:** July 28, 2018, 09:36:51 pm »

I agree with not getting too complicated.
I do think the extra digits provide some meaningful information though.
The graph shows my quiet 2.5V reference on the 10V range of the 34401a.

qu1ck · « **Reply #103 on:** July 28, 2018, 11:02:03 pm »

That's interesting, that looks like 8 digits on 10v range. How can you be sure that isn't just ADC noise?
Either way, I can't do anything about adding those digits, that information is not sent to front panel.

hillflyer · « **Reply #104 on:** July 29, 2018, 04:49:07 pm »

Yeah, no problem.

Re. ADC noise: In 6 1/2 digit slow mode, it looks like there is about 2uV p-p noise incl. the reference noise.
I use 5 paralled MAX6325 for lower noise.
I am sure you cannot rely on the long term accuracy of these extra digits, but sometimes it is helpful
to be able to squeeze a bit of extra info out of that measurement if needed...

qu1ck · « **Reply #105 on:** August 06, 2018, 11:36:46 am »

Long overdue update. Good news, I didn't screw up

Board works perfectly fine. Don't mind the botched wire on the last pic, it's an impatient man's diode.

HighVoltage · « **Reply #106 on:** August 06, 2018, 11:53:26 am »

Looking really good!

Zucca · « **Reply #107 on:** August 06, 2018, 12:10:13 pm »

Drool!

coromonadalix · « **Reply #108 on:** August 06, 2018, 09:14:44 pm »

drool +1

bitseeker · « **Reply #109 on:** August 07, 2018, 03:13:32 am »

Wow! As Dave would say, "It's like a bought one."

qu1ck · « **Reply #110 on:** August 07, 2018, 09:03:37 am »

Testing and implementing display rotation (almost) done:

By the way I have 11 spare boards. 5 from original batch (need a bit of precision scraping of solder mask) and 6 from re-fab. Allpcb fixed their shit, no questions asked. Also both times they sent 6 instead of ordered 5.

I'm going to keep 1 but I will probably send out the rest to interested parties for a symbolic payment that I have yet to think of. Frequent posters of this thread get first dibs.

Zucca · « **Reply #111 on:** August 07, 2018, 10:03:52 am »

vote qu1ck for president.

Looks awesome.

HighVoltage · « **Reply #112 on:** August 07, 2018, 10:15:08 am »

You did an amazing job with this.

coromonadalix · « **Reply #113 on:** August 07, 2018, 10:51:21 am »

is it me it seem very bright

would it be possible to dim it a little

nice job

Zucca · « **Reply #114 on:** August 07, 2018, 10:56:14 am »

With the acrylic glass on top it should be just perfect... I would not dim it.

qu1ck · « **Reply #115 on:** August 07, 2018, 04:43:00 pm »

At some point contrast will be configurable to reduce burn in. But it looks just right on max imo.

Detzi · « **Reply #116 on:** August 07, 2018, 07:06:42 pm »

thats a really nice mod. I like it, great work!

But will the OLED not have the tendency to burn in ?

free_electron · « **Reply #117 on:** August 07, 2018, 07:43:48 pm »

the display is much smaller than the real characters.
i would change the font to be more 7 segment like and scale down the mVDC text.
in essence : get rid of the bargraph : larger numericals , smaller alpha.

otherwise i like it.

coromonadalix · « **Reply #118 on:** August 07, 2018, 08:13:57 pm »

just sad not to find a perfect fit in size snif, but job well done, next a fluke 8846a lolll

bitseeker · « **Reply #119 on:** August 08, 2018, 02:36:09 am »

Looks awesome, qu1ck! And you went from concept to production quite quickly, too (very much in line with your username

). I'm definitely interested in a board.

Regarding user-specific preferences for display/font size, etc., qu1ck said he was making the project open source, so you'll be able to modify how it looks and could adapt it to other displays.

qu1ck · « **Reply #120 on:** August 14, 2018, 10:39:03 am »

Firmware and hardware is released.

I only have mechanical considerations left to resolve I think. I.e. how to mount the display.

qu1ck · « **Reply #121 on:** August 27, 2018, 01:39:12 am »

As luck would have it the metal shroud of the old screen fits new screen pretty much perfectly.
Even existing small flaps that used to hold the glass panel can now hold the display pcb eliminating need for any screws!

On the left the pcb slightly leans on the big fat MCU, in the middle shroud flaps are over it and at the far right end shroud flaps are under it. That creates small tension in pcb which is enough to hold it in place pretty well.

This is how it looks like in the panel:

And the satisfying conclusion to this endeavor:

One thing that is not ideal is the front glass being quite thick requires a usb cable with long connector end, your standard phone cables will not click in.

But while this is a conclusion for the project it's not the end for firmware. I still have not utilized the onboard eeprom, which I plan to store settings in.
Changing contrast on the fly, displaying a label in place of the bar graph, custom fonts and ability to display bigger digits at the expense of bar graph are on my radar.
You can follow the firmware github repo for future updates.

bitseeker · « **Reply #122 on:** August 27, 2018, 01:59:58 am »

Amazing how well all the new bits fit in place. Congrats on a very cool and successful display upgrade.

mlefe · « **Reply #123 on:** August 27, 2018, 02:10:42 am »

Excellent work!!

qu1ck · « **Reply #124 on:** August 27, 2018, 02:15:00 am »

Thanks

Now I have 10 boards I can send out and 1 mostly working VFD screen

Anyone who wants a board can pm me, we will exchange addresses and I will send you a board in exchange for a fridge magnet. I like fridge magnets

Doesn't have to be a big one, something that can be send with ordinary mail is fine. if it's connected to your local landmark that would be great, but anything will do.
I don't expect to receive a lot of requests, but in case I do priority will go to users who posted in this thread.

bitseeker · « **Reply #125 on:** August 27, 2018, 02:29:24 am »

That's a unique idea. Let me see what I have or could locate that would be neat to send to you.

coromonadalix · « **Reply #126 on:** August 27, 2018, 10:35:59 am »

Maybe send some email of your project at Xdevs for your / substitution replacement display

it could be an good resource

qu1ck · « **Reply #127 on:** August 28, 2018, 01:48:23 am »

xdevs submission process looks way too cumbersome. Uploading docs to ftp is so last century.

I did submit my project to hackaday tho. Maybe they will feature it.

coromonadalix · « **Reply #128 on:** August 30, 2018, 12:10:23 am »

Now on HackaDay

bitseeker · « **Reply #129 on:** August 30, 2018, 12:16:10 am »

Congrats, qu1ck!

https://hackaday.com/2018/08/29/faded-beauty-dmm-gets-an-oled-makeover/

Zucca · « **Reply #130 on:** August 30, 2018, 07:02:11 am »

Congrats, well done!

HighVoltage · « **Reply #131 on:** August 30, 2018, 08:16:45 am »

How nice to see it on hackaday.
Congratulations.

coromonadalix · « **Reply #132 on:** August 31, 2018, 06:11:32 pm »

Have you seen this display ? RS232 interface would it be possible to adapt / interface it

would the physical size fit

http://noritake-vfd.com/gu256x64d-7000bx.aspx

pdf
https://www.eevblog.com/forum/repair/fluke-8846a-repair-shenanigans/?action=dlattach;attach=511772

qu1ck · « **Reply #133 on:** August 31, 2018, 07:09:57 pm »

You can interface it (using parallel, rs232 is too slow) but it's too big. I think you can fit at most 135x35mm display without taking dremel to your dmm.
Also it costs half the dmm

justanothername · « **Reply #134 on:** December 30, 2018, 04:01:00 pm »

So.
I spent the day trying to get the display working, but I must give up for now, I'm completely stuck.
Installing the platformio IDE and the tools in windows was not easy, i must say this seems to be a linux-only project. I really would apreciate just a .hex file to upload with JFLASH but there is nothing on github.
So I don't really know if I did everything right, since there is a tool needed in Windows to get the driver working (Zadig) and there are many driver options to choose from. I was able to flash the bootloader onto the MCU by soldering SWO wires onto it. And I was able to find the correct settings in Zadig to upload it at least once. The status now is that it displays the bargraph, but nothing else (see attached picture).
I was not sure how to connect to the PCB to the display board of the 34401a, but at least clock and int seemed clear. I tried crossing out MISO and MOSI (DI and DO) but no reaction. The problem now is that i don't know if it just can't decode the display data or if it the MCU somehow crashes after the bargraph is drawn.
So:
What is the correct connection? Is there a hex or bin that works when i just flash it by SWO? how should I set the boot jumper (I can see by looking the picture that position F is soldered)? How can i assure that the program is working at least?
That was quite a frustrating journey until now

coromonadalix · « **Reply #135 on:** December 30, 2018, 04:58:30 pm »

Qu1ck told me the pinouts used are in parallel of the falt ribbon cable

here's the answers he gave me :

I took power from floating 5v, output of U553.
Your other option is to take it from input of that regulator, in that case you are less likely to feed any switching noise from oled screen (it has a built in boost converter) into multimeter, but I highly doubt that matters in any way. My measurements did not show any noticeable impact.
But if you take it from input you will be on the limits of lm1117 power dissipation with the polygon I have for it on the board. You can stick small piece of metal as heatsink on it or better yet rip out the boost converter from the screen and feed higher voltage into the panel directly. That will limit current consumption of the front panel converter (my board) and eliminate any switching noise. But I didn't bother, total current consumption of my board + oled screen is 60-70 mA. If you feed 5v into lm1117 it will be just fine. Just don't take it from +18v becase a) it's used in sensitive analog stuff and b) voltage drop for the regulator will be too high.

FPINT is not currently used

Send him an email if you need some help, in a month i'll order the lcd to try this project for myself too, i have a nice 34401 to play with.

But he told me his project is not tested with the newest pcb version having the 75518 vfd driver ... i have 2x 34401a with this pcb

justanothername · « **Reply #136 on:** December 30, 2018, 06:05:05 pm »

Quote from: coromonadalix on December 30, 2018, 04:58:30 pm

Qu1ck told me the pinouts used are in parallel of the falt ribbon cable

For testing purposes i was powering the PCB with a laboratory power supply. Powering was ok, I could even see the resonator working at 8MHz.
I checked all the solder joints end even probed with the scope on the MCU pins, the signals were present. I managed to use the jlink with SWD in platformio and flashed the program without bootloader. Aside from the bargraph beeing drawn, no data was displayed, just as before. The last thing before I reassembled the unit was that I tried every possible permutation of the cable connection.
I used these contacts at the flat ribbon connector:
GND (1)
IGFPDI (4) - tried at MISO and MOSI and INT
IGFPSCK (6) - connected always to SCK
IGFPDO (2) - tried at MISO and MOSI and INT
IGFPINT(10) - tried at MISO and MOSI and INT
As I can see in the service manual, there is also a version of the display board with an 80C51 microcontroller. Idk if I can determine the used components without desoldering the VFD, but maybe there are different protocols used in later versions. For now I will leave the VFD soldered in, as it is fully functional, but a little dim.
For the powering situation, another way is to use -13V as VCC and -18V as VDD (gnd). Then use the outputs of the comparator U607 as inputs to the OLED-board. Both (-18V and -13V) should then be fed through some ferrites.
Since the OLED panel got boost converters on it, it may be necessary to add some additional shielding. Maybe i will try to improve the EMI radiations of the converter. The usual methods would be to increase output capacitances, to add shunt capacitors from in to out, or to change in/out capacitors to lower-ESR types.
But first things first, the next goal for me is to actually see something on the display.

coromonadalix · « **Reply #137 on:** December 30, 2018, 06:46:32 pm »

For the front panel, if you look on the back pcb and see two dip rows of soldered pins + the ribbons and vfd pins ... youll know that you have the nec unobtanium display .....

The newest version has only the vfd rows pins and the ribbon pins and pn: 66512 sticker on it, my other pcb vfd doesn't have the sticker ??

sn : us3610xxxx
sn: 3146-A75xxxx

Both have the firmware : 10-05-02 ??
Version: 06-04-01 and lower = old pcb
Version: 06-04-02 and higher = new pcb

Once again, qu1ck wrote not tested with the newest pcb version

VCC (2) floating 5 volts output of U553, i would not dare to poke on the +/- 18v lines they are for the measurements sections ... it could affect the meter ?
GND (1)
IGFPDI (4) - should be MOSI
IGFPSCK (6) - should be SCK
IGFPDO (2) - should be MISO
IGFPINT(10) - should be INT but not used

We see clairly (picture attached) he used 5 pins on his pcb, not the 6th (int)

coromonadalix · « **Reply #138 on:** December 30, 2018, 07:11:12 pm »

Oh i think we need the adafruit gfx librairies to compile it ?? The only thing i have on hand is the stm32 blue pills boards, they are arduino IDE compatibles ...

I have received from Qu1ck one of his pcb, but don't have time to assemble it right now, too many projects on hand, and i go on vacation january 10

There is an firmware.bin (attached) who is already compiled .. try this one

The other firmware_debug.bin (attached) spit out on serial some data ??

He wrote : the eeprom is not needed for now ??

justanothername · « **Reply #139 on:** December 30, 2018, 07:29:59 pm »

Quote from: coromonadalix on December 30, 2018, 06:46:32 pm

The newest version has only the vfd rows pins and the ribbon pins and pn: 66512 sticker on it

This seems like my version (attached pic).
I can confirm that I tried the configuration you described and it does not work. Do you know if the panels are interchangeable across versions? If not, then it is obvious that there are protocol differences.
For the firmware: I use the STM32F103CB with double flash size, so I recompiled the project for this controller. However, it should be no problem to flash a firmware compiled for C8 straight onto the CB.
As for the adafruit gfx libraries, you can load them with Platformio within VSIDE, but you need to manually delete SPITFT as stated in his howto.md.
here is the modification to platformio.ini for my board:

Code: [Select]

[env:release]
platform = ststm32
framework = arduino
board = genericSTM32F103CB
board_build.variant = custom
debug_tool = jlink
upload_protocol = jlink

firmware attached.

coromonadalix · « **Reply #140 on:** December 30, 2018, 07:47:19 pm »

the pcb are not interchangeable if you dont downgrade the firmware version prior to thoses i've wrote, come from a Keysight service note ...

qu1ck · « **Reply #141 on:** December 30, 2018, 09:37:45 pm »

justanothername
Congrats, you appear to be the first person aside me who built this even though I already sent out a few boards over the last months.

coromonadalix already gave you most of the information and everything they said is accurate. You have already found a way to compile and flash the firmware but just for posterity, prebuilt binaries are available on github, the link is just not intuitive to find for people unfamiliar with github interface:
https://github.com/openscopeproject/HP34401a-OLED-FW/releases

Your display initializes with bargraph, which means firmware works fine. STM32F103CB and STM32F103C8 are exactly the same, even though c8 is supposed to have half the flash, in practice they work fine and can be flashed with more than 64k binaries. There are no guarantees, of course, but neither I nor many other blue pill owners ever saw a c8 chip with less than 128k actual flash.
You definitely have new front panel, which I never tested because I don't have it. Lets try to make this work together and if needed I can make adjustments to firmware to make it compatible with new meters.

First flash the debug firmware (to compile it just add #define DEBUG in config.h or compile with debug target with 'platformio run -t debug'). That firmware prints out lots of information into usb serial so just post here the info that it prints out when meter is just turned on and idling on voltage range. There should be steady stream of updates to front panel.

Second thing you can do is grab a 5-10 second capture of clock and data lines with logic analyzer if you have one (again with meter idling on voltage range).

justanothername · « **Reply #142 on:** December 30, 2018, 09:51:51 pm »

Quote from: qu1ck on December 30, 2018, 09:37:45 pm

You definitely have new front panel, which I never tested because I don't have it. Lets try to make this work together and if needed I can make adjustments to firmware to make it compatible with new meters.

Wonderful! I'll get back to you later next week since I'm off for new years eve and propably have to get sober first.
PS: I have 9 PCBs left that I don't need. If anyone needs one, this is the deal: you send me a PM, I send you my adress, you send me a postcard, I'll send you a PCB back in a letter.

coromonadalix · « **Reply #143 on:** December 30, 2018, 10:32:43 pm »

@Qu1ck could the code be ported to the arduino ide's ??

I do know the blue pill must have the right boot loader ?? could it be viable or doable

qu1ck · « **Reply #144 on:** December 30, 2018, 10:43:51 pm »

Quote from: coromonadalix on December 30, 2018, 10:32:43 pm

@Qu1ck could the code be ported to the arduino ide's ??

Yes, it should be doable since arduino IDE for bluepill uses same framework as I do. But frankly I have no interest to spend time on this, you'll have to figure it out.
My advice: ditch the arduino IDE like the glorified trash notepad with a compile button that it is. Any of the platformio IDEs are miles ahead and completely superseed arduino IDE. I use Atom based one because it came out first but VSCode is even better.

justanothername · « **Reply #145 on:** July 13, 2019, 03:26:56 pm »

After a long time a quick update.
I now got myself one of these cheap replacement VFDs from aliexpress. If someone needs the oled display i built, please send me a private message, maybe we can figure something out.

qu1ck · « **Reply #146 on:** July 14, 2019, 11:25:26 am »

Just wanted to note, I'm still open to help you or anyone else with newer meter and some free time to resolve incompatibility with current firmware. Since I only have an older meter I can't do it myself. I would like to see logic analyzer dumps of SPI bus to start.

justanothername · « **Reply #147 on:** July 15, 2019, 03:14:18 pm »

Quote from: qu1ck on July 14, 2019, 11:25:26 am

Just wanted to note, I'm still open to help you or anyone

Thank you for the offer! The thing is: I got paranoid. I've been watching how the voltage reading of the meter was changing when the case was unscrewed. Then I thought about the extra two clocked devices (cpu @ 8mhz and oled @ i dont know) I was about to put into the housing.
I know it is bullshit and will not affect the precision, but I did shit my pants and went with the replacement vfd.
I'm very sorry.

coromonadalix · « **Reply #148 on:** July 15, 2019, 08:23:13 pm »

I do have recent hardware front pcb's in my two 34401a meters, but i dont have the logic analyser thing ....

never used such tools

qu1ck · « **Reply #149 on:** July 16, 2019, 02:08:21 am »

Get yourself cheapo analyzer, any hobbyist should have one in their tool kit.
https://www.ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer-24M-8-Channel-FPGA-debugging-tool-With-buffer/173828458153?hash=item2878fbc6a9:g:E6kAAOSw56Fc0-yt

It's supported by open source software sigrok/pulseview: https://sigrok.org/wiki/Downloads

iMo · « **Reply #150 on:** August 13, 2019, 09:56:21 pm »

Any idea what is the filament current of the original display?
Thanks.

coromonadalix · « **Reply #151 on:** August 13, 2019, 10:06:07 pm »

10 ohms of impedance / resistance

iMo · « **Reply #152 on:** August 13, 2019, 10:25:59 pm »

Ok, 10ohm, and the voltage is 6V (when looking into the SM p.9-7) therefore 600mA AC, imho.

coromonadalix · « **Reply #153 on:** August 13, 2019, 10:29:12 pm »

6v in 10 ohms is 600ma not 60 ma

iMo · « **Reply #154 on:** August 13, 2019, 10:36:19 pm »

That is a long back I saw something like 600mA

A pretty large current, my display is normally off (I use BT), so I think I will switch the filament off as well.. Another project..

coromonadalix · « **Reply #155 on:** August 13, 2019, 10:57:17 pm »

you can turn the display off thru some commands, you can find the user manual easily

page 132
http://ecee.colorado.edu/~mathys/ecen1400/pdf/references/HP34401A_BenchtopMultimeter.pdf

DISPlay {OFF|ON}
Turn the front-panel display off or on.
[Stored in volatile memory]

http://cna.mamk.fi/Public/Slabra/Agilent/Multimetro_Digital_34401A_Quick_Reference_Guide.pdf

qu1ck · « **Reply #156 on:** August 13, 2019, 11:02:10 pm »

That will not cut filament power, it is not digitally controlled.

coromonadalix · « **Reply #157 on:** August 13, 2019, 11:15:41 pm »

yep you're right quick

@imo do you want to save the remaining life of the vfd ??

iMo · « **Reply #158 on:** August 13, 2019, 11:21:19 pm »

Sure, the filament is permanently on. The command (via remote or from the keypad) switches off all the segments (such it deloads the 2x18V anode voltage) only.

As a first step I want to decrease the power consumption by 4Watts

qu1ck · « **Reply #159 on:** August 13, 2019, 11:36:10 pm »

If I recall correctly you can just pull 2 brown wires from the transformer that provide filament voltage from the power connector block that goes into main board. Isolate the pulled contacts and that's it.

Are you using some sort of GPIB to bluetooth converter?

iMo · « **Reply #160 on:** August 13, 2019, 11:43:45 pm »

I've been using rs232 to HC-05. Powered from the meter.

coromonadalix · « **Reply #161 on:** August 14, 2019, 12:00:23 am »

You could use an i/o line to switch of your vfd

You have pio2 thru 11 to play with ...

https://www.rhydolabz.com/documents/HC-05_datasheet.pdf

the command at page 11 section 17 should give you what you need

https://www.rhydolabz.com/documents/HC-05%20AT%20Commamd.pdf

just add you on / off circuit on pio line Ie : an small npn transistor with an small 5v relay ??

iMo · « **Reply #162 on:** August 14, 2019, 12:12:38 am »

I plan to use an MCU put inside the meter for such tasks..
The HC-05 will stay outside the box.

PS: the toggling with PIO pins works in AT mode only, afaik.
I've been using it as a dumb serial device passing bytes at 9k6 8N2 to/from the meter.

coromonadalix · « **Reply #163 on:** August 14, 2019, 12:58:56 am »

The 34401 can constantly output " talk only " if you set it to adress 31 and select gpib or rs232 output ??

From Keysight

In the "talk only" mode, the Agilent 34401A automatically sends readings directly to the GP-IB or RS-232 port. To enable the "talk only" mode, first set the HP-IB address to "31" using the front-panel I/O Menu. Then, select either the GP-IB or RS-232 interface (also in the I/O Menu)

iMo · « **Reply #164 on:** August 14, 2019, 07:27:53 am »

Yes it can do via rs232 with the 31 address. It sends out strings (scientific floating point, like "+9.99995790E+00") with results.
For example you may read the rs232 strings with an external MCU and display them on any display you wish then..

PS: the filament changes its resistance when ON, imho. So the current will be smaller after the filament heats up..

hakko · « **Reply #165 on:** September 08, 2019, 02:07:55 pm »

HI! I scored on 34401A (agilent dated december 2006) it have a dead front panel vfd. It does not show any digit $:-\$ . The front panel have a EE80C51BH 34401-88813 REV 2.0 and HV518PJ vfd driver. The meter respond for key press.
Investigating the problem I had decoded the the data from the main board cpu to front panel with a logic analizer the data will be attached here. I also decoded the serial bus from 80C51 ---> HV518 and it have clock and data activity also latch pulse signal and strobe are always at 0 state. I think the mcu is fine but it have a dead vfd driver. The board have no shorts or huge heat elements (checked with thermal camera).
I removed the vfd driver and applied +18V (with current limit resistor) on plate and anode segments for a short time and the vfd segments light up so the vfd display it's not faulty

Anyone with this board rev 66522 had this problem before? I ordered HV518 from utsource but I don't know if it's good quality

coromonadalix · « **Reply #166 on:** September 08, 2019, 02:45:22 pm »

the hv518 can be ordered here

https://www.digikey.com/number/en/microchip-technology/150/HV518/114088

hakko · « **Reply #167 on:** September 08, 2019, 02:56:37 pm »

But the shipment is 40$ for a 5$ part

coromonadalix · « **Reply #168 on:** September 08, 2019, 03:13:11 pm »

Damn in my location, its nothing

But for Brazil its expensive, just checked

An complete 34401a pn 34401-66522 board+vfd included is around 200$ usd from Keysight, and they dont have tons of them left ...

And you cant swap them with an older version of the pcb, the meter FW wont allow it.

service note : 34401A-06

My curiosity would be : retrograde the firmware and try the older display pcb with the unobtanium drivers ??

hakko · « **Reply #169 on:** September 08, 2019, 03:35:12 pm »

Quote from: coromonadalix on September 08, 2019, 03:13:11 pm

Damn in my location, its nothing

But for Brazil its expensive, just checked

An complete 34401a pn 34401-66522 board+vfd included is around 200$ usd from Keysight, and they dont have tons of them left ...

And you cant swap them with an older version of the pcb, the meter FW wont allow it.

service note : 34401A-06

My curiosity would be : retrograde the firmware and try the older display pcb with the unobtanium drivers ??

It might work with old firmware but i don't know if the meter will work fine since newer main boards have also hw changes from the old ones specially in analog section I don't know if asics are also changed too.
HV518 is also used by arduino guys I think china ones will work since it's quite usual ic.

qu1ck · « **Reply #170 on:** September 08, 2019, 10:15:10 pm »

hakko
Thanks for interesting data. I looked at SPI data dump you posted and the control frame headers on new panels differ from the old, no wonder my firmware doesn't work. But I kinda expected that.

For example first thing immediately obvious is that text control frames start with 0xff 0x2d instead of 0x00 0x7f and annunciator update starts with 0xff 0x00 instead of 0x7f 0x00.
Also there seem to be random 0x00 frames from cpu to panel sometimes (button state query?).

If you have time could you compile a table of control frames like found here? https://github.com/openscopeproject/HP34401a-OLED-FW/blob/master/protocol.md
That would help update firmware for these new panels.

qu1ck · « **Reply #171 on:** September 13, 2019, 02:38:23 am »

Thanks to coromonadalix who stepped up to help with capturing SPI data on a newer model 34401a meter I was able to figure out the differences in the protocol, which turned out to be minimal.
Here is new firmware that should be compatible with both old and new meters. firmware_debug.bin will spit out received decoded data onto usb serial line. If anyone can validate it I will publish new firmware and the fix to github.

coromonadalix · « **Reply #172 on:** September 14, 2019, 05:32:45 pm »

had tons or problems to make a blue pill work, boot loader problems i did not understood i'm a total nooob for this

He sent me an firmware.bin file who replace the boot loader, and have the debug option, thus always needing an st-link to work.

Heres the results on a serial monitor (attached photo) , i dont have an oled display, never received it.

my comments
-----------------------------------------------------------------------------------------------------------------------
Inverted the miso mosi line going to the blue pill (if im not mistaken)
pb13 is the clk
pb14 is the 34401a mosi line / blue pill miso
pb15 is the 34401a miso line / blue pill mosi
ground wire

Arduino IDE board enumeration is :

BN: Maple Mini
VID: 0x1EAF
PID: 0x0004
SN: Upload any sketch to obtain it

Select com9 ; it says Maple Mini

I start the Arduino serial monitor and voila is see the data coming out ... woh hoooooooo

Q: What are the 2 lines of Annunciators meanings ?
they have 0000 0001 etc ...

----------------------------------------------------------------------------------------
Going right to left in the menus

Dcv - Acv - 2w / 4w ohms - freq - period - DCI - ACI all went fine, annunciators follow fine, played with the range arrow more digits less digits all ok

-----------------------------------------------------------------------------------------------------------------------

problems

Continuity spits data very fast and crashes
Diode test spits data very fast and crashes the pill red light flashes ?

The rs232 monitoring seems to crash the communications ... not enough buffers ?? or slow down theses tests ??

Have to unplug power or a long reset and restart rs323 monitoring

If i do a long reset the red led flashing is gone, restart monitoring, all is fine, if i'm outside continuity or diode tests.

Goood job you have done thks for your patience and many emails exchanged.

coromonadalix · « **Reply #173 on:** September 14, 2019, 05:44:00 pm »

Edit with continuity open data is going very fast

rs232 monitor Termite hold longer before it crashes too ??

Termite wont reopen the connection even if the pill is resetted

Arduino monitor does

after the pill was resetted

wictor · « **Reply #174 on:** September 14, 2019, 07:44:58 pm »

It would help, if serial printing had lower priority, since it is disturbing spi decoding during debug.

qu1ck · « **Reply #175 on:** September 14, 2019, 08:51:36 pm »

I’m glad you got it working. I will publish the fix on github shortly, including the "no bootloader needed" firmware and better instructions.

To answer some of your questions:

Annunciator line with 4 digits is hexadecimal representation of 2 bytes where each bit corresponds to one of the glyphs on the display. For example 4th bit is for "Man" and 1st bit is for "*". So you see it changing between 0008 and 0009 meaning that "Man" is lit and "*" is flashing.
More is explained here https://github.com/openscopeproject/HP34401a-OLED-FW/blob/master/protocol.md

Continuity/diode mode spitting data out so fast that it crashes the firmware: as wictor guessed it's because of serial printing interfering with spi decoding. When serial buffers fill up because data is coming too fast the main firmware loop is blocked. You see the led on the bluepill flash for the same reason: this means main loop can not catch up to incoming data. This doesn't happen on release firmware so this is not an issue. And you should never use the meter while it's connected to your pc since your frontend will not be floating potential anymore.

coromonadalix · « **Reply #176 on:** September 15, 2019, 01:00:41 am »

Yeah i was lucky, nothing bad happened, i made sur not to connect the probes on anything, even my cheap saleae logic analyser clone "cypress fx2" was loading the data lines if the board was not suplied at the same time the 34401a dmm was powered on

Time to reorder another oled ?? i hope this time i get it loll if you have your old board with the mask pcb problem to scrape, i would take it

You wrote to me your oled display project would be compatible with the old and newests front panels, right ?

thks @Quick1 for your project and help

qu1ck · « **Reply #177 on:** September 15, 2019, 02:17:53 am »

New binaries are up on github
https://github.com/openscopeproject/HP34401a-OLED-FW/releases

I will update howto.md soon.

coromonadalix yeah I still have some boards left from first batch, I'll send you one.

New firmware is compatible with both old and new meters, correct.

hakko · « **Reply #178 on:** September 15, 2019, 06:56:40 pm »

Thanks @qu1ck for the job in protocol decoding... I also was able to do a dirty display for my meter (new panel version) using my implementation. I was tired of stm32 so i used a psoc 4 board that i have around. I used 2 spi ports as slave to get the data from the meter and a 16x2 crap lcd

qu1ck · « **Reply #179 on:** September 16, 2019, 12:19:05 am »

Yeah, that doesn't look half bad. You will have a hard time with annunciators though

coromonadalix · « **Reply #180 on:** September 16, 2019, 12:19:19 am »

better than nothing eh loll hush hush go find an oled display loll

For the unused second line he could write the function directly : cont, diode in place of the icons ?

hakko · « **Reply #181 on:** September 16, 2019, 06:34:13 pm »

This setup was just to test the meter main board functions before full restore since i don't have gpib cable. It pass on self tests and on real test it's also fine

bitseeker · « **Reply #182 on:** September 17, 2019, 01:54:22 am »

Nice test. If the display controller supports custom characters, that could make for some nice annunciators (if it was for longer-term use).

6151kokodef · « **Reply #183 on:** October 22, 2021, 02:22:54 pm »

I just bought one from eBay with serial number 3146A57XXX and it has the unobtainium NEC driver chip. It has dots after the characters. I replaced the VFD with one from ebay (Samsung SSVD branded) and it was like new - so glad it's not the chip.

It's an absolute pain to desolder the VFD with a solder sucker, so I put in turned pin sockets to make future troubleshooting and replacement easier.

HighVoltage · « **Reply #184 on:** October 22, 2021, 02:37:54 pm »

Quote from: 6151kokodef on October 22, 2021, 02:22:54 pm

I just bought one from eBay with serial number 3146A57XXX and it has the unobtainium NEC driver chip. It has dots after the characters. I replaced the VFD with one from ebay (Samsung SSVD branded) and it was like new - so glad it's not the chip.

It's an absolute pain to desolder the VFD with a solder sucker, so I put in turned pin sockets to make future troubleshooting and replacement easier.

You also got lucky that the ebay VFD is working correctly. Not all of them do that.
Congratulations on a successful repair.

floobydust · « **Reply #185 on:** October 22, 2021, 07:13:40 pm »

I have one 34401a, new VFD fixed the polka dots problem - only for a while, when the DMM is hot they faintly appear. It is intermittent now.
The dots are a combination problem of aged VFD having low transconductance, needing high drive voltage for blanking, as well as the NEC VFD driver PMOS aging getting old and lazy.

dreamcat4 · « **Reply #186 on:** January 18, 2022, 08:16:50 pm »

got here the same problem, dots between the characters. and am going to leave it like this for the time being while considering options. you see maybe the oled would be lasting for a longer time than a new vfd, given the way the driver is already leaking and degraded as explained above here ^^. if it really cannot be replaced?

just am still a bit unsure. for example wanted to know if by installing the oled it might affects negatively the precision of measurements. but maybe there was already some testing with that in mind? and can see existing results for that? look up somewhere?

floobydust · « **Reply #187 on:** January 18, 2022, 09:26:43 pm »

The polka dot problem is caused mainly by both- an aging NEC MCU and VFD.
If you replace or rejuvenate the VFD display, it can work for a while longer. But I have one 34401a that polka dots sometimes show up as it runs warmed up.
So I started working on a replacement front panel board, to keep the stock VFD and just use a VFD driver+MCU compatible with the old main board firmware.

I forgot Qu1ck's schematic but plenty of power available from the unused filament winding on the tranny. Adding noise or load to +/-17.4V rails would affect the analog sections of the multimeter, I would not run the OLED power from that.

dreamcat4 · « **Reply #188 on:** January 18, 2022, 09:50:53 pm »

thanks for these insights. so then i shall see what comes of this...

BTW checking the schematic on github here....

https://raw.githubusercontent.com/openscopeproject/HP34401a-OLED-HW/master/schematic.png

it seems qu1ck gets the power in from a +12v J5 marked there as DISPLAYPWR ?

not sure where that is supposed to hook up to. but yes that was my main concern with the oled mod.

in the meantime will also be patiently waiting to see if you can eventually replace the vfd driver in yours flooby. not in any particular hurry

floobydust · « **Reply #189 on:** January 18, 2022, 10:01:06 pm »

3.12" OLED need 12-15VDC at 25-50mA typ, depending on how much is lit up. About 2/3W.
If this is generated by an on-board boost-converter, it will draw a lot from a 3.3V rail, up to 250mA.
So how this is powered is important not to pollute or overload the 34401a power supply.

qu1ck · « **Reply #190 on:** January 19, 2022, 11:10:45 pm »

@dreamcat4

Quote

for example wanted to know if by installing the oled it might affects negatively the precision of measurements. but maybe there was already some testing with that in mind?

I don't have any precision standards to verify this, my 34401a is literally the most precise thing on my bench. But I did measure a AD587 based reference before and after the mod and the difference was well within temp drift of the source. Take that for what it's worth.

Quote

it seems qu1ck gets the power in from a +12v J5 marked there as DISPLAYPWR ?

not sure where that is supposed to hook up to. but yes that was my main concern with the oled mod.

On the display that I used there is a boost converter to 12v. I provisioned DISPLAYPWR hookup to use it as power source there and desolder/cut off the onboard converter on the display. I ended up not doing that because I couldn't measure any noise coupling into meters power lines. But the option is there.

@floobydust

Quote

3.12" OLED need 12-15VDC at 25-50mA typ, depending on how much is lit up. About 2/3W.
If this is generated by an on-board boost-converter, it will draw a lot from a 3.3V rail, up to 250mA.

Correct, 250mA is a very high figure though. In this application the display is only showing some text and small icons, at most 10-20% is lit up. My measurements showed <100mA load on the 3v3 line. That's including the stm32 microcontroller.

dreamcat4 · « **Reply #191 on:** January 19, 2022, 11:41:37 pm »

those details are a great help and i appreciate the reply qu1ck. it would seem i am in a pretty similar situation over here. as it happens got some voltage refs from digikey recently. a few different ones but nothing ultra precision. and also a variety of common jellybean regulators. after watching dave's recent video on this topic, i stocked up

your solution looks pretty reasonable so please let me say thank you for your hard work there

floobydust · « **Reply #192 on:** January 19, 2022, 11:59:49 pm »

I took the 250mA value from example Blue 3.2" 256x64 OLED datasheet it's 3.3V boosted to 12V and 100% lit for 250mA. You can't pull that much off the +17.4V rail so I wasn't' clear where power is coming from, on the in-guard side.

RikV · « **Reply #193 on:** August 02, 2022, 06:02:10 pm »

Thanks for this great job! This will certainly be useful one day when I find a 34401A for a reasonable price....

cellularmitosis · « **Reply #194 on:** August 07, 2022, 12:39:50 pm »

Quote from: imo on August 14, 2019, 07:27:53 am

Yes it can do via rs232 with the 31 address. It sends out strings (scientific floating point, like "+9.99995790E+00") with results.
For example you may read the rs232 strings with an external MCU and display them on any display you wish then..

Like this

https://www.eevblog.com/forum/testgear/external-display-for-agilent-34401a-(or-any-dmm-with-rs232-output-stream)/msg4344103/#msg4344103

iMo · « **Reply #195 on:** October 14, 2023, 12:32:32 pm »

I've been still thinking how to switch off the filament (my display is always off, but the filament is always on), I will do it with a simple switch placed somewhere on the rear, perhaps..

Btw. - this is what I did in past to deload my PC and save energy - there is the rear db9 serial connector, it has got 2 "free" pins (see the service manual).

I've been using one of the free pin as a 5V source (off the 5V outguard regulator placed nearby, via a 4R7 and 100nF to gnd) for the powering the external mcu.

The second free pin has been used as the output of the internal LM35 temperature sensor (powered off the 5V outguard vreg).

The meter's rs232 to cmos 3V3 level is simply done via a transistor (the bluepill reads the incoming data only).

As I wrote in past here there is the BT HC-05 sending data (115k2) off the bluepill to any external device (a cheapo smartphone with serial terminal in my case) logging the data coming off the bluepill (and I make 2x 16bit temperature measurements, temperature/gain compensation, averaging/smoothing of any kind, stddev, all in float64, incl. time/date capture from DS3231 in that bluepill, sending all the results upon each new sample as a .csv record).
Thus the total power consumption with long measurements is minimal (except the filament)

mmx01 · « **Reply #196 on:** February 27, 2024, 02:46:02 pm »

Hi,

Maybe this is a bit necro-posting but I am trying to adapt this solution to another instrument and another MCU. I am working on a damaged E3632a which appears to share a lot of HW/design with 34401a, it did not survive shipping and complete front panel is in pieces. VFD did not survive and other parts suffered as well... so trying to see what I could save and cannot verify what is really operational control wise. There is some life but faar from ideal.

Changes for me are using ESP32 instead of STM32 and after adapting the platform, I get a lot of errors with decoding. ESP32 runs at 240Mhz/40Mhz crystal so speed should not be an issue. Using external interrupt to capture following 8 bits per original routine. For now I don't output to LCD/Oled and modified the SW (interrupt routine) to ESP32. I read all bytes to a char buffer dumping them to serial only once every 500 EOF messages.

So there shouldn't be loop/delay issues while collecting 500 samples since I am not triggering serial output more than once every 500 messages. Also I set baud to 1Mbit on both ESP32 and the terminal.

Code: [Select]


void IRAM_ATTR sckInterrupt() {
  // mid byte power on detection
  now_us = micros();
  if (byte_len != 0 && (now_us > (last_us + 1500))) { //MAX_SCK_DELAY
    byte_len = 0;
  }
  last_us = now_us;
  output_acc = (output_acc << 1) + ((GPIO.in >> 23) & 1);
  input_acc = (input_acc << 1) + ((GPIO.in >> 18) & 1);
  
  byte_len++;
  if (byte_len == 8) {
    if (byte_ready) {
      byte_not_read = true;
    }
    input_byte = input_acc;
    output_byte = output_acc;
    byte_len = 0;
    byte_ready = true;
  }
}

void startSniffing() {
  attachInterrupt(digitalPinToInterrupt(19), &sckInterrupt, RISING);
}

inline void endFrame() {
  buf_len = 0;
  frame_state = UNKNOWN;
  mi++;
  if(mi == 500) {
    for(int z=0; z<mi; z++) {
      for(int x=0; x<15; x++)
       Serial.print(mb[z][x], HEX);
      Serial.println(".");
    }
  mi = 0;
  }
}

By default it says " OUTPUT OFF " for a message type decode but we can clearly see bits missing/errors in some of the messages. I am a bit lost as to why would this be other than perhaps HW fault.

14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F555450555C204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 04F5554505554204F464620000.
14:56:20.852 -> 204F7554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505574204F464620000.
14:56:20.852 -> 204F555450555404F464620000.
14:56:20.852 -> 204F5554505550204F464620000.
14:56:20.852 -> 204F555C505554204F464620000.
14:56:20.852 -> 204F5554501554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.

qu1ck · « **Reply #197 on:** February 27, 2024, 03:14:56 pm »

Judging by the fact that you have half of a hex digit missing in the output in some cases the fault is much more likely in your uart and not decoding. Try lower baud rate or different uart chip.

mmx01 · « **Reply #198 on:** February 27, 2024, 03:38:39 pm »

I thought about this as well but UART is already another attempt due similar issues I have faced with i2c connected oled. Similar defects are happening also via i2c with UART completly removed from the loop. You use parallel interface and I thought initially it may be due i2c being slower and standard SSD1306 libraries requiring display.display() to push the entire buffer out, taking extra cycles with capture/decoding still running (explaining missing bits/sometimes bytes) but the same happens via serial.

Now I started thinking about reducing number of variables and getting STM32 dev board instead of ESP32 (although I did not immediately see why it wouldn't work). Tested it also with 10k resistors on the SCK/MISO/MOSI lines but ESP32 is 5V tolerant and same defects appeared with or without the resistors towards the FP (exluding issue of overdriving pins).

qu1ck · « **Reply #199 on:** February 27, 2024, 04:46:09 pm »

> Similar defects are happening also via i2c with UART completly removed from the loop

Similar is not the same. When you print a hex digit to uart and only see one char instead of 2 that means your uart is borked, no other explanations.
Missing bits can be explained by timing or by slow IO (io clock is not the same as core clock) or by ringing (check connections).

If you have timing issues you can check 2 things
1. Every byte is read as soon as it comes in, my code has a check provisioned for it. On the original board it lights up an error led if SPI bits are coming in faster than the board can process them.
2. Every frame is processed before next frame comes in. Time between frames is a lot bigger than between bits so you can accurately measure it in code itself and check if your display output routines are fast enough.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee