# Connexions

You are here: Home » Content » Texting Over the Speaker-Air-Microphone (SAM) Channel

### Lenses

What is a lens?

#### Definition of a lens

##### Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

##### What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

##### Who can create a lens?

Any individual member, a community, or a respected organization.

##### What are tags?

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

#### In these lenses

• LabVIEW Digital Communications

This module is included inLens: Analog / Digital Communications with National Instruments LabVIEW
By: Sam Shearman

Click the "LabVIEW Digital Communications" link to see all content selected in this lens.

Click the tag icon to display tags associated with this content.

### Recently Viewed

This feature requires Javascript to be enabled.

### Tags

(What is a tag?)

These tags come from the endorsement, affiliation, and other lenses that include this content.

# Texting Over the Speaker-Air-Microphone (SAM) Channel

Module by: Ed Doering. E-mail the authorEdited By: Sam Shearman, Erik Luther, Brett Hern

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 module refers to LabVIEW, a software development environment that features a graphical programming language. Please see the LabVIEW QuickStart Guide module for tutorials and documentation that will help you: • Apply LabVIEW to Audio Signal Processing • Get started with LabVIEW • Obtain a fully-functional evaluation edition of LabVIEW

## Note:

Visit LabVIEW Setup to learn how to adjust your own LabVIEW environment to match the settings used by the LabVIEW screencast video(s) in this module. Click the "Fullscreen" button at the lower right corner of the video player if the video does not fit properly within your browser window.

## 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

1. Implement an ASK demodulator based on an envelope detector, a noncoherent detector
2. Appreciate the importance of a message preamble for successful receiver operation
3. Translate the ASK receiver block diagram into a LabVIEW block diagram

## Deliverables

1. Summary write-up of your results
2. Hardcopy of all LabVIEW code that you develop (block diagrams and front panels)
3. Any plots or diagrams requested

### Note:

You can easily export LabVIEW front-panel waveform plots directly to your report. Right-click on the waveform indicator and choose "Export Simplified Image."

## Setup

1. LabVIEW 8.5 or later version
2. Modulation Toolkit 4.0 or later version
3. Computer soundcard that supports full-duplex operation
4. Speaker
5. Microphone
6. Two computers (optional)

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

• Carlson, Crilly, and Rutledge -- Ch 14
• Couch -- Ch 3 and 5
• Haykin and Moher -- Ch 7
• Lathi -- Ch 13
• Proakis and Salehi (FCS) -- Ch 10
• Stern and Mahmoud -- Ch 5

## 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.

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.

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.

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.

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.

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.

## Procedure

### SubVI construction

Build the subVIs listed below. You may already have some of these available from previous projects.

Demonstrate that each of these subVIs works properly before continuing to the next part.

### 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.

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.

### 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.

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.

### Testing and demonstration

Debug and test your receiver with your pre-recorded audio .wav files. Once you are satisfied that your receiver works properly, run your text sender as a separate application. Your soundcard is likely full duplex, and so both the text sender and text receiver should be able to access the soundcard simultaneously. You may also like to work with a friend with his or her own computer to make the texting activity more interesting.

You may also want to experiment with full-duplex texting between two different machines. Choose two different carrier frequencies, one for your friend and another for yourself. Be sure to choose a bit rate and pulse shaping so that each of you only uses up to half of the available SAM channel bandwidth. Try relatively long messages and confirm that you can simultaneously send and receive messages. This is the essence of frequency division multiplexing.

## References

1. Carlson, A. Bruce, Paul B. Crilly, and Janet C. Rutledge, "Communication Systems," 4th ed., McGraw-Hill, 2002. ISBN-13: 978-0-07-011127-1
2. Couch, Leon W. II, "Digital and Analog Communication Systems," 7th ed., Pearson Prentice Hall, 2007. ISBN-10: 0-13-142492-0
3. Haykin, Simon, and Michael Moher, "Introduction to Analog and Digital Communication Systems," 2nd ed., Wiley, 2007. ISBN-13: 978-0-471-43222-7
4. Lathi, Bhagwandas P., "Modern Digital and Analog Communication Systems," 3rd ed., Oxford University Press, 1998. ISBN-10: 0-19-511009-9
5. Proakis, John G., and Masoud Salehi, "Fundamentals of Communication Systems," Pearson Prentice Hall, 2005. ISBN-10: 0-13-147135-X
6. Stern, Harold P.E., and Samy A. Mahmoud, "Communication Systems," Pearson Prentice Hall, 2004. ISBN-10: 0-13-040268-0

## Content actions

PDF | EPUB (?)

### What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

#### Definition of a lens

##### Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

##### What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

##### Who can create a lens?

Any individual member, a community, or a respected organization.

##### What are tags?

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks