EEVblog Electronics Community Forum
Electronics => Repair => Topic started by: 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 (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/ (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.
-
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
-
I will definitely hook it up to a logic analyzer but first I need to find any dip comparator |O 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? :o I'll have to measure that tomorrow, 3:30am right now, too tired to think :)
I'll come back with some experiment results soon.
-
:horse:
https://www.eevblog.com/forum/buysellwanted/ebay-many-faulty-hpagilent-34401a-multimers/msg811170/#msg811170 (https://www.eevblog.com/forum/buysellwanted/ebay-many-faulty-hpagilent-34401a-multimers/msg811170/#msg811170)
-
@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.
-
I apologize
-
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.
-
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.
-
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.
(https://i.imgur.com/et0J2Ca.png)
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
(https://i.imgur.com/EsCJLZ0.jpg)
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:
(https://i.imgur.com/6gG5ygZ.png)
I captured 4 seconds of traffic and with some bash-fu extracted ascii data:
$ 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.
-
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.
-
@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.
-
This thread, member says it's the display: https://www.eevblog.com/forum/testgear/hp34401a-display-with-dots-after-every-digit/msg1228322/#msg1228322 (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 (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.
-
@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.
-
@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
-
@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.
-
No display has such a thin thread that will not take 1mA.
-
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 (https://en.wikipedia.org/wiki/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.
-
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.
-
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.
-
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:
(https://i.imgur.com/sBpczOl.jpg)
(https://i.imgur.com/8Cr6wcb.jpg)
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.
-
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.
-
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 :)
-
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.
-
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.
-
would be nice to have another type of display adapted ...
-
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.
-
its the driver.
the adjacent pins in the chip leak signals. they ALL go bad sooner or later.
simply replace the driver chip.
-
@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.
-
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 (https://www.eevblog.com/forum/testgear/hp34401a-display-with-dots-after-every-digit/msg1228322/#msg1228322) :-//
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
-
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.
-
(https://i.imgur.com/AId0xw1.jpg)
-
@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 )
-
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 (http://ww1.microchip.com/downloads/en/DeviceDoc/20005847A.pdf)
The TI driver has push-pull output stage, while the NEC FIP output stage is PMOS with weak pull-down.
-
@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.
-
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 ...
-
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).
-
Oh, the suspense! :popcorn:
-
maybe this datasheet may help : https://www.newhavendisplay.com/app_notes/SSD1322.pdf (https://www.newhavendisplay.com/app_notes/SSD1322.pdf)
-
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.
-
an future competitor to the 6 1/2 digit meter thread here lolll
-
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.
-
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:
(https://i.imgur.com/0IGfNEK.jpg)
Starting on secret feature now :)
-
So cool. I see you've got annunciators (at least one in the pic) and the sampling indicator, too. :clap:
Oh, the suspense...
-
Homer Simpson drooling loll :-+
-
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
-
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.
-
@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 (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.
-
@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, 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
-
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
-
Really nice job!
Looking forward to your final design.
-
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.
-
All right, here it is. Behold: the secret feature unveiled :D
https://youtu.be/LWxOfaXVN3I (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:
(https://i.imgur.com/flhAWUN.jpg)
-
Nice work!
-
I love it! :clap: Makes me want to buy another 34401A, but with a bad display, to upgrade it.
Next secret features: graph and histogram? ;D
-
I have a broken 34401A with a bad VFD laying around, would be nice to test !
-
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
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.
-
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
-
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. :--
-
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. :-+
-
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.
-
Thanks for the update. Yeah, hopefully it all fits nicely inside. Keeping my fingers crossed.
-
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).
(https://i.imgur.com/CxDRkCb.jpg)
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 :D
-
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?
-
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.
-
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).
(https://i.imgur.com/CxDRkCb.jpg)
Excellent work. I really like how this turned out. Yours is the first successful matrix screen (LCD or OLED) implementation I've seen.
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 :D
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).
-
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 :D 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.
(https://i.imgur.com/xnGRZQ3.jpg)
-
It looks very nice readable behind the original window.
Very nice job!
-
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.
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.
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.
On the bright side, the display is quite, well, bright :D 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.
(https://i.imgur.com/xnGRZQ3.jpg)
That's good news. I was afraid that the filter would be too dark. It looks fine.
-
qu1ck, impressive. Somebody should give you a Keithley 2xxx when you are done with the 34401a. ::)
Congrats.
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.
-
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.
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.
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.
-
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.
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.
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.
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.
-
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.
-
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."
-
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.
-
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.
-
Yeah, it's another level for sure.
-
... 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 (https://bbs.espressif.com/viewtopic.php?t=133) 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.
-
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.
-
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.
-
What PCB software are you using?
-
Kicad 5 rc3.
Sent from my moto g(6) using Tapatalk
-
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.
-
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
-
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 (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.
-
Poor chinese bastards have no weekends :D 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/ (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.
-
It's going to the fab!
Sorry for asking, which one?
-
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/ (http://ibom-showcase.bitballoon.com/)
Really cool, good job! :-+
-
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
-
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/ (http://ibom-showcase.bitballoon.com/)
Really cool, good job! :-+
That is a very cool tool!
-
Really cool, good job! :-+
That is a very cool tool!
Nice one, qu1ck is now in my buddies list.
-
Well this is a hilarious fuckup (images clickable):
(https://i.imgur.com/EbYoDcr.jpg)
Do you see it?
How about now?
(https://i.imgur.com/SvLrhVs.jpg)
And yes, I double checked my gerber files, they are obviously correct :D
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.
-
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.
-
I'll try to scrape the solder mask off
Yes, it will be not pretty but it should work.
-
Yeah, only ground plane pads got affected and only 2 of the 4. :-//
Fret not, some elbow grease and good microscope to the rescue:
(https://i.imgur.com/hbM4SC5.jpg)
(https://i.imgur.com/6PeqOIQ.jpg)
(https://i.imgur.com/iuAoBAM.jpg)
Also had some fun with recording video. I just might record the whole assembly process too.
https://youtu.be/ZoB_NMqq5YA
-
Looks good, qu1ck. If you record the assembly, I'll watch. :-+
-
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 (https://github.com/openscopeproject/InteractiveHtmlBom)
Better than earlier demo (https://openscopeproject.org/InteractiveHtmlBomDemo/OSPx201/ibom.html)
Started a thread for it in KiCad section https://www.eevblog.com/forum/kicad/interactive-html-bom-plugin/ (https://www.eevblog.com/forum/kicad/interactive-html-bom-plugin/)
-
How about displaying the 1 or 2 extra digits that are available via GPIB or RS232?
-
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.
-
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.
-
Don't get too over complicated lolll
-
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.
-
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.
-
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...
-
Long overdue update. Good news, I didn't screw up :)
(https://i.imgur.com/1YsGkNX.jpg)
(https://i.imgur.com/pmdvrba.jpg)
(https://i.imgur.com/wT1HEOY.jpg)
Board works perfectly fine. Don't mind the botched wire on the last pic, it's an impatient man's diode.
-
Looking really good!
-
Drool!
(https://cdn2.vectorstock.com/i/1000x1000/42/41/drooling-emoticon-vector-794241.jpg)
-
drool +1
-
Wow! As Dave would say, "It's like a bought one."
-
Testing and implementing display rotation (almost) done:
(https://i.imgur.com/bZpQViy.jpg)
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.
-
vote qu1ck for president.
Looks awesome.
-
You did an amazing job with this.
-
is it me it seem very bright ??? would it be possible to dim it a little ??? nice job :)
-
With the acrylic glass on top it should be just perfect... I would not dim it.
(https://i.imgur.com/xnGRZQ3.jpg)
-
At some point contrast will be configurable to reduce burn in. But it looks just right on max imo.
-
thats a really nice mod. I like it, great work! :clap: But will the OLED not have the tendency to burn in ?
-
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.
-
just sad not to find a perfect fit in size snif, but job well done, next a fluke 8846a lolll
-
Looks awesome, qu1ck! And you went from concept to production quite quickly, too (very much in line with your username ;D). 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.
-
Firmware (https://github.com/openscopeproject/HP34401a-OLED-FW) and hardware (https://github.com/openscopeproject/HP34401a-OLED-HW) is released.
I only have mechanical considerations left to resolve I think. I.e. how to mount the display.
-
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!
(https://i.imgur.com/uPaCK7T.jpg)
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.
(https://i.imgur.com/vb7f11p.jpg)
This is how it looks like in the panel:
(https://i.imgur.com/LLBGMiV.jpg)
And the satisfying conclusion to this endeavor:
(https://i.imgur.com/FP5pQ6R.jpg)
(https://i.imgur.com/M9DBcBK.jpg)
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.
-
Amazing how well all the new bits fit in place. Congrats on a very cool and successful display upgrade.
-
Excellent work!! :-+ :clap:
-
Thanks
Now I have 10 boards I can send out and 1 mostly working VFD screen :D
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.
-
That's a unique idea. Let me see what I have or could locate that would be neat to send to you.
-
Maybe send some email of your project at Xdevs for your / substitution replacement display ??? it could be an good resource ???
-
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.
-
Now on HackaDay :)
-
Congrats, qu1ck!
https://hackaday.com/2018/08/29/faded-beauty-dmm-gets-an-oled-makeover/
-
Congrats, well done!
-
How nice to see it on hackaday.
Congratulations.
-
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 (http://noritake-vfd.com/gu256x64d-7000bx.aspx)
pdf
https://www.eevblog.com/forum/repair/fluke-8846a-repair-shenanigans/?action=dlattach;attach=511772 (https://www.eevblog.com/forum/repair/fluke-8846a-repair-shenanigans/?action=dlattach;attach=511772)
-
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 :D
-
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 :)
-
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
-
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.
-
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)
-
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 ??
-
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:
[env:release]
platform = ststm32
framework = arduino
board = genericSTM32F103CB
board_build.variant = custom
debug_tool = jlink
upload_protocol = jlink
firmware attached.
-
the pcb are not interchangeable if you dont downgrade the firmware version prior to thoses i've wrote, come from a Keysight service note ...
-
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).
-
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.
-
@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 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 (https://platformio.org/platformio-ide) are miles ahead and completely superseed arduino IDE. I use Atom based one because it came out first but VSCode is even better.
-
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.
-
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.
-
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.
-
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 :(
-
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 (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 (https://sigrok.org/wiki/Downloads)
-
Any idea what is the filament current of the original display?
Thanks.
-
10 ohms of impedance / resistance
-
Ok, 10ohm, and the voltage is 6V (when looking into the SM p.9-7) therefore 600mA AC, imho.
-
6v in 10 ohms is 600ma not 60 ma
-
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..
-
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 (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 (http://cna.mamk.fi/Public/Slabra/Agilent/Multimetro_Digital_34401A_Quick_Reference_Guide.pdf)
-
That will not cut filament power, it is not digitally controlled.
-
yep you're right quick
@imo do you want to save the remaining life of the vfd ??
-
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 :)
-
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?
-
I've been using rs232 to HC-05. Powered from the meter.
-
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 (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 (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 ??
-
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.
-
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)
-
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..
-
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 :-//
-
the hv518 can be ordered here
https://www.digikey.com/number/en/microchip-technology/150/HV518/114088 (https://www.digikey.com/number/en/microchip-technology/150/HV518/114088)
-
But the shipment is 40$ for a 5$ part :P
-
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 ??
-
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.
-
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.
-
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.
-
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.
-
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
-
It would help, if serial printing had lower priority, since it is disturbing spi decoding during debug.
-
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.
-
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 :phew:
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
-
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.
-
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 :-DD :-DD
-
Yeah, that doesn't look half bad. You will have a hard time with annunciators though :)
-
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 ?
-
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 8)
-
Nice test. If the display controller supports custom characters, that could make for some nice annunciators (if it was for longer-term use).
-
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.
-
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.
-
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.
-
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?
:-+
-
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.
-
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
-
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.
-
@dreamcat4
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.
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
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.
-
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
-
I took the 250mA value from example Blue 3.2" 256x64 OLED datasheet (https://www.buydisplay.com/blue-3-2-inch-arduino-raspberry-pi-oled-display-module-256x64-spi) 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.
-
Thanks for this great job! This will certainly be useful one day when I find a 34401A for a reasonable price....
-
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 ;D https://www.eevblog.com/forum/testgear/external-display-for-agilent-34401a-(or-any-dmm-with-rs232-output-stream)/msg4344103/#msg4344103 (https://www.eevblog.com/forum/testgear/external-display-for-agilent-34401a-(or-any-dmm-with-rs232-output-stream)/msg4344103/#msg4344103)
-
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) :)
-
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.
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.
-
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.
-
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).
-
> 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.
-
I have wired red led with flag byte_not_read. With oled configured it does turn on from time to time but this is not aligning with oled defects.
With led off defects still appear. However without oled, red led does not come on.
Agreed serial issues appear independent from oled issues in a sense for oled there's more a bit flip issue than half byte lost with serial.
I put some time captures in SW, for message to message the period measured from first interrupt until EOF is avg. 116800us = 8.5Hz. Since I push the buffer out to display on EOF (all bytes in the buffer), I would expect it to be okay. i2c could handle up to 40fps, so there's room there. i2c is set to 400kHz.
https://youtu.be/vYpie1gxGXQ
(https://youtu.be/vYpie1gxGXQ)
For ringing mitigation I put short cables and series resistors but little to no change. Will try with STM32 tomorrow and if not getting anywhere will get a cheapo logic analyzer.
18:00:57.821 -> 204F5554505554204F 64620000.
18:00:57.821 -> 7474757972737674757476757500.116407.
18:00:57.821 -> 204F5554505554204F464620000.
18:00:57.821 -> 7574767579747574747474747600.116918.
18:00:57.821 -> 204F5554505554204F464620000.
18:00:57.821 -> 7474747574787576747675737700.116913.
18:00:57.821 -> 204F5554505554204F464620000.
18:00:57.821 -> 7677737673757574737676747700.116896.
18:00:57.821 -> 204F5554505554204F464620000.
-
So with STM32F4 board everything works fine with the same i2c oled... no defects. Processing time for each byte has not changed between ESP32 and STM32 however, frame processing time is 26% faster with STM32.
Indeed ESP32 GPIOs are not running at 240MHz like the cores do, but still the APB bus runs on 80MHz. I had not expected issues with the ESP32 performance for this not very complex decoding task yet empirically it proves to be the case.
Now I can move on to mapping other codes for different display features.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7474747475747474747574747400.86855.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7474757474757575757474747400.86555.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7474747475747474757574747400.85627.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574747475747474747474747400.85136.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7475757474747475747474747500.86854.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574757474747475747475747400.86554.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574757574747474747475747400.86043.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574747474757574747475757400.86556.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574747474747474747574747500.86556.
-
How are you doing the level-translation, do you have a schematic? Just to see if that is the problem.
I would also ensure the radio is turned off to prevent TX packets from making interference and power system spikes, in active mode it can spike to 250mA.
I have the rotary encoder bits reverse-engineered somewhere and will look for that when I get a chance.
-
With ESP32? Level shifting is not needed, IO is 5V tolerant.
-
With ESP32? Level shifting is not needed, IO is 5V tolerant.
No mention of 5V tolerance in Espressif datasheets "3.6V max" so I treat it as that. The hiccup looked periodic in the video, happens at a regular interval so something else must be at play.
Changing to the STM32, one way to solve it.
-
You are right about the datasheet, for official use I would not push it. For hobby I did many times and "the internet" is full of statements it does. While it is not in the datasheet, it does support 5V when VCC is 3.3V.
As to how I would approach level shifting, resistor dividers may not be fast enough and when I play with FPGAs and 5V->1.8V (older 5VCMOS or TTL logic) I resort to gtl2000dgg. Quite fast for such projects at 33MHz, bi-directional without direction pin, with minimal passive components to get going. Issue is the package is not breadboard friendly so it was cheaper to get STM32 dev kit than ordering level shifting PCB. Once I get the PSU running for business I may come back to ESP32 as project and implement level shifting because it is still unclear to me why ESP32 would struggle with this task, bit banging with timing logic.
Nonetheless it is impressive how much thought qu1ck put into his project. Also trimmed display library with parallel interface where he writes via registers makes it very efficient. I managed to hit the limit with the i2c oled today :) when pressing buttons fast my oled is freezing and the red light is on. It seems not possible to write directly to memory of SSD1306 via i2c so I am getting also parallel interface oled to move on.
M.
-
An Espressif guy mentioned it works with 5V input but was a bit leery about lifetime of the silicon as it's not tested up there.
There was no need to bit bang with the STM32 but yes with the ESP32? I also thought it could keep up but it does have a kernel and FreeRTOS (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/freertos.html) in the background that might be the problem.
Do you have a running front panel board connected, while snooping the data stream? It sounded smashed up.
I ask because there is a watchdog between the front panel MCU and main CPU. No response from the FP causes the main CPU to issue a RESET (IGFPRES) and beep as well. I thought that could cause the glitch you kept seeing but no.
-
I have the FP connected and sniff in parallel to the actual communication. Some buttons do work but overall its condition is as seen...
[attach=1]
Since entire front is destroyed buying the shell with buttons, PCB and VFD would cost more than what I paid for the device. So my plan is to get this to a working state with oled and 3d print the front with likely new pcb with push buttons.
Encoder was also destroyed (in fact it split into two parts) but mechanically it turned out okay so I put it back together.
-
iMo, did you progress with a simple and practical way to de-energise the display filament?
I want to operate my meter for logging, and the display is showing some intensity variation, so I have some incentive to turn the display off as well as de-energise the filament - for the purpose of lowering internal temp rise, and prolonging useful service life of the display. The assumption would be that de-energising the display filament has some correlation with display related failure/degradation.
A concern could be if mains power is toggled, and the meter turns back on with display enabled (which I assume happens due to volatile memory), and that may add risk if the filament is otherwise switched off. I guess a mains power latched contact could remove that risk.
-
you could use the internal front rear switch lever / rod to actuate a switch ?
if you dont use the rear inputs, a front rear movement could activate a filament switch ? some push lock and push unlock ??
just tie wrap something on the lever, but be careful not to damage it ? they get slightly fragile on both end