Replacing OLED screen on an Agilent U1253A Multimeter

[eb4eqa]

Great! Can't wait to see it working! Thx!

Roberto

[norb]

Having successfully fixed my U1253B OLED display, which went dim a few weeks ago, i thought i´d share my experience as well:

First, I thought wtf, googled, and found out about the OLED-problem. I decided to send the meter to the vendor, maybe there was some kind of warranty or good will, and got a service offer (see below). Interesting business model.

As i didnt´t want to spend hours making pcbs and stuff, i followed the procedure from kostelectronics switzerland:


This is the replacement display at taobao in chinese, it´s offered for U1273 and U1253:
https://item.taobao.com/item.htm?spm=a230r.1.14.101.7c43260eXXQFvS&id=591402268582&ns=1&abbucket=19#detail

Luckily there is an english taoabo site, tbfocus.com, and this is the display there:
https://shop.tbfocus.com/item.php?id=591402268582#4133487996875

I ordered the display via a tabao sales agent and received the diplay about 10 days later. It was a straight swap, just cut 7 pins which were protruding from the left side of the display pcb.
The display lower end is a bit longer, I therefor put countersunk M2 screws, which fit underneath the protruding display glass plate. Also I put insulation on und under the pcb where the two upper srews are because there are pcb tracks very close to the bores.

Costs / Euro:
Display 59,-
Taobao agent: 15,-
Shipping: 24,-

Regarding the repair procedure by Markus in his Coneheads.de blog:
http://new.mash.webclient6.de/index.php/bauen/sonstiges/47-agilentu1252

he didn´t mention where he got the display from, which i suppose is this:
https://lcdstore.de/OLED-Modul-128x64-Punkte-monochrom

It is obsolete, but there is a replacement, for which you need an additional pcb:
https://lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/CFAL12864J-Y
https://lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/Command-Switch-2

So whichever way you choose to replace your display, maybe you find some help here, as i did on this great forum.

Thanks to all.

Edit: posting images here is a bit tricky ...

[kitsune-denshi]

Seeing that there is still some interest in repairing these meters, I thought I'd share the results of my take at tackling the display issue.

First of all, thank you everyone who has contributed here so far and especially for posting images of the various fixes, that really motivated me to have a go.

Initially, I had a thought very similar to gmarsh, in that all that would be needed to get rid of of the one-column shift would be to intercept the address data and subtract one from it. So I went about that and made a little board with a small FPGA (Lattice ICE5LP1K) to do that. However, when starting to dig, it became apparent that there were a lot more things that needed fixing than "just" the first column, mostly do do with the fact that the "original" display has 132 columns of display memory (instead of 128 on the SSD1309) and the multimeter assumes that only a portion if that is visible and relies on the data to wrap around after 132 columns and so on.

Anyway, after some digging (I think) I finally managed to work around all the oddities and now have a SSD1309 display working without any pixel-weirdness in my U1273A.

I will do a proper write-up (including schematics, layout and a slightly cleaned-up version of the Verilog) in the next few days and share it here if people are interested. But for now I just wanted to make a quick post to share the end result.

[gmarsh]

That looks great!

You've got me worried now I captured a good bit of the data stream from the meter and as far as I can tell, the meter doesn't seem to take advantage of wrapping.

Like when it's clearing the screen on startup, it writes 0xB0 0x02 0x10, then writes 128 data bytes to clear the first page, then repeats on the next page. Once the meter is up and running, it seems to write randomly to the screen in small bursts, overwriting individual digits or whatever. I haven't seen it write beyond the edge of the screen but I don't really have a good way to check for that. If it does write off the edge of the screen, I hope I can work around it in an 5M80EZ64 because that's what I've got coming from Mouser for the first round of boards...

I've attached the design files I've got so far. I'll hold off posting the actual Eagle files or gerbers until I'm 100% sure the design works, in case a Chinese factory decides to start shitting out something that doesn't work that has my name on it.

[kitsune-denshi]

That looks great!

You've got me worried now I captured a good bit of the data stream from the meter and as far as I can tell, the meter doesn't seem to take advantage of wrapping.

Thank you for you kind comments and for sharing the schematics. Nice to see we had basically exactly the same idea - clocking the thing off the WR line. I figured that would be the way to get the lowest power consumption. Here is also my schematic for reference, but the Verilog will have to wait until it's had a tidy-up. 

I don't think you need to be too worried, but just for reference these are the major snags that I picked up on:

• You already wrote that yourself, but there are some multi-byte commands, where the second byte looks like a standalone address command. So it's keeping track of the preceding commands to not incorrectly decrement something when it isn't actually an address.
• The minus sign (in front of the measured value) is actually drawn as 11 pixels starting from address 0 (when in actual fact the first two columns aren't supposed to be displayed). However, with the decrement-address approach (which works for all other content), that means the start of the minus signs will wrap around and start drawing at the right-hand edge of the screen. My approach to that was to detect the commands for address 00, and then instead of the next two data bytes (which are supposed to be invisible anyway), output the two address commands again and only then let the subsequent data through - that way the two "invisible" columns stay hidden and it draws correctly from address 00.
• When a new screen is loaded, the multimeter draws a "background" (some blocks of active pixels) to the bottom 8 rows. I think they are intended to be overwritten with e.g. the range indicator and things like that. However, for some bizarre reason it starts drawing that at address 241, and it then writes the full 132 bytes. However, because the memory is only 128 columns in the SSD1309, when things wrap around the active pixels end up in places where they are not being overwritten later with the correct indicators. The workaround there was to catch the specific command sequence for drawing at that one particular address (B0 01 1F), and then output 00s instead of the data.

However, especially with the last one I'm not sure how universal that is, as I didn't see those artifacts on any of the images that others have posted (conversely, the last row was always ok on mine, whereas it seemed garbled on a lot of photos that people posted). My multimeter was quite an early model, so it may well be that newer firmware versions do behave slightly differently from what I'm describing.

As for resource utilisation, it's actually not that bad still. In the RTL it's only 6 flip-flops (1 for the carry from the subtraction, 1 for the multi-byte commands, and 2 each for the dealing with the minus sign and last-8-rows artifacts), but it does say it's using 54 LUTs... 

[gmarsh]

Thanks for the hints and figuring this all out. Everything you've described there seems pretty CPLD-able.

Negative edge of /WR seemed to be the only good way to clock the thing, yeah. Thankfully the meter is nice enough to make the data lines and DC signal valid for both the falling and rising edges of /WR, and the SSD1309 clocks incoming data on the rising edge of /WR. Between that and them writing the column address LSB-first, you'd think the folks at Agilent were planning for this hack.

Thanks for sharing your design too. Wow, that Lattice part is a beast... lots of block RAM and DSP blocks, PLL block, excellent quiescent current consumption, and $5 CAD in singles from Digikey. Gonna have to keep that one in my back pocket.

[norb]

Regarding different display controllers, i found this german document on lcdstore.de with details about differences between 1303, 1305 and 1309.

If anybody is interested, i could translate it into english.

[fbpicsous]

I ordered the display via a tabao sales agent and received the diplay about 10 days later.
Costs / Euro:
Display 59,-
Taobao agent: 15,-
Shipping: 24,-
It is obsolete, but there is a replacement, for which you need an additional pcb:
https://lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/CFAL12864J-Y
https://lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/Command-Switch-2

LCDstore.de sells an agilent U1253 replacement... but only in Germany 
https://lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/LC-OL12864-09-YO-AG

Keysight quote was ~100-150€ without taxes (2019), but now, they doesn't sell spare part (not available for direct sale) 
https://www.keysight.com/my/partDetail/U1253-66007

Thanks for sharing your taobao experience.

[norb]

LCDstore.de sells an agilent U1253 replacement... but only in Germany 
https://lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/LC-OL12864-09-YO-AG

Keysight quote was ~100-150€ without taxes (2019), but now, they doesn't sell spare part (not available for direct sale) 
https://www.keysight.com/my/partDetail/U1253-66007

Thanks for sharing your taobao experience.

If anybody wants to buy this display from Germany, i would offer my help.
Just throw a can of beer over the fence .. :-)

[gmarsh]

Boards are in!

[Toshi]

It is displayed correctly using SSD1305.

[Toshi]

Requires conversion PCB.

[DKelectronics]

Any news - does it look like it is working?

[gmarsh]

Boards are built and mostly tested - 1.8V regulator works, 13V regulator works, but my crappy Aliexpress USB Blaster clone doesn't work at all.

Got a Terasic one ordered which I'm hopefully getting next week.

[gmarsh]

Update: GAAAAAAAH

I got the top row and bottom row of the 20 pin connector switched.

I can probably make it work anyway, with a bunch of trace cuts and magnet wire. It'll be ugly but it'll be hidden within the meter at least

[voltsandjolts]

my crappy Aliexpress USB Blaster clone doesn't work at all.

Maybe your having the same problem I had with driver install on Win10. I just got a cryptic error message about a bad driver.
Turns out that Win10 by default now requires signed drivers and Intel/Altera are too lazy to sign theirs.
Of course the error message doesn't explain that at all.
You can perhaps disable signed driver enforcement or use an older signed driver.
See this thread:
https://community.intel.com/t5/Programmable-Devices/Windows-10-driver-support-for-USB-Blaster/td-p/55323

[gmarsh]

Got it working! Had to change the driver in device manager, go through the whole "Have Disk.." dialog, choose a Bus Blaster II JTAG driver from the Quartus install directory and ignore a bunch of warning dialogs.

Modifying the board to fix the connector miswiring looks feasible, since I can reorder them in the FPGA. Gotta pull the pin header to cut a trace between the two VBAT pins, but that's not too bad. Another goof is I didn't 100% nail the mounting hole locations so I have to enlarge the holes a little.

[kitsune-denshi]

Right, so after over a month I finally had the time to sit down and document the display interface board: https://kitsune-denshi.net/projects:display-if

The board replaces the power supply / display mounting board in the U1273A and takes a "normal" SSD1309 display (although with a ZIF connector as opposed to the soldered type used originally). I think this takes care of all the weird and wonderful display artifacts and should give you the "original" display experience.

If you would like to build your own, please have a look at the web site linked above where I have put all the design files. I haven't had any issues building two of the boards, so I'm quite confident that the design is ok to build as-is. Also, you do not need a programmer for the FPGA - it's enough if you can program a serial flash through SPI (e.g. using the ICSP port of a  XGecu TL866II Plus). If you do run into any issues, especially compatibility issues with different multimeter models or firmware versions, please do let me know so maybe I can try and address them.

The BOM component cost is just over €10 (at one-off quantities), so with PCB and display you'll be looking at a total material costs of maybe €35-€40. So depending on how much you value your time / enjoy tinkering with equipment that should just work, you might be better off following the route outlined by e.g. norb above and just get a direct replacement display.

Anyway, I'm really glad that I could finally put the lid back on the multimeter and now continue with the never-ending list of other projects that always take way too long and probably will never get finished.

[rsjsouza]

That was a great procedure. Thank you for sharing.

[eb4eqa]

Great work, thank you for sharing.

Your website is fantastic.

Roberto

[voltsandjolts]

@kitsune

I have a 1272A which is IMHO the best handled DMM for electronics. Avoided the '73 because of the screen issue - but it's no longer an issue!

You NAILED this. Nice low power solution and very well documented

Edit: Is this now the world's first handheld DMM with an FPGA inside?

[The Hooded Foot]

I'd just like to add my thanks to Kitsune.

After my U1273A screen died, I found a video in which someone replaced the screen with the OLED from a Bolymin BL12864G, which was a near drop-in replacement] since it uses the same SSD1303 controller.  Unfortunately, I accidentally bought the BL12864G2, which uses an SPD0301, and has a different pitch flat flex connector.

Kitsune's design will be a great base for me to try and adapt to this different screen.

Once again, my thanks for your hard work.

[kitsune-denshi]

Thank you all for your kind messages, really appreciated!

I'm personally quite keen to see how gmarsh's design works out - it's quite a bit less complex and so should be even easier to build or adapt.

Out of curiosity, does anyone actually know what the actual failure mechanism of the original OLEDs is? To me it felt way too abrupt to be ageing (meter was fine, put it in a box for 4 months, screen was unusably dim when taking it back out), so I wonder if it's actually the controller dying?

[chickenHeadKnob]

Thank you all for your kind messages, really appreciated!

I'm personally quite keen to see how gmarsh's design works out - it's quite a bit less complex and so should be even easier to build or adapt.

Out of curiosity, does anyone actually know what the actual failure mechanism of the original OLEDs is? To me it felt way too abrupt to be ageing (meter was fine, put it in a box for 4 months, screen was unusably dim when taking it back out), so I wonder if it's actually the controller dying?

One  mechanism is moisture getting inside display, causing chemical degradation of oled. controllers can last forever pretty much.

[gmarsh]

Thank you all for your kind messages, really appreciated!

I'm personally quite keen to see how gmarsh's design works out - it's quite a bit less complex and so should be even easier to build or adapt.

Out of curiosity, does anyone actually know what the actual failure mechanism of the original OLEDs is? To me it felt way too abrupt to be ageing (meter was fine, put it in a box for 4 months, screen was unusably dim when taking it back out), so I wonder if it's actually the controller dying?

Current state of 'er: it's madness at work right now so I haven't had a chance to do any further work on the thing.

I can confirm that the SSD1309 panel soldered onto the original board produces a working but backwards display, so I can confirm I haven't fried the meter or display with the reversed connector.

I did a bunch of trace cuts and airwires on one board to get the pinout "sort of right" again, but it doesn't work, even with the CPLD acting in passthrough mode. Not sure what's wrong, but I'm going to modify a 2nd board and hope for the best.