In my visit to the SDR Forum Test Workshop, I observed something interesting. The presentations given by instrumentation vendors focused on verifying the analog and digital performance of the RF subsystem. These vendors all have very nice equipment, such as spectrum analyzers, to do this testing.
However, some of the questions from the audience during the round-table discussion asked about issues that had nothing to do with the RF subsystem. Those questions were about frustrations in testing the software in a software-based electronic system. One question was on how to get a PC to talk to the radio over the Ethernet interface. JTRS radios are typically controlled via SNMP and a user was looking for a toolkit (
I found one here) to talk to their radio.
Two other attendees needed to trace a device failure to a software condition such as a stack overflow or a priority inversion, both software bugs that expose themselves as if they are hardware failures. The worst part about these bugs is that they are typically hard to reproduce and can take a long time to track down. This makes them expensive to track down because in test, time is money.
Labels: JTRS, SNMP, Software Test, SoftwareDefinedRadio
RF Test is one of the largest areas of the test market. Somewhere around 1/3rd of all test equipment purchases are for RF test. I've been looking into this market for the past 6 months or so to see we need to be doing in LabVIEW (Desktop, RT, Embedded, FPGA) to better serve people testing RF with the NI platform.
One interesting area of RF development is in
"Software Defined Radio". The term is most specifically applied to the
JTRS (Joint Tactical Radio System) program in the military but really applies to the way in which radio design is changing. Historically, radios were implemented in "hardware": either in chips from various silicon vendors or in discrete components on a board. You may have bought a science kit when you were 10 to make an AM radio that consisted of a transistor or vacuum tube and some other electronic components.
The design of radios is changing. The first migration was moving the signal manipulations that used to take place in the analog domain to the digital domain. A
DSL modem has chips inside that use digital signal processing to convert the analog signal that travels down the copper wire into bits that become Ethernet packets.
The second migration was to perform these signal processing operations in a re-programmable device. When the 33.6 KBit modems came out, they were implemented using "standard" digital signal processors from
Motorola Semiconductor (now Freescale),
Rockwell, or others. Using a reprogrammable processor allowed the device to support multiple standards or to be upgradeable when new versions of the standard were released. Now, you are seeing the same thing happen with more 'exotic' radios that broadcast in the RF range rather than just ones that transmit over phone lines. The JTRS program envisions a radio that can run
more than 30 different standards with the same hardware. These radios use a combination of processors and FPGAs to perform the signal processing needed to pull this off. There is still some very complex analog circuitry in the radio to pull this all off but, as some attendees of a conference I just went to noted, "the bits are getting much closer to the antenna".
Technorati Tags: SoftwareDefinedRadio, Modem, Test, JTRSLabels: JTRS, Modem, SoftwareDefinedRadio, Test
