LED display for HP 3457A multimeter - I did it :-)

[bingo600]

Wooowww   

Very nice looking mod 

Any chance you would describe the protocol ?

/Bingo

[stj]

that's an incredible amount of mechanical effort!!

i would have used a starburst VFD, it would have looked good, but probably not even close to that good. 

[texaspyro]

I've got 3 or 4 3457's hanging around here that could use a display upgrade.  If you build more of these, I'm in.  I'd also be interested in your code / protocol info.   I'd probably implement it using a VFD or modern backlight LCD.

I have a project on the back burner to do a replacement front panel board for the HP-531xx counters using (probably) a backlit LCD.  There are a lot of those out there with weak VFD's.  HP only sells the display as a complete front panel board... $1800.

[xi]

Wow, I didn't expect so many answers! Thanks for your nice comments about my mod

Just answering quickly some of your questions ; I will post the protocol and schematic on tomorrow, I am too tired tonight

As for the 3478A, I think it would work too (I used the doc of this DMM to get the pinout of the display and the function of each line - it is more detailed than the 3457A one). But, you would loose the indications at the bottom of the display (MATH, CAL, SHIFT, ...), because on the 3478A, these indications appear directly on the display (contrarily to the 3457A where the indications are printed below the display).

The colon is used to describe parameter's value. For example, if you launch the command "ID?" from the menu, it displays "ID?:HP3457A".

As for selling a kit ... I don't know, I think it would be too expensive compared to the current price of the HP 3457A. But I will calculate with the BOM.

[Macbeth]

Amazing job, especially all that work to add the colons and commas on the third PCB. 

Please do publish the protocol, even though it removes some of the fun for us masochists who enjoy reverse engineering that kind of stuff!

[Dave]

Absolutely superb! These are the kinds of amazing projects that keep me hooked to this forum.

[timb]

Awesome job! 

I have one bench meter, but I never use it.  It is a Keithley 175 and it has the same hard to read display at certain angles.  I got it for $30 CDN out of curiosity more than anything.

I'm working with Technogeeky to come up with a replacement display board for the Keithley 197/197A, and I wouldn't be surprised if it used a very similar display board, if not the same one. Keep your eyes peeled.

We should pool our resources, as I’m halfway done with an OLED mod for the 197. I’ve almost got the mechanical portion down (I designed a small frame that can be laser cut from plastic), now all I need to do is design the replacement PCB. The trick is getting the button positions right (I’ve scanned in the existing board so I can get precise measurements).

I’ve also got some preliminary firmware going on an MSP430 to decode the signals.

I’m still waiting on the OLEDs to get in from China so I can try it out on the meter itself.

Initially, I was going to use LEDs like the OP’s 3457A mod, however it would have been difficult to replicate the annunciator symbols (BATT, HOLD, etc.) without implementing a diffuser and custom cut mask (I experimented with cutting the symbols into a black vinyl mask, adding a diffuser and then lighting them from behind with a single LED, but I wasn’t quite satisfied with the results). An LED cluster would have also used a lot power, which the 197 doesn’t have to spare. An OLED display won’t use more than 50mA, which is inside the 5VD rail’s buffer.

Anyway, send me a PM, I’m about 50% done with my project. I was planning on releasing it as a retrofit kit.

—

As for the OP’s project: A work of art! Please release schematics and such. From the looks of the 3457A’s LCD and interface, this LED mod should be extendable to other gear from that era, like the HP 3488A switch mainframe, which has the same style LCD as the 3457A. (In fact, it may even be the same LCD, it’s the same size and alphanumeric, with bottom markers and everything.)

[precaud]

Superb! Congrats!  I want one!

[TiN]

Very cool, impressed with amount of work into that old meter. 
Where did you get black screen in front of LEDs for contrast? I'm looking for that film for VFD displays...

[cs.dk]

Very nice mod

[SeanB]

Looks like a regular 80% or so solar film, simply cut to size. You can buy a whole roll, or just ask any car tint installer for an offcut in the desired shade and they likely will have a load of pieces you can cut the window out of for free.

[tggzzz]

Have you done any tests to ensure and assure that changes in the current powering the LEDs doesn't affect the measurements?

[hugo]

Congrats to you XI, awesome job. 

[cncjerry]

I'm really impressed.  I have two of those meters and coupled with very bad eyesight with Glaucoma and cataracts, I hate the display.  Absolutely hate it.

Did you engrave the boards with CNC or etch them?

Nice work all around.

Jerry

[xi]

HP 3457A multimeter LCD display protocol

As several of you asked for it, this is the protocol of the HP LCD display

• Electrical lines description

A 34 pin HE10 connector is used on the HP 3457A digital motherboard (same as those used for the 3.5" floppy drives). The ribbon cable attached is cut in two parts: pins 1 to 16 for the keyboard and pins 17 to 32 for the LCD display (pins 33 and 34 are NC).

Below is the pinout and the description of the LCD part of this HE10 connector.

Code: [Select]

                                               (NC) 17|18 (V3V: power supply for the LCD)
                            (instruction line: ISA) 19|20 (V2V: power supply for the LCD)
(1 = read data on ISA / 0 = read data on INA: SYNC) 21|22 (V1V: power supply for the LCD)
                                               (NC) 23|24 (GND)
                                   (data line: INA) 25|26 (OS1: for internal oscillator of the LCD display ; connected to a 470pF capacitor on the motherboard)
  (second clock, same as O1 with a small delay: 02) 27|28 (NC)
                                        (clock: 01) 29|30 (NC)
                          (global chip select: PWO) 31|32 (VCC: +5V with a serial resistor of 1k on the motherboard)
                                               (NC) 33|34 (NC)
So this is a serial synchronous transmission, and for us there are 5 interesting lines: PWO, 02 clk, SYNC, ISA and INA. With these lines we are able to completely decode the protocol of the LCD display. (note: O1 and O2 clocks are exactly the same, but the O2 line is 6µs late compared to O1. We will use rising edge of O2 clock to sample the data, because it has the best timing (middle of each data bit)).

Note: the pinout of the DIL connector (LCD end of the ribbon cable) is given on my schematic that I will publish soon. Basically, pin 17 of the HE10 goes to pin 1 of the DIL support, pin 18 on pin 2, ... and pin 32 on pin 16!

• Protocol overview

Let's observe a capture of a full frame (once received, this frame will display the above text "BEEP,-99999.1_", with two annunciators lit : "SMPL" & "MATH"):


Description of each line:
PWO: this is the global chip select, when at level "1", the LCD display is selected and must read the data.
CLK 02: this is the clock for the data received on ISA and INA lines. Max clock frequency is 55kHz (may be less, I guess it depends on the processor load).
SYNC: this line is at level "1" when the data must be read on ISA line / at level "0" when the data must be read on INA line. On the above screenshot, the SYNC line goes "high" 7 times, meaning there are 7 instructions sent on ISA line
ISA: this line sends the instructions to the LCD display, I have found 7 types of instructions:
 - 0x3F0: select the LCD display (1 byte)
 - 0x2E0: ?
 - 0x320: toggle display ON/OFF
 - 0x2F0: annunciators ON/OFF ("SMPL", "REM", "SRQ", "ADRS", "AC+DC", "4W", "AZOFF", "MRNG", "MATH", "REAR", "ERR", "SHIFT") (2 bytes)
 - 0x028: write A registers (6 bytes)
 - 0x068: write B registers (6 bytes)
 - 0x0A8: write C registers (6 bytes)
INA: this line sends the data to the LCD display (eg the values to display on the digits)

Chip Select: is not a line from the motherboard, it is generated by my board with a bit of logic (we will see why later)

Let's zoom on the complete frame: complete frame (very large image)
We can see 7 instructions sent on the ISA line in this order: 0x3F0, 0x2E0, 0x320, 0x2F0, 0x0A8, 0x028, 0x068. Some frame will have less instructions, in fact, only the data that change are re-transmitted (if you press the "SINGLE" button of the DMM, the data are sent once to the LCD display, then nothing changes, so nothing is transmitted anymore (to be exact, when nothing changes, the data are retransmitted each 2 minutes or so).
Below is a screenshot of two successive frames, one has 7 instructions, the following only has 4 instructions, because only the annunciator changed:


The INA line shows the data that follow each instruction. In the following section we will describe the useful sections more in-depth.

• Examining the first instruction: 0x3F0 = select the display

General info about the transmission:
- Each bit are transmitted reverse, ie the bit 0 (= Least Significant Bit) of a register is sent first ...
- The same apply for the digits: digit 12 (the last one) is transmitted first ...

Let's observe the first instruction received on the above complete frame: 0x3F0:

The doc I found says this instruction is to select the display, and the display is selected when the data received on INA line is 0xFD. Let's verify!

Let's check the instruction between C1 and C2 markers first: remember that instructions are sent on ISA line when SYNC line is at level "1". On the above screenshot, we can see that we received these bits:
0000111111 (10 bits).
Also remember that the bits are sent in reverse order, so once reordered, the data on ISA line is:
1111110000 = 0x3F0 = select the LCD display command

Now we are going to check the data between A1 and A2 markers: remember that data are sent on INA line when SYNC line is at level "0". On the above screenshot, we can see that we received these bits:
10111111 (8 bits).
Also remember that the bits are sent in reverse order, so once reordered, the data on INA line is:
11111101 = 0xFD = select the LCD display value

What about the bits received between C2 and A1 markers ? (two clock pulses)
There are always these two bits, whatever the line (ISA or INA), and they are always 0. The useful data always starts after these 2 bits, and are then sent on a multiple of 8 bits.
In other words, each transmission of data starts with a 10 bits set, followed by n 8 bits sets. But since the first 2 bits are always 0, we can ignore them and consider that the data are only composed of 8 bits sets.
Ignoring these 2 bits is not an easy task for the microcontroller, because it is not designed to receive a variable length of data on the SPI bus For this reason, I have added a bit of logic (two D flip-flop to delay the SYNC signal and an XOR gate to generate my "Chip Select"). With this logic, I am able to decode directly the data from the HP 3457A using the hardware SPI module from the Atmel microcontroller (the "Chip Select" line directly drives the CS input of the Atmel: the CS input is only enabled when at logic level "0" ).

• The Digits part

Ok, I hope you have understood how the frame is built, so now let's decode the interesting part of the frame: the data sent to the digits
We will ignore the useless (for the mod) instructions (0x2F0, ...) and we will decode the 0x028 / 0x068 / 0x0A8 instructions. There are 3 registers of 6 bytes each = 18 bytes in total to describe the 12 chars of the display + the punctuation. Each register is set by one instruction received on ISA line: 0x028 for register A, 0x068 for register B and 0x0A8 for register C.

This screenshot shows the complete decoding of the 0x028 command (values for register A), up to the next command 0x068.

The principle for decoding this instruction is exactly the same as for the "First instruction: 0x3F0", so refer to this section to understand it
The data set received for register A is (hexadecimal): 1F 99 99 D9 50 25

Note that there are 6 more bytes transmitted after these 6 bytes, but they are always 0, so we don't bother to retrieve and decode them (I don't know the purpose of these bytes).

This is screenshot for 0x068 command = values for register B:

The exact same principle applies to decode it, and the data set received is: 31 37 33 23 0D 00

Similarly, the register C (0xA8 command) will decode as: 00 00 00 00 00 00

Ok, so "BEEP,-99999.1_" is displayed on the screen, and we have 3 registers, containing the following values ... how to match them?
 reg A = 1F 99 99 D9 50 25
 reg B = 31 37 33 23 0D 00
 reg C = 00 00 00 00 00 00

• Decode the Digits

After much research for "HP LCD charset" and other similar things, I ended-up finding this little treasure: the complete doc of a ROM for the HP41C! This is a calculator that contains a LCD display with a similar protocol as the one used on the DMM ; thanks HP for the good consistency between the products This is here: http://www.series80.org/Misc/ZenROM.pdf

The most interesting info are on page 115 and following (section 8.2 "Display handling"):
- description of the format of the frames
- description of the instructions (some are missing, like the 0x2E0, but it's enough to understand the protocol)
- and the most interesting: the HP character set for the LCD display! Below is a reproduction of this charset, with the value for each char (eg, char 'X' has value "0x18")


Each byte of register A contains 4 LSB bits for each digit (meaning there are the LSB part of 2 digits in each byte)
Similarly, each byte of register B contains 2 MSB bits for 2 digits and 2 bits for the punctuation of 2 digits
And, each byte of register C contains the Extended bit for 2 digits.

Below is a table that represents the 6 bytes received for each registers (A, B & C), and the matching digits data.

Code: [Select]

----------------------------------------------------------------------------------------------------------------------
|Byte nr received |        1        |        2       |       3       |       4       |       5       |       6       |
----------------------------------------------------------------------------------------------------------------------
|Digit number     |   11   |   12   |   9   |   10   |   7   |   8   |   5   |   6   |   3   |   4   |   1   |   2   |
----------------------------------------------------------------------------------------------------------------------
Char value is given by retrieving the following bits from register A, B & C:
(The first line represents the 7 bits of the char value ; this value directly matches the HP charset showed above)
(The second and third line show which register and bit needs to be read to retrieve the char value. Eg, "RegB3_bit1" means Register B, byte 3, bit 1)

Code: [Select]

------------------------------------------------------------------------------------------------------------------------------
| bit number for one char         |     6      |     5      |     4      |     3      |     2      |     1      |     0      |
------------------------------------------------------------------------------------------------------------------------------
| pos in the reg. for even digits | RegCn_bit0 | RegBn_bit1 | RegBn_bit0 | RegAn_bit3 | RegAn_bit2 | RegAn_bit1 | RegAn_bit0 |
------------------------------------------------------------------------------------------------------------------------------
| pos in the reg. for odd digits  | RegCn_bit4 | RegBn_bit5 | RegBn_bit4 | RegAn_bit7 | RegAn_bit6 | RegAn_bit5 | RegAn_bit4 |
------------------------------------------------------------------------------------------------------------------------------
Lets apply this table to our example. Remember we got these values in the registers:
 reg A = 1F 99 99 D9 50 25
 reg B = 31 37 33 23 0D 00
 reg C = 00 00 00 00 00 00

So if we want to decode digit 4 for example, using the first table, we know that digit 4 data are stored in byte number 5:
Digit 4 data are 50 (reg A), 0D (reg B), 00 (reg C). Written in binary, this is:
01010000 (reg A), 00001101 (reg B), 00000000 (reg C)
Now we use the second table to decode the char ; digit 4 is an even number, so decoding is done using these bits:

Code: [Select]

| RegC_bit0 | RegB_bit1 | RegB_bit0 | RegA_bit3 | RegA_bit2 | RegA_bit1 | RegA_bit0 |
|     0     |     0     |     1     |     0     |     0     |     0     |     0     |= 0010000 = 0x10
Last, we use the HP charset to see that char 0x10 is the letter 'P', eg what was expected (forth digit of "BEEP,-99999.1_" text)

• Decode the Punctuation

The punctuation is transmitted in the register B, using the exact same principle as above.

Code: [Select]

-------------------------------------------------------------
| bit number for the punctuation  |     1      |     0      |
-------------------------------------------------------------
| pos in the reg. for even digits | RegBn_bit3 | RegBn_bit2 |
-------------------------------------------------------------
| pos in the reg. for odd digits  | RegBn_bit7 | RegBn_bit6 |
-------------------------------------------------------------
And the charset for the punctuation is this one:

Code: [Select]

--------------------
|Value | Sign      |
--------------------
| 0    |   (none)  |
| 1    | . (point) |
| 2    | : (colon) |
| 3    | , (comma) |
--------------------(note: the annunciators are transmitted separately in another instruction)

Lets apply this table to our example. Remember we got these values in the registers:
 reg A = 1F 99 99 D9 50 25
 reg B = 31 37 33 23 0D 00
 reg C = 00 00 00 00 00 00

So if we want to decode punctuation for digit 10 for example, using the first table, we know that digit 10 data are stored in byte number 2:
So, digit 10 data is 0x37 (reg B) = 00110111 (reg B)
Now we use the punctuation decoding table ; digit 10 is an even number, so decoding is done using these bits:

Code: [Select]

| RegB_bit3 | RegB_bit2 |
|     0     |     1     |= 0b01 = 1
Last, we use the charset for the punctuation to see that value 1 corresponds to punctuation '.' (point), eg what we expected (punctuation for 10^th digit of "BEEP,-99999.1_" text)

• Decode the Annunciators

Remember, the annunciators are the functions "SMPL", "REM", "SRQ", "ADRS", "AC+DC", "4W", "AZOFF", "MRNG", "MATH", "REAR", "ERR", "SHIFT" below the display.
They are send just after the instruction 0x2F0, like in the screenshot below:


As always, the instruction is between C1 & C2 markers. Decoding the instruction gives 0x2F0, which indicates that the annunciators will follow on INA line.

Decoding the annunciator is really simple: they are sent on INA line between markers D1 & D2, and there is one bit per annunciator. The only difficulty is that they are written reverse (as always), so the first transmitted bit is the last annunciator.

Code: [Select]

---------------------------------------------------------------------------------------------------
| annunciator  | SMPL | REM | SRQ | ADRS | AC+DC | 4Wo | AZOFF | MRNG | MATH | REAR | ERR | SHIFT |
---------------------------------------------------------------------------------------------------
| bit position |  12  | 11  | 10  |  9   |   8   |  7  |   6   |  5   |  4   |  3   |  2  |   1   |
---------------------------------------------------------------------------------------------------
Applied to our example, we have bit's positions 4 and 12 which are at level "1", meaning that "MATH" indicator and "SMPL" indicators are ON

• Literature

- This is the key documentation, starting at page 115, it gives the instructions supported by the display, and the complete charset: http://www.series80.org/Misc/ZenROM.pdf
- This one shows the representation of the HP charset on 14 segments display (the chars are scattered at various places, and some symbols are missing) : https://www.pungerer.net/pfx/MesPockets/HP/hp41cv/QuickCards/HP41QuickGuideSunthProgA.jpg
- The service manual of the HP 3478A for the description of the LCD display lines (page 141, section 7-F-66): http://www.arimi.it/wp-content/Strumenti/HP/Multimetri/hp-3478a-Service.pdf


That's the end! I have spent a lot of time writing this "spec" ; I hope it will benefit to someone!
Feel free to ask if something is unclear or poorly written ...

[xi]

Very cool, impressed with amount of work into that old meter. 
Where did you get black screen in front of LEDs for contrast? I'm looking for that film for VFD displays...

This is grey perspex (the original brand) ref 923 in 3mm thickness. I have tested several colors, and this one is the best for this application (once multimeter is closed, you don't see at all the unlit digits nor the punctuation). Specs are here: http://www.perspexsheet.uk/neutral-923-perspex/ and I bought it from here: https://www.ebay.fr/itm/361076230021

And no problem at all to machine this perspex sheet on my CNC:

Have you done any tests to ensure and assure that changes in the current powering the LEDs doesn't affect the measurements?

The original HP 3457A consumes about 9.5W on the mains input line, with the extension board inserted. The mains fuse is 80mA at 230V, meaning that max power consumption could be 18W in theory (just to give an idea). The LED module consumes 2W in normal use with yellow displays (up to 4.5W when all digits are lit). It is plugged directly on the same transformer output as the digital motherboard, using an extension (see image below), so I don't load at all the 5V regulator of this board nor I load the windings used for the analog board.

I have also measured the input voltage on the 5V regulator of the digital board: 10.9V when the LED display is disconnected / 10.4V when the LED display is connected and used normally / 10V when the LED display is all lit. And ripple is 0.5V peak-peak on this input, so the 5V regulator will fully work at all loads.

So I am quite confident that the power consumption increase will not affect at all the measurements. HP took a large security margin for the voltages, and after several hours of work, the transformer keeps quite cool.
In case of doubt, I could still mount the red version of the Displays, which is low power / high brightness, and thus reduce the power consumption by a factor 2 I think.

I'm really impressed.  I have two of those meters and coupled with very bad eyesight with Glaucoma and cataracts, I hate the display.  Absolutely hate it.

Did you engrave the boards with CNC or etch them?

Nice work all around.

Jerry

Thanks for your feedback!
And sorry, I used the wrong term: the boards are etched and not engraved, you are right I use the CNC to drill and cut them.

[tggzzz]

Have you done any tests to ensure and assure that changes in the current powering the LEDs doesn't affect the measurements?

The original HP 3457A consumes about 9.5W on the mains input line, with the extension board inserted. The mains fuse is 80mA at 230V, meaning that max power consumption could be 18W in theory (just to give an idea). The LED module consumes 2W in normal use with yellow displays (up to 4.5W when all digits are lit). It is plugged directly on the same transformer output as the digital motherboard, using an extension (see image below), so I don't load at all the 5V regulator of this board nor I load the windings used for the analog board.

I have also measured the input voltage on the 5V regulator of the digital board: 10.9V when the LED display is disconnected / 10.4V when the LED display is connected and used normally / 10V when the LED display is all lit. And ripple is 0.5V peak-peak on this input, so the 5V regulator will fully work at all loads.

So I am quite confident that the power consumption increase will not affect at all the measurements. HP took a large security margin for the voltages, and after several hours of work, the transformer keeps quite cool.
In case of doubt, I could still mount the red version of the Displays, which is low power / high brightness, and thus reduce the power consumption by a factor 2 I think.

You missed a key word in my question, even though I used italics to emphasise it: changes.

Your response above is about the mean power dissipation. Your calculations and measurements may well be true, but are only vaguely relevant and are not definitive.

The LCD display will draw a constant current no matter what is displayed. The LED display will draw a different current depending on what is displayed. Every time the current changes there might well be some noise injected into the instrument's sensitive front-end - and that could affect the measurement.

If the display is multiplexed, and most LED displays are multiplexed to reduce the pin/wire count, then the current will change at the digit rate. The worst noise injection would probably occur when the display is 181818 or 111888 since  5 segments are changing from on to off and vice versa.

If, unusually, the display is not multiplexed, then the worst noise injection would occur whenever the displayed value changes. If no part of the measurement cycle is occurring at that time, then noise injection would probably be unimportant.

Without having considered the problem in detail, I will guess that any problems are most likely to appear with measurements:

• high source impedance, say 100kohms to pick a common value in metrology
• AC, not DC (although there might also be issues with DC measurements)
• values near 0V
• where a sub-harmonic of the multiplexing is near the mains line frequency, so that the mains frequency filter does not remove interference from the main
• where the number of displayed segments changes most, e.g. 181818

[voltsandjolts]

That's the end! I have spent a lot of time writing this "spec"

Well done on the reverse engineering and the nice write-up, much appreciated 

[xi]

Have you done any tests to ensure and assure that changes in the current powering the LEDs doesn't affect the measurements?

[...]
So I am quite confident that the power consumption increase will not affect at all the measurements. HP took a large security margin for the voltages, and after several hours of work, the transformer keeps quite cool.
In case of doubt, I could still mount the red version of the Displays, which is low power / high brightness, and thus reduce the power consumption by a factor 2 I think.

You missed a key word in my question, even though I used italics to emphasise it: changes.

Your response above is about the mean power dissipation. Your calculations and measurements may well be true, but are only vaguely relevant and are not definitive.

No, I didn't miss the word in your question Simply, as you must have noticed, English is not my native language and I have understood your sentence differently: I though you were talking about "changes in the current powering the LEDs" compared to the current powering the LCD, and I have answered to that question. In fact you were talking about current variations during the LEDs commutation. Sorry, It must be perfectly clear for the natives, but it was unclear for me.

The display is obviously multiplexed, otherwise It would need more than 200 pins to drive the LEDs and 200 wire passing from one board to the other in my design! Yes, the worst case is when I switch from one digit with many segments lit to a digit completely OFF (like when there is a space in the text displayed).

When designing the power supply, the perturbations were one of my concern: I have added some external filtering (coil and capacitors) at the input of the Murata DC/DC converter, in order to reduce EMI (there are some spectral analysis given by Murata that guarantee the max value of the EMI when using these external components).

I guess your overall question is about EMI? Conducted EMI or radiated EMI?
As for the conducted EMI, I am not too worried: the LED commutation is low frequency and this is typically well filtered by the capacitors and the regulators of the DMM. Moreover, a power filter doesn't eliminate these low frequencies either, so they do cross the transformer, as well as my board may generate them, and the DMM is designed to work with that.
I was a bit more worried about the higher frequency EMI (included those generated by the DC-DC), hence the coil, and hence my connection on the "Digital" winding of the transformer and not the "analog" one (I don't know if it is useful, but it won't hurt, moreover than HF generally doesn't cross well a 50Hz power transformer).
And I was also worried about radiated EMI, and for this part, I have no real clues, nor any device to measure them.

As for your proposed "problematic" tests:
- I did some measurements near 0 with a µV DC source (see the firsts photos), and results are really good: there is absolutely no visible change between the LCD version and the LED version.
- Today I did some tests with a resistor, as you advised: mounted the LCD display back, used a high stability 200k resistor, waited 3 hours for the equipment and the resistor to be perfectly warmed, mounted back the LED display, waited a bit more and compared the results: at the same room temperature (22.5°C), the result are exactly the same: 200.0118kOhms.
- I don't have a stable enough AC source, so I can't answer you on this part.
- I did another test too: simply choosing the "FREQ" measurement with nothing connected to the inputs: it still displays 50Hz as it did before, so I guess there are not too much radiated EMI.

The comparison tests I did don't show any problem, but no, I just can't assure that the LED display doesn't affect measurements. I just did what I though good to maximise my chances of success, and it seems to be OK when comparing before/after, but assuring that would need costly measurement equipments that I don't have.

Hope this answers part of your question. If you think there are some designs flaw, or if you know better ways of designing LED display, please say so. I have some Enertec 7045 here too with the schematics, I will take a look at their design.

P.S. I will be without internet during 1 week, so don't expect too quick answer.

[tggzzz]

Have you done any tests to ensure and assure that changes in the current powering the LEDs doesn't affect the measurements?

[...]
So I am quite confident that the power consumption increase will not affect at all the measurements. HP took a large security margin for the voltages, and after several hours of work, the transformer keeps quite cool.
In case of doubt, I could still mount the red version of the Displays, which is low power / high brightness, and thus reduce the power consumption by a factor 2 I think.

You missed a key word in my question, even though I used italics to emphasise it: changes.

Your response above is about the mean power dissipation. Your calculations and measurements may well be true, but are only vaguely relevant and are not definitive.

No, I didn't miss the word in your question Simply, as you must have noticed, English is not my native language and I have understood your sentence differently: I though you were talking about "changes in the current powering the LEDs" compared to the current powering the LCD, and I have answered to that question. In fact you were talking about current variations during the LEDs commutation. Sorry, It must be perfectly clear for the natives, but it was unclear for me.

Those are reasonable points. My apologies for being unnecessarily belligerent.

The display is obviously multiplexed, otherwise It would need more than 200 pins to drive the LEDs and 200 wire passing from one board to the other in my design! Yes, the worst case is when I switch from one digit with many segments lit to a digit completely OFF (like when there is a space in the text displayed).

When designing the power supply, the perturbations were one of my concern: I have added some external filtering (coil and capacitors) at the input of the Murata DC/DC converter, in order to reduce EMI (there are some spectral analysis given by Murata that guarantee the max value of the EMI when using these external components).

I guess your overall question is about EMI? Conducted EMI or radiated EMI?

Either or both From a users perspective it wouldn't matter since either would be bad.

As for the conducted EMI, I am not too worried: the LED commutation is low frequency and this is typically well filtered by the capacitors and the regulators of the DMM. Moreover, a power filter doesn't eliminate these low frequencies either, so they do cross the transformer, as well as my board may generate them, and the DMM is designed to work with that.
I was a bit more worried about the higher frequency EMI (included those generated by the DC-DC), hence the coil, and hence my connection on the "Digital" winding of the transformer and not the "analog" one (I don't know if it is useful, but it won't hurt, moreover than HF generally doesn't cross well a 50Hz power transformer).
And I was also worried about radiated EMI, and for this part, I have no real clues, nor any device to measure them.

Any such measurement is difficult - and unreliable in the sense that it is difficult to reproduce and easy to measure a different value.

As for your proposed "problematic" tests:
- I did some measurements near 0 with a µV DC source (see the firsts photos), and results are really good: there is absolutely no visible change between the LCD version and the LED version.
- Today I did some tests with a resistor, as you advised: mounted the LCD display back, used a high stability 200k resistor, waited 3 hours for the equipment and the resistor to be perfectly warmed, mounted back the LED display, waited a bit more and compared the results: at the same room temperature (22.5°C), the result are exactly the same: 200.0118kOhms.

Did you try measuring the DC voltage across the (relatively high) resistor, which should, of course, be zero. The AC voltage across the resistor should be the thermal Johnson noise in the resistor. If not then it is possible that interference is causing problems - of which one interference source might be from the LED commutation currents.

- I don't have a stable enough AC source, so I can't answer you on this part.
- I did another test too: simply choosing the "FREQ" measurement with nothing connected to the inputs: it still displays 50Hz as it did before, so I guess there are not too much radiated EMI.

I think it would be unlikely that the meter could measure a frequency of switching noise.

The comparison tests I did don't show any problem, but no, I just can't assure that the LED display doesn't affect measurements. I just did what I though good to maximise my chances of success, and it seems to be OK when comparing before/after, but assuring that would need costly measurement equipments that I don't have.

Accepted, but if you lack expensive equipment then you have to think and to use skill and imagination - which is usually beneficial

Hope this answers part of your question. If you think there are some designs flaw, or if you know better ways of designing LED display, please say so. I have some Enertec 7045 here too with the schematics, I will take a look at their design.

P.S. I will be without internet during 1 week, so don't expect too quick answer.

No answer is necessary!

If you can devise measurements that would be most affected by interference, and can compare the measurements with an unmodified meter, and show there is no difference, then you have gone a long way to demonstrating interference isn't a problem.

[coromonadalix]

wow   just wow    i wish i could do some reverse protocol etc ... ,  great work

[Specmaster]

Really is a great job you did there and I agree with the other lads on here, you could set up a small manufacturing process for these and sell them as complete replacement displays.

Perhaps starting up a small company designing replacement displays for other similar meters now you know how to do it. This could be your chance to go into business developing these kits and offering them as kits and or complete pre-built units with all the instructions on the procedure for fitting the replacement displays? 

[Keicar]

I'm in awe - that's gorgeous!

Cheers,

Karl.

[Echo88]

https://hackaday.com/2017/11/15/leds-give-hp-3457a-ddms-lcd-display-the-boot/ 

[Swake]

Félicitation, très belle réalisation! 

There might be a market for these kinds of mods. Lots of HP/Agilent equipment are build with very similar LCD displays. Would not be surprised if all of these use the same protocol. Also those with the fading VFD displays.
As you have access to a CNC machine you might consider milling your own segmented digits out of some black plexiglass. Very similar as what is done in cheap LED clocks. They solder the leds directly to the PCB board with the milled-out plexy hot-glued on top. This way you can have any design you want and choose from many more LEDs to suit your color and power consumption needs.