Making the Machine Smarter
How is communications test equipment designed? How are the needs and suggestions of technicians translated into the capabilities of the next generation of test and measurement sets? To learn the answers to these questions, MRT Features Editor David Keckler visited with David Hagood, design engineer with IFR Systems. Based in Wichita, KS, with subsidiaries in Beaverton, WI, and Chandlers Ford, UK, IFR has been developing test equipment for communications, avionics and general measurement since 1968. In recent years, the company has acquired other test equipment manufacturers such as York Technology and Canadian Marconi.
IFR’s COM-120B service monitor, introduced in 1995, is widely used in the land mobile radio market. Hagood is an electrical engineer, who primarily designs software. For several years he has been the lead software designer for the COM-120 series. He is also an amateur radio enthusiast familiar with the technician’s tasks, and he performs the maintenance on his ham group’s repeater.
MRT: Does your own ability to function as a technician help with design?
Quite a bit. For example, there was a feature that showed up in version 408. The tracking generator used to be only at the same signal as you were looking at. So one day I was aligning the IF of an amateur repeater, and saying to myself “I’d like to be able to stimulate the thing at the receive center frequency and look at the IF and see my IF response. Wait a minute, there’s no hardware reason why I can’t do that.” So I knocked that in as a proven concept, and marketing saw that and said “Make it so!” Because I do use the unit, I can have a feel myself for features that are useful from a technician’s point of view.
MRT: You’ve said that Y2K (MRT August) compliance is basically a non-issue for the software in your units.
We did it right the first time. The only other date-related issue is that we’re using MS-DOS format internally, so there are the same 25 or so internal counters for the DOS date stamp for the files system, but that’s just because of the nature of a DOS file system. The only other information we use is for calibration date. Well, I store the full date as an inside integer, which means I’ve got until the year 32,767 before it gets to be a sticky issue. I implemented the full leap year calculation, so it knows that 2100 is not a leap year and 2000 is. If you’re going to do it, do it right. I’m not programming in the days of COBOL and machines with inadequate memory.
MRT: How much of the software in the last generation of the COM-120B system is new?
I’m personally responsible for probably about 35% of the code that’s in the box today. It started out running on a 188 microprocessor; now it’s running on a 486. It started out with 0.5MB of memory reserved for program storage; currently, it’s running about 11.5MB of program storage, program code. We’ve added the EDACS protocol, we’ve added the MPT 1327 trunking protocol and a lot of little features. We added the PCMCIA file system support. A feature that we wanted to put in, then decided against putting in, then decided against against putting in, is remote programming language. You can write applications that run entirely within the box. We have a language that we call TMAC, that allows you to write your own applications, so you can write a program and have it resident in the box, and that program can do very sophisticated tests. We can directly access the screen and do things on that screen. We have application programs that you can buy, load into your 120 and run, to automate testing a cell site, or automate testing a radio or do more sophisticated tests than what we saw fit to build in. So it gives us a good way to meet a customer’s needs.
MRT: Most options nowadays are already built in and are just triggered by activation codes?
It depends. There are some options for the 120, like an optional function generator, an optional amplifier to give you +13dBm HR that have to be done at a service center because you have to take the unit apart and bolt something into it. But most of the functions in the 120 are software, so it’s just a question of enabling those pieces of software.
The nice thing about that is it lets the customer buy a unit-low-ball it-buy just the basic unit. Then, if they say, “Oh, darn, we need a tracking generator on the analyzer.” You say “Fine. What’s your unit serial number. OK, here are the two magic numbers.” And our man-boom-has a tracking generator, and he’s not down for three days while the unit goes into the service center.
MRT: So most of the test processing is now in the software that you’ve built into the unit, as opposed to it being just an information-gathering tool that has to be downloaded into a PC back at the shop?
Right. Exactly. The application programs-those you load into the unit-but we just send you a card that you plug into the unit that pulls the software into the unit and stores it in the unit’s internal memory. Like, if you were to buy the Auto-cell NT program, which is a resident macro program for testing cellsites, you plug the card into the front of the unit, the unit pulls the software off the card and stores it in its internal memory, and you now have that option, to run that software.
MRT: How does IFR determine what the ergonomics of operating the unit will be? How do you decide on pressure switches vs. buttons, how the GUI (graphical user interface) for the screen will work? Does one person oversee the integration or is it a team effort with different angles of attack?
It’s a little bit of both. During the design phases, the project lead will have an overall vision of the project. But at the same time, people will come in and make suggestions. There’s a give-and-take through the initial phases of the design as to how things work out. Then you finalize on the design, and at that point, you either redesign a new box, or live within that design. For the 120, obviously, by the time I became the software lead on the project, the hardware in the box was pretty well defined, and it was just upgrading the software and upgrading the processing hardware within the box.
MRT: How much of the design of a test unit’s screen, the GUI, is oriented to the user vs. what’s convenient to the programmer or designer?
Well, we try to make it as easy as possible for the technician. My time is paid for once, up front. His time is paid for every time he uses the box. If it’s a pain for him to use the box, then he’s not as likely to recommend the box, his boss isn’t as likely to buy it, and I’m not as likely to get my bonus, so we’ve tried to make it as easy as possible. There’s an ongoing debate between two kinds of user interface: The 1200-style user interface with lots of knobs and switches and dials and buttons, and the 1600-type and 120-type interface where you have a screen and cursor locations on the screen. They all have their advantages and disadvantages. The nice thing with the 120 is, if you’re on a specific cursor location, I can give you all the functions pertinent to that location at once, whereas with knobs and switches and buttons and dials, you sit back and say “Hmm. What knob do I twiddle to make this happen?” But at the same time, when you have your head poked in a repeater chassis, with your arm crooked around sideways holding a scope probe in one place, and now you’re going to change the generator frequency, and you wonder “Am I in the right cursor field?” And that’s where the 1200-style interface works. There are tradeoffs between the two interfaces. The ideal would be to have a little bit of both. That’s something I hope to experiment with, with the user interface design, in the future.
MRT: Which needs to get smarter? The machine, or the man?
The machine. You’ve got a guy who has 12 different types of radios, three different types of repeaters, 14 different types of tests that he needs to conduct. He needs to prepare a printed form for the customer to show what was tested and how it was tested. If he tries to keep all that stuff in his head, he’s going to forget where he lives [laughs]. Test instruments are becoming-well, they’re a computer, basically. Let the computer store this information. More and more, that’s the direction we’re trying to go in, we’re trying to be able to automate these tests. … That’s why you try to make the base unit, the part that I do the most coding on, pretty flexible, and you give the applications guys all the tools to make all of these little tests a lot more easily. They can knock them out quick and they can knock them out cheap, and if the customer wants, he buys the programming manuals and writes his own applications, and he can automate the tests. So the tech basically pushes the green button and does what it tells him on the screen. The techs will get smarter-they’ll have to-but the machine is the one that has to get smarter, quicker.
MRT: How do you know when to stop adding to the box, given weight considerations and other practicalities?
That’s usually part of marketing. You try and hit a certain weight target, a certain price target, and then you haggle. “Well, if want three hours’ battery life, we’re going to have some batteries in this thing, and that’s going to add some weight. What are we willing to live without?”
MRT: Are there certain problems with some of the frequencies in use right now, as far the degree of accuracy, that you can safely say you’re measuring?
We usually strive for the entire range of the instrument. So like on the COM-120, we spec from 250kHz to 1GHz, and within that range. It shouldn’t matter. The 120 won’t tune down to “zero,” but we do not spec performance below 250kHz. So, if you’re making measurements down there, don’t call us 100% accurate-we may be, but we don’t claim to be.
MRT: It’s uncommon to work down there, though.
Oh, I’ve done weird things, like take the COM-120’s RF input and put it on the audio path of an FM radio and tune in the subcarriers at 67kHz. I was troubleshooting some radios for the blind doing that sort of thing … I can’t think of too many people who are using frequencies that low for anything that we would be measuring, anyway.
MRT: You mentioned radios for the blind. Is there any thought about adding speech recognition or speech synthesis to test equipment?
Obviously, speech synthesis and speech recognition would be nice for a handicapped user; if you’re a sight-impaired technician, those would be nice. But if you’re trying to make it easier for a technician who’s rummaging around inside of the equipment, I think the military has the best idea, a little head-mounted display (HMD) linked back to the box, so he can look down and see the display in his glasses and look at what he’s doing …. On some of our other projects, on the 1900 and the 1800, we have aa standard VGA output. Theoretically, if you get an HMD that took standard VGA signals, you could plug that in. … One of the things I’m looking at is using protocols like X-Windows so that the display of the unit can be shunted over to another computer for display. Just link it over to our test instrument and bring up the display there. One of the things that may show up in future units would be to imbed a Web browser, and have an internal CD-ROM or hard drive that we could get manufacturers to put their service manuals on in HTML and allow the unit to bring that up. If you could couple that with an HMD, you’d have a very good diagnostic system.
MRT: Speaking of military-style equipment, how do military-style hardening and environmental ruggedness fit into test equipment design?
It depends on the customer you’re talking to. Obviously, if you’re trying to sell to [the military], then being ruggedized to their specs is paramount. For most of our commercial gear, we do some ruggedization by default. On the 900 family spectrum analyzer we made, NASA needed a spectrum analyzer to examine the spectrum around the shuttle while it was in orbit, because they were trying to find good frequencies for ship-to-suit radios. They went to everyone else and said “We need a spectrum analyzer that will go up to 20GHz, that can take shock and vibration, 3Gs of acceleration on launch, and landing stresses and work off dc.” And everyone else said, “We can build you one.” And we said, “Yeah, the 900 will do that already. Shock and vibration? That thing will ride down a dirt road in the back of a truck!” They only had to make a couple of modifications for safety issues on the dc connections, wrapped it and away it went.
MRT: Off the shelf?
Yeah.
MRT: Does IFR do any “focus group” sessions with test equipment users or run any type of training classes?
We do have some training classes that we hold here [Wichita]. We don’t especially do focus groups per se, but we will work with technicians both here at IFR who use the equipment as well as technicians outside. We do try and do an extensive alpha- and beta-test program with technicians in the real world and find out what their issues are. Code goes out with bugs … When we first release an upgrade, like we did for LTR, or EDACS or MPT 1327 we have it pretty much “ready for prime time” and then let customers use it. But they know they’re getting a beta software. We work a deal with them on that, so we don’t hit them with a full price and then send service patches out. These guys see and do things that we’re never going to simulate here, like trying to make a power measurement on a signal with a 3MW AM transmitter sitting next to you.
MRT: What’s on the horizon for test equipment needs?
I think the single most important thing in radio communications is moving data, as opposed to moving voice. Ericsson’s EDACS has their data protocol on it; more and more you see a lot of police departments using mobile data terminal systems that are plugged into the trunking radio system. Of course, both GSM and CDMA cellular have a data mode that bypasses the vocoder and goes straight down to the bitstream. What you’re going to see in all the trunked radio markets is the same thing. As spectrums get tighter, and you can’t go with FM anymore, you’ve got to go with digital just to crunch the spectrum down, and once you’re sending bits, “bits is bits.” It doesn’t matter whether they’re representing voice or data. The thing I keep in mind on any new project is six little characters-TCP/IP (transmission control protocol/Internet protocol)-because that’s the direction you’re going to see a lot of people going in. A lot of people are going with their own data protocols, but they end up reimplementing all the capabilities of TCP/IP. I suspect that in the future, more and more trunked radio systems are going to have IP capability in addition to voice capability.
