Summary

Texting and instant messaging are familiar and popular communication techniques. Text messages composed of ASCII characters, with each character composed of eight bits, ultimately form a stream of bits transmitted from the source to the receiver. Normally the text message moves through a complex data network, and the user only sees the endpoints of the system. In this project, however, you will be able to follow the text message on its complete journey through a binary ASK transmitter, a speaker-air-microphone (SAM) channel, and a binary ASK receiver.

This project depends on successful completion of the two prerequisite projects, Speaker-Air-Microphone (SAM) Channel Characterization and Binary ASK Transmitter.

Objectives

Deliverables

Setup

Textbook Linkages

Refer to the following textbooks for additional background on the project activities of this module; see the "References" section below for publication details:

Prerequisite Modules

Complete the lab projects Speaker-Air-Microphone (SAM) Channel Characterization and Binary ASK Transmitter before you begin this project.

If you are relatively new to LabVIEW, consider taking the course LabVIEW Techniques for Audio Signal Processing which provides the foundation you need to complete this project activity, including: block diagram editing techniques, essential programming structures, subVIs, arrays, and audio.

Introduction

Figure 1 shows the hardware setup for this project. One computer running a "text sender" LabVIEW VI translates a text message into a bitstream, modulates the bitstream as an ASK signal, and plays the signal to a speaker. A second computer running a "text receiver" VI listens to the microphone signal, records and demodulates the ASK signal, regenerates the transmitted bitstream, and translates the bitstream back to text. The text sender and receiver VIs can run in parallel on a single computer to simplify development.

Figure 1: High-level block diagram of the project

The frequency response and bandwidth of the speaker-air-microphone (SAM) channel were measured in an earlier project, Speaker-Air-Microphone (SAM) Channel Characterization. As discussed in the Binary ASK Transmitter project, the bit rate and pulse shape can be adjusted to place the transmitted signal in various sub-bands or to fully occupy the available channel bandwidth. The channel bandwidth can be allocated in a number of different ways for this project. For example, use the full channel bandwidth to minimize the amount of time to transmit a message. However, transmitting messages simultaneously between two computers requires two different transmitter carrier frequencies and careful choice of bit rates and pulse shapes to ensure the signals remain contained in a sub-band of the channel.

The text message to be transmitted is a collection of ASCII characters. ASCII, the American Standard Code for Information Interchange, defines a mapping between familiar alpha-numeric characters (as well as other types of characters) and 7-bit binary patterns. For example, the five character sequence "hello" maps to the bit sequence 1101000 1100101 1101100 1101100 1101111. See the Wikipedia article on ASCII for ASCII mapping tables and further information.

LabVIEW offers a complete set of tools to manipulate and process text, including methods to translate text to bit sequences and vice versa. Swapping the random number generator currently serving as the message source in the transmitter from the Binary ASK Transmitter project with a text-to-bitstream converter quickly creates the necessary text sender for this project.

Figure 2 shows a high-level block diagram of the ASK receiver to be constructed in this project.

Figure 2: ASK receiver block diagram

The recorded microphone signal serves as the receiver input. The receiver filter is a bandpass filter centered at the transmitter's carrier frequency with a bandwidth selected to match the transmission bandwidth. The receiver filter therefore admits the signal of interest but removes out-of-band noise and signals in adjacent bands.

The ASK signal spectrum contains a strong carrier component, making noncoherent detection feasible. Coherent detection requires carrier synchronization, a more complex approach. Noncoherent detection, on the other hand, can be simply implemented using an envelope detector. The envelope detector recovers the baseband signal. The Figure 3 screencast video discusses the envelope detector principles of operation, implementation by a lowpass filter followed by a rectifier, and choice of lowpass filter corner frequency based on bit rate.

Figure 3: [video] Envelope detector principles of operation, implementation, and parameter selection

The normalizer, the third block in the sequence, shifts the baseband signal to eliminate the DC bias and scales the signal to the range ±1. The normalizer can be considered a type of automatic gain control (AGC) to compensate for variations in speaker signal strength and microphone gain settings.

Up to this point the baseband signal can be considered an "analog" signal, even though it is in reality a discrete-time sampled signal. The sampler selects a single sample point from the baseband signal once each bit interval. The sampling process itself is very simple, but how does the sampler know when a bit interval has elapsed? Fortunately a hidden yet vital component in the sampler block called the bit synchronizer extracts timing pulses directly from the baseband signal, provided the signal meets certain requirements.

The Figure 4 screencast video discusses the bit synchronizer principles of operation and implementation considerations.

Figure 4: [video] Bit synchronizer principles of operation and implementation

As discussed in the previous video, the bit synchronizer's bandpass filter can be considered a high-Q resonator tuned to the bit rate, where Q stands for quality factor, the ratio of the bandpass filter's center frequency to its bandwidth; high Q indicates narrow bandwidth. The resonator produces sustained oscillations when the input bitstream contains approximately equiprobable ones and zeros. The high Q value assures that the resonator will continue to oscillate for a short time even when the bitstream has occasional runs of constant values. A high-Q resonator possesses inertia -- once oscillations have started, the resonator will continue to oscillate for a time, even without excitation. However, just as in any system with inertia, an inactive resonator requires excitation for a significant period of time before oscillation reaches a useful amplitude.

Now consider a receiver waiting for a signal, and suppose the transmitter only generates nonzero signals when it is actually sending a message. If the bitstream can only be sampled once the bit synchronizer "revs up," so to speak, how can the first few bits of the message be correctly sampled? In fact, the first few bits of the message could not be recovered this way. However, the transmitter is free to transmit additional bits before the message bits -- a preliminary bit sequence called a preamble.

The Figure 5 screencast video discusses the design of the preamble to accomplish two goals: (1) to "wake up" the bit synchronizer (more formally called channel seizure), and (2) to facilitate frame synchronization, the process of recovering meaningful symbols (ASCII characters, in this case) from the stream of ones and zeros.

Figure 5: [video] Preamble design for bit synchronizer "wake up" and frame synchronization

Consider once again the receiver block diagram of Figure 2. The threshold comparator (also called the decision device) follows the sampler and compares each sampled signal value to zero. A sampled signal value higher than the threshold is declared a binary 1, and a value lower than the threshold is declared a binary 0. The threshold comparator completes the bitstream regeneration process; in the absence of noise, the bitstream produced by the comparator is identical to the transmitted bitstream.

The last block in the receiver retrieves ASCII characters from the bitstream. The earlier Figure 5 screencast video briefly discussed the need for frame synchronization, which is now considered in more detail. Suppose the message preamble consisted only of the alternating one-zero pattern necessary to start the bit synchronizer. Certainly the total length of the preamble is known, so in principle it would seem that the first message bit could be determined after some well-defined number of cycles after the bit synchronizer starts up. The problem is that this "well-defined" number of cycles can vary slightly due to noise levels, signal amplitude, and many other variables; the first actual message bit cannot be determined reliably this way.

Also, suppose the individual ASCII bit patterns were all transmitted as one contiguous bitstream by packing all the 7-bit patterns one after another. If the first message could not be determined correctly, then all remaining bits would likewise be interpreted incorrectly. Good system design should be fault tolerant, meaning that an interpretation error on one character should not affect the entire message.

These problems are addressed by inserting framing bits around each ASCII character. The Figure 6 screencast video describes the concepts of framing bits and frame synchronization, and why a sequence of binary ones (also called the steady mark sequence) is an important second part of the preamble.

Figure 6: [video] Frame synchronization and steady mark sequence in preamble

Procedure

Text sender

Copy the application VI you completed at the end of the Binary ASK Transmitter project to a new VI named TextSender.vi. Be sure to use the version that includes raised cosine pulse shaping as an option.

Modify the message generation section to use util_BitstreamFromText.vi to convert a front-panel text control value into a bitstream.

Design a preamble sequence that satisfies the requirements for bit sync and frame sync described in the introduction. Concatenate the preamble to the beginning of the message bitstream.

Clearly state your preamble sequence in your report.

Use util_BitstreamToText.vi to display the complete transmitted message in hexadecimal format.

Listen to your transmitted ASK signal and view the power spectrum for several choices of bit rate, carrier frequency, and pulse shape.

The Figure 7 screencast video describes two different ways to form the preamble sequence, and describes how to choose the hexadecimal display modes for text controls and indicators.

Figure 7: [video] LabVIEW coding tips for preamble sequence and hexadecimal displays

Audio test signals

Record several receiver input signals as audio .wav files as test signals to save development time in the next section. Use sam_GrabAudioDynamic.vi to capture the audio and save to a .wav file using "Graphics and Sound | Sound | Files | Sound File Write Simple.vi" as shown in Figure 8.

Figure 8: Record receiver input audio test signals

Text receiver construction

Review the ASK receiver block diagram of Figure 2. Assemble your subVIs to create TextReceiver.vi according to the block diagram. Note that several of the blocks on the diagram are composed of two subVIs: (1) The "normalizer" includes regen_ExtractPreamble.vi and regen_NormalizeToPreamble.vi, (2) the "sampler" includes regen_BitSync.vi and regen_Sampler.vi, and (3) the "bitstream to text" block includes regen_FrameSync.vi and util_BitstreamToText.vi.

Remember to test as you build. Start with the input signal, add a processing block, and then add relevant waveform indicators to confirm correct operation before you proceed to the next processing block.

Include the following front panel control values:

• recorded .wav file -- path
• use recorded signal -- Boolean
• fs, sampling frequency [Hz] -- DBL
• fc, carrier frequency [Hz] -- DBL
• Tb, bit interval [s] -- DBL
• adjust sampling instant [% of bit interval] (0%) -- DBL
• receiver filter bandwidth [Hz] -- DBL

The following front-panel indicators, especially the waveform graph indicators stacked vertically in the order listed below, visualize the complete "inner workings" of the ASK demodulation, bit sync, and frame sync operations; these visualizations will greatly improve your understanding of the behavior of each major component of the receiver as well as their interrelationships:

• received signal -- the receiver input signal from the microphone or test file
• received spectrum -- with amplitude calibrated in dB
• receiver filter spectrum -- received filter output signal, with amplitude calibrated in dB and Y-scale to match the received spectrum; output of the receiver filter
• receiver filter -- receiver filter output signal
• baseband -- envelope filter output signal
• preamble -- regen_ExtractPreamble.vi output signal
• normalized baseband -- regen_NormalizeToPreamble.vi output signal
• baseband absolute value -- intermediate signal from regen_BitSync.vi
• bandpass filter -- intermediate signal from regen_BitSync.vi
• thresholded bandpass filter -- intermediate signal from regen_BitSync.vi
• baseband + sampling instants -- envelope detector and "actual sampling instants" from regen_Sampler.vi signals overlaid on the same waveform graph

Also include the following indicators on the front panel, clustered together below the vertical stack of waveform graphs:

• eye diagram -- waveform graph; output of the LabVIEW Modulation Toolkit "MT Format Eye Diagram.vi" to show the eye diagram of the baseband signal produced by the envelope detector
• preamble detected? -- Boolean from regen_ExtractPreamble.vi
• message detected? -- Boolean from regen_FrameSync.vi
• bitstream length -- length of bitstream produced by regen_FrameSync.vi
• bitstream -- Boolean 1-D array produced by threshold comparator
• bitstream (hex) -- text with hex display mode to show output of threshold comparator
• received message -- text produced by util_BitstreamToText.vi
• framing error? -- Boolean 1-D array produced by util_BitstreamToText.vi
• received frames -- Boolean 2-D array produced by util_BitsToWords.vi
• bit rate [Hz] -- reciprocal of bit interval, Tb

The Figure 9 screencast video shows a suggested front-panel layout for the text receiver.

Figure 9: [video] Recommended panel layout for the text receiver

References