Fluke 8846A Teardown - Page 1
Forum section: electronics / general

author: free_electron
author_rank: Super Contributor
timestamp: July 07, 2012, 07:08:54 pm
content: As some of you know , i took a 8846A and a screwdriver a couple of days ago based on some threads running on the forum here.And here's what i found ...We're all familiar with this one. Big fat graphics display , rubber keypad and a USB host port. Bananajacks on the left. Nothing special.Made in the USA. No internal user serviceable parts ... right... where's me solderin iron... ?The front panel uses a CIG ( Chip in glass ) VFD display from noritake-itron.You can see the massive amount of traces leaving the internal chips in the above image.Data is fed over a parallel bus and all display scan electronics is inside the vacuum glass. 11 filaments are used to emit electrons so the pixels can be turned on.The frontpanel is a simple PCB that only has the USB connector and the pads for the membrane keyboard. nothing really interesting to see.The connection from display board to main board is over a right angled 2mm pitch dual row pin header.The silvery backside of the display reflects the board pattern. There is a metal shield (removed in this picture) over this whole assembly as the high voltages used in the display, and the scanning no doubtedly causes interference in the sensitive electronics of the meter.The main circuitboard holds all electronics:There is a clear split between the inguard and outguard portion of the system. Inguard is a term used to denote the portion of the meter electronics that has direct galvanic contact with the meter inputs and probes. The outguard is the chassis-earth reference electronics. there is a galvanic barrier between them ( clearly seen as the large empty zone runnong diagonally over the bord from top left to bottom right.In the above image anything bottom left of the barrier is the inguard.Here anthing bottom left of the barrier is the outguard.Since we need communication between two worlds we need a bridge that preserves galvanic isolation. Here Fluke has gone the opto way. But, instead of using off the shelf optocouplers, they went all out using discrete IR leds and optotransistors under a shield.The pair on the left left is the channel fron outguard to inguard while the one on the right does inguard to outguard.The entire system has ample supply voltages almost all made using LM317 / LM337's. There is a power line sync circuit just below the yellow wire on the connector. Here they sync onto the mains frequency and trigger on the zero cross. This signal is used by the meter to trigger the actual measurement.NPLC: Near- Power Line Cross. NPLC can also stand for 'Number of Power Line Cycles'. Both are correct and there's two things at play:- For DC measurements the machine will execute the sampling of the input signal at the exact moment of the power line cross. The electrical field emanating from nearby power cables is then minimal. For sensitive measurements this drops the noise floor ( improves Signal/noise).- For AC measurements we integrate the result post-rms converter over multiple power line cycles. Here we count a number of power line cycles and we integrate the measurement to even push noise further away. You can use both mechanisms to gain at least an extra digit of resolution.Before we dig in to the succulent world of the inguard , let's take a look at the outguard area.We find an Altera Cyclone 1C12 fpga. Not exactly a new part since we are at Cyclone IV now ... a big fat SDram sits in the back and booting is done from a Spansion Flash chip on the right. The flash chip holds the FPGA configuration and implements a NIOS softcore running a Linux-based operating system. An ICE + trace connector sits top right. Kind of strange to have this still on the board as the flash chip is clearly pre-programmed before soldering ( the 2662989 and 64916 strings on the spansion chip are lasered AFTER the chip is programmed ) . There's also a little 'oopsie' wire visible around the flash chip. Looks like someone didn't run DRC when they did the board...This circuitry is complemented by a NXP / philips ISP7164 USB host controller and a National Semi DP8384 ethernet Phy ( the MAC no doubtedly sit in the FPGA. )an LTC1385 does old-skool RS232 translation.Left of the flash chips we find the GPIB bus transceivers: a 75160 and 75161 pair. The GPIB bus controller is no doubtedly integrated in the FPGA as well, as the classic bus controllers all have gone the way of the wind.TI's TMS9914 / ML9914, Intel 8291/8292, NEC upD7210, Motorola 68488, Philips NXP HCF4788 are all long obsolete. The ML9914 is still in production but you will only find that one in Agilent equipment. It is a mask lithography gate array with the 9914 logic embedded. Pin and function compatible with the TMS9914. Only the 9914 / upd7210 were popular for GPIB.You may encounter the 68488 in older hp equipment that is based around an 6802, 6809 or 68000 cpu. As for the philips chip.. i've only ever seen that in philips test equipment.The intel 8291/8292 pair is a slave controller / host controller. HP agilent uses these in quite a few designs as well. Although only the 8291 will be found. You only need the 8292 ( which is essentially a preprogrammed 8048) if you want to make a controller. As test instruments are typically slaves you will not find that thing. The upd7210 is a NEC clone of the 8291.National instruments have their TNT4888 asic and some agilent and Rohde/schwarz equipment uses those. These machines are typically PC-based as the tnt4888 is an ISA bus compatible part. The 4888 is a slave device only. There is a 4888s is a master device and you need to sign an NDA to get that one. Royalty payment is involved whenever you wish to make a bus master.... slaves are royalty free. Although the status right now is unclear. Last i heard the patents finally expired while other sources claim not until 2015 for the 488.2 extentions...Enough sidetracking.The analog section is well protected using the classical bussman fuses found in many a Fluke instrument.The input section uses proper dual coil relays, as not to influence incoming signals with the magnetic field of the coils.Fusable resistors , voltage spark-gap capacitors (black vertical devices with slits in em ) , ptc's (black drums left) and mov's (blue drum's right) galoreCurrent sensing is done properly using a kelvin resistorThe whole macine uses precision laser trimmed hybrid devices:These are not your run-of-the-mill open hybrids but they are vacuum sealed with a glass cover. ( probably quartz ) and are trimmed after sealing. Pretty expensive stuff.Range mulitplexing is done using high precision analog switches from Maxim (wide body ic) and plenty of guard traces are available around input pins of both the chips and the precision resistors.You can clearly see al the guard-loops on the backside of the board. some of these lie on ground potential but some are connected to output signals of opamps.The True-RMS section has no surprises either.The classic circuit using the AD637 and precision capacitors . Look like polystyrene SMD versions.The entire inguard system is controlled by its own FPGA: another Altera Cylcone 1c12 , tied to an Alliance semiconductor Static ram. this FPGA boots from a serial configuration memory. There is a trace port available, as opposed to a simple JTAG port, which leads me to believe there may be another NIOS processor mapped in this thing running a piece of code.This processor probably gets its firmware over the optical link during the system start. This allows for easy update as the entire meter firmware is held by the outguard flash chip.The entire inguard system derives its long term stability and accuracy from a linear technologies thermally controlled buried zener ( much like the LM399 )Now, here's a bit i didn't like at all : the input switch.The front panel buttons are a wobbly bit of cheap plastic that are simply clamped on the pcb. they move push-rod that controls an even crappier construction at the back of the machineA plastic block with some simple stamped wiping contacts being dragged over pcb traces to swicth between front and back. Simply snapped on to the pcb....This doesn't fit a 6 1/2 digit multimeter. For a little 3 1/2 digit handheld ... ok.. But for this kind of machine ? It just feels wrong...I'm going to go out on a limb here , and most of this is speculation on my part, but i think this machine was designed by committee.- The analog engineers went all out creating a really precise system using expensive hybrids , precision electronics under control of an fpga .- The marketing guys absolutely needed a very expensive graphics ddisplay , ethernet capability and other 'eye-candy'. They had to sacrifice so much money on the dual fpga , flash , rams, usb and ethernet stuff that the development cycle would have been too long and the cost of software development and maintenance high ( including the LXI connectivity over LAN) . Time to market would be impaired.By the time everything was assembled the price point of the hardware was so high that there was no money left to make this thing profitable...So firmware development money was cut by slapping in a linux kernel and used some code-monkeys to write an application as opposed of doing real firmware on an asic.There was no money for a decent multipole switch ( those are pricey too ) so they went the wobbly wonky style pcb switch way.It feels like a true fluke on the analog design part. High precision , High quality , and when that was done the panic kicked in... we, need to save money ! we are late !... but we will not scrap the eye-candy or the lan connectivity , so we will sacrifice some more money on a second fpga and then cut corners wherever else we can ... like using a cr2032 battery to store data in the inguard ? Why ? Ever heard of eeprom ? or Fram if you are worried about multi write cycles... it's not user replacable since you break the calibration seals by opening the machine and that's a no-no in a lab environment.It just doesn't 'feel' right... but that's my opinion. As of running a full blown 2 megabyte operating system for a mulitmeter ? That's shooting mosquito's with an entire platoon armed with bazooka's...

author: Monkeh
author_rank: Super Contributor
timestamp: July 07, 2012, 10:32:39 pm
content: We the people demand source code.

author: free_electron
author_rank: Super Contributor
timestamp: July 07, 2012, 11:13:13 pm
content: pff. demand demand ... nothing in life is free. If you can afford this machine you don't need no stinking sauce...In another thread on the forum here someone has actually found the source. You can download an update for this machine and it comes with all files. The meter firmware is a precompiled binary though... most likely becasue the rom image holds not only the OS and meter firmware but also the FPGA binary ... so it's one packaged file ready to be dumped in the flash ... nothing you can do.

author: Monkeh
author_rank: Super Contributor
timestamp: July 07, 2012, 11:16:59 pm
content: Quote from: free_electron on July 07, 2012, 11:13:13 pmAnd what about other firmware versions? Does the machine come shipped with a notice about the GPL code?

author: free_electron
author_rank: Super Contributor
timestamp: July 07, 2012, 11:42:11 pm
content: yes it does. they give you all the files in the download.The mulitmeter firmware is a binary only though. its a full linux image including all source , but the 'program' that does the actual meter is only a binary. No source. ( not needed. the GPL only covers the linux portion not the app running on it ... ) Same goes for the FPGA code. That is not subject to GPL. ( luckily the GPL does not govern everything in the world , or no company would make anything anymore... they are in it for the money , not to give their know how and research away for free.. )

author: Monkeh
author_rank: Super Contributor
timestamp: July 07, 2012, 11:46:37 pm
content: I'm fully familiar with the GPL and LGPL licenses, thank you..The cave man attitude to open-source software was good for brief amusement at least.No sign of source code in the only download I've been able to find.E: According to the GPL statements on their site it's available for the cost of distribution, by writing to them. Which will be excessively expensive for someone to burn a CD and mail it to you, when it's essentially free to just put it on their website. How very typical.

author: free_electron
author_rank: Super Contributor
timestamp: July 08, 2012, 12:06:21 am
content: Check out the other thread onthe forum here. There's people that have it apparently.

author: codeboy2k
author_rank: Super Contributor
timestamp: July 08, 2012, 01:44:18 am
content: Thanks, nice teardown FE.I imagine they couldn't get off the shelf opto-couplers big enough to cross that gap. That's why they build their own from discretes.I have a question about the rear connections. If I understand the inguard/outguard thing correctly, then outguard is earth referenced I/O connectors, chassis, etc. Inguard is floating and has the meter inputs. So what's that bit of outguard ground plane extending underneath the rear meter inputs in pictures 8 and 9? I couldn't see it clearly. There's 4 plated through holes near some diode that may or may not be populated. Then what appears to be a power plane or ground plane from the outguard side extends underneath the rear input connectors. Can you look more closely? what's going on there? Thanks!

author: free_electron
author_rank: Super Contributor
timestamp: July 08, 2012, 03:25:11 am
content: correct. Outguard is earth referenced ( chassis ground , centerpin of the iec plug ) Inguard is the 'floating part.The optos .. there is long body CNY17's like 2 centimeter long , but i think those are to slow. they probably needed a very fast coupler. As i speculate, there is another NIOs in the inguard FPGA that waits for its code after powerup. the FPGA and core + a bootloader is dtarted form the little 8 pin config rom , and that sets up a serial link with the main CPU that then loads the 'application'.You are right there is a bit of ground plane under the rear input connectors. hmmm. i don;t think it is connected anywhere. probably just shielding. there is a switch though. they can detect if you plug in the ammeter cable in the wrong hole... so that's probably why.i can't verify . i don't have the machine here. i did this during a lunchbreak... sneaky stuff >

author: M. András
author_rank: Super Contributor
timestamp: July 08, 2012, 01:34:07 pm
content: hmm nice writeup thanks, wondering what this thing could do with a proper firmware even using the same linux base, much more functionality if most of the stuffs done in software.hell with it, i would love to get one but the pricewhats the life of that cr2032? 2-3 years? if this thing completly cut off from any power source. i hope it doesnt hold the cal data

author: codeboy2k
author_rank: Super Contributor
timestamp: July 09, 2012, 12:03:49 am
content: Quote from: free_electron on July 08, 2012, 03:25:11 amAnd did your coworker know you took apart his fluke while he was having a burgerlol..

author: free_electron
author_rank: Super Contributor
timestamp: July 09, 2012, 12:10:05 am
content: my fellow cow-orkers were equilly interested to see what is in therelickily there were no man-agers around to spoil the fun.

author: anotherlin
author_rank: Frequent Contributor
timestamp: July 09, 2012, 09:12:26 am
content: User chrome has a DMM4040, a rebadge of the Fluke. May be not exactly the 8846A but a slightly less capable model, which shares most characteristics.He was kind enough to give me a file list of the included "source code". So I was able to investigate a little bit.To sum-up, full source code of the Linux for DMM is included, along with all libraries. But no source code for the program (zpf) that actually runs the DMM.That is perfectly "legal", as only Linux is GPL, but not the program you run with it. Fluke may have good reason to not give source code for actual program. They may want to keep their algorithms secret.As the source code of this specific version of Linux is available, we can gain some knowledge of the "internals" of the DMM. However, as "user-side" program may run with full privilege (this is an embedded Linux, not a desktop Linux), not all low-level hardware access routines need to be in kernel module. There is code for the Spansion (see teardown) flash chip but not much else.This Linux has been probably bought from microtronix, their name appears in source directory, also see their website which mention fluke as one of their customer.

author: free_electron
author_rank: Super Contributor
timestamp: July 09, 2012, 04:44:31 pm
content: Even with the source it may not be an easy task to alter the thing. The problem is this thing is running in a NIOS processor so you need the compiler for that .... There's a free version but the nios stops working after 1 hour or so.. unless you pay $$$$Second problem is that the rom image ( what sits in the spansion flash chip ) holds both the software AND the FPGA bitstream ... this stuff is intermingled... so you need the FPGA source as well ( no doubtedly made using the SOC design tool from Altera and using a bunch of IP cores you need licences for ..Since that source is unobtainium ... your changes of rebuilding the rom imgae are zilch.. and even if you have the source you will need the full blown tools from altera to synthesize and compile and that stuff is also $$$$.

author: anotherlin
author_rank: Frequent Contributor
timestamp: July 09, 2012, 10:18:42 pm
content: This is an exercise in futility but I wouldn't be so "negative".The Fluke source code includes the gcc compiler for NIOS. This is fully understandable as Linux code is littered with non standard gcc extension uses. And from what I've saw from the fluke source code, everything to do a build is there. Also, in the Rigol DMM post, some guy (lukas ?) mentionned that the firmware upgrade was actually a jffs2 disk image. You may well mount it on desktop Linux and tamper it.You cannot modify the FPGA, of course. But it seems you can definitely modify the stuff running on it.However, as I said before, it is an exercise in futility. You don't have hardware info, so you can't do anything useful. The DMM can be LAN connected, you may add a custom server listening for connections, but that's the most useful stuff that you may do.

author: free_electron
author_rank: Super Contributor
timestamp: July 09, 2012, 11:44:55 pm
content: you may be able to build the rom image but then the real problem begins : this rom image needs loading in sopc builder to be merged with the FPGA bitstream and be placed in a file to put in the flash ... you don't have the fpga bitstream ... not can you create it since the verilog source or sopc project isn;t there , nor do you have the ip cores or licences used.... and anything you compile with sopc builder with the free licence will run for 1 hour and then stop. you need to pay $$$ to unlock the nios.Besides . this is a 1000$+ piece of precision equipment. That you muck around with a 40$ router and linux .. be my guest... but with a 1000$ + piece of machinery ? hands-off. Put down the mouse and step away from that computer !

author: Monkeh
author_rank: Super Contributor
timestamp: July 10, 2012, 01:36:43 am
content: Where's your sense of adventure?Anyway, the point was not to play around with modifying the source.