Audio Test Equipment - Computer Control

[PB2]

I've been looking at audio test equipment such as the Heathkit IG-18 and HP239A/339A, Bob C's analyzer, and something that comes to mind is that it would be much better to have computer control of these instruments. Anyone who has done tedious measurements at multiple frequencies knows how time consuming it can be. It would be excellent to have software scripts to do frequency sweeps, etc. I remember in the old Mac clinics that they would test distortion at 20 Hz, 1 k, and 20 kHz, then smoothly connect them. GPIB is the obvious choice, but is complex, I'd probably go for a very simple parallel interface and control it from Visual Basic on a PC or a microcontroller. I can see this as a huge time sink so I doubt that I'll do it anytime soon.

Anyone know of a bargain priced small signal relay? It has been a while since I looked for them.

[klewis]

Pete,

I've been using Agilent's VEE software. I purchased the student version for $75 (I don't know if they will make it available for that price to everyone - I'm an adjunct faculty at a University). Pete Millet gave me copies of his HP8903A control interface in native VEE. With that and stuff I made, I can run the 8903A along with a 3562A spectrum analyzer to get good consistent results for FFT plots. I'm happy to share my native VEE visual code.

Ken

[PB2]

Thanks Ken, I'll be in touch if I ever move a computer controlled version along.

I'm leaning toward just getting a better sound card with ARTA which would obviously be computer based but I will get in touch if I ever do the computer controlled analog unit.

[dchisholm]

Pete, I share your sentiments but also estimate that the task of creating an effective computer-control interface will require as much effort as the instrument's original design.

I think you're aware the task logically divides into three efforts. For those following the thread, they are:

1. The first is to convert the instrument itself from mechanical control to electrical control. At the least this means replacing mechanical devices like switches and manual potentiometers with electromechanical relays, motorized pots, solenoids, etc. Although this is a notably inelegant (and probably expensive) approach, careful attention to detail may actually produce an instrument with performance superior to the original mechanically-controlled version. From time to time I have been amused while operating a "modern", "digital", instrument . . . and as I select functions or ranges via a keypad, touchscreen, or software interface, I hear the "clickey-clickey" (or occasional "ker-schlunk") of relays and actuators configuring the internal electronics. In spite of potential performance improvements this approach still suffers from limited speed and operational lifetime due to the mechanical nature of the control devices.
   
   Probably the next more elegant alternative uses logic gates, electronic switches, and circuits with electronicly-controlled characteristics (e.g., transconductance amplifiers, current mirrors, etc) in place of the mechanical devices. At the present time these devices are generally inferior to their mechanical (or electromechanical) counterparts in fundamental ways. Just like the folks who make butter don't claim that it tastes as good as margarine, Alps is unlikely to emphasize that their best pots have the linearity and bandwidth of a typical VCA. On the other hand the electronic components have secondary advantages: mechanical switches and relays find a CMOS analog switch tough to beat when it comes to contact bounce. The creative challenge is to conceive clever ways to work around these devices' imperfections while exploiting their advantages.
   
   At a higher level of electronic automation a major portion of the instrument's functionality is moved into the digital domain. Examples include replacing linear oscillators with direct digital synthesis (DDS), and replacing analog filters with DSP algorithms. In one sense this move is analogous to exchanging the lumberjack's crosscut saw for a chainsaw, or the two-horse hitch for a steam traction engine. However, even a digital- or software-dominated architecture typically requires a high-performance analog front-end or output stage. (So maybe it's more like moving from a carbureter to a fuel-injected engine, with a corresponding shift from mechanical precision to sensors and electronic processors.) I'd guess that at the present time the design of this kind of instrument beyond the resources and abilities of all but a handful of hobyists and DIY-ers.
2. The second portion of the task is the logic interface within the instrument. The Bob Cordell THD Analyzer demonstrates the challenge. We could replace each of the zillion rotary switch contacts with a relay (or electronic switch), but then we have the problem of controlling the relays. The minimal approach would simply re-insert single-pole rotary switches, connected to operate the relays associated with each switch position. But by adding various degrees of combinational logic we may be able to supplement the instrument's functionality with a modest amount of design effort. For example, more complicated switching schemes - such as the "progressively shorting", or "short all connections but one" options - can be easily implemented. A little combinational logic can also circumvent some kinds of operator errors, such as engaging a THD analyzer's 400 Hz hi-pass filter when the fundamental input frequency is less than 200 Hz.
   
   A high-end user interface would use a processor, probably a low- or mid-range microcontroller. Keypads and multi-function input sensors, as well as character- or even graphics-based LCD displays are viable even with modest budgets. Programming microcontrollers takes a different mindset, and different body of knowledge, than analog circuit design but both the information and the tools are readily available to mere mortals at minimal cost. The challenge is more in the area of ergonomics: the iPod is a standard of comparison for packing a lot of functionality into a simple, intuitive interface; while the VCR clock that blinked "12:00 AM" for decades on end (due to an inscrutable user interface) is legendary.
   
   (As a side note, both discrete logic and an integrated processor face the question of how information is transferred within the instrument. Dedicated, single-purpose control lines - e.g., 10 wires for frequency tuning, 6 wires for range selection, 2 wires for balanced/unbalanced input, etc, etc - quickly become unwieldy. Short-distance serial buses like IIC or SPI minimize interconnection complexity but require additional electronic processing, and the clock signals create a potential for serious EMI/EMC problems. A not-entirely-satisfactory compromise is to use a parallel data bus, probably 8 to 16 bits wide, with a similar number of strobe lines that tell each subsystem when to grab a value from the data bus.)
3. The third design task is the hardware, firmware, and software interface to the computer itself. The IEEE-488 (nee GPIB) bus has persisted for 35 years or more. From its inception some complained that it was over-powered and cumbersome for many of the devices it controlled, but it supplanted a plethora of custom, incompatible, interfaces that had started to appear on laboratory instruments. Unfortunately it is rather rare in the world of desktop and laptop personal confusers (PC's).
   
   The legacy "PC serial port" (a mutation of RS232) has lost favor, but the hardware interface is easy to implement on a small microcontroller in the instrument. The "Local Interconnect Network (LIN) Bus" uses a similar asynchronous serial transmission, and is also compatible with low-end controllers, but adds a lot of useful features and standardization. Unfortunately, it seems to be unknown outside a small number of automobile models.
   
   The "PC Parallel Port" seems to have acquired bidirectional capability, and became a viable general-purpose interface, about the time it disappeared from general use. Based on what little I know, it should be fairly easy to implement on low-end microcontrollers - but I don't recall seeing it done, so maybe there is more difficulty than I'm aware of. One disadvantage is the physical cabling itself: the stiffness, and diameter, of some parallel-port cables is just a little short of what is needed to jump-start a locomotive.
   
   
   
   Currently, USB seems to be well on the way to becoming ubiquitous. Microchip (and, I presume, other microcontroller manufacturers) advertise mid-range parts with "USB capability". It's my understanding that a USB peripheral requires a fair amount of housekeeping and handshaking interaction with the computer it's connected to, but the "firmware stack" to do this is typically available from the microcontroller vendor. It might be necessary to make the connected instrument "look like" a computer mouse, keyboard, or memory stick to avoid developing firmware drivers for both the computer and the instrument end of the connection.
   
   Perhaps somebody on the Forum has an idea of how much development effort may be required to create "drivers" (not sure if that's the correct term) or other interface software on the PC end. I know it's relatively easy to pass data through the PC serial or parallel ports using, e.g., stock VBA, Visual C++, etc but I don't know if that extends to USB or not. And, if you want to use something like LabView, or the TEK "Open Choice Desktop", do you need a "virtual instrument software architecture" driver in addition to a driver for your particular instrument?

I'd also like to hear of others' experiences with this kind of project. It seems large, but probably not as large as an elephant. And they say even an elephant can be eaten, if you take it one bite at a time.

Dale

p.s. - The surplus and closeout vendor "All Electronics" often seems to have a fair assortment of small-signal relays. The DIP-socket and "sugar cube" styles often sell for around US$1 (+/- 3 dB). Of course, sometimes you have to contend with non-standard pinouts or strange coil voltages but that's tolerable for preliminary experiments to investigate feasibility.

[PB2]

Hi Dale, that is a lot to read and you've made a lot of assumptions.

I've been doing digital design as my main profession for about 30 years and am fully aware of the issues you bring up.

Relays: I took a look at relays and as I've found in the past it seems that Omron has the best offerings at reasonable prices from surplus houses and ebay. About a buck a piece, even less if you don't mind a 24V coil. The relays might end up being less expensive than some of the selector switches that are used in these complex instruments.

Interface: The obvious solution is USB. However, my plan would be to use a very simple byte wide parallel bus inside the unit, employing ribbon cable with multiple connectors to go from board to board within the unit. It can VERY easily be adapted to a PC printer port where the front panel and scripted controls are a window on the PC. Probably a VB program just to keep it simple and easy to program. This bus could alternatively go to a very simple microcontroller inside the unit to provide USB and/or front panel encoders, display, etc. interfaces, even GPIB. A Basic Stamp comes to mind as very easy to program and there are eval boards with a proto area that would work fine. Octal registers would hold the control data clocked by a strobe that is only active when loading the register - no free running clock on the analog board.
The bus would use a standard PC floppy connector and cable since prefab cables are available inexpensively for PCs or can be salvaged from junk PCs. Not the hardware interface just the cable.

Let me explain how I got to computer control and it is good to use an example. I was thinking of doing a PC board for the HP239A, then thought how time consuming it would be to make up all the selector switches, and the general hand wiring. This combined with how time consuming it is to do tests with a manual instrument led me to computer control with just the parallel interface to a PC. The HP239A is already mostly switched for frequency selection so there is no need to compute values just replace selector switches with relays. There is one variable pot for fine frequency selection that could be replaced with a scaled version of the other resistive switch. It would be much more efficient to make the resistive elements just a binary weighted ladder but then the software would be a bit more complex. Everything would go on one circuit board to keep lead length short and simplify assembly. The interface for an oscillator would have frequency, and amplitude as controls - should be easy to program. I really, seriously dislike modern equipment where you have to go through levels of menus to get to a control. DIY you can tune the UI however you want.


I disagree with your statement:
"estimate that the task of creating an effective computer-control interface will require as much effort as the instrument's original design."
as long as you follow a keep it simple approach.

There are USB to parallel port adapter cables but I'm not sure if they'd work with whatever code I developed.
I'd have no plan initially to have it work with Lab View but I'm sure someone could write a driver for it.

Here is an AVR microcontroller development board with a USB interface:
Just add a connector for the proposed parallel interface bus in the prototyping area.
http://www.sparkfun.com/products/32

PIC with USB:
http://www.sparkfun.com/products/8562

[PB2]

I'm leaning toward using an old laptop as the display/controller for this project and remembered that even a fairly old P4 based one that we have here only has USB - no parallel or serial port. We actually have a perfectly good P2 based laptop from about 1997 that DOES have both printer and serial ports. The STAMP software environment runs on it and I'm fairly certain that VB 6 will also run under Win98, LOL!

Anyway, the printer port is fine for debugging but someday that PC will fail and a USB solution would be needed. I have a USB to serial cable (Parallax USB to Serial (RS-232) Adapter) that works with the newer laptop connected to a STAMP eval board that should be fine to handle a simple serial protocol for writing and reading to/from registers on the parallel bus. An advantage of using a simple text based serial port interface is that most programming environments support them without any sort of special driver. You could even hook up a dumb terminal to read and write registers. These STAMP boards can be found on ebay fairly cheap:
"Three" Basic Stamp Homework Boards | eBay

I decided to dive into the STAMP world a few years ago and quickly found that the lack of interrupts or multitasking makes it impossible to do any sort of complex task. I programmed it to decode an IR remote control stream but there was no efficient way to do this and simultaneously monitor a front panel encoder for example. I am confident that the STAMP can provide the basic interface from a serial port to a parallel bus but not much more. It would be nice to have the micro measure the frequency of the oscillator for example so that the control program can fine tune the frequency. This is easy to do with a PIC; there are many examples on the net but not with the STAMP.

I tend to agree with this perspective on programming especially with larger computers such as PCs:
Mike's MicroController WebSite
I remember the days of Borlands compiled Turbo Basic and it would make much more sense for the code to be compiled for these micros rather than interpreted. Even VB is compiled.
I also purchased a BX-24 that is pin compatible with the STAMP but programmed in a flavor of BASIC that is a subset of VB. I've not moved much further with the BX-24 and they don't seem as popular as they were in mid 2000. They are AVR based and I think you can program them in the native AVR environment also.
Edit: Just stumbled onto this discussion of ZBasic for the AVRs which might be a better solution than BASICX:
http://oakmicros.com/content/index.php

A simple AVR proto board with AVR Studio IDE (free) probably makes more sense as it is more cost effective, and I have one around here also in case I decide to add more features but it is only programmed in C or Assembler.

A free VB environment on the PC would be nice and I think it is VB 2010 Express that is free from MS, toward the bottom of the page:
Compare Visual Studio 2010 Products | Microsoft Visual Studio

However, I believe that VB6 is better but unsupported and not free. It's been some time since I did any VB programming.

[benb]

Originally Posted by PB2

Anyone know of a bargain priced small signal relay? It has been a while since I looked for them.

You mean like these?
5VDC Relays-The Electronic Goldmine
Later you mentioned using 24V or other coil voltages, they got those too:
Relays-The Electronic Goldmine
For "high quality" contacts this looks interesting:
RK1-24V High Frequency 24VDC Relay-The Electronic Goldmine

As far as computer control, interfacing and whatnot, if you're willing to throw money at it there's National Instruments software which has a visual programming language. I've only used it in a couple of seminars, but it's impressively easy to come up with some neat and useful on-screen controls, interfaces and displays. It was made to quickly do exactly what you want to do.

On the other hand, if you just wanted to spend money and get the job done, Audio Precision would be just about the only choice. Of course the big drawback of such a system is it takes away all the fun of doing it yourself.

[Conrad Hoffman]

IMO, designing the instrument interface hardware makes it too hard a project, at least for most people. One should either get an AP system (hey, problem solved!), a good sound card, or go with GPIB/HPIB and dedicated instruments. I use the HP8903B for most things. Control is cheap and easy using the Prologix GPIB/USB converter. I write my control software with PowerBASIC, which is quite similar to VB in syntax, but offers vastly more in terms of structure and performance. Think power and low level capabilities of C++ but with the more reasonable syntax of basic. That also lets me set up tests with my HP meters and counter. If I had an arb generator, my life would be complete.

(PB2, if you remember those old Mac clinics, you're as old as I am! They were a big thing back in the day. I still have my hand plotted 4-point "printout" from when they did my scratch built Tiger amp.)

[PB2]

Originally Posted by benb

You mean like these?
5VDC Relays-The Electronic Goldmine
Later you mentioned using 24V or other coil voltages, they got those too:
Relays-The Electronic Goldmine
For "high quality" contacts this looks interesting:
RK1-24V High Frequency 24VDC Relay-The Electronic Goldmine

As far as computer control, interfacing and whatnot, if you're willing to throw money at it there's National Instruments software which has a visual programming language. I've only used it in a couple of seminars, but it's impressively easy to come up with some neat and useful on-screen controls, interfaces and displays. It was made to quickly do exactly what you want to do.

On the other hand, if you just wanted to spend money and get the job done, Audio Precision would be just about the only choice. Of course the big drawback of such a system is it takes away all the fun of doing it yourself.

The goal is to do this for minimal cost and to try to get better performance than the HP8903 or Boonton 1120/21, perhaps even Bob C's design. Bob has suggested some OP amp upgrades. Obviously one could throw money at it.

I was thinking of the Omron G6S line of relays. You have to be careful of minimum current ratings.

Your speaking of Labview it seems, that is not a free package and it would require writing a driver perhaps something only NI can do. On the other hand the Student version is inexpensive, does anyone know if the tools/documentation for writing a driver are included with the software?

[PB2]

Originally Posted by Conrad Hoffman

IMO, designing the instrument interface hardware makes it too hard a project, at least for most people. One should either get an AP system (hey, problem solved!), a good sound card, or go with GPIB/HPIB and dedicated instruments. I use the HP8903B for most things. Control is cheap and easy using the Prologix GPIB/USB converter. I write my control software with PowerBASIC, which is quite similar to VB in syntax, but offers vastly more in terms of structure and performance. Think power and low level capabilities of C++ but with the more reasonable syntax of basic. That also lets me set up tests with my HP meters and counter. If I had an arb generator, my life would be complete.

(PB2, if you remember those old Mac clinics, you're as old as I am! They were a big thing back in the day. I still have my hand plotted 4-point "printout" from when they did my scratch built Tiger amp.)

I disagree with what you're saying about the instrument interface making it too hard of a project. One goal would be to eliminate most of the front panel work by making all the controls virtual on the PC, then it is just writing fairly easy software and doing it once. The digital control software and hardware interface is trivial and easy to debug. Having most of the parts on one or two boards with computer control eliminates all that hand wiring for the selector switches making it an easy stuff the board and solder project.

I have designed, debugged, microcoded, and written test software for custom floating point and graphics processors. The digital interface design for this is totally trivial, IMO.

I'm thinking now of doing a notch filter first to use as a distortion magnifier, as Bob calls it (not the same as his DM), in front of a PC sound card based system. This capability should make it possible to then test other parts of a complete system if I decided to go ahead with it. On the other hand, if I did a notch filter with auto tune such as Bob's then I've done most of a THD analyzer. Might be interesting to do the autotune in the micro - if possible. I'd try to get the residuals down in the notch filter with better OP amps. Computer control and having a state variable filter design makes it trivial to put a band-pass or low-pass after the oscillator, has anyone tried this? Obviously the bandpass has to have lower residuals than the oscillator.

How did your Tiger amp do at the clinic by the way?