Measurement and analysis techniques for wireless systems

Story

December 16, 2011

Commercial and military communication standards require that waveforms adhere to rigid specifications to ensure that devices interoperate with equipment from other vendors. Wireless transmitter and receiver designs both need to adhere to standards, but transmitter design is typically a straightforward process. Wireless receiver design is a more challenging exercise, and the use of real-world test signals can significantly accelerate the design process and ensure interoperability. The tasks involved in the design of a wireless receiver include:

• Develop receiver algorithms
• Create test vectors and run tests on a PC
• Conduct laboratory tests of the design in a controlled environment
• Verify the design works with captured field data

Some of these tasks require technical computing software; others require test and measurement tools. The following discussion uses the Mode S secondary surveillance radar standard as an example to demonstrate how a unified technical computing and measurement environment enables engineers to develop more robust designs, use real-world data to verify they meet performance specifications, and confirm that they satisfy interoperability requirements.

Mode S signal details

Mode S is a transponder-based communication system used by commercial aircraft to report their aircraft identification, position, altitude, and velocity to air traffic controllers and collision avoidance systems. Transmitters on the ground send interrogations to commercial aircraft, and the aircraft respond with flight information to those queries. The Mode S standard is published by the International Civil Aircraft Organization. The standard has already been adopted in Europe and is being gradually introduced in the United States. The Mode S standard specifies details of the signal format:

• Transmit frequency: 1,090 MHz
• Modulation: Pulse position modulation
• Data rate: 1 Mbps
• Message length: 56 μsec or 112 μsec
• 24-bit CRC checksum

The message content depends on whether the specific message is short (56 μsec) or long (112 μsec). Short messages contain the message type, aircraft identification number, and a CRC checksum. Long messages also contain the altitude, position, velocity, and status. Each Mode S message begins with an 8-μsec synchronization and preamble. This information establishes that a valid message is being transmitted and enables receivers to determine when the message bits start.

Receiver algorithm design

Mode S communication is characterized by very short messages interspersed with long idle periods. In a crowded airspace, there can be several commercial aircraft transmitting multiple legacy signals in the same frequency band that Mode S uses. A Mode S receiver must reject these legacy signals as well as other spurious signals, recognize the presence of a Mode S message, and launch a demodulation and decoding process to extract the data.

Decoding a Mode S message starts with correlating the incoming signal to the Mode S synchronization pattern and comparing the result of the correlation to the noise floor of the receiver. When the synchronization pulse is present, the correlation should be well above the noise floor so that the peak correlation value can be used to calculate the start of the message bits (see Figure 1).

 

Figure 1: Correlation of data to the Mode S synchronization pattern and comparison to the receiver noise floor.

(Click graphic to zoom by 1.9x)

 

Each 1-μsec message bit has one of two possible bit patterns. A logical 1 is on for the first 0.5 μsec and off for the second 0.5 μsec; a logical 0 is off for the first 0.5 μsec and on for the second 0.5 μsec. If the receiver sample rate is set to 12.5 MHz, each bit will comprise either 12 or 13 samples. A simple strategy for bit decoding is to sum the magnitude of the first six samples and the last six samples for any individual bit and assign a 1 or a 0 based on the results.

The last 24 bits in the message are the CRC checksum. To ensure the message has been properly received, the receiver must compute the checksum for the message bits and compare it to the last 24 bits in the message. If the computed checksum matches the received checksum, the message is valid and the message type, aircraft ID, position, altitude, and velocity can be decoded.

To speed up the development and testing of the algorithm, engineers today use technical computing environments that enable them to seamlessly develop and test algorithms using both synthesized and captured data.

Algorithm testing with Mode S data

Engineers will typically verify receiver algorithms using test data from multiple sources, including:

• Data generated synthetically and formatted using the Mode S standard
• A test signal transmitted in the lab and captured by test equipment
• Real-world RF data captured from aircraft flying overhead

For example, receiver designers might start by constructing baseband data signals that match the Mode S responses to test their algorithm. They could then add impairments such as random noise to test the algorithm’s robustness. This approach serves as an initial test to verify that the basic receiver processing works correctly and to determine performance boundaries, such as the minimum Signal-to-Noise Ratio (SNR) needed for reliable reception. As a next step, the designer might generate an ideal signal using a waveform generator and verify the algorithm by capturing this signal with test equipment.

Once the algorithm has been tested against an ideal signal, the design is ready to be tested against multiple Mode S transponders. Verifying interoperability is important because multiple vendors design and sell Mode S equipment. Testing with real-world signals is vital because it is easy to misinterpret the standard, which is 213 pages long, and testing against multiple designs can reveal overlooked nuances in the standard. Also, the RF environment is unpredictable and introduces many impairments, including interferers within the specified frequency spectrum and distortions introduced by transmitters in addition to complex channels with problems caused by multipath reflections, weather, and foliage.

Using modern signal and spectrum analyzers engineers can capture live Mode S data by tuning to the response frequency, setting the sampling rate, and storing the received In-Phase/Quadrature data. The recorded data can then be used to validate that the receiver design works with real-world signals.

If the algorithm is designed in a technical computing environment, then much of this part of the testing process can be automated. First, the spectrum analyzer can be controlled using script commands sent via GPIB or USB interfaces. Most front-panel controls on the spectrum analyzer can be accessed and scripted using these interfaces. Second, data from the spectrum analyzer can be imported directly into the environment. This approach provides several advantages. First, scripting ensures tests are repeatable. Second, scripting enables testers to launch lengthy tests without having to manually conduct the test process. And third, scripting can be used to automate data retrieval and eliminate the need to manually run file transfers, burn DVDs, or set up network drives.

When using MathWorks Instrument Control Toolbox, controlling and analyzing data from a spectrum analyzer is a three-step process:

Connect: Establish a network connection between a PC and the test equipment.

Measure: Set measurement parameters and send capture commands to the test equipment.

Analyze: Retrieve captured data from the test equipment over the network connection and process the data.

The testing process is also accelerated when the measurement script is developed interactively and graphically. For example, as they develop scripts, engineers can execute Standard Commands for Programmable Instruments (SCPI) instructions from the MATLAB command prompt and use the Test and Measurement Tool graphical user interface to communicate with the test instrument.

A sample test script is shown in Figure 2. The script sets up the instrument, issues the capture commands, and retrieves the data. Writing a test script does require a small additional time investment up front compared to performing the steps of a single manual test. However, as scripts are reused multiple times or employed to automate long, unattended tests, the investment is recouped many times over in time savings.

 

Figure 2: A sample Mode S test script

(Click graphic to zoom by 1.9x)

 

Using a spectrum analyzer and the approach outlined here, engineers can receive and decode Mode S signals from aircraft flying nearby.

Automated testing

Unifying the measurement and computation segments of this example gives an engineer designing the receiver the ability to run automated tests on an algorithm design with real signal sources. A receiver design that works well on one test data set might fail with equipment from other vendors or in different wireless environments. An automated process helps engineers run tests efficiently against a wide range of test conditions and vendor equipment.

Stronger algorithms, more fully tested designs

Accessing data transmitted from real wireless sources is a key step in verifying a receiver design. A unified environment in which engineers develop algorithms and automate the collection and processing of data streamlines development. MATLAB and Instrument Control Toolbox were used to write a 300-line script to:

• Control wireless test equipment, including spectrum analyzers
• Retrieve stored data for off-line processing
• Demodulate and decode the received data

Using this approach and a unified environment, wireless engineers can access more realistic data, try out more receiver algorithms, and run more performance tests. This ultimately produces stronger algorithms and more fully tested designs.

Mike Donovan has worked for MathWorks for seven years and is a manager in the Application Engineering Group. He has a BSEE from Bucknell University and an MSEE from University Of Connecticut. Mike has more than 10 years of experience working on military radar and satellite communication programs. He can be contacted at Mike.Donovan@mathworks.com.

Dr. Jon Friedman is the Aerospace & Defense and Automotive Industry Marketing Manager at MathWorks. Prior to joining MathWorks, he worked at Ford Motor Company and as an independent consultant on projects for Delphi, General Motors, Chrysler, and the U.S. Army Tank-automotive and Armaments Command (TACOM). He holds a B.S.E., M.S.E., and Ph.D. in Aerospace Engineering and a Masters in Business Administration, all from the University of Michigan. Contact him at jon.friedman@mathworks.com.

MathWorks 508-647-7000 www.mathworks.com