Black Friday flashback

I know Black Friday is still two weeks away, but can you imagine getting this as a Christmas present back in the day?

Interestingly enough, back in 2009 one of these sold for $4150 on eBay.

The geekiest part for me is the cloud chamber.  I remember reading about Wilson's work and playing with simplified cloud chambers back in undergrad.    Cool.

Reasons to test

I tend to be a packrat for interesting articles.  I'll come across something interesting, open the page, and then move on.  Consequently, I'll pile up 20, 30 or more open links on Chrome for iPad until I finally break down and binge read.

Today is a lazy Sunday morning, so I binged.  One of those stored links dated to way back in July about reasons to test.  It's a nice little summary of four canonical test types.  However, it missed at least two test reasons that are specific to volume manufacturing: binning and SPC.

Suppose your company makes thousands of widgets that have variations in a key parameter.  You therefore have two choices: spend time and money reducing that variation to acceptable limits, or find customers that desire those variations.  If you opt for the second one you spend time and money to implement the testing for that parameter, and you use the test results to put the parts into different categories for different customers.  That's binning.

I'm not going to try to describe statistical process control (SPC).  I've taken a couple of small courses in in it, and I've applied it to manufacturing testing at a couple of different companies.  But I'm no expert.  Go here for a good summary, and follow the external references for more detail.  All I will say is:

1. SPC is a requirement for high volume manufacturing.  
2. You need lots of data for SPC.
3. You have to test to get that data.

So why did the article's author leave out these items?  I can think of three reasons.  First, maybe he thought they fell under the verification or validation categories.  I could maybe buy the verification for SPC argument, but that's as far as I would go.  Second, his testing experience is in low-volume industries (i.e. - certain military markets) where SPC or binning isn't useful.  Third, he just wrote the article quickly to meet a deadline without thinking it through.

That last reason is a little harsh.  But this lazy Sunday morning is also kind of cold and overcast, so I'm a little morose.

(the internets love cats)

Matlab improvements

I went to a Matlab seminar a couple of weeks ago,  Actually, I thought that I would mostly hear about RF and microwave testing using Keysight (the company formerly known as Agilent) test equipment.  I knew they would throw in a little Matlab, especially since Keysight and MathWorks have becomes  BFFs (here or there).

I realized early in the day that it was shaping up to be a majority Matlab experience.  So I decided to roll with it and listen - besides which, I also scored a coffee mug.

My experience with mathematical software like Matlab is complicated.  Back in grad school I test drove  an early version of Maple, and I used MathCad to make some nifty models for my thesis.  But in the working world Matlab and Labview tend to conflict more than complement - google Matlab versus Labview to see what I mean.

I had used Matlab at several different companies the past decade and viewed it as a great tool if you're a researcher trying to put something together.  But when you have to get something to test shippable product, go with the more professional Labview.

That opinion was shaken up a bit with what I saw in the seminar.  The last version I used was Matlab 2007.  The latest version (2014) has quite a few new tools.  I'm not going to make this a Matlab commercial, but here's what caught my eye:

• Better debug support
• Source code control
• More tools fork converting what you just did into m-script or functions.
• OOP support
• Data highlighting tools

Of course, none of this means that I'll drop Labview and migrate to Matlab.  But the experience was an eye-opener...

PXI work

So I found this link on EDN about PXI systems last year when I was doing some research for a new project.  I was going through old notes this weekend & cleaning up some files when I found it.  I'm not quite sure anymore why I saved it.  Maybe it's because the author mentioned hybrid slots?  I bookmarked the link last year when I was shopping for a PXI chassis for a new test system, but that's as far as memory takes me.

Anyway, I started thinking about PXI-related issues again this past week, and stumbling across this link reminded me of the experience I had selecting the hardware last fall.  After I had determined how the the test system would work, I made a list of all the hardware I needed: DMM, power supply, multiplexer switches, and relays.  It was too much for a cDAQ to handle (as much as I liked the concept), so I started shopping PXI companies.

I priced out what I needed from four different vendors.  At a startup company you try to keep the costs low, so I spent over week justifying the cost for the system.  If the test system would cost $10k or more, I had to show the legwork to minimize that cost.  Of course the expense of someone like me - getting paid what I was paid - digging around to save a grand or less didn't make much sense.  But so it goes.

I ended up buying the PXI gear from NI, and the test system worked.  And the one thing I got out of that week I spent shopping PXI prices?  There wasn't much difference between the vendors.  Originally I tried to shy away from NI since I assumed their stuff would be pricey.  But in the end it was barely more expensive than what I could get from the other three companies.  Learn something new every day, I suppose.

My experience with Labview OOP

About a year ago I started working at a new company.  One of my first tasks was to automated  functional testing for a robotics controller.  When I started we were shipping individual units out for sampling, and I had to test them by hand.  That took about 3-4 hours (including setup time and recording all the data), and we didn't cover all the testing we should be doing.  So my goals for the project were to:

1. Reduce the time down to ~15 minutes
2. Automate it so a technician could easily run it
3. Run additional tests that couldn't be done by hand
4. Save all the data to a database

Once I mapped out the program requirements and logical flow, I decided to make this my first foray into object-oriented Labview.

I had taken a class in LVOOP years ago, and I had read how-to's and  case studies with OOP in Labview, but I had never used it for a work-related project.  There were several reasons I used.

• I was re-engineering a program written by a previous engineer so I had to stick with pre-existing logic.
• I was writing small VIs for a larger TestStand implementation
• My programming partners didn't know LVOOP at all.  

Plus I may have been a little intimidated by the whole idea of an unknown architecture.  So I stuck with the standards: state machines, producer-consumers, and event-driven programs.

But now I had no excuses.   It was a brand new project, I was the only one working on it, and the project's complexity cried out for a sophisticated solution.  This was the perfect time.

And you know what?  It wasn't hard at all.  Maybe it was the OO programming I had done before in VB and C++, but the implementation went smoothly.  The only Labview-related glitch I had was early in the project when I tried to update a VI class member, but I worked it out.  And those classes I wrote for that project ended up being very reusable for two other projects I developed later on.  Excellent.

Testing and mobile devices

Below are links for two recent articles.  Both articles discuss mobile devices and testing, but they cover very different subjects: testing apps for mobile devices and using a mobile device for testing.

The first article is sort of an editorial lament/challenge about the issues mobile app developers face.  Dr. Dobbs has a top rate rep for covering software development, and I'm not going to try to paraphrase what they published.

The Evaluation Engineering article is something of a mini-survey of software and hardware available for mobile devices (mostly Android and iOS devices).  A couple of these apps I already have on my iPad, but there were some new ones I hadn't seen before.  I particularly liked the spectrum analyzer app and the LogisScope app-and-hardware.  Neat stuff.


Sometimes I bookmark similar articles and read them together when I have time.  After I did that with these articles, it just sort of struck me how the mobile aspect of testing - which didn't even exist ten years ago - is just incredibly new and cool.  And yet it's still the same thing, just in a different (and cooler) package.

Intro to DAQ

United Elecronic Industries has recently (again) put out a document called "Everything You Ever Wanted to Know about Data Acquisition."  This is apparently a three-part endeavor, and part 1 is available here.  I took a quick look at it, and it appears to be what it says it is - and introduction to DAQ.

I want a tricorder

Android Tricorder App

Last year I compiled a list of tools all test engineers should have.  That list came to mind a couple of months ago when I got my spiffy Droid Incredible phone and downloaded the Tricorder app.  It's a VERY cool tool/toy, especially for a test engineer.

I was reminded of that list again when I read the "New Age of DMMs" article in Evaluation Engineering.  The title implied to me that there was a new line of DMMs I didn't know about.  Sadly, it didn't deliver on that promise - I already knew about PXI DMM cards and the new capabilities they had.

But what about new handheld DMMs?  So I checked out Fluke (of course), and they have a couple of neat multimeters I hadn't seen before.  The Fluke 289 is a good DMM that has logging capability with a TI-calculator-type graphing option (it got a Best In Test award in 2009). Even better, the Fluke 233 has a slick wireless option - you can hook it up, put the display in your pocket, walk up to 30 feet away and still read what it's measuring.

Fluke 289

Fluke 233

Both of those would be nice to have.  But I still want a tricorder.

Misleading specifications

I've been learning more about solar cell testing over the past year.  I have a couple of test systems I'm developing, I've taken data, and it's been interesting.  It's also been frustrating.

As an example let's consider I-V sweeping, the bread and butter of semiconductor testing.  Most of the basic values of a solar cell can be determined from a quick IV check.  One of those values, the short circuit current (I_sc), helps determine the maximum power a cell could theoretically produce.  A high I_sc is nice to have.

When I first looked at measuring IVs for solar cells last year, I tried to re-purpose my National Instruments PXI chassis to this task.  I knew that the source measure unit (SMU) in the chassis (PXI-4130) could only go up to about 1A, but there was an auxiliary supply that could plug right in to the SMU: the PXI-4130 Power SMU.  On the NI page for the aux the output specs are listed at "12 VDC, up to 5 A, up to 60 W, 0 to 55 °C" (note the "5A" limit).  So I bought the aux supply and got started testing.

But as I tested larger and better cells, with more total current output, I ran into limitations with the NI approach.  I couldn't measure an I_sc above 2 amps.  This confused me somewhat, since I had seen the the five amp limit on the NI page.  Adding insult to injury, I didn't even need the SMU to output that current - the solar cell was generating the current.  

I then considered connecting multiple SMUs.  There is a "knowledge base" article on the NI website that supposedly answers the question, "What is the Maximum Voltage and Current that the NI DC Power Supplies can Source when Cascading Outputs?"  But nowhere on that page does it list a maximum current.  I even found a Photovoltaic Solar Cell I-V Characterization Bundle page that says you can "add more SMUs to get three times the voltage or current."  I struggled with this problem for a month.  

Well, I finally got an answer from NI last week.  The SMU cannot measure above 2A current because the PXI chassis has to dissipate the power, regardless of where the current source is.  The chassis has "a hard limit on the amount of power consumed by each of the SMUs."  In other words, National Instruments has some cleaning to do on their website.

------------------------

So what's the moral of this rant?  First, I'm going to get a different power supply (maybe Agilent).  Second, you cannot always trust the hardware verbage you read online.

Check your test equipment

I heard about a perfect example of #1 on my test engineering fears list on the radio the other day.  Some doctors announced earlier this summer that they had "identified a group of 150 genetic variants that they said appeared to allow people to live past 100."  Very cool, but now it appears that there was a flaw with their test equipment.

Of course, I've never had that problem before....

Instrumentation Finder website

There's a relatively new website called Instrumentation Finder. To quote from their intro page:

This site aims to provide a one stop shop for any and all Instrumentation requirements whilst providing all users with the option to source equipment from overseas suppliers outside their normal purchasing reach.

I've tried it out some and it is a) heavily biased towards UK and Europe suppliers (they say that is changing), and b) still a work in progress. But I certainly like the idea of a website specifically for finding instrumentation manufacturers and their products.

Tools every test engineer needs

The May 2009 issue of Popular Mechanics has a very nice article listing the 50 tools every man needs and how to use them.  I enjoyed reading the article, and certainly learned a few things - for example, WD-40 stands for "Water Displacement 40th attempt" since it took 40 tries to get the formula right.  And this article started a train of thought.

What are the essential tools a test engineer needs?  I'm not talking about industry-specific measurement equipment, but rather tools that span those industries.  So I combed through the list of tools I've used at multiple companies, tools I commonly see in labs, and of course Google.  I also included software packages as tools - that's part of how engineers roll in the 21st century.  

So below I offer, in no particular order, my personal top list of tools every test engineer should have (or at least know how to use).

Digital Multimeter

The first that comes to mind is the DMM, the essential tool for troubleshooting electrical connections.  My personal favorite is the standard Fluke model.

Leatherman

I'm surprised the Popular Mechanics article didn't list this as an honorable mention.  I've already written about its usefulness.

Power Supply

A good utility power supply is essential to any lab.  My personal favorite is the Keithley 2400.

Labview

You have to have some way to automate data acquisition and storage.  I've used Visual Basic, C - heck, I've even used Fortran.  But like it or not, Labview is designed to be used for test engineering, and it shows.

Statistics Package

Once you get the data, you need a way to analyze it: graphing beyond just the basic X-Y axes, SPC work, trending.  A good spreadsheet package will get you most of the way there, but for more detailed work you may need something more like Matlab or Minitab.  My personal favorite is JMP. 

Oscilloscope

Almost as important a troubleshooting tool as the DMM, oscilloscopes were popularized by Tektronix.  I still think they make the best ones.

Video Microscope

This one is obvious.  Sometimes you need to zoom in and take a picture.

TEC & Thermister

I can't count the number of times I've had to use a TE cooler (sometimes coupled with a fan assembly) to adjust or control temperature of a DUT.  They're easy to use, small, have no moving parts, and relatively maintenance free (unless you fry it).

Function Generator

