Fluke 8846A repair shenanigans.

[Johnny10]

Tin, you changed Outguard FPGA correct?

[TiN]

Yes.

[Johnny10]

On my unit the Inguard is not responding.

I have a functioning Outguard.
But no readings on display...
Removing the shields from the phototransistors reveals  "XC6115 series  high-precision, low current consumption voltage detectors with watchdog. The series consist of a reference voltage source, delay circuit, comparator and output driver".
Which is what triggers my error after a few seconds delay. I can see the pattern on the oscilloscope.

Outguard waiting for a signal, then resetting after time delay, coinciding with the error message appearing on the display.

[TiN]

Johnny10, slow down, or you will get me wasting time on this 8846 again. 

On serious note - good find.  I think reversing schematics for isolation interface would be rather easy.

[picburner]

Removing the shields from the phototransistors reveals  "XC6115 series  high-precision, low current consumption voltage detectors with watchdog.

To me U54 & U63 look like AD8601ARTZ op-amp.
In fact a phototransistor pin is connected to the -in input of the op-amp and this makes sense.
What would it do to connect to the wd terminal of an XC6115??

[Johnny10]

I am certainly not an expert on SMD markings since I have been wrong before.

SMD part marked AAA 5 pins SOT-25.

I used  SMD-Codes from 2007

[picburner]

The smd codes are difficult to interpret and often generate confusion because the same code can correspond to many different devices.
I don't have this DMM and then I can't make measurements but to amplify the signal of a phototransistor I would use a hi-speed op-amp not a
voltage detector with watchdog

[Miti]

Hi Tin,

My 8845A had a dying IR LED but it popped an error, I don't remember which error. I replaced it with a regular IR LED from an old TV remote and it works well for about 2 years now. Spray cold those LEDs, replace them. It's worth a try.

[TiN]

Hi Tin,
My 8845A had a dying IR LED but it popped an error..

IR led was second thing I swapped (first one was check and confirmed good, also recap all power supply circuits). Didn't help.

[Johnny10]

OK, More testing validates picburner

Pin 1 Signal Out
Pin 4 Input
Pin 5 V+  3.43V

on the AAA 5 pin IC  AD8601ARTZ

[massivephoton]

LAN port however does not work, cannot connect to it either in static IP mode, or DHCP. DHCP does not get any IP address from network. Perhaps LAN Phy is killed?

Too bad ethernet didn't work even while the unit worked. Telnet on port 23 asks for login/psw, which is disclosed in plaintext in the available 2.x firmware files. Once inside, there's uCLinux basic commands, ftp server, some scripts for comm configuration as well as default settings stored.

Symptoms:
(...)
5.All connect to LAN, and activity pulses can be seen at two second intervals. One time I saw one of them connect to my Asus router and get an IP address. I was unable to get it to repeat this though...

Did you ever manage to get an IP again? You could try to login on port 23 and inspect. Also, there are chances that the firmware update (or downgrade?) tool works from this point.

My unit runs the latest firmware listed in Xdevs.com, and I'm having a minor issue that if I break the telnet connection sometimes it no longer accepts SCPI connections on port 3490, but keeps alive at port 23. I know I shoudn't be using wi-fi with instruments, but hey, it's pretty good when it works. Already tried to reboot each network devices in the path between the notebook and the DMM, but didn't work. I'd like to telnet connect on port 23 and restart the telnet process to regain SCPI control on port 3490, but when I kill the only telnetd process listed on `ps aux` command, the connection on port 23 is interrupted. I can reconnect on port 23, but  it doesn't restore telnet connection on port 3490. Also, if I run a reboot command, it restarts the outguard processor, the DMM keeps measuring and updating the display, but still no connection on telnet on port 3490.
I can try to replicate tests or copy files from the instrument if needed. You may try to convince me, but I just don't feel inclined to open the unit, since it's still under warranty. Sorry, I couldn't resist and turned it on instead of tearing it apart. :-(

Hope your meters return from the dead soon!
Happy halloween!

[SilverSolder]

What is the purpose of the aluminum box over the input connections on the 8508A in the picture?  In later pictures, it (or a clone) appears on the calibrator as well.

[massivephoton]

Had a little more time to play on the weekend.

All power on my 8846 is fine, nothing cooking or shorted. It is not relevant to the "init screen hang" issue, because meter should boot even with inguard section completely unpowered (removed transformer cable from inguard).

Probably, but I wouldn't be so sure on v1 firmware.

Jwalling, yes, there is no life on optos from outguard to inguard. There is slow square wave on pair from inguard to outguard (perhaps just heartbeat signal).

The measurement app is ca. 1MB in size, /usr/bin/zfp. Killing this process halts measurements, freezing the display. I'd expect the opto communication to halt too. Zfp app is called at the end of /etc/rc script:

Code: [Select]

#!/bin/sh
#
# system startup.

# expand and mount the ramdisk
#/bin/dd if=/usr/bin/ramfs.img of=/dev/ram0
/bin/expand /ramfs.img /dev/ram0
/bin/mount -t ext2 /dev/ram0 /tmp -n
/bin/expand /ramfs.img /dev/ram1
/bin/mount -t ext2 /dev/ram1 /var -n

# mount proc file system
/bin/mount -t proc proc /proc -n

# mount sysfs
/bin/mount -t sysfs sysfs /sys -n

# mount the jffs2 R/W file system
# /bin/mount -t jffs2 /dev/mtdblock2 /usr -n

# mount the romfs RO (SAFE) partition
/bin/mount -t romfs /dev/mtdblock4 /safe -n

# Configure the GPIB interface
/usr/bin/gpib_config

# manually assign ip address (uncomment and edit as appropriate)
# note: first ifattach (no args) sets local loopback
/bin/ifattach

# Set the MAC and IP address
/usr/bin/setmac
/usr/bin/ipenet

# start up the internet superserver
/bin/inetd &

# run 2 sec delay
/usr/bin/me_sleep

#If the application was installed using a windows
#machine the files may not be executable so change
#the permissions just-in-case
chmod 777 /usr/bin/zfp

#Start up the application
/bin/sh -c /usr/bin/zfp &

# that's it... success
exit 0


I have tried so far things like:
* Replace RJ45 magnetics and Eth phy (suspected dead LAN input, that get NIOS CPU in FPGA stuck waiting) = no help.

It's also possible that eth0 initialization script didn't complete. The firmware update manual mentions the ip 169.254.115.202. Also, setenet script on /usr/bin further mentions the following ip/mac tables:

Code: [Select]

mac_address='00:80:40:00:20:AE'
ip_address='129.196.136.131'

case $1 in
    halfdome) mac_address='00:80:40:00:20:A6' ; ip_address='129.196.136.112' ;;
    mlandich) mac_address='00:80:40:00:20:A7' ; ip_address='129.196.136.116' ;;
    dbartley) mac_address='00:80:40:00:20:A8' ; ip_address='129.196.136.117' ;;
    zippy)    mac_address='00:80:40:00:20:A9' ; ip_address='129.196.136.119' ;;
    rdz)      mac_address='00:80:40:00:20:AA' ; ip_address='129.196.136.122' ;;
    denny)    mac_address='00:80:40:00:20:AB' ; ip_address='129.196.136.125' ;;
    jwitters) mac_address='00:80:40:00:20:AC' ; ip_address='129.196.136.129' ;;
    britz)    mac_address='00:80:40:00:20:AD' ; ip_address='129.196.136.130' ;;
    test1)    mac_address='00:80:40:00:20:AE' ; ip_address='129.196.136.131' ;;
    test2)    mac_address='00:80:40:00:20:AF' ; ip_address='129.196.136.200' ;;
esac

Note how close the mac address found here:

00:80:40:00:56:A9 [on the screenshot]

On my unit the mac address starts with 00:C0:, which might suggest that something is wrong on eth0 initialization. I'd suggest to ping and/or telnet these ips using an auto mdi-x adapter or crossover cable configured with an ip on the same subnet.

Some services to play with:

Code: [Select]

ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
uptime 24/tcp
http 80/tcp
I think uptime can be useful to an automation task know that the unit is already warm-up. Telnet connection return an increasing number, not sure, but maybe tens of minutes, and immediately closes connection.

* Replaced outguard SDRAM = no help
* Replaced outguard FPGA (bought new Cyclone from Digikey) = no help
* Freezespray bunch of stuff around  = no help anymore. Originally it helped and made meter work randomly for shortime.

Any chance that the flash memory got its last breath from a cold breeze?

When it was working, it took about 10-20 seconds to boot from init screen, and you can hear relay click after 2-3 sec from power on. Now it however does not click anything, just sitting silly.

When zfp app is launched it adjusts measurements, and the relays fill their mag lungs to cry hello world!

Supervisor chip that drive reset to NIOS FPGA is ok, reset is correctly toggled high on power on. There is some life to SDRAM data pins, so it's doing something.
I tried to probe RS232 chip in hope to find debug CPU console output, but there was no signals.

I didn't see any indicia of console on tty on the files. I didn't even connect using serial yet, but I'd try 115200 baud, at least on later firmwares, since inittab file on /etc shows:

Code: [Select]

# inittab for uClinux
# Format:
# ttyline:termcap-entry:getty-command
  ttyS0:vt100:/bin/agetty 115200 ttyS0

# ttyS1:vt100:/bin/agetty 9600 ttyS1
# ttyS2:vt100:/bin/agetty 9600 ttyS2

# ttyJ0:vt100:/bin/agetty 115200 ttyJ0

Hope there's something like uboot halt on any key here...

So far best shot would be to trace JTAG to the debug connector, and connect USB Blaster, to try if anything can be done from that side (perhaps read back NOR flash).

I agree, but only if ethernet really not initialized, and also if we don't find any boot console at tty.

But it's a long shot, as we don't have binary image from the FW flash. 8846A update tool have only bits and pieces, but not the full dump binary.

I must say that the firmware seems to include the full firmware, in pieces, it's true, but integer pieces. After extracting recursively the firmware, we get a folder 'instruments_e6f0b851bdee_zg_ia_sf/884X/bin' holding the firmwares, with the following files: beta_noinfo_reversed.rbf,
busybox, f884x_versions, flashcp, flash_eraseall, jffs2.bin, me_sleep, u69_nios.flash, vmlinux.bin, vmlinuxRev14ptf.bin, vmlinuxRev17ptf.bin, zfp, zfp_837;
and the recipes under /884X/procedures show exactly where each image should go.

One last bit, restarting zfp app restores my measurement telnet connection at port 3490. 

Regards.

[TiN]

Cudos for the investigations, that could be very helpful. Perhaps its possible to build "binary image" that can be flashed to new flash chip to try? My meter have 1.x few so there is no "source" update part for this version. But I'd love to try that and even buy programmer that can do TSSOP56 chips.

[massivephoton]

Cudos for the investigations, that could be very helpful. Perhaps its possible to build "binary image" that can be flashed to new flash chip to try? My meter have 1.x few so there is no "source" update part for this version. But I'd love to try that and even buy programmer that can do TSSOP56 chips.

I think it's possible to build a binary. I'm not sure if mtdblock[0-4] really are partitions of the same flash chip. If so, we can find the offsets and create the image. Also, I can try to copy the entire 2.37 flash from my unit to a single file on a usb pendrive. Just don't know how to do it yet.

Also, the firmware 2.10.882.24 already includes full images to upgrade from 1.x:

Code: [Select]

09/29/06-16:59,null    [OG SW]
10/06/06-22:22,null    [IG SW]
09/26/06-15:16,null    [OG HW]
09/26/06-15:23,null    [IG HW]
Sep 27 2006,null       [OS Build]
r1,proc_649_130        [Rel. 1 --> Rel. 7: upgrade using proc_649_130]
04/02/07-08:10,null
10/06/06-22:22,null
09/26/06-15:16,null
09/26/06-15:23,null
Sep 27 2006,null
r2,proc_688_130        [Rel.2 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
09/14/07-21:54,null
08/20/07-20:19,null
08/21/07-16:30,null
Aug 23 2007,null
r3,proc_837_200_082307 [Rel.3 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
09/14/07-21:54,null
08/20/07-20:19,null
08/21/07-16:30,null
Oct 25 2007,null
r4,proc_837_200_102507 [Rel.4 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
12/12/07-20:15,null
08/20/07-20:19,null
08/21/07-16:30,null
Nov 30 2007,null
r5,proc_837_201        [Rel.5 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
02/15/08-18:44,null
08/20/07-20:19,null
08/21/07-16:30,null
Nov 30 2007,null
r6,proc_837_210        [Rel.6 --> Rel.7: upgrade using proc_649_130]
02/14/08-08:54,null
02/15/08-18:44,null
08/20/07-20:19,null
08/21/07-16:30,null
Nov 30 2007,null
r7,proc_882_210        [Rel.7 --> Rel.7: upgrade using proc_649_130]

For instance, the code for procedure proc_649_130 is:

Code: [Select]

connect,null
wiz,syst:rem
step,1
tcomm,rm /usr/bin/vmlinux.bin
tcomm,rm /usr/bin/u69_nios.flash
tcomm,rm /usr/bin/vmlinuxRev14ptf.bin
tcomm,rm /usr/bin/beta_noinfo_reversed.rbf
tcomm,rm /bin/busybox
fcwd,/usr/
fget,calparams
fcwd,/bin/
fput,busybox
fcwd,/usr/bin/
fput,vmlinuxRev14ptf.bin
fput,flashcp
fput,flash_eraseall
fput,zfp
fput,me_sleep
tcomm,chmod 777 /usr/bin/flashcp
tcomm,chmod 777 /usr/bin/flash_eraseall
tcomm,chmod 777 /usr/bin/me_sleep
tcomm,rm /usr/bin/config/*
tcomm,mv /usr/bin/vmlinuxRev14ptf.bin /usr/bin/vmlinux.bin
tcomm,/usr/bin/flashcp -v /usr/bin/vmlinux.bin /dev/mtd1
tcomm,rm /usr/bin/vmlinux.bin
disconnect,null
reboot_simple,null
connect,null
wiz,syst:rem
step,2
fcwd,/usr/bin/
fput,vmlinux.bin
tcomm,/usr/bin/flashcp -v /usr/bin/vmlinux.bin /dev/mtd2
tcomm,rm /usr/bin/vmlinux.bin
fput,beta_noinfo_reversed.rbf
tcomm,/usr/bin/flashcp -v /usr/bin/beta_noinfo_reversed.rbf /dev/mtd0
disconnect,null
reboot_simple,null
connect,null
wiz,syst:rem
step,3
tcomm,/usr/bin/flash_eraseall -j /dev/mtd3
tcomm,mkdir /mnt/jffs2_blk3
tcomm,chmod 777 /mnt/jffs2_blk3
tcomm,/bin/mount -t jffs2 /dev/mtdblock3 /mnt/jffs2_blk3 -n
tcomm,rm -Rf /mnt/jffs2_blk3/*
tcomm,dd if=/dev/mtd1 of=/mnt/jffs2_blk3/jffs2.bin
tcomm,flashcp -v /mnt/jffs2_blk3/jffs2.bin /dev/mtd1
disconnect,null
reboot_simple,null
connect,null
wiz,syst:rem
step,4
fcwd,/usr/bin/
fput,u69_nios.flash
restorecal,null
wiz,syst:rem
step,5
wiz,ig_download "/usr/bin/u69_nios.flash"
message,"UPDATE DONE"
disconnect,null
end,end

Procedure proc_882_210 does nothing, since the installed firmware is already release 7.

[Nifty]

So many brave (or naive) people

[Johnny10]

You can buy a working used one on ebay for 550 dollars.  Oops, I take that back, all 12 are sold.

Tektronix DMM4050 6.5 Digit Multimeter
Item Information
Condition:
Used
Quantity:
0 available 12 sold / See feedback
Price:
US $550.00
$47 for 12 months with PayPal Credit
opens a installment calculator layer
*

[BU508A]

I've found the datasheets for the two display versions:

Noritake Itron VFD Module, 256x64 Dot Graphic

Type 1: GU256x64D-7000
Type 2: GU256x64D-7000BX

Differences I've found so far:

- BX is newer (2016 vs. 2006)
- block diagram
- BX has a higher power consumption / higher current consumption
- to be continued ...


TME has five tpye 1 displays ready for delivery:
https://www.tme.eu/de/details/gu256x64d-7000/vfd-displays/noritake-itron/

[dew]

I'm new to this, but AFAIK:
Fluke is using it's own controller for VFD display in 884XA meters. VFD part is MN25664J. It is an older model with 5V supply and logic.
Same VFDs are used in GU256X64D-3900 or GU256X64D-3900B displays
Noritake (manufacturer?)
Mouser
DigiKey (3900), DigiKey (3900B)
These GU[...] displays come mounted on their own controller with UART interface that you would not need for the Fluke. Very hard to take VFD off the controller. Glued with double side tape across the whole surface.

GU256X64D-7000_tme and GU256X64D-7000BX_tme both seem to use MN25664M VFD module (glass part). M version is newer, uses 3.3V and a different interface.

[ASEMechanic]

I'm new to this, but AFAIK:

Fluke is using it's own controller for VFD display in 884XA meters. VFD part is MN25664J. It is an older model with 5V supply and logic.

Same VFDs are used in GU256X64D-3900 or GU256X64D-3900B displays

...

These GU256X64 displays come mounted on their own controller with UART interface that you would not need for the Fluke. Very hard to take VFD off the controller. Glued with double side tape across the whole surface.

Okay, I'm going to revisit this very old thread because it actually helped me out this week. And this will be a long post, so grab your popcorn.

I bought a Fluke 8846A off eBay fairly cheap because it had an aging display with pretty bad burn-in. Still perfectly functional and recently calibrated, so I thought I'd give it a shot. Unit arrived, plugged it in, and fired it up. As expected, the display was a bit dim and the burn-in was noticeable, but otherwise it was perfectly functional. Certainly not disappointed as I knew what I was getting.

Aaaaaaand then I began the process of trying to locate a replacement display. Going through normal channels yielded zip. No Fluke replacement parts anywhere. Well, it's an older discontinued device so I get it. Started scouring forums and came across the XDevs thread regarding a Fluke 8846A teardown. https://xdevs.com/fix/f8846a/ (This is, incidentally, the exact same article and unit found at the start of this very thread posted by TiN, although I hadn't seen this thread yet.) Anyway, it thankfully indicated the part number of the VFD and gave me something else to work with.

2 days of scrounging, parts sourcing, and even looking for dead units to salvage a display from again yielded nothing. I was about to just give up and resign myself to a dim display, at least until I could procure a reasonable working one later on down the road, when I came across this very thread. The post above gave me hope, although I had to be realistic that it was from almost 5 years ago and that I may not be able to find anything available.

Leave it to Mouser... They actually have 58 (now 57 ) of the GU256X64D-3900B displays in stock. Yes, they're pricey at $270.48, but they absolutely do have the MN25664J VFD display on them. The same display that is in the 884xA meters. I ordered one and hoped for the best. In the meantime, I went ahead and opened the unit up to remove the display and controller from the front panel. I wasn't going to touch it until I could verify that I could remove the new display from the controller, but at least it was just that much less to do when it arrived.

Got my display in today (Friday) at about 11:00 AM. Verified that the pinout all looked correct and then went to work. First thing was to separate the adhesive. This was actually easier than I had anticipated. I'm not sure about the display Dew had observed, but this one had 2 thinner strips of double sided tape on the edges instead of one wide sheet. A little Goof-Off and a thin razor knife made quick work of separating the controller board from the VFD, leaving only the terminals. 21 terminals to be exact. Using a couple small pieces of PCB for leverage between the VFD and controller board, I applied a little pressure and used the hot air from my solder rework station to slowly draw the terminals out. This took about 5 minutes as I didn't want to force anything and possibly break a pin or crack the glass of the VFD.

Once I got it all apart, I verified that the part number was identical (it was a match!), and then I then went to work on taking the old display off of the Fluke adapter board. This was considerably easier as I just cut the old one off and removed the terminal pieces one at a time. A little solder wick, a quick wash, and the board was ready to go. I inserted the new VFD into the adapter, spot soldered the end terminals, and then I placed the assembly into the meter panel so that I could get the offset correct with no gaps. With the adapter board screwed back in place, I finished soldering up the terminals. After a quick check to make sure everything looked good, I then reassembled the meter.

Fired the unit up and it worked like a champ! Display is crisp and clear. I ran the display test and that completed perfectly. This whole process went about as well as could have been expected (or hoped) and only took about 2 hours from start to finish.

If anyone is in need of a VFD for the Fluke 884xA, I can tell you that this is about the only option available. If you have a solder rework station and have no qualms about sacrificing the GU256X64 controller, then this is a sure way to get a new display. It works well and it isn't nearly as difficult to accomplish as it appears.

Mouser still has these:
https://www.mouser.com/ProductDetail/Noritake/GU256X64D-3900B

Noritake also still lists these on their website:
https://noritake-vfd.com/gu256x64d-3900b.aspx

I hope this post helps someone the same way that the previous post helped me.

Good luck!!

The Noritake GU256X64D-3900B display disassembled

The Fluke 8846A display and adapter board

The Fluke 8846A with new VFD installed

[bdunham7]

Well, it's an older discontinued device so I get it.

Good work!  Just to be clear, was the display assembly (p/n 2454039) unavailable from Fluke directly or was it just too expensive?  The meter is discontinued, but just recently and I would expect it to still be supported.

[ASEMechanic]

I did find that part in the manual, but there was nothing I could find anywhere on the internet pertaining to the front panel P/N 2454039. Even the VFD part MN25664J itself was severely limited in information. None of the Fluke parts or repair facilities I contacted had anything available.

I think the problem is that while Noritake still manufactures the MN25664J VFD, they no longer sell it individually. This severely limits availability of the part. The only way you can get them is attached to one of their controllers. I do have an e-mail into Noritake VFD to see if there's any way to be able to acquire the VFD individually. We'll see where that goes.

At least for now, there is a workable solution. My meter has a brandy-new display and I'm a happy camper. 

[gamalot]

Tonight is Chinese New Year's Eve, I gave myself a gift, upgraded my Tektronix DMM4040 to Fluke 8846.

Just about half an hour ago, I happened to see this topic, and then saw that someone had uploaded firmware to xDevs.com, so I decided to try my luck.

Now I am very happy, as you can see in the pictures it can correctly measure capacitance and temperature, those are not features of DMM4040 nor 8845.

Thank you so much everyone! 

[ASEMechanic]

Wow! That's pretty cool. I didn't even realize that you could upgrade the meter by just changing the firmware. I guess it makes sense, though. All the hardware is there, just need the right software.

Yeah, I downloaded everything xDevs had on their site for the Fluke 884x meters. From the address where you downloaded the firmware, just enter the directory address without the filename. The directories allow indexing so you can see everything in there. Then it's just Right-Click and Save As. You won't be disappointed!

Since 8845s go for less than the 8846 (some as low as $700), I may try to pick some up and upgrade the firmware in them.

Good luck and enjoy your new meter.

[analogRF]

dmm4040 does have the USB while Fluke 8845A does not so in that regard dmm4040 is closer to 8846A/dmm4050

If I am not mistaken the boards on 8845A and 8846A are not identical. Well, they are but there are a couple of missing chips on 8845A
which might be the USB controller. I might be totally wrong...

I have not seen the inside of DMM40xx....