Products > Test Equipment

Replacing OLED screen on an Agilent U1253A Multimeter

<< < (46/69) > >>

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:

--- Quote from: gmarsh on February 08, 2021, 06:32:24 pm ---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.

--- End quote ---

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...  :o

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod