New Agilent 34461A 6.5 Digit Bench Multimeter

[ben_r_]

WinCE wasn't that great on a phone platform either.

Sure as heck was not!

[EEVblog]

Even an accurate, expensive meter like that can (or, should be able to) serve well as a general-purpose meter in addition. Sure, it'll be warming up for a while if I need that much accuracy, but if I don't, I still want to be able to use it without waiting for that damn startup sequence.

Then simple, don't by a feature laden meter with a complex OS for on/off intermittent use. Use the right tool for the job.

[Fsck]

WinCE wasn't that great on a phone platform either.

Sure as heck was not!

I stand corrected.  Well, I guess then that WinCE is not good for anything...(then)...

So wrong. It's good at pissing people off. (though, not a very good pro)

On another note, I wonder if we'll see more siba fuses in NA with this.

[Oracle]

it's a good meter for the price, but my priority now is to get a waveform gen....

[ben_r_]

it's a good meter for the price, but my priority now is to get a waveform gen....

I recently picked up an Agilent 33220A Arb Gen and its been awesome! You can sometimes find them in good to perfect condition on eBay for around $800-900

[fpga]

A lot of manufacturers choose WinCE for political reasons-- rather than technical ones.  If you are ever working on a project that requires a GUI, file-system, and Ethernet connectivity, please don't use WinCE (unless you are forced to).  There are many paths that lead to the same destination, but some of those paths are the dumbest way to go.  For the executives reading the Microsoft sales brochures, WinCE sounds like a dream-- [paraphrasing]: "Practically everything is already done for you-- just install it, and wham!  Now you can hire Windows programmers that know absolutely nothing about embedded systems programming, and have your product ready in half the time!"  The reality is that no, you still have to hire embedded systems programmers that know what the hell they are doing, and because you have now added many layers of over-bloated code, the memory size and boot-times are going to be much bigger, and the firmware project is going to take 3-5 times as long (in my experience-- I've only worked on 5 projects involving WinCE before I gave up on it forever).

PLEASE-- FRIENDS DON'T LET FRIENDS DESIGN EMBEDDED SYSTEMS WITH WINDOWS !!!

And Agilent (I know you are reading this thread)-- you should be ashamed.

QUIT BASHING WINCE!!! We all hate Microsoft, but give some credit where credit is due!

Decisions for choosing an OS for a product is not made on a whim, particularly if it impacts a good portion of the products developed and supported by a company for a period of 10 to 20 years. Agilent most likely made the decision for their future instruments back around 2004 or 2005. Back then, before Android, iPad, iPhone, and smartphones, the choices were much different than they are today. Blackberrys had 2 line LCD screens, the Palm Pilot had a green backlit monochrome screen, the iPod had a white monochrome screen with the click wheel, and Microsoft had WinCE, which had full color graphic touchscreen support, Ethernet, WiFi, Bluetooth, USB, etc. The first smartphones and tablets (PDAs) ran WinCE. The first competitor to WinCE based smartphones was the Palm Treo, which became quite popular, but it was Palm proprietary, had no support for Ethernet or WIFI, and very limited 3rd party app support.

Where was embedded Linux back then? Back then, embedded Linux distros were basically ports from desktop distros, with limited peripheral support, very limited graphics support, poor GUI, no low power management, very limited non-PC hardware support, etc. If you wanted a BSP, and perhaps some form of support, your only options were to go with MontaVista, LynuxWorks, or TimeSys, which were exorbitantly expensive. The development tools were around $80k USD per seat, with licensing easily exceeding $120k for the OS and a few options like video display, USB, and Ethernet. Also the licensing model was tied to end product model number and single binary. If you developed a whole product family, then you would multiply the licensing cost by the number of products, plus you had a 20% annual maintenance fee. So for Agilent to choose Linux back than, they would have to shell out several $M easily on just the OS plus the 20% maintenance for the next 10 or more years.

That would have been half the problem, but GUI for Linux was simply not a priority. Most Linux hackers back then did their entire development using a text only screen. Yes, they booted their workstation to Linux console and would never run a GUI desktop. GUIs were for sissies, or lamers as some of my coworkers would call them. Real programmers used vi and make files, not IDEs. The Linux GUIs back then were all based on X-Windows, which worked very well for remote logins, but was very inefficient for an embedded type GUI, plus the fonts and dialog boxes were usually misaligned, and no touchscreen support.

Embedded Linux was used very successfully in stuff like network equipment, routers, gateways, servers, NAS, etc. These devices needed the network support and file system of a full fledged OS, but didn’t care for a GUI. Most of these devices would have a few push buttons and 2 or 4 line LCD screens on the front panel for displaying status.

By contrast, WinCE Platform Builder was ~$1k USD, and that included the BSP and all the tools needed for development. The licensing model was based on stickers that needed to be purchased for each shipped unit and ranged between $10 to $30 each in low volumes with volume discounts. Microsoft offered support for over 30 different processors, plus all of the major vendors back then had a WinCE BSP to support the specific peripherals for their SoC MCUs. For 3rd party support, there was Adeneo and BSquare, which developed BSPs for many of the MCU vendors as well as offered design services. Remote debugging WinCE on the device was over Ethernet and worked just like debugging any application in Visual Studio. Pressing F5 would build your WinCE app, download it to your device, and start execution. You could step through code and set breakpoints, and view variables and stack just as easily as debugging any desktop application. By contrast, on Linux you would run make files in the console, then use a $20k JTag pod to download your application, and then run console GDB, and have fun decoding hex addresses and values. Take your pick.

As for WinCE taking a long time to boot – Toradex have been able to offer an ARM SOM running WinCE 7 that boots in less than 500ms. It does a full cold boot to GUI in about the time it takes to press the power switch. I have yet to see an embedded Linux board boots that fast.

That was then. Today, Microsoft is not the same company it once was, and the new management geniuses are hard at work to make sure it will never be. Today most of the major ARM MCU vendors provide free of charge embedded Linux BSPs with full support for all of their onchip peripherals. There is Android and QT for GUI development. You still have to buy the development tools, but the competition has driven the prices down to more justifiable levels.

Where are the Microsoft programmers today that developed WinCE? They quit in frustration and went to work for Google to develop Android.

While I agree that the days for Microsoft are numbered (with the help of their management), I would not blame Agilent, or anyone else, for choosing to use WinCE a few years back because, quite frankly, it was the best option available at that time for an embedded OS with a nice GUI.

[fpga]

Wow!  I sense a "Microsoft Love Fest" going on here...

... it is far better (cheaper, and more efficient with both firmware and hardware) to use an RTOS, together with GUI, file-system, and networking libraries.  After completing several WinCE, embedded Linux, and Embedded WinXP projects, I can attest to this fact.  A full-blown general purpose O/S adds layers and layers of unnecessary complexity, and drives the end-unit price up (with royalty fees in some cases, and greater firmware cost in others)-- not to mention a greater number of software bugs that will probably never be fixed on an embedded device.

.. There is simply no reason at all to put a full-blown general purpose O/S in any instrument.  That's my learned opinion, and I am not going to change my mind about that.

Oh-- If I want to "bash" some company on this forum for the ridiculous engineering choices they made, then I should be able to do it-- and you should be able to express your opinion as well-- the readers and participants of this forum are intelligent and smart enough to make up their own minds, and they don't need *you* to be their "information nanny".  OK?

I referred to Microsoft in a past tense -- their days of inspiration are long gone. Maybe they have a future with their game consoles. Personally I believe that Linux, both desktop and embedded is the future, but there's still work to be done.

I'm impressed with your experience using WinCE, Windows Embedded, and embedded Linux. Unfortunately, things are a bit different if you develop products with multiple complex interfaces and GUI using an RTOS. Unless one of the free or open source versions fits your application perfectly, using an RTOS can be very expensive, particularly with the licensing. And very often you are on your own to support the MCU of your own choice and the onchip peripherals. For a product like the 34461A, you could be talking about $30k for the base RTOS + $20k for the TCP/IP v4 stack + $15k for web server + $20k for USB host + $20k for USB device + $15k for FAT16/32 file system, and $50k for GUI. Some vendors charge royalties, others base the prices by the number of units you predict you'll sell up front. Now multiply by the number of end models you have and add 20% annual maintenance. On top of that investment, you still need to develop all of the drivers. That WinCE looks real cheap now for what you get out of the box.

I'm not sure why you would call WinCE a full blown general purpose OS. Yes it can be built as such, but you have full control over which drivers and components are added to the BSP as well as which applications are in the binary. I don't think one would be able to install and run solitaire on the 34461A.

Second, the hassles you had experienced with WinCE and Windows Embedded -- I presume you had done .NET application programming. Whoever came up with the brilliant idea of running managed code on an embedded device, is beyond me. The last thing you'd want a scope to do when you press the trigger button is to start garbage collection.

As for the "information nanny" -- not the case. Anyone can say just about anything here, even bashing poor judgement -- that's the beauty of these forums, but if you criticize without insightful backup, you're bound to get negative a reaction. There are a lot of haters out there that hate just about everything. Problem is that many of them can't give an intelligent reason for their hatred.

[fpga]

@DiligentMinds.com:

If what you say about Keil MDK is true than it would be a game changer in the industry. Do you have actual experience using it in a commercial product or just believing in the marketing material? Do you know what specific commercial products use it?

I've banged my head with the RTOS vendors for years. They all sound great on the glossy paper, but once you buy in and start integrating the parts, they are quick to tell you that you are on your own. Things like the TCP/IP stack that you just licensed for $15k along with that $30k RTOS, well you are on your own to port them to your ARM because we only tested them on an x86 with a generic NE2000 Ethernet adapter. Then when you get to see the source code, you realize that they designed it to used the 8037 DMA which has no functional resemblance to the bus master DMA you are adapting. Try telling your manager that the RTOS and stacks he licensed will take you at least a few months to get working. I have yet to see a nice BSP with an RTOS that supports all of the on-chip peripherals and all you have to focus on is developing drivers to your own custom interfaces and the application code.

I agree that people are the most expensive resource. That is why using a well supported OS and tools can often be far cheaper than "free" software.

I'll take a look at again at the Keil MDK, but I need to see more than the glossies to be convinced.

[Someone]

@DiligentMinds.com:

If what you say about Keil MDK is true than it would be a game changer in the industry. Do you have actual experience using it in a commercial product or just believing in the marketing material? Do you know what specific commercial products use it?

Altium added something of that scale quite a long time ago, look where it got them As I recall the licensing was effectively bundled with the designer package and there was no piece part royalty.

[fpga]

Altium added something of that scale quite a long time ago, look where it got them As I recall the licensing was effectively bundled with the designer package and there was no piece part royalty.

Funny you mention Altium. I bought their package and pay them yearly for maintenance. It's great for schematics and layout, reasons I bought it. It also includes an embedded C compiler and embedded software. But unfortunately they have not updated that part of the product in the last 10 years, and unless you care for using 10 year old micros, its of limited value. Same goes for their FPGA tools -- great for playing around with their NanoBoards, but not much else. So if you can ship a NanoBoard, repackaged as your own product, its great. If you need to design your own board and use a more modern MCU or FPGA, look elsewhere.

[AlfBaz]

So if you can ship a NanoBoard, repackaged as your own product, its great. If you need to design your own board and use a more modern MCU or FPGA, look elsewhere.

Funny you should say that. I remember them offering enclosures for the nanoboard for just that reason

[fpga]

Keil provides examples of each function on the different ARM MPUs that the IDE supports (pretty much all of them, unless they are hot off the press).  Remember, ARM bought Keil-- the Keil compiler will support any new ARM extension before anyone else does.

I know the Keil compiler supports all ARM MCUs, but were the MDK libraries customized for all of the peripherals on each vendors MCU? Do they provide GUI libraries beyond simple vector drawing and widgets, i.e., do they support dialog boxes, popup menus, 2D animation with smooth screen updating, etc.?

[fpga]

So if you can ship a NanoBoard, repackaged as your own product, its great. If you need to design your own board and use a more modern MCU or FPGA, look elsewhere.

Funny you should say that. I remember them offering enclosures for the nanoboard for just that reason

Pure genius! Now why do I need the schematic and layout part of Altium if I can just use the Nanoboard and call it my own product?

[EEVblog]

Funny you mention Altium. I bought their package and pay them yearly for maintenance. It's great for schematics and layout, reasons I bought it. It also includes an embedded C compiler and embedded software. But unfortunately they have not updated that part of the product in the last 10 years, and unless you care for using 10 year old micros, its of limited value. Same goes for their FPGA tools -- great for playing around with their NanoBoards, but not much else. So if you can ship a NanoBoard, repackaged as your own product, its great. If you need to design your own board and use a more modern MCU or FPGA, look elsewhere.

Correct. Altium never got close to keeping up with embedded/FPGA device support, and never will.
It was a novel implementation, and looked great in the demos, but beyond that it was pretty useless and had to many traps for any serious work.
Hence hardly anyone used it for anything but traditional schematic/PCB. The embedded and FPGA tool idea was a complete flop, and cost the company almost it's entire several hundred million dollar fortune.
Altium really did think everyone would use their FPGA board instead of designing their own! Hence why they offered the PCB tool as "optional extra"      (rare triple emoticon worthy)

[David_AVD]

I don't personally know of anyone that uses more than the schematic and pcb design tools in Altium.

[Bob S]

DiligentMinds..

Thanks for attempting to get this thread back on topic. Did Dave even mentioned WinCE in his video?
I will have one of these DMMs next week and keep hoping to see some helpful feedback on its overall use.

[ben_r_]

DiligentMinds..

Thanks for attempting to get this thread back on topic. Did Dave even mentioned WinCE in his video?
I will have one of these DMMs next week and keep hoping to see some helpful feedback on its overall use.

Yes its glad to see that the topic is getting back on track, but in all seriousness, dealing with the bootup time and any other issues there may be is definitely helpful feedback on this device.

[Leon]

Yes its glad to see that the topic is getting back on track, but in all seriousness, dealing with the bootup time and any other issues there may be is definitely helpful feedback on this device.

I see the bootup time as a non-issue. Benchmeters are not bought for their quick boot properties: you need these puppies to warm up for about an hour before you can do some serious measurements. And waiting for 60 or 61 minutes really isn't that much difference. So you either wait a long time anyway or keep the unit on all of the time on your bench. In any case, a boot time of 50 seconds really is a non-issue. And if you really need a quick and dirty measurement, surely you have a hand-held DMM lying around?

[grego]

The big question now is splurge on this new 34461A or get a used 34401A on ebay for less than half the price.  New shinies are so hard to resist sometimes.

[grenert]

I completely agree with the complaints about boot-up time.  While certainly you need a long time to get accurate precision measurements, you don't always need that level of accuracy.  Sure, you could just use a handheld, but if you've already got the bench meter there, why should you have to clutter it up with another meter?

If I had a Ferrari, I would hope that it could get me to the corner shop as well as take me around a track

[mikeselectricstuff]

Another thing I noticed in the tear-down, is that there does not appear to be an Ethernet cable going from the front-panel/out-guard-controller to the back panel.  What this means is that they are running 100-base-T signals (which are differential and hyper-sensitive to impedance anomalies) through the fancy connector on the bottom of the out-guard (from panel) board.

It's run as diff.pairs near the edge of the PCB, so pretty well seperated from the other stuff, and being differential it will already be pretty robust. I can't see why the link from magnetics to Phy should be particularly sensitive - 100Mbits isn't really that high. Take a look at the liberties taken in some cheap DVI cables and switches, which still manage to mostly work...   

[Oracle]

it's a good meter for the price, but my priority now is to get a waveform gen....

I recently picked up an Agilent 33220A Arb Gen and its been awesome! You can sometimes find them in good to perfect condition on eBay for around $800-900

I know $800 is a very good price the problem is the shipping price+tax....but i think i get a HMF2525: it's going to be something like 900 eur, used only 3 times and already taxed...

[EEVblog]

Another thing that struck me as being kind of weird-- was the 10A current input in addition to the 3A input.  I get it that they are trying to maintain compatibility with the 34401A, but why can't they do that with a single 10A input?  How is some controller hooked up to GPIB going to know if it is a 3A or a 10A input?  Weird...  Perhaps someone can chime in here and explain this...

The 10A range does not have the autoranging.
Probably done to use the same shunt resistor value.

[EEVblog]

The display on this appears to be the same one used on the Garmin GPS (and others), but without the touch-screen.  That one is made by Sharp-- and is on their list for "industrial displays" (which have long-term support).

That wouldn't surprise me. I would expect them to chose a display from a big name with long term support commitments. Not just whatever they can get from the Shenzen market this week 

[Rufus]

OK, I'm going to answer myself here.  It seems that in order to maintain compatibility with the 34401A, they had to do this to keep the burden voltage the same.

10A on a single input would mean the relays (one extra), shunt protection circuits, and front/back terminal switch would all have to be rated at 10A (+ whatever overload they have to take before a 10A fuse blows). If that was practical and economical then why didn't the 34401A do 10A or even 5A?

10A on a separate front only terminal costs the terminal, an HRC fuse, and a current shunt.