Similar to the power supply, this is a tool a test lab has to have, or it's just not a test lab.

Well, there's my list.  Feel free to suggest more if you want.

Atlas LHC - Very cool stuff

As I've mentioned before, I cut my testing teeth in high energy physics.  Once again, I'm cleaning out my in box and I found a great article in Evaluation Engineering about the Atlas Experiment for the Large Hadron Collider.  It's chock-full of details about all the different measurements they do, and it sort of made me nostalgic for my grad school days - sort of.  

At any rate, I'm pretty sure the massive detail the test engineers at Atlas have to deal with exceeds the difficulties Intel has when testing it's chips. 

BTW, here's a funny cartoon that came out about the time the LHC went online.  Perversely amusing:  http://xkcd.com/401/

Testing very small stuff

I was cleaning out my inbox (again) and started reading a recent issue of Evaluation Engineering. I realized that I had referenced articles from them before, did a search, and found three separate times (one, two, three). So the next box car in my train of thought ran, "I wonder what they say about nanotech testing?"

For the last 9 months or so I've been involved in testing devices that involve either MEM structures or nanoscale devices. This has required a certain evolution in my thinking. For example, a few years ago I had never thought I'd have to automate & analyze the data from an interferometer that imaged micro-scale shutters. I did just that this past spring.

I think the first time I was really aware of nanotechnology as a going concern was back around 1991 when I read Great Mambo Chicken and the Transhuman Condition. Of course, that book is somewhat out of date 18 years later, but at the time it was a great read - I still have my copy.

SO I've been reading more about testing at this level lately. Here's a few articles:

Imaging at the atomic level

Battery development & testing
Testing a nanotech system

Keithley has been particularly active in this area. Two years ago they introduced a nanotech testing blog. A couple of weeks ago I received a Nanotechnology Test & Measurement Resource Guide. Good for them.

After reading more details about nanotech testing over the past couple months, I've come up with two conclusions. One, I've barely scratched the surface. Two, nanotechnology is rapidly expanding, and I thnik the need for testing it will be key in the 21st century.

The right tool for the job

My dad was an electrician and something of a general purpose handyman. He had tools everywhere - from the shed to the basement to a fully-stocked work van. One of the many things I learned from him is that any job you do is a lot easier if you have the right tool. To that end he had a lot of different kinds of tools. As a kid and then a teenager (when I used to help him on weekends and the summer) it amazed me how inventive the people who designed those tools were.

I started carrying a pocketknife when I was about 12 or 13 years old, probably because it was a useful tool. I bought my first swiss army knife in college and loved it. I always used it. Knife, screwdriver, bottle opener, even a little saw - what else could an engineer-in-training want?

I found that answer when I bought my first Leatherman tool. In the last dozen years I've used that tool all across the country in clean rooms, trade shows, customer visits, and even at parties opening beer bottles. I still have it, I still use it, and any young engineers I encounter eventually hear that they should buy their own (and stop using mine).

So the other day I pulled it out to adjust a screw on a cabinet and wondered how long these tools had been around. It has been an essential tool in my career for a long time, but how much longer had they been around? Turns out that 2008 is the Leatherman tool's 25th anniversary. So this is my official toast to 25 years of the right tool for many jobs.

Embedded testing

I recently downloaded a document called "Embedded Design Guide" by Tektronix. It's a 54pg PDF file that serves as an introduction to testing Embedded Systems. You can find it here or here.

My experience with embedded systems work is very limited, confined mostly to writing code for a microcontroller or debugging software written on an embedded system. But I like to have at least a passing familiarity with most technology I have to use. I haven't finished reading the file, but it appears to provide just that: a passing familiarity.

Vendor books about testing - National Instruments

Back in October I posted about recent test system manuals Keithley and Agilent had written. In a post last month I mentioned that NI had also put out a manual that I would eventually review as well. Here it is.


First Thoughts
NI is very good at marketing. They interact well with customers, get knowledgeable sales people embedded with key industries, and support their hardware and software. So when I say they excel at marketing it is truly meant as a compliment. Yet this proficiency also hurts them. Read on and you'll see.


Sections
There are four sections and 14 chapters divided amongst the sections. The first is just an introduction, the second discusses test system guidelines, the third goes over improving a system, and the last one consists of case studies.

Section 1
This single chapter reads more like a position paper for NI being the best ever than an introduction to a test system guide. Pity. For example, on just a single page (1-5) the author referenced three different marketing white papers. My hopes for the manual diminished.

