There I was at the Minneapolis airport following the EMC Symposium, waiting for my flight to Seattle when I ran into Janet O'Neil. As we chatted about the symposium and various things EMC, one subject led to another until I told her about my interests in software for controlling EMC test equipment. Being an independent consultant, I have several clients with a variety of EMC test equipment, all with the same concern: How do I automate this stuff to take readings faster, more reliably, and yet make it easy enough to operate such that you do not need a full time employee with an advanced degree in computer engineering to operate and maintain the system?
Janet is not one to let an opportunity slip by. Turning to me she said, "How would you like to do an article for our newsletter on this?" If you have ever turned down a request by Janet, please contact me. I would love to know how you did it. Anyhow, here is my story.
When I first started EMC testing, I worked on an HP141T spectrum analyzer. For those of you who are not familiar with this analyzer, it used a number of plug-in modules for different frequency ranges. The most popular ones to me covered 100 kHz to 110 MHz (in two bands!), and 10 MHz to 1300 MHz. Another was used for low frequency (up to 300 kHz) and a fourth for gigahertz testing, not that there was any reason to go up there. Our company did not even own one of those modules. The technology for this machine was from the late 1960s. I loved that machine.
Needless to say, computer control was not an option, nor available, nor possible. Well, that is not completely true - you could attach an X-Y plotter. But to draw a limit line (by hand), you had to know all your correction factors: cable loss, probe or antenna factors, pre-amplifier factors, broadband correction factors - and oh how we loved those broadband correction factors. One day, I discovered my plotter was not able to respond to the sharp peaks of a narrowband spike. The slew rate was so slow on the plotter, sharp spikes were not drawn at their full amplitude. The solution was to take pictures of the screen, which would be glued to pieces of paper and lines would be drawn on it with an indelible marker. I loved that machine.
In those days, and the days that preceded it, we had tables of data. These tables were hand written lists of correction factors for cables and current probes, antenna factors, cable losses, bandwidth correction factors, limit lines, and a few things I am sure I forgot. To obtain accurate readings, each of these factors had to be accounted for. And to think we had open containers of coffee and lit cigarettes in those days. What were we thinking?
It is true I had an HP87 on my desk. I was one of three people in the company with a "personal computer", using that term loosely. This … uhm, computer ran basic programs, had a GPIB (IEEE 488, HPIB, or whatever other term you might use in public) controller built in, and we had it expanded with an additional 128 KBytes of memory. You could draw graphs, make tables of data, calculate values, and heat the room, all at the same time. Ah the wonders of technology.
It will be at this point I will receive eMails and letters from people who used the NF-105 receiver. This was a fancy radio with a needle movement for measurement, and a headphone jack. Hours would be spent hand tuning a frequency band looking for a peak, and when one was found, these people would write down the frequency and amplitude. Everything was done by hand. And can someone explain why the only headphone you could get were black plastic with no padding, and torturous to wear more than 10 minutes?
Back to my story. By the mid 1980's, more EMC test equipment was becoming computer controllable. Some companies were supplying software to support their systems. Along came our EATON Series VII Receiver System, controlled by an HP9836 computer running HP Basic (also known as Rocky Mountain Basic). Systems such as the EATON equipment, the Electro-Metrics Receiver System, the HP8566/8568 spectrum analyzers, and others, used dedicated software controllers. Often these packages were open code, which made it nice when a modification needed to be made. In my case, comment fields, the ability to repeat testing, speeding up the test setup, the layout of the presentation, and others were modified and (I would say) improved.
Unfortunately, if you added any new equipment, or if the existing equipment was updated, the control software needed to be revised or updated, or worse yet, we were on our own because there was nobody else out there to help us. Thankfully, those days are behind us.
Over the next few issues, we will review software control of EMC test equipment. Since starting this research I have discovered a growing number of providers. These include TILE by Quantum Change, EMITest by CKC, EMC Automation by TDK, RadiMation by DARE!! of the Netherlands, and a package by Underwriters Laboratories. I will review each for their strengths and flexibility to control a wide variety of equipment. I will try to keep in mind that you, like my clients and me, might have a collection of new and used test equipment from a wide variety of manufacturers with each having to perform commercial, military, aerospace and/or telecommunications testing, and each of these needing emissions and immunity or susceptibility tasks. We will also look at the ability to make readings of other test equipment such as digital multimeters, oscilloscopes, data loggers, and the like. Let us see how they do. I will see you in a few months.
Patrick André is president of André Consulting, Incorporated and has been in the EMC field for 20 years. He received a degree in Physics from Seattle University and performed postgraduate work in Electrical Engineering. He is a NARTE Certified Engineer in EMC and ESD. He can be reached at pat@andreconsulting.com. EMC