Section 2
There were two saving graces to this section. Chapter five has a good overview of different buses, and chapter seven reviews the PXI standard. Otherwise it is more marketing than substance.

Section 3
These three chapters were somewhat of a revelation. The marketing was minimized in favor of looking at 1) ways to speed up a test, 2) measurement accuracy, and 3) system longevity. Cool.

Section 4
I liked the first chapter in the manual. Describing software-defined radio testing, it was short & too the point. But the other three case studies were all but useless. Okay, so Microsoft used LV and a PXI chassis to test the XBox - why not spend a few pages and describe the test architecture or obstacles that were overcome in the design. Each case study reads like an extended press release.


Summary
Unfortunately, this testing manual is more like the Agilent manual (bad) than the Keithley manual (good). It pushes a theme of "NI products are the best thing since sliced bread." The only time it mentions Agilent is to take them to task for the lack of support of IEEE1394 (VEE isn't mentioned at all). The manual could have used a good editor - the exact same graph, bandwidth as a function of latency, shows up an improbable FIVE times under different titles.

In other words, if it wasn't for section 3 I would write off the whole manual as a waste of space on my hard drive.

Virtual Instruments

I said in a post last month that I would read & review Designing Next Generation Test Systems - An In-Depth Developers Guide from National Instruments. I'm practically done now & will post my thoughts in a couple of days. But parts of this manual neatly dovetailed with a conversation I had earlier this week about virtual instruments.

NI is big on the concept of a virtual instrument - use the computer in place of the benchtop instrument to do the measurements. I've used this concept for potentiometers and oscilloscopes. But I just don't think this works in all cases, or even most cases. I have two reasons to back this opinion.

Complicated real-world measurements
There are some properties that are more than just a voltage or current. You need a good deal of physical hardware to actually acquire the data. Several examples I'm familiar with include optical spectrometers, digital communications analyzers, and (more esoteric) high energy particle detectors. A good deal of additional circuitry, physical devices, and sometimes patented techniques are involved.

Test Expertise
Hardware companies that build test equipment often have a good deal of knowledge and experience making that kind of measurement. That information often is built into the desktop instrument that performs that measurement. In most of those sorts of situations I would rather have the actual instrument than spend time and effort trying to duplicate that expertise myself.


I am not saying that virtual instruments are invalid. I think they work well for any non-complicated measurements or measurement techniques that are well-established (i.e. - the modern triggered oscilloscope was invented over 60 years ago). But sometimes you need the actual hardware.

Outsourcing a test station, part 1

Over the past few months one of my major projects has been building a test system that we are shipping to a contract manufacturer in Asia. The station is similar to our in-house systems, but different considerations were needed because it will be operating independently of our system. It has been a lot of work to this point, but it is finally nearing completion.

This is not the first time I have built a station that was shipped to a contract manufacturer - when I worked for Dupont several years ago our contract manufacturer had the equipment in house to build our products but didn't have the equipment or software to test it. I think this underlines something unique about test engineering: it is oftentimes easier to build something than it is to test it. When you are testing something you are verifying that what you built meets certain requirements. You must have confidence in the data, so extra care goes into the measurements. I think THAT is why test systems are built by the contracting firm and then shipped out - often the test system is specialized to suit your product, and you have to trust the data.


If the schedule holds, the station will ship out sometime next month, and I will fly out to help set it up and verify it after the new year. I will write more about this experience as the project progresses.

I do NOT expect to post more to the blog the rest of this week. Thanksgiving is coming up, and I have plans.

Agilent vs. Keithley

While spending time reviewing the testing handbooks by Agilent and Keithley, I started thinking more about the differences between the two companies. Here's a quick synopsis of publicly available information:

Keithley
Employees: 650
Founded: 1946
Operating Income: ~$10 million
Net Income: ~$8.4 million

Agilent
Employees: 19390
Founded: 1999 (split from HP, founded in 1939)
Operating Income: ~$465 million
Net Income: ~$3.31 billion

Now of course I realize that Agilent does more than just make test & measurement hardware - for example, they also have an investment group. I also realize that Agilent makes instruments for a lot more applications than Keithley.

I've bought & used instruments from both companies. I think both companies make good products, have good tech support, and do a good job of knowing their customers. But still, I find it very interesting that Keithley, such a small company by comparison, holds up its own so well against a huge conglomerate like Agilent. I guess there's something to be said for being small and focused.