Software radio prototype: An acoustic...

Software radio prototype:

An acoustic communicationsystem using OFDM signals

Oliver Charlesworth13th June 2006

4th Year Project Reportfor the degree of MEng in Electronic Engineering

Primary Supervisor: Dr. Yuriy ZakharovSecondary Supervisor: Prof. Alister Burr

Copyright © 2006, University of York. All rights reserved.

Abstract

A MATLAB-based implementation of an OFDM modem has been developed for use overan acoustic channel, operating at audio frequencies. The modem is capable of simplexoperation in a line-of-sight indoor environment, and in a transmission bandwidth of2 kHz, an uncoded BER of less than 10−5 has been demonstrated at a data rate of3.2 kbit/s using QPSK. A datagram protocol and GUI have also been implemented, thesecan be used to send text and images to demonstrate the operation of the modem.

Contents

I Introduction 6

1 Project introduction 71.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Prior art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Specific contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Constraints, assumptions and scope . . . . . . . . . . . . . . . . . . . . 10

1.4.1 Communication direction . . . . . . . . . . . . . . . . . . . . . . 101.4.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4.3 Signal-to-noise ratio (SNR) . . . . . . . . . . . . . . . . . . . . . 101.4.4 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4.5 Numeric precision . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4.6 Algorithmic complexity . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Literature survey 13

3 An overview of OFDM 143.1 Advantages and disadvantages . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Architectural scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Current implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

II Theoretical background 18

4 System model 194.1 FDM model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 OFDM model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 DFT-based implementation . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Use of a cyclic prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4.1 Vector interpretation . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.2 Scalar interpretation . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5 Practical aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1

Contents

4.5.1 Null sub-carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5.2 Coded OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Channel model 275.1 Static multipath model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Determining channel length . . . . . . . . . . . . . . . . . . . . . 285.1.2 Frequency selectivity . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Fading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Validity of discrete channel model . . . . . . . . . . . . . . . . . . . . . 30

6 Environment characterisation 326.1 Frequency selectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Fading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Noise and interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 Frequency synchronisation 387.1 Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.2 Hardware measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8 Timing synchronisation 418.1 The van de Beek estimator . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.1.1 Performance characterisation . . . . . . . . . . . . . . . . . . . . 438.1.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9 Channel estimation 469.1 Rationale for frequency-domain estimation . . . . . . . . . . . . . . . . . 469.2 Rationale for pilot-based estimation . . . . . . . . . . . . . . . . . . . . 46

9.2.1 Pilot patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479.2.2 Estimator categories . . . . . . . . . . . . . . . . . . . . . . . . . 47

9.3 DFT-based ML estimators . . . . . . . . . . . . . . . . . . . . . . . . . . 489.3.1 Comb pattern estimator . . . . . . . . . . . . . . . . . . . . . . . 499.3.2 Block pattern estimator . . . . . . . . . . . . . . . . . . . . . . . 529.3.3 Performance comparison . . . . . . . . . . . . . . . . . . . . . . . 529.3.4 Choice of pilot symbol values . . . . . . . . . . . . . . . . . . . . 53

9.4 Effects of a non-sample-spaced channel . . . . . . . . . . . . . . . . . . . 539.5 Incorporation of timing synchronisation . . . . . . . . . . . . . . . . . . 55

9.5.1 Timing-offset identification using phase rotations . . . . . . . . . 569.5.2 Timing-offset identification using peak detection . . . . . . . . . 569.5.3 Timing-offset identification using moments . . . . . . . . . . . . 56

2

Contents

9.5.4 Performance comparison . . . . . . . . . . . . . . . . . . . . . . . 579.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

10 Signal acquisition 5910.1 The Schmidl-Cox acquisition method . . . . . . . . . . . . . . . . . . . . 59

10.1.1 Similarity to van de Beek estimator . . . . . . . . . . . . . . . . 6110.2 Improved timing acquisition . . . . . . . . . . . . . . . . . . . . . . . . . 6210.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

III System implementation 63

11 Baseband integration 6411.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6411.2 Baseband testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6411.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

12 Live system integration 6612.1 Forming a passband system . . . . . . . . . . . . . . . . . . . . . . . . . 66

12.1.1 Problems with time-domain interpolation . . . . . . . . . . . . . 6712.1.2 Forming passband signal in the frequency domain . . . . . . . . 6812.1.3 Spectral limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

12.2 Choice of modulation scheme . . . . . . . . . . . . . . . . . . . . . . . . 7012.3 Working with audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7112.4 Running live tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

12.4.1 OFDM parameter settings . . . . . . . . . . . . . . . . . . . . . . 7212.4.2 Testing acquisition and synchronisation . . . . . . . . . . . . . . 7212.4.3 Initial BER measurements . . . . . . . . . . . . . . . . . . . . . . 7312.4.4 Finding optimum centre frequency . . . . . . . . . . . . . . . . . 7312.4.5 Finding optimum signal power . . . . . . . . . . . . . . . . . . . 7412.4.6 PC-to-PC communication . . . . . . . . . . . . . . . . . . . . . . 74

12.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

13 Sending useful data 7613.1 Datagram principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7613.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

13.2.1 Structure of text and image datagram headers . . . . . . . . . . 7713.3 Example output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7813.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

14 The GUI 79

15 Program design 80

3

Contents

15.1 Audio input and output . . . . . . . . . . . . . . . . . . . . . . . . . . . 8015.1.1 The Data Acquisition Toolbox . . . . . . . . . . . . . . . . . . . 81

15.2 Program structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8215.2.1 DataSource and DataSink interfaces . . . . . . . . . . . . . . . . 8215.2.2 CircularBuffer class . . . . . . . . . . . . . . . . . . . . . . . . . 8315.2.3 Transmitter and Receiver classes . . . . . . . . . . . . . . . . . . 8515.2.4 DatagramSource and DatagramHandler classes . . . . . . . . . . 8515.2.5 PilotGenerator class . . . . . . . . . . . . . . . . . . . . . . . . . 8515.2.6 Estimator interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8615.2.7 SimChannel class . . . . . . . . . . . . . . . . . . . . . . . . . . . 8715.2.8 Speaker and Mic classes . . . . . . . . . . . . . . . . . . . . . . . 8715.2.9 LiveChannel class . . . . . . . . . . . . . . . . . . . . . . . . . . 8715.2.10 SETTINGS structure . . . . . . . . . . . . . . . . . . . . . . . . 87

15.3 Use of the profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

IV Final comments 89

16 Further work 9016.1 Unresolved issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9016.2 Future projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

17 Conclusion 9317.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Appendices 95

A Derivation of the channel estimator MSE 96

B Derivation of some SNR relationships for baseband OFDM 98B.1 Baseband OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98B.2 Inclusion of pilots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100B.3 Inclusion of CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

C Equipment used 101

D Code listings 102D.1 class DatagramSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102D.2 class DatagramHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104D.3 class Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107D.4 class Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111D.5 class LiveChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117D.6 class Speaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

4

Contents

D.7 class Mic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120D.8 class CircularBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122D.9 class DataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125D.10 class DataSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127D.11 class Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129D.12 class PilotGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133D.13 Helper functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

D.13.1 getParams.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136D.13.2 setDerivedParams.m . . . . . . . . . . . . . . . . . . . . . . . . . 137D.13.3 bin2PSK.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139D.13.4 PSK2bin.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139D.13.5 MLS.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Summary of mathematical notation 141

Glossary of abbreviations 142

References 143

5

Part I

Introduction

6

Section 1

Project introduction

The subject of this report is a six-month MEng project, based on an investigation into thetheoretical techniques required to develop a modem capable of digital data transmissionin an indoor airborne acoustic environment, and the subsequent software developmentto realise this modem in real-time. The title of this project embodies three key concepts;software radio, acoustic communication, and OFDM, each of which is discussed below.

Orthogonal frequency-division multiplexing (OFDM) [1] is a data communication schemethat has found increasing popularity in the last two decades, particularly in the field ofdigital wireless applications, as it possesses certain properties that give distinct designand performance advantages over traditional single-carrier schemes in certain scenarios.These advantages have already been exploited in the development of international stan-dards, such as Wi-Fi networking and European digital TV and radio broadcasting, andmake OFDM a strong contender for future 4th-generation (4G) standards. OFDM isintroduced in more depth in Section 3.

The software radio paradigm [2] encompasses two key principles. Firstly, a significantproportion of the signal synthesis and recovery processes is performed digitally in soft-ware (or in firmware on an FPGA), so that the burden on analogue RF hardware isminimised. The second (and more important) principle is dynamic reconfigurability ofradio operation. A software radio allows real-time changes in parameters, and evenchanges in protocol. This concept is particularly suited to any application which relieson multiple orthogonal protocols, such as:

• Military field communication.

• Mobile telephony, where the rapidly-changing requirements of the last two decadesand lack of global standardisation have resulted in myriad overlapping physical-layer protocols, spanning 2G, 3G, and in the near future, 4G.

• Mobile computing connectivity, where technologies such as Bluetooth, Wi-Fi,WiMAX and telephony are often required simultaneously.

7

Section 1: Project introduction

Currently, these applications typically implement each protocol with a separate, ded-icated RF and baseband front-end, consuming space, power and production cost. Ifinstead, all the protocols could be implemented in software, these disadvantages wouldbe eliminated.

The field of acoustic data communication experiences relatively little attention or ex-posure, as the majority of commercial applications are far better suited by wired orRF-based wireless communication systems. However, there are some scenarios whichmandate the use of an acoustic medium, in particular:

Underwater communicationSea water exhibits high electrical conductivity (typically around 5 S/m), and sorapidly attenuates all but the lowest-frequency electromagnetic waves. This makesacoustic propagation an interesting candidate for communication in this environ-ment.

Audio watermarking and programme-specific informationWith the increasing ease of digital distribution of copyrighted music, digital rightsmanagement (DRM) technology is receiving considerable attention. Audio water-marking is one possible solution, and involves encoding DRM data as audio data,which is then superimposed onto the original audio signal. The encoding is ideallydesigned to exploit the human psychoacoustic response so that it is inaudible.

Programme-specific information is a similar concept; in this instance, the embed-ded data is meta-information about the audio programme, such as title, artist,source, and playlist information.

1.1 Rationale

The rationale for this project is two-fold:

• Whilst most communications systems operate at high data rates and high car-rier frequency, the maths that describes the system and channel phenomena (e.g.synchronisation, multipath and equalisation) is essentially the same at audio fre-quencies in an acoustic medium. Therefore, this is an excellent opportunity toinvestigate many of the techniques involved, whilst using a cheap, easily-accessibleplatform, as opposed to the esoteric RF hardware that would be required if thismodem were to be implemented at VHF or microwave frequencies.

Furthermore, designing and experimenting with possible algorithms is far easierto achieve in a software environment such as MATLAB than it would be in FPGAhardware as would be required for higher-frequency implementations.

• When implemented, the system will provide a tangible demonstration of an OFDMsystem in practice. The user will be able to alter system parameters and the

8


environment, and observe the effects these have, and will also be able to hear themodem operating.

1.2 Prior art

Acoustic modems are frequently the subject of undergraduate theses, and OFDM im-plementations are no exception. Whilst summaries of many of these previous attemptsmay be discovered via web search, specific details on performance characterisation areoften lacking. For example, Franz et al. [3] claim a data rate of 7 kbit/s over a distanceof 5 cm, although it is not clear what the transmission bandwidth was, nor the BERperformance. Bastidas et al. [4] claim a data rate of approximately 2 kbit/s, although noother performance details are given.

There are few commercial acoustic OFDM modems, and even fewer with publicly avail-able details of operation. One recent implementation was announced by the Japanesecompany NTT DoCoMo, with the development of a system for embedding digital datainto an existing audio stream, claiming data rates of up to 1 kbit/s.

1.3 Specific contribution

This project has resulted in the development of a real-time OFDM audio-frequencyacoustic modem, implemented in MATLAB under a Windows environment. The modemoperates between a speaker and microphone in simplex mode only, is self-synchronising,and capable of operating in a noisy indoor acoustic environment. In a transmissionbandwidth of 2 kHz, a data rate of an uncoded BER of 3.2 kbit/s has been demonstratedat a BER of 5× 10−6 (95% confidence interval [1.6× 10−6, 1.2× 10−5]).

A modular software implementation has been developed, allowing both real-time liveoperation and baseband simulations to be carried out. Most aspects of the system arepresented as configurable parameters; the individual modules automatically configurethemselves appropriately based on these parameters. The software has been designedso that its structure is easily reconfigurable; it may be arranged to provide PC-to-PCcommunication, single-PC (loopback) operation, PC-to-WAVE-file recording, or WAVE-file-to-PC playback and reception.

Furthermore, a high level of module decoupling has been achieved. For instance, thetransmitter and receiver are not hard-coded to any particular pilot pattern;1 variouspilot patterns are generated by an entirely separate module. Equally, the receiver is nothard-coded to any particular channel estimation scheme; instead an estimator interfacehas been provided. This potentially allows any estimation algorithm to be used, with anydegree of processing latency, as the receiver module will automatically adapt accordingly.This approach allows great flexibility in any future development work on the project.

1 The concepts of pilot patterns and channel estimation are introduced in Section 9.

9


One of the aims of the project has been to produce a tangible demonstration of theOFDM modem operating in real-time. To this end, a simple datagram protocol layerhas been developed, allowing the transmission of text and image files; both of theseformats are highly visual, allowing easy identification of data errors.

A graphical user interface (GUI) has also been developed, allowing the user to selectsource text and images, configure various modem parameters and explore their effect onperformance. Real-time graphical feedback of the internal operation of the receiver isalso displayed.

1.4 Constraints, assumptions and scope

There are many scenarios that a wireless communications system could exist in. Forexample, digital TV is a simplex, one-to-many, continuous-stream broadcasting schemewhere latency is not an issue, whereas Wi-Fi is a full-duplex, bursty, packet-based schemewith tough latency and multiple-access control requirements [1]. Naturally, this projectcould not aim to cover the properties of all scenarios, so some limits have been imposedon the range of scenarios to be covered.2

1.4.1 Communication direction

Due to the added complexity that would be involved with a duplex system, and thepractical aspects of a MATLAB implementation, the modem will be operated in simplexmode, i.e. strictly one-way communication. This implies that any protocol implementedover the modem must be a datagram-based, connectionless one, with no possibility ofre-transmissions.

1.4.2 Mobility

The transmitter and receiver will both be kept immobile during the course of commu-nication. This reduces two major sources of Doppler shift, which reduces the burden onvarious synchronisation and estimation algorithms in the receiver.

1.4.3 Signal-to-noise ratio (SNR)

Obviously, with the benefit of a mains power-supply, there is no inherent restriction onthe transmit power, so in theory SNR could be made arbitrarily large, providing anarbitrarily large increase in modem performance.

In practice, however, transmit power is fundamentally limited by the rating of thespeaker(s), and channel attenuation is a function of separation distance. As will be

2 This section was originally presented in the Initial Report, and has been reproduced here for thesake of completeness, along with some additional points.

10


shown, in the case of OFDM, a tighter limit exists due to the non-constant amplitudeof the signals produced.

1.4.4 Application

For the sake of generality, it has been assumed that the modem is to be used to transmitarbitrary data, i.e. no a priori information about the user data will be exploited (asa counter-example, UMTS applies greater protection to certain bits because they areknown to be more important for voice reproduction quality [5]). Also, it is assumed thatthe user data will be independently and identically distributed (i.i.d.).

Whilst for many real applications, aspects such as low latency and short acquisitiontime are extremely important, for the sake of this project, these factors will be ignored.

1.4.5 Numeric precision

Finite numeric precision has several critical implications, including:

• Signal quantisation, leading to:

– Increased wideband noise, and a decreased SNR,

– Possible limit cycles in otherwise stable recursive filters.

• Filter coefficient quantisation, which may give non-optimally positioned poles andzeros, which in turn may lead to:

– Altered spectral response,

– Instability.

In a practical application, numeric precision will almost certainly be more limited thanthat of the MATLAB platform being used in this project – most embedded proces-sors, DSPs and FPGAs will not be able to offer double-precision (64-bit) floating-pointsupport; indeed, many platforms do not provide native floating-point support at all.

Therefore, in comparison with a typical 16-bit hardware implementation, for instance,MATLAB could be regarded as having “infinite” precision. Adopting this assumptionhas allowed greater focus to be placed on the mathematical aspects of the algorithmsbeing used, rather than the finer details of how to implement them in practice.

1.4.6 Algorithmic complexity

In a similar vein to the last point, the computational resources of a practical embed-ded platform are inherently limited due to power, board space, and cost. Very often,algorithms must undergo considerable simplification and approximation before they aresuitable for an embedded target, usually at the expense of performance. Running on amodern Pentium 4 or AMD Athlon platform – as in this project – greatly reduces the

11


need to make such trade-offs. However, the capability of eventual target platforms hasbeen kept in mind whilst choosing algorithms for this project; there is little point increating a demonstration modem based on a design which is completely intractable ina realistic setting.

The MATLAB profiler has been used to identify algorithmic bottlenecks and hotspots,and changes made where appropriate. It is worth noting, though, that MATLAB hasbeen specifically designed to trade efficiency for increased code clarity; in other words,measuring performance on a MATLAB platform is not necessarily a reliable indicatorof the relative performance of optimised code on another platform.

1.5 Report structure

This report summarises the work carried out since the Initial Report [6] was written.

In this part, a brief summary of the literature sources surveyed is presented, followedby a qualitative overview of OFDM.

Part II introduces the theoretical framework that the modem is based on. First, suitablesystem and channel models are introduced. Next, solutions are presented to the keyproblems of frequency and timing synchronisation, channel estimation and correction,and signal acquisition.

Part III documents the implementation of the complete modem in software, first asa baseband simulation, and then as a live passband system. The results of variousperformance tests are also summarised.

Finally, Part IV discusses further work that could be done to improve the system,including suggestions for future project topics, and then presents an overall conclusionof the work carried out for this project.

12

Section 2

Literature survey

The basic principles of OFDM operation (as covered in Section 4) are explained incountless books and online resources. However, there are few resources readily availablethat specifically deal with the more involved aspects of an OFDM implementation.However, a book by van Nee and Prasad [1] presents an overview of subjects such assynchronisation, pilot-based estimation, PAPR reduction and coding, and provides someuseful references to previous work.

On the other hand, the academic literature consists of many hundreds of papers onOFDM; in general, the best quality papers can be found in the IEEE Transactions onCommunications, Signal Processing and Information Theory. Selecting the most use-ful of these papers has been a difficult process, as many of them present incrementalimprovements on previous work, or contain irrelevant or impractical proposals. Rele-vant papers are introduced separately in each of the sections in Part II on frequencysynchronisation, timing synchronisation, channel estimation, and signal acquisition.

More general communications topics are covered in great detail in books by Proakis [7]and Rappaport [8]; these have been particularly useful for gaining an understanding ofchannel-related effects, and also as a background reference to enable comprehension ofthe more involved academic papers. Mathematical topics related to stochastic parameterestimators are covered by Scharf [9], and to a lesser extent by Sayed [10].

13

Section 3

An overview of OFDM

OFDM is a data transmission technique, its key feature being the use of multiple carriersto transmit several data streams in parallel, whose frequencies are chosen to provideorthogonality. In this respect, it is a special case of frequency division-multiplexing(FDM) (or multi-carrier modulation (MCM)).

A traditional FDM transmitter [11] modulates data onto independent carriers (com-monly known as sub-carriers), each running at a different frequency. The receiver willrecover the data by first isolating each sub-carrier using a bank of band-pass filters, andthen demodulating each separately.

OFDM is an extension of this principle, offering the following advantages over FDM:

• In an FDM system, the spectra of the sub-carriers must be separated by frequency-domain guard intervals, to allow for the finite roll-off of the non-ideal band-passfilters. This leads to an inefficient use of the available bandwidth.

OFDM, on the other hand, allows the sub-carrier spectra to overlap, maximisingspectral usage, as illustrated in Figure 3.1.

• An FDM system typically requires a bank of RF oscillators in both the transmitterand receiver, one for each sub-carrier.

In an OFDM transmitter, however, the mathematical relationship between thesub-carriers allows baseband generation using an IDFT (or IFFT), which maythen be mixed up to RF with a single oscillator. Equivalently, in the receiver, asingle RF oscillator may be used to bring the sub-carriers down to baseband, wherethey are then separated using a DFT (or FFT). This is illustrated in Figures 4.2and 4.3.

• For similar reasons, an OFDM system does not require a band-pass filter bank inthe receiver.

These ideas will be described more fully in Section 4.

14

Section 3: An overview of OFDM

f0 f1 fN−1fN−2

f0 fN−1

(a)

(b)

Guardband

1/T

Figure 3.1: Comparison of spectra. (a) FDM; a frequency-domain guardband is required between each pair of sub-carriers. (b) OFDM; the sub-carrier

spacing has been reduced to 1/T .

It is important to note that OFDM is not considered a spread-spectrum technique.Neglecting sidelobes, an OFDM system requires a similar bandwidth to a single-carriersystem operating at an equivalent baseband bit rate.

3.1 Advantages and disadvantages

OFDM has several advantages [1] over a single-carrier system of an equivalent bit rate,that make it particularly attractive for wireless systems:

Reduced ISIThe OFDM symbol period is much longer, leading to proportionally lower ISI(inter-symbol interference) for a given channel delay spread. ISI may be eliminatedaltogether by appropriate use of a time-domain guard interval, in the form of acyclic prefix (CP), described in Section 4.4.

Simplified channel equalisationIf the sub-carrier spacing is chosen appropriately, the channel frequency responsemay be modelled as flat on a per sub-carrier basis. This can greatly simplify the de-sign of the receiver equaliser, replacing the multi-tap time-domain equaliser (TEQ)commonly used for single-carrier systems with a bank of single-tap frequency-domain equalisers (FEQ).

15


Adaptive loadingSub-carrier loading (i.e. the bit rate per sub-carrier) may be non-uniform. Thisallows, for instance, sub-carriers with lower SNRs to be modulated with a constel-lation with a larger Euclidean distance.

DiversityFrequency diversity may be easily exploited, in the form of coding and interleavingthat spread codewords across the sub-carriers.

However, there are also disadvantages to the use of OFDM which must be considered:

Synchronisation requirementsReceiver synchronisation must be far more accurate than for a single-carrier sys-tem, both in frequency and time. Synchronisation errors cause large degradationsin BER performance. The phase noise of the receiver LO must also be tightlycontrolled

Reduced spectral efficiencyUse of the CP reduces symbol rate and consumes transmit power, leading to areduced spectral efficiency.

PAPROFDM waveforms tend to have a high PAPR (Peak-to-Average Power Ratio),requiring a more linear power amplifier, and a DAC with a greater dynamic range.In general, this will lead to increased transmitter cost and power consumption.

3.2 Architectural scenarios

There are three potential architectural scenarios that advocate the use of OFDM,namely:

• Single data-source transmission, utilising all carriers

• Multiplexing of many independent data sources

• Multiple-access control

At present, the first scenario is by far the most common use of the OFDM principle,although the multiple-access scenario is now also being put into practice in the form ofOFDMA (Orthogonal frequency-division multiple access).1

This project will be considering only the first scenario; however, many of the principlesand techniques observed will be applicable to the others.

1 OFDMA is one of the options available for the 802.16 PHY [12], and is being considered for the802.22 PHY [13].

16


Scheme 802.11a+g 802.16 DVB DAB2K mode 8K mode

Num. of sub-carriers 52 200 1705 6817 1536Num. of pilots 4 7 193 769 0Sub-carrier spacing 312.5 kHz Variable 4.464 kHz 1.116 kHz 1 kHzCyclic Prefix length 1/4 1/4, 1/4, 1/4

1/8, 1/8,1/16, 1/16,1/32 1/32

Constellation BPSK, QPSK, QPSK, DQPSKQPSK, 16-QAM, 16-QAM,

16-QAM, 64-QAM 64-QAM64-QAM

Table 3.1: Parameter comparison of OFDM-based standards.

3.3 Current implementations

At present, OFDM forms the physical layer (PHY) of several digital communicationstandards. The most important of these are summarised here; a comparison of their keyfeatures is given in Table 3.1.2

DVB-T and DVB-H [15]European Digital TV standard for terrestrial targets (DVB-T); extended to coverhandheld devices (DVB-H).

DAB [16]European Digital Radio standard.

IEEE 802.16 (WiMAX) [12]IEEE global standard for Wireless Metropolitan Area Networks (WMAN).

IEEE 802.11a+g (Wi-Fi) [17]IEEE global standards for Wireless Local Area Networks (WLAN).

G.DMT ADSL [14]ITU standard for ADSL.

2 The specification for G.DMT [14] could not be accessed, so its parameters cannot be listed here.

17

Part II

Theoretical background

18

Section 4

System model

This section offers a brief description of the operation of discrete-time OFDM model,starting with its roots in continuous-time FDM, and will introduce some of the keymathematical notation that will be used throughout the rest of this report. A readerfamiliar with the operation of OFDM may skip this section.

4.1 FDM model

OFDM is a special case of FDM. In its simplest form, an FDM system can be viewed as aset of multiplexed parallel transmission channels, each operating at a different frequency,as shown in Figure 4.1.

Assuming these channels are synchronised, i.e. they each operate at the same symbolrate, and transitions on all symbol streams occur at the same times, the output can beexpressed as:

s(mT + t) =1√N<

{N−1∑k=0

Xk,m ej2πfk[mT+t]

}(4.1)

Figure 4.1: Block diagram of an FDM system. Symbol index m omitted forclarity.

19

Section 4: System model

where k is the sub-channel (frequency) index, m is the symbol (time) index, T is thesymbol period, the {fk} are the centre frequencies of the sub-channels, and the {Xk,m}are the complex data symbols to be transmitted. The purpose of the 1/

√N scaling factor

will become apparent later.

4.2 OFDM model

The FDM system is converted to an OFDM system by ensuring that the sub-carriers areorthogonal over each symbol interval, which is achieved by setting the frequency spacingbetween adjacent sub-carriers, ∆f = fk+1 − fk, to 1/T . The OFDM output waveformcan therefore be expressed as:

s(mT + t) =1√N<

{N−1∑k=0

Xk,m ej2π[fc+k∆f ][mT+t]

}(4.2)

where fc is some overall frequency offset.

The equivalent baseband signal is given by:

x(mT + t) =1√N

N−1∑k=0

Xk,m ej2πk∆ft (4.3)

There are two advantages to this development over FDM:

• Orthogonalisation means that no explicit filters are required to isolate the indi-vidual sub-carriers at the receiver; instead, the incoming OFDM symbols may beprojected onto the orthogonal basis functions given by:

vk(t) =1√N

e−j2πk∆ft, k ∈ [0, N), t ∈ [0, T ) (4.4)

• The spectra of the individual sub-carriers overlap, greatly reducing the overallbandwidth required for a given data rate. This difference is illustrated in Fig-ure 3.1.

In discrete-time notation, as is more appropriate for a DSP-based solution, we define aset of samples of this signal, xm[n] = x([m + n/N]T ), whose values are given by:

xm[n] =1√N

N−1∑k=0

Xk,m ej2πkn

N (4.5)

20


Figure 4.2: Block diagram of an IDFT-based OFDM transmitter. Symbolindex m omitted for clarity.

Figure 4.3: Block diagram of a DFT-based OFDM receiver. Symbol indexm omitted for clarity.

4.3 DFT-based implementation

(4.5) is in the form of a unitary inverse discrete Fourier transform (IDFT), i.e. thesamples {xm[0], xm[1], · · · , xm[N−1]} in the m-th symbol period are given by the unitaryIDFT of the corresponding data values {X0,m, X1,m, · · · , XN−1,m}:

xm[n] = DFT −1k {Xk,m} (4.6)

This not only confirms that the waveforms constitute an orthogonal basis, but also givesa clue as to how the transmitted signal may be synthesised. Figure 4.2 demonstratesthe principle. Note that the output of the IDFT is generally complex, so the mixer isactually a quadrature mixer, with only the real output taken.

First, an IDFT converts the incoming data symbols into the time-domain sample set{xm[n]} in a block-by-block fashion. Each block is multiplexed by a parallel-to-serialconverter (denoted P/S), and the serial stream is then converted to the continuous-timesignal x(t). x(t) is up-converted to the carrier frequency, giving the passband signals(t), which is then transmitted.1

The receiver shown in Figure 4.3 uses the inverse process. The received signal r(t) isfirst down-converted to baseband y(t), and then converted to the discrete signal ym[n].Each time-domain block is demultiplexed by a serial-to-parallel converter (denoted S/P),

1 Note that several practical details have been omitted from this description, such as the use of anIF stage, signal shaping, and RF band-shaping filters.

21


and a DFT is then performed to recover the data symbols. This process is expressedmathematically as:

Yk,m = DFT n{ym[n]} (4.7)

In a software radio implementation of the transmitter, the up-conversion may be per-formed in discrete time by up-sampling x[n] and sinc-filter interpolation, before beingpassed to the DAC. A similar software approach may be used for the down-conversionin the receiver.

The use of an IDFT and DFT allows the signal to be synthesised and analysed atbaseband without the need for multiple phase-coherent oscillators. Efficiency can befurther improved by using an IFFT/FFT implementation.

4.4 Use of a cyclic prefix

A cyclic prefix (abbreviated CP) is a time-domain technique for maintaining orthogo-nality of the OFDM symbols and sub-carriers in a frequency-selective channel. Its effectwill be examined in both a scalar system representation, and also in a more useful vectorrepresentation. We start with the vector interpretation.

4.4.1 Vector interpretation

The scalar equations of (4.6) and (4.7) may be re-written in vector notation, as:

xm = Q∗Xm (4.8)

Ym = Qym (4.9)

where xm =[xm[0] xm[1] · · · xm[N − 1]

]Tand Xm =

[X0,m X1,m · · · XN−1,m

]T

are vectors containing the time-domain samples and data values corresponding to them-th transmitted OFDM symbol, respectively, ym and Ym are vectors containing thetime-domain samples and data values corresponding to the m-th received OFDM sym-bol, respectively, and Q is the unitary DFT matrix, given by:

Q =1√N

W−0.0N W−0.1

N · · · W−0.(N−1)N

W−1.0N W−1.1

N · · · W−1.(N−1)N

...... . . . ...

W−(N−1).0N W

−(N−1).0N · · · W

−(N−1).(N−1)N

(4.10)

where WN = ej2π/N is the DFT twiddle factor.

In the absence of noise, ym = xm. Substituting into (4.8) and (4.9), we see that the

22


original data symbols are recovered:

Ym = Qxm (4.11)

= Q(Q∗Xm)

= Xm

However, in the presence of a linear time-invariant (LTI) frequency-selective channelcharacterised by a finite-length impulse response given by {h[0], h[1], · · · , h[L− 1]}, thefollowing relationship holds:

ym =

h[L− 1] · · · h[1]h[L− 1] · · ·

. . .

xm−1

+

h[0]h[1] h[0]

...... . . .

h[L− 1] · · · h[1] h[0]h[L− 1] · · · h[1] h[0]

. . . ...... . . .

h[L− 1] · · · h[1] h[0]h[L− 1] · · · h[1] h[0]

xm

, h′′xm−1 + h′xm (4.12)

If we now apply the DFT-based recovery as before:

Ym = Qym

= Q(h′′xm−1 + h′xm)

= Qh′′Q∗Xm−1 + Qh′Q∗Xm (4.13)

Clearly, there is ISI, as both the m-th and (m − 1)-th transmitted blocks contributeto the m-th received block. Furthermore, Qh′Q∗ is non-diagonal, which destroys thesub-carrier orthogonality, resulting in ICI.

If a time-domain guard interval of length L or longer is introduced between successive

23


Figure 4.4: Use of a cyclic prefix (CP) as a time-domain guard interval.

blocks, then h′′ = 0, hence the ISI is eliminated. If a CP, explained below, is used asthe guard interval, then the ICI is eliminated as well.

A CP of length L is formed from the last L samples of the time-domain block, asillustrated in Figure 4.4. In the same noiseless frequency-selective channel as before, thereceived block is now given by:

ym =

h[0] h[L− 1] · · · h[1]h[1] h[0] h[L− 1] · · ·

...... . . . . . .

h[L− 1] · · · h[1] h[0]h[L− 1] · · · h[1] h[0]

. . . ...... . . .

h[L− 1] · · · h[1] h[0]h[L− 1] · · · h[1] h[0]

xm

, hxm (4.14)

h is in circulant form, and is therefore diagonalised by the DFT matrix. Performing theDFT recovery now gives:

Ym = Qym

= QhQ∗Xm

= HXm (4.15)

where H = diag{H0,H1, · · · ,HN−1} contains the eigenvalues of h, and may be inter-preted as the frequency-domain representation of the channel.

4.4.2 Scalar interpretation

The orthogonalising property of the CP also has a scalar interpretation. The receivedtime-domain series y[n] is formed from the linear convolution of the transmitted time-

24


domain series x[n] and the channel impulse response h[n], i.e.:

y[n] = h[n] ∗ x[n] (4.16)

Use of the CP transforms this linear convolution into a circular convolution on a block-by-block basis, which may be denoted thus:

ym[n] = h[n]~N

xm[n] (4.17)

The discrete convolution theorem states that circular convolution in one domain is equiv-alent to direct multiplication in the transform domain, hence taking the DFT of (4.17)gives:

Yk,m = HkXk,m (4.18)

4.5 Practical aspects

4.5.1 Null sub-carriers

In a practical hardware-based OFDM system, use of a DC sub-carrier at basebandrequires the ADC in Figure 4.2 to have negligible DC output offset and drift, and thatall analogue circuitry up to the mixer is DC-coupled. This is often difficult, so in somesystems (e.g. DAB [16]) the DC sub-carrier is not used, and set to zero.

In order to perform discrete pulse-shaping for sidelobe suppression, the baseband time-domain vector xm must be oversampled. In practice, this is usually achieved by zero-padding the frequency-domain vector Xm before applying the IDFT. The zero valuesused are exactly equivalent to unused extra sub-carriers, and so are often known asvirtual sub-carriers (VSCs).

4.5.2 Coded OFDM

All practical OFDM systems use FEC coding to reduce error ratio. Whilst this is truefor single-carrier systems as well, there are further reasons for why coding is particularlybeneficial in OFDM.

The overall BER in an uncoded OFDM system (or a system where each sub-carrier iscoded independently) is given by:2

BER =1N

N−1∑k=0

BERk (4.19)

where BERk is the BER of the k-th sub-carrier.2 This assumes that each sub-carrier carries the same bit rate.

25


In such systems, BER performance is dominated by the sub-carriers with the lowestSNR, as these will have BERs that are greater by perhaps an order of magnitude ormore [1]. If coding is instead performed across sub-carriers, or alternatively the codedsub-carrier data streams are interleaved, then each stream experiences the same SNR,which leads to better BER performance.3

3 Historically, this use of coding in OFDM used to be known as Coded OFDM (COFDM), e.g. [18].However, this is now considered such an integral part of any OFDM implementation that this term issomewhat redundant.

26

Section 5

Channel model

The transmission medium for the system is a wireless acoustic channel. In an enclosedspace such as a room, this should certainly be considered a multipath environment,and the channel is therefore frequency-selective, not AWGN. If the physical objects(including the air) that make up this environment are non-static, then the channel willalso be time-variant, perhaps leading to significant fading effects.

This section first discusses the mathematical model that should be used to describe theseeffects, both in order to form a suitable baseband simulation, and also to allow suitableparameters to be chosen for the live system. Next, some potential problems with thetraditional discrete model are investigated.

Some of these effects are characterised in Section 6.

5.1 Static multipath model

Each multipath component undergoes a different path length between transmitter andreceiver, so experiences a specific propagation delay. It also experiences a specific pathloss, as well as further losses induced by reflections from absorptive surfaces.

The electromagnetic channel model used in the majority of OFDM literature is based onthe above description, and uses the following discrete filter representation, in passbandform:

hBP [n] =I∑

i=1

αiδ[n− ni] (5.1)

where {αi, ni} are the amplitude and excess delay (in samples) of the i-th multipathcomponent, and I is the number of multipath components.

For the purposes of this project, it is assumed that the same model will hold for anacoustic medium. This assumption relies on all effects being linear, and all reflectionsbeing specular.1

1 A diffuse reflection will lead to a continuum of multipath components, and the summation of (5.1)

27

Section 5: Channel model

When converted to baseband, (5.1) becomes:2

h[n] =I∑

i=1

αiej2πfcniδ[n− ni] (5.2)

where there is now a complex rotation factor, so h[n] is complex, in general.

For an outdoor environment, FIR behaviour is usually assumed, so I is finite. However,in an indoor environment, IIR behaviour is to be expected, as reflections will occurindefinitely, bouncing from wall to wall (essentially the room acts as a recursive filter).This would require I = ∞.

Even so, for the purposes of this project, an FIR channel model will be used. The IIRwill exhibit approximately exponential decay,3 and so will be negligible beyond a certainpoint. Use of this model greatly simplifies symbol recovery, as it allows formation of h,and therefore H (as defined in Section 4.4).

5.1.1 Determining channel length

It is the maximum excess delay, Γ, which for the purposes of the project will be knownas the channel length, that governs the choice of CP length; we need L > ΓMAX, whereΓMAX is the maximum allowable channel length.

Figure 5.1 shows a typical indoor acoustic impulse response, with power (magnitudesquared) on a logarithmic scale; the exponential IIR decay is clearly visible as a constantnegative gradient. This illustrates the difficulty in determining Γ in practice; a somewhatarbitrary threshold would have to be set. Another, more tangible, measure is the RMSdelay spread, σt, which is the square root of the second central moment of |h[n]|2.However, this does not help in determining CP length.

The channel lengths involved will certainly be in the order of tens or hundreds of mil-liseconds; this can be justified by considering a typical residential room space with amajor dimension of around 5 m. Along this dimension, the first reflection will be delayedby d/v = (5 m / 340 m/s) ≈ 15 ms (where v = 340 m/s is the speed of sound in air). Furtherreflections along this dimension will occur at multiples of 15 ms.

Clearly, the larger the room, the greater the delay on non-line-of-sight components,which will generally lead to an increase in the delay spread at the receiver. This is not aproportional relationship, however, as these components also undergo greater path lossin a larger room.

would become an integral.2 h[n] and hBP [n] maintain the standard passband-to-baseband relationship:

h[n] = <n

hBP [n]ej2πfcno

3 This is the case for any stable, causal, recursive filter.

28


0 0.02 0.04 0.06 0.0810

−4

10−3

10−2

10−1

100

101

102

103

104

Excess delay (s)

Impu

lse

pow

er

Figure 5.1: Typical indoor acoustic impulse response (Figure 6.2(a)), inpower form.

5.1.2 Frequency selectivity

The baseband time-domain model of (5.2) can be transformed to the frequency domain:

Hk = DFT n{h[n]}

=I∑

i=1

αiej2π[fc− k

N ]ni (5.3)

where the {Hk} are those of (4.18).

This shows that the phase-shifts and amplitudes (and therefore SNRs) on individualOFDM sub-carriers are directly determined by the channel impulse response.

5.2 Fading

If there are mobile scatterers in the environment (e.g. people), then some of the multipathcomponents will be time-variant; their relative delays and amplitudes will alter withtime. Movement of air may also cause small Doppler effects. This can be modelledby taking the LTI baseband channel model of (5.2) and allowing the parameters to befunctions of time.

h[n, ν] =∑

i

αi[ν]ej2πfcni[ν]δ[n− ni[ν]] (5.4)

The variation of the {αi[ν], ni[ν]} with ν is known as fading. If the channel is quasi-static for the duration of an OFDM symbol, then the channel is broadly classified as slowfading, otherwise it is classified as fast fading. A fast fading channel greatly complicatesthe maths of symbol recovery presented in Section 4.4, so for the sake of simplicity aslow fading channel will be assumed for the purposes of this project; this assumption is

29


justified in Section 6.2.

The line-of-sight path would normally imply Ricean-like statistics [8, p. 212]; however,a small enclosed environment with highly reflective surfaces could give delayed compo-nents of a similar magnitude to the line-of-sight component, so this assumption is notnecessarily valid.

5.3 Validity of discrete channel model

The traditional discrete channel model of (5.2) presented in many of the papers surveyedhas one major drawback; there is zero chance of it being a representative model of aphysical channel, as the actual channel has a continuous impulse response.

To understand why this is a problem in an OFDM system, we must refer back to thematrix model of the system, and note that in order to diagonalise the baseband channelmatrix h as in (4.15), it must first be possible to describe the channel in terms of amatrix. For this to be the case, the continuous channel must be modelled as a sum ofweighted sample-spaced delayed components, thus:

h(t) =∑

i

αiδ(t− qiTs), qi ∈ Z+ (5.5)

where Ts is the sample period.

A more realistic model is that these components are not necessarily sample-spaced,i.e. we should remove the integer restriction on the {qi} in (5.5), which can now bere-written:

h(t) =∑

i

αiδ(t− τi) (5.6)

Clearly, a time-domain channel matrix h can no longer be formed, but we can continueto analyse the effect using scalar equations.

Forming h[n] from h(t) can be regarded as a low-pass sampling process:

h[n] = {h(t) ∗ s(t)}|t=nTs (5.7)

where for perfect band-limiting, s(t) = sinc(πt/T).

The sampling effect on two impulse components from (5.6) is shown in Figure 5.2. Ass(t) satisfies the Nyquist criterion, the sample-spaced component gives h[n] = 0, exceptfor the n that coincides with the impulse position. However, the non-sample-spacedcomponent gives h[n] 6= 0 for all n. Therefore, for a non-sample-spaced channel, thediscrete response h[n] is an IIR filter.

This presents a number of problems:

30


0 1 2 3 4 5 6 7 8 9 10t/T

s, sampling index n

h(t)

, h[n

]

Sample−spacedcomponent Non−sample−spaced

component

Figure 5.2: Effect of sampling band-limited impulses.

• h[n] is now longer than the CP, so there will be ISI, even for a continuous-timechannel h(t) which is shorter than the CP.

• As a further consequence of h[n] being longer than the CP, the circular convolutionassumption no longer holds, hence the diagonalisation of the channel matrix in(4.15) no longer occurs. This results in ICI.

• DFT-based channel estimation schemes (see Section 9.3) essentially window h[n]with a rectangular window of length L. This will truncate an IIR h[n], resulting inspectral leakage (Gibbs’ phenomenon) in the frequency-domain channel estimate.

31

Section 6

Environment characterisation

In order to perform representative software simulations and make informed design de-cisions, it is necessary to characterise the transmission environment. In this sense, theterm “environment” encapsulates the behaviour of all components between the trans-mitter and receiver software of which there is no design control, namely:

• Soundcards

• Audio amplifier

• Loudspeaker(s)

• Microphone(s)

• Acoustic channel, including:

– Multipath effects and path loss

– In-band noise and interference

This concept is illustrated in Figure 6.1.

Figure 6.1: System diagram. The “environment” is encapsulated within thedotted lines.

32

Section 6: Environment characterisation

Any noise, non-linearities, and frequency or time selectivity exhibited by any of thecomponents listed above will combine; therefore for the purposes of this project, theenvironment can be considered as a single black box. This simplifies characterisation;for instance, the frequency response of the amplifier, speaker, microphone and channelwill all contribute to the effective channel length, Γ.

This section explains a set of acoustic measurements taken to characterise the noiselevels, frequency-selectivity and time-variance of a typical indoor environment. However,in such an environment, the nature of the frequency-selective response is dependenton many factors, such as room dimensions, wall material, and presence of obstacles(absorptive or reflective). These will vary greatly from room to room, so it is doubtfulthat a useful representative model can be obtained. The best we can hope to do isidentify trends such as the presence of a prominent line-of-sight peak component, andtypical values for delay spread.

6.1 Frequency selectivity

Theoretically, all that is needed to measure impulse response is a true impulsive source(i.e. x(t) = δ(t) in continuous time, or x[n] = δ[n] in discrete time). In practice, δ(t) isphysically unrealisable. δ[n] is realisable, but injects very little energy into the channel,thus measurements will be well below the noise floor.1 Instead, an alternative widebandsource is required, with a much lower PAPR to allow high SNR measurements.

Typically, a maximal length sequence (MLS, also known as an m-sequence) is used. AnMLS is a bipolar binary sequence of length 2m − 1, m ∈ Z+, and can be generated bya length m shift register with a set of feedback taps and XOR gates.2 Their use forthis purpose (especially for audio characterisations) is well documented, but some keyproperties will be summarised here:

1. PAPR = 1, the minimum possible.

2. Autocorrelation function is a very close approximation to an impulse train:

rxx[ν] =

2m, ν = k(2m − 1), k ∈ Z

−1, otherwise(6.1)

3. Flat frequency response, except for a near-zero DC component.

Property 2 ensures that the chance of a shift ambiguity is extremely unlikely, whilstProperty 3 ensures that the SNR is constant across the measurement bandwidth.

1 The alternative is to increase amplitude, but this is limited by the capabilities of the audio amplifierand speakers, and will introduce non-linear distortion if increased beyond a certain level.

2 Perhaps surprisingly, MATLAB supplies no function for generating MLS; therefore, the functionMLS() (see Appendix D.13.5) has been written for this purpose, using the polynomials given in Proakis[7, p. 436].

33


0 50 100 150t (ms)

h(t

)

0 2 4 6 8 10f (kHz)

|H(f

)|2

0 50 100 150t (ms)

h(t

)

0 2 4 6 8 10f (kHz)

|H(f

)|2

(a) (b)

(c) (d)

σt = 11.2ms

σt = 23.1ms

Figure 6.2: Acoustic impulse responses and frequency responses of twodifferent rooms.

The following observations are made:

• In order to avoid time-domain aliasing of the estimated impulse response, the MLSused must be longer than the channel response.

• The DFT-based estimation of frequency response requires that the signal block hasundergone circular convolution (for the same reasons as described in Section 4.4).To this end, a CP must be used. For the sake of simplicity, the MLS may just berepeated (i.e. a CP length of 100%).

• The SNR may be increased by a factor of N by averaging over N measurements,assuming that the channel is time-invariant over the entire measurement window.In practice, this is most efficiently achieved by transmitting the MLS N +1 times,and taking FFTs of all but the first captured MLS block, as each block will act asthe CP for the next.

Figure 6.2 shows typical results obtained for two rooms of different sizes, clearly showingthe effect on channel length and delay spread. (a) and (b) correspond to a room withapproximate dimensions 4 m × 2.5 m × 2.5 m (length × width × height); (c) and (d)correspond to a room of 6 m × 3 m × 2.5 m. Note that the spectral null at 6 kHz in

34


−40

−20

0

20

40

60

80

nk

|S[n

,k]|2

(dB

)

Figure 6.3: Acoustic channel scattering function (decimated for clarity).

each graph can be attributed to a notch in the microphone response; see Figure C.1.As expected, there is a prominent peak at the beginning of each time-domain response,corresponding to the line-of-sight path which has not undergone any absorptive loss.

6.2 Fading

In order to characterise the time-variant nature of the channel, the MLS-based mea-surement scheme may be used again. This time, however, the results are used to form a2-dimensional scattering function. Proakis gives the continuous-time scattering function,S(τ, λ), as the following Fourier transform [7, p. 807]:

S(τ, λ) =∫ +∞

−∞rhh(τ,∆t)e−j2πλ∆td∆t (6.2)

where rhh(τ, t) is the channel autocorrelation function, given as:

rhh(τ,∆t) = E{h(τ, t)h∗(τ, t + ∆t)} (6.3)

In practice, we do not have the autocorrelation information a priori, so we must userealisations of the channel h(τ, t) instead. Furthermore, we will only have access to thediscrete impulse response h[n, ν], so (6.2) becomes:

S[n, k] =N−1∑ν=0

h[n, ν]e−j2πkν

N (6.4)

where here N is the total time (in samples) over which the measurements are being

35


2 4 6 8 100

5

10

15

20

25

Frequency (kHz)

Noi

se p

ower

(ar

bitr

ary

units

)

102

103

104

−60

−40

−20

0

20

Frequency (Hz)

Noi

se p

ower

(dB

)

(a)

(b)

Figure 6.4: Acoustic noise power profile. (a) Linear scales. (b) Logarithmicscales.

made.

S[n, k] can be interpreted as the frequency response of the fluctuations in h[n, ν] overtime, at each value of excess delay, n. A surface plot of the scattering function measuredfor the room of Figure 6.2 over 15 minutes is shown in Figure 6.3.3

This shows that at all k 6= 0, S[n, k] is buried in noise; this implies a narrow Dopplerspread, and therefore a long coherence time. Hence the original assumption of a slowfading channel is justified.

6.3 Noise and interference

In order to predict where in the audio band the system would perform best, it is useful toknow the spectral response of the noise sources that the signal will be subjected to. Thisknowledge, combined with that of the channel response, allows the sub-carrier SNRs tobe estimated. For the sake of simplicity, Gaussian amplitude statistics will be assumedfor all noise sources.

Noise in the room of Figure 6.2 was characterised by averaging the magnitude-squared

3 The 15-minute period was imposed by memory limitations in MATLAB. However, this is sufficientto show the effect.

36


FFTs of 1,000 audio captures taken over approximately 20 minutes. The resulting noisepower profile is shown in Figure 6.4(a). This room contains a PC with several noisyfans, whose harmonics are the cause of the spikes in the profile. Plotted in dB on alogarithmic frequency scale, Figure 6.4(b), the profile exhibits an average linear roll-offat −20 dB/dec, which is equivalent to 1/f (Brownian) noise.

6.4 Conclusion

A method for measuring the acoustic impulse response of a room was implemented usingMLS to maximise the SNR of the readings. As expected, the response altered from roomto room, and with transducer location. The MLS method was also used to produce anapproximation to the 2-D scattering function of the room, the result of which showedthat the responses exhibited little or no Doppler spread, and hence justified the slowfading approximation made earlier.

Ambient and system noise levels were also measured. They were found to be frequency-variant, approximating 1/f characteristics.

37

Section 7

Frequency synchronisation

In a practical RF OFDM system, carrier frequency synchronisation is critically impor-tant, as any error destroys the sub-carrier orthogonality. This section first covers someof the theory behind frequency synchronisation, and then discusses hardware measure-ments which demonstrate that according to an existing approximation, the transmitterand receiver are already adequately matched, theoretically negating any need for explicitfrequency tracking and correction.

7.1 Theory

If the receiver LO is not matched to the carrier frequency of the incoming signal, thenthe basis functions described in (4.4) will effectively become:

v′k(t) =1√N

e−j2π[k∆f+fε]t, k ∈ [0, N), t ∈ [0, T ) (7.1)

where fε is the frequency error, or carrier frequency offset (CFO).

While the {v′k(t)} still form an orthogonal basis set, none of them is orthogonal to anysub-carrier component of the incoming signal (assuming fε is not an exact multipleof the sub-carrier spacing ∆f). Therefore, each received sub-carrier symbol will havecontributions from every transmitted sub-carrier symbol, giving ICI. Furthermore, theeffective received power from the correct sub-carrier will be reduced, as its power willbe distributed across all {v′k(t)}. These two effects are shown in Figure 7.1.

Pollett et al. analyse this effect numerically in [19], comparing the degradation in effectiveSNR for a typical OFDM system with that of an equivalent single-carrier system. Theyshow that the degradation for OFDM is several orders of magnitude worse, implying thatsuch a system must incorporate stringent frequency synchronisation. The approximationthey present is:

∆ SNR ≈ 103 ln 10

(π

fε

∆f

)2 Es

N0(7.2)

38

Section 7: Frequency synchronisation

fε

Drop in signal level

ICI

Figure 7.1: Frequency-domain representation of the effect of CFO onreceived signal amplitude and ICI.

where ∆ SNR is the SNR degradation (in dB). This shows that the degradation is afunction of the ratio fε/∆f, termed the relative CFO.

Various CFO estimation and synchronisation schemes were surveyed for the Initial Re-port [6]. However, these schemes are based on the assumption that it is only the LOsthat are in error, i.e. there is only an additive spectral shift. In the system proposedfor this project, both the effective LO frequencies and the OFDM symbol rates of thetransmitter and receiver are directly governed by the respective soundcard clock rates.Any discrepancy in the two clock rates will therefore manifest itself as a relative fre-quency compression or expansion. This will lead to an error in both fc and ∆f , whichinvalidates the assumptions in these synchronisation schemes.

However, as discussed below, the nominal level of uncorrected CFO in the proposedsystem is low enough not to warrant explicit correction, if the above approximation isused.

7.2 Hardware measurements

To analyse the level of discrepancy in soundcard sampling rates, the following steps wereperformed:

1. The analogue output of one PC’s soundcard was directly connected to the analogueinput of another.

2. The first PC was set to play two short MLS, separated by approximately 1000seconds of silence, at 44.1 kHz.

3. This was captured by the second PC, also at 44.1 kHz.

4. The captured waveform was correlated against the MLS to identify peak locations,

39

Section 7: Frequency synchronisation

and the number of samples between peaks was measured.

This procedure indicated an error of approximately 250 samples in 4.41 × 107, corre-sponding to a relative CFO of approximately 5 × 10−6. Using (7.2), and assuming anSNR of 10 dB, this results in ∆ SNR ≈ 10−8 dB, which is negligible.1 Consequently, afrequency synchronisation procedure should be unnecessary in the receiver.

7.3 Conclusion

The problems resulting from CFO have been described, and an existing approximationfor the associated SNR degradation has been presented.

Measurements of the offset between two PCs have been taken; according to the approxi-mation, it is at a negligible level. It has been identified that this offset is a sampling rateoffset, which causes a spectral compression rather than shift; nevertheless, it has beenargued that at such low levels of offset, the effects are still negligible. Consequently, acorrection scheme has not been implemented.

1 Whilst this was only measured at 44.1 kHz, it is assumed that all nominal soundcard samplingrates (8 kHz, 22.05 kHz, etc.) are derived from the same onboard clock, so this value of ∆SNR will holdat all other rates.

40

Section 8

Timing synchronisation

As discussed in the Initial Report [6], the original intention was to investigate the use ofblind timing estimators to perform synchronisation, the obvious advantage being thatthis would increase spectral efficiency. Several were found in the literature; in particular,two looked especially promising [20, 21].

Initial work was undertaken into developing one of these [20] in a baseband MATLABsimulation, and characterising its performance, and is introduced below. As will bediscussed in the following sections, this estimator was found to be of limited use, becausebetter performance was found from channel-estimator-based synchronisation. For thisreason, the estimator in [21] was not investigated.

8.1 The van de Beek estimator

The van de Beek timing estimator [20] is actually a joint timing/CFO estimator. Ashas been discussed, CFO considerations have been ignored, allowing some slight simpli-fications to the structure of this estimator.

For a flat channel, the van de Beek algorithm is a ML estimate of integer timing offset,but as the original paper states, it is non-optimal in a frequency-selective channel.

The estimator operates in the time domain on the sampled received waveform; thepremise is exploitation of the redundancy imposed by use of the CP. To a first-orderapproximation, it can be viewed as utilising a sliding windowed autocorrelator to identifythe location of the CP. Whilst the full derivation of the ML estimate presented in thepaper will not be repeated here, the basic principle is outlined below.

We define the autocorrelation function for the received waveform, y[n] as follows:

ryy[n, ν] = E{y[n]y∗[n + ν]} (8.1)

Note that the inclusion of a CP means that y[n] is non-stationary, hence two parameters

41

Section 8: Timing synchronisation

Figure 8.1: OFDM symbol time-domain layout, showing pair-wisecorrelations in an AWGN channel. Correlated pairs share the same label.

are required for the autocorrelation function.1

In an AWGN channel, each sample within a CP is correlated with the correspondingsample from the end of the block, whereas all other sample pairs are uncorrelated (as-suming i.i.d. data), illustrated in Figure 8.1. Therefore, ryy[n, ν] is maximised when n

falls within a CP, and ν = N , the useful symbol length. The SNR of this metric can beimproved by summing ryy[n, N ] over L consecutive samples.

Therefore, we may form the following sliding-window time-domain autocorrelator func-tion:

γ[n] =L−1∑i=0

y[n + i

]y∗

[(n + N) + i

](8.2)

A typical sequence for γ[n] is shown in Figure 8.2. Essentially, the peaks in |γ[n]|correspond to estimates of the CP locations; however, the full estimator also contains anormalising term, E[n], based on the energy of the samples in the current window:

E[n] =L−1∑i=0

∣∣y[n + i

]∣∣2 +∣∣y[

(n + N) + i]∣∣2 (8.3)

The rationale for this is explained in van de Beek’s paper.

The full ML estimate of the CP location for the m-th block is given by:

νm = arg maxn

{|γ[n]| − ρ

2E[n]

}, n ∈ Im (8.4)

where Im is the set of sample indices corresponding to the m-th block, and ρ is relatedto the SNR:

ρ =SNR

SNR+1(8.5)

A block diagram structure of the estimator is given in [20], but as mentioned above,CFO estimation is not required, so it can be adjusted to that shown in Figure 8.3.

1 In fact, y[n] is 2nd-order cyclostationary [21].

42


0 1280 2560 3840 51200

0.1

0.2

0.3

n

|γ[n]

|

Figure 8.2: Typical |γ[n]| sequence for four OFDM symbols. SNR = 10 dB,N = 1024, L = 256.

Figure 8.3: Structure of modified van de Beek estimator.

8.1.1 Performance characterisation

In order to characterise the performance of the estimator at various values of SNR andCP length L, a set of simulations were run, and the MSE in estimated block positionwas used as a metric. The results (averaged over 10,000 OFDM symbols) for an AWGNchannel are summarised in the graphs of Figure 8.4. As can be seen, and as found byvan de Beek, performance initially improves with L, but hits a fundamental error floor(analogous to the Cramér-Rao lower bound) at each SNR.

Figure 8.5 shows the effect that a typical frequency-selective channel has on estimatorperformance; as can be seen, MSE drops much more slowly with SNR than in an AWGNchannel.

8.1.2 Analysis

There are a number of problems with the van de Beek estimator, in terms of bothimplementation and performance:

• The drop in estimator performance in a frequency-selective channel is not desirable.

43


10 20 30 40 50 6010

−2

10−1

100

101

102

103

104

105

106

L

MS

E (

sam

ples2 )

SNR = 5 dB

SNR = 10 dB

SNR = 15 dB

Figure 8.4: Timing estimate MSE of van deBeek estimator vs. CP length L. N = 1024.

0 5 10 1510

−2

10−1

100

101

102

103

104

SNR (dB)

MS

E (

sam

ples2 )

ρ known, AWGNρ = 1, AWGNρ known, frequency−selective channel

Figure 8.5: Comparison of MSE performancevs. SNR with and without knowledge of ρ, and

in AWGN and frequency-selective channels.N = 1024, L = 64. Frequency-selective channel

is of length 12.

• The algorithm requires the value ρ, which in turn requires the receiver to calculatean SNR estimate. Alternatively, we may use the approximation ρ = 1, whichresults in a further drop in performance at low SNR, as shown in Figure 8.5.

• The sliding correlator implementation is processor-intensive, equivalent to resource-intensive in an embedded environment. van de Beek’s research group present alow-complexity approximation to this estimation algorithm in an earlier paper [22];however, this reduction in complexity is achieved by quantising the received wave-form to a 1-bit complex stream. This would be beneficial on a DSP or FPGA-basedplatform, but of no use in MATLAB.

In any case, the performance results show that even at relatively high SNR in an AWGNchannel with perfect knowledge of ρ, there is significant variance in the timing estimates.If uncorrected, then the symbol on each sub-carrier will undergo a phase-shift that alterslinearly with sub-carrier frequency, as given by the DFT shift theorem:

DFT n{x[n + ν]} = ej2πkν/NXk (8.6)

To analyse the effect this has on system performance, we consider the smallest possiblenon-zero error, ν = 1, in an otherwise noiseless channel, with all sub-carrier symbolsXk = ejφ for some fixed arbitrary φ. It is clear that the received symbols are given by:

Yk = ej[φ+2πk/N] (8.7)

which are uniformly spaced on the complex unit circle, as illustrated in Figure 8.6. Ifan M -PSK modulation scheme is in use, then only N/M of these symbols will be in thecorrect sector, giving a SER of M−1/M, and a BER of 50%.

44


Figure 8.6: The effect of a unit sample timing error on the receivedconstellation of an N = 32 OFDM system using 8-PSK.

A similar effect will occur for arbitrary {Xk} and any non-zero integer ν, but alwaysresulting in a BER of 50%. An equivalent effect also occurs for differential PSK.

This timing offset can be corrected by a channel estimation scheme; this is describedin Section 9.5. If a channel estimation scheme is used for this purpose, then a sepa-rate timing synchronisation algorithm is redundant, and only consumes extra resources.Therefore, for the purposes of this project, no further investigation into separate timingsynchronisation has been carried out.

8.2 Conclusion

The theory of operation of the van de Beek timing estimator has been presented, and amodified version implemented at baseband to evaluate its performance, using estimatorMSE as a metric. In an AWGN channel, results matched the trends found by van deBeek; the MSE decreased with CP length, but hit a SNR-dependent lower bound. In afrequency-selective channel, performance was degraded.

It was also identified that the estimator algorithm was processor-intensive, due to itstime-domain correlation implementation.

It was then shown that the non-zero MSE implied that a channel-estimation schemewould be required; this in turn implied that a separate timing estimator would beredundant.

45

Section 9

Channel estimation

In the Initial Report [6], the requirement for channel estimation was originally dismissedas potentially unnecessary, as use of a differential modulation scheme was planned.1

However, as mentioned in Section 8.1.2, it is possible (and in some senses, preferable)to implement timing synchronisation with a channel estimation scheme.

Therefore, this section first looks at some basic theory behind channel estimation, thendescribes the implementation chosen for this project, and characterises its performance.Next, the effects of a non-sample-spaced channel on estimator performance are examined.Finally, an extension to perform synchronisation is described.

9.1 Rationale for frequency-domain estimation

The Initial Report stated a desire to use blind estimation if possible, as this would achievegreater spectral efficiency. However, the majority of blind estimation schemes found arehighly complex, and it was doubtful whether enough time would be available to evaluateand implement the proposed estimators. Consequently, only non-blind techniques havebeen considered, to help ensure that a successful system would be produced at the endof this project.

9.2 Rationale for pilot-based estimation

In an OFDM system, channel effects are most commonly corrected with a frequency-domain equaliser (or FEQ), i.e. post-DFT, as opposed to the time-domain equaliser (orTEQ) that is usually found in single-carrier systems. There are certain situations thatmotivate the use of a TEQ in OFDM; for instance, shortening a channel longer than theCP [23]. However, for the purposes of this project, these will be ignored.

We can consider an OFDM modulation scheme as a 2-dimensional time-frequency lattice,

1 Of course, in a sufficiently time-variant channel, even a differential scheme will require some formof channel correction.

46

Section 9: Channel estimation

and a frequency-selective time-variant channel as a 2-dimensional function over thislattice. Transmission of known symbols at known locations (commonly referred to aspilot symbols) on this lattice allows the receiver to estimate the value of H at thoselocations, i.e. they form noisy samples of the channel response function. Some examplepilot patterns over this lattice are shown in Figure 9.1, where m is the time index, andk the sub-carrier index.

If the variation in H is both band-limited and time-limited, then the Nyquist samplingtheorem implies that it may be reconstructed from a sufficient number of periodically-positioned estimates. Once H has been reconstructed, it can be used to correct thephase and amplitude of the received data symbols before detection.2

9.2.1 Pilot patterns

A given channel will have particular frequency-selective and fading characteristics, i.e.its variations will exhibit a certain level of time-limiting and band-limiting, and willtherefore require a particular 2-D sampling pattern in order to reconstruct it efficientlyand without aliasing errors.

The various pilot patterns shown in Figure 9.1 are suitable for different channel types.The comb pattern of Figure 9.1(a) uses dedicated pilot sub-carriers, giving a set of pilotsin every symbol period, and is particularly suited to channels exhibiting significant fadingfrom symbol to symbol. The block pattern of Figure 9.1(b) uses dedicated periodic pilotsymbols that contain pilots on every sub-carrier, and is more suited for time-invariant orslowly fading channels, allowing highly accurate frequency-domain estimation withoutinterpolation. The scattered pattern of Figure 9.1(c) is a compromise between the two;a version of it is is used, for instance, in DVB [15].

Later sections will describe which pattern has been chosen, and why.

9.2.2 Estimator categories

Performance of the estimator is of course limited by the inherently noise nature of thechannel estimates at the pilot locations. If nothing is known about the channel statistics,then the best we can do is form a least-squares estimate, which is equivalent to an MLestimate in white Gaussian noise [10, pp. 690-691].

If, on the other hand, the channel statistics are known a priori at the receiver in the formof the covariance matrix RHH , then an optimal estimator (in the linear minimum MSE(LMMSE) sense) may be formed by using a 2-D Wiener filter. The LMMSE approachis considerably more complex, and several papers in the literature have attempted to

2 For a PSK-based modulation scheme, there is no need to correct amplitude before symbol detection.However, the channel amplitude information may be used to provide symbol reliability information forsoft-decision FEC decoding.

47


Figure 9.1: Some example pilot patterns. Each has the same average pilotdensity, but will permit different time and frequency variation in H.

(a) Comb pattern. (b) Block pattern. (c) Scattered pattern.

look for simplifications that do not impact on its performance, for instance Edfors et al.[24] present a subspace-based approach using singular value decomposition.

Morelli and Mengali offer a comparison of these estimator categories in [25]. They findthat at above a certain SNR and with a sufficiently long CP, the difference between theML and LMMSE estimators in a sample-spaced channel is negligible. This fact, coupledwith the extra complexity of the LMMSE estimator (and its requirement for knowledgeof RHH), means that for the purposes of this project, only DFT-based ML estimatorshave been considered.

9.3 DFT-based ML estimators

DFT-based estimators exist for both the comb pilot pattern and the block pilot patternof Figure 9.1(a) and (b); each is described below. The scattered pattern of Figure 9.1(c)would require a more complex implementation, and so has been rejected for the purposesof this project.

These estimators operate by first forming a least-squares (LS) estimate of the channelat pilot locations. We start with the following relationship:

Yk,m = Hk,mXk,m + Vk,m (9.1)

where Yk,m is the frequency-domain received symbol, Xk,m is the frequency-domaintransmitted symbol normalised as |Xk,m| = 1, Vk,m is white Gaussiam noise uncorrelated

48


with Xk,m, and Hk,m is the channel coefficient to be estimated. From now on, the timeindex m is omitted for clarity.

A LS estimate for Hk is therefore given by:

Hk = X∗kYk (9.2)

= Hk + X∗kVk

= Hk + V ′k

9.3.1 Comb pattern estimator

Whilst many papers discuss the DFT-based approach, none of those surveyed presenta derivation of its operation. Therefore, the following derivation has been developed,and demonstrates how the pilot estimates may be interpolated to the data sub-carrierfrequencies.

If h[n] is shorter than the CP, i.e. time-limited so that it is non-zero for n ∈ [0, L)only, then a sampling period KS ≤ N/L is sufficient for complete recovery of the originalfunction, therefore we need at least L uniformly-spaced pilots. Let the pilot sub-carriersbe indexed by {kpi|i ∈ [0, Np)}, where Np is the number of pilots in use, with:

kpi = iKS + kp0 (9.3)

We start with the DFT relationship:

H = Q

[hL

0

]

= Q

[IL

0

]hL (9.4)

, Ψ1hL (9.5)

where IL is the L×L identity matrix, and in this instance, H =[H0 H1 · · · HN−1

]T

and hL =[h0 h1 · · · hL−1

]Tare vectors containing the frequency-domain and time-

domain channel coefficients, respectively, and Ψ1 is an N × L matrix containing therelevant entries of the DFT matrix:

[Ψ1]k,l =1√N

W−klN , k ∈ [0, N), l ∈ [0, L) (9.6)

49


If we define an Np × L matrix, Ψ2, in the same way:

[Ψ2]i,l =1√N

W−kpilN , i ∈ [0, Np), l ∈ [0, L) (9.7)

then we can obtain a vector containing the channel coefficients for the pilot sub-carriersonly:

Hp = Ψ2hL (9.8)

This suggests that Hp may be interpolated to the full frequency-domain vector H:

H = Ψ1(Ψ∗2Ψ2)−1Ψ∗

2Hp (9.9)

where the inverse of Ψ∗2Ψ2 exists as Ψ2 is tall (or square) and has full rank, as will be

shown further on.3

If we replace Hp with a vector, Hp, containing the ML estimates from (9.2), then weobtain:

H = Ψ1(Ψ∗2Ψ2)−1Ψ∗

2Hp (9.10)

, MHp

where H is a ML estimate of H.4

A more efficient implementation can be found by expressing Ψ2 as:

Ψ2 =1√N

W−kp0.0N · · · W

−kp0.(Np−1)N

... . . . ...

W−kp(Np−1).0

N · · · W−kp(Np−1).(Np−1)

N

[IL

0

](9.11)

3 Ψ2 has full rank even when the pilots are not uniformly-spaced, hence the inverse of Ψ∗2Ψ2

always exists. In fact, in a noiseless system, any L pilots would be sufficient to reconstruct the channel.However, in the presence of noise, the optimal pilot positioning (in an MSE sense) is the uniform spacing,as demonstrated in [26].

4 If Hp is a ML estimate, then H is also a ML estimate, as Ψ1(Ψ∗2Ψ2)

−1Ψ∗2 provides a unique

mapping, and so the invariance property holds [9, pp. 217-218].

50


Figure 9.2: DFT-based channel estimator for a comb pilot pattern,simplified for PSK-based modulation schemes.

The first matrix on the right-hand side is Np ×Np square, and by substituting (9.3):

Ψ2 =1√N

W−kp0.0N · · · W

−kp0.(Np−1)N

... . . . ...

W−((Np−1)KS+kp0).0N · · · W

−((Np−1)KS+kp0).(Np−1)N

[IL

0

]

=1√N

W−0.0Np

· · · W−0.(Np−1)Np

... . . . ...

W−(Np−1).0Np

· · · W−(Np−1).(Np−1)Np

1

. . .

ej(Np−1)φ

[IL

0

]

,

√Np

NQp Φ

[IL

0

](9.12)

where Qp is an Np × Np DFT matrix, and Φ is a diagonal phase-shift matrix, with

φ = −2πk0/N. Qp and Φ both have rank Np, and[IL 0

]Thas rank L. Therefore Ψ2

has rank L, and hence full rank, as required for (9.9).

(9.12) may be substituted into (9.10), giving:

H =

√N

NpQ

[IL 0

0 0

]Φ∗Q∗

pHp (9.13)

This is more efficient, as Q and Q∗p may be implemented as an FFT and IFFT respec-

tively, and the effect of Φ∗ is obtained simply by element-wise multiplication of a vector.Note that for a PSK-based system, the scalar coefficient is unnecessary. This procedureis illustrated by the block diagram of Figure 9.2.

51


Figure 9.3: DFT-based channel estimator for a block pilot pattern,simplified for PSK-based modulation schemes.

The per-sub-carrier estimator MSE, derived in Appendix A, is given by:

MSEk =σ2

V L

Np(9.14)

where σ2V is the noise variance.

In a noiseless system, Np = L = ΓMAX is the minimum required for the invertibilityassumption of (9.10), giving perfect reconstruction. However, when subject to noise,the estimator MSE increases proportionally with L, as (9.14) shows. Therefore, in apractical system, we will need Np � L.

9.3.2 Block pattern estimator

A block pilot pattern permits a slightly simpler structure, as there is no need to performfrequency-domain interpolation. In its simplest implementation, an estimate for eachHk is formed directly from the pilot block, and then used to correct all subsequent datablocks until the next pilot block. A suitable block diagram structure is illustrated inFigure 9.3.

9.3.3 Performance comparison

Negi and Cioffi [26] show that for a time-invariant channel, the MSE performances ofthe two estimators above are equivalent, given the same pilot-to-data ratio. However, ina fading channel, the block-based estimator will generally give worse performance dueto its slower update rate.

Performance of the block-based estimator could be improved by implementing someform of time-domain interpolation between successive estimates. This could range fromsimple linear interpolation, through to band-limited (sinc) interpolation.5 Clearly, thegreater the interpolation window, the greater the latency, and the greater the memoryrequirements at the receiver.

5 The optimum interpolation is actually given by the 2-D Wiener filter, but as already mentioned,this has been dismissed due to the requirement for a priori knowledge of RHH .

52


PAPR = 128

n

|h[n

]|2

PAPR = 1.0079

n

|h[n

]|2

PAPR = 3.0271

n

|h[n

]|2

(a) (b) (c)

Figure 9.4: Pilot symbols transformed to the time domain (y-axes are not toscale). (a) 128 pilots, all with value 1. (b) 127 pilots, generated by length-127

MLS. (c) 128 pilots, generated by truncating length-255 MLS.

In general, then, it would appear that better overall performance is achieved by usinga comb pilot pattern. However, the problems described in the next section suggestotherwise.

9.3.4 Choice of pilot symbol values

The phase values chosen for the pilot symbols do not affect estimator performance.However, other criteria may be used to select an optimal set of pilot values. In partic-ular, minimisation of PAPR is a worthwhile goal, and is an equivalent problem to thatdiscussed in Section 6.1. For instance, using the same phase for all pilots is an especiallybad choice in this regard, as it results in an impulse train in the time domain, as inFigure 9.4(a).

The optimal set is given by a MLS, Figure 9.4(b); however, this would require Np =2m − 1, m ∈ Z+, which would make efficient implementation of an FFT difficult in anembedded system. One approach would be to generate a length 2(m+1) − 1 MLS, andtruncate it to 2m. This is less than optimal, Figure 9.4(c), but still significantly betterthan the impulse train described above.

There may be better sequences of length 2m, but the truncated MLS has been consideredadequate, especially considering that in reality the data sub-carriers will contribute tothe PAPR as well.

9.4 Effects of a non-sample-spaced channel

The estimators presented here operate under the assumption that the channel responseh[n] is strictly time-limited to n ∈ [0, L). As described in Section 5.3, this assumptiondoes not necessarily hold in the case of a non-sample-spaced channel. Therefore, thechannel estimators will effectively truncate h[n] with a rectangular window, causingconvolution of Hk with a sinc function, leading to the standard problem of spectralleakage.

53


0

0.2

0.4

0.6

0.8

1

1.2

k

|Hk|

Figure 9.5: Example of spectral leakage in |Hk| caused bynon-sample-spaced channel. Pilot locations shown by vertical dotted lines.

This will affect estimator performance for even the most benign channel responses. Asan example, Figure 9.5 shows the estimator output for a nominally flat channel withzero noise, but with the time-domain impulse occurring half way between two receiversamples. Two effects can be seen:

• The greatest error occurs at the edges of the transmission band.

• There is zero error at pilot locations.

Morelli and Mengali describe this behaviour in [25], but incorrectly attribute it to theuse of VSCs.6 However, they do offer an approach which could potentially mitigate thedegradation in performance, which involves using a greater density of pilots at the edgesof the transmission band, where per-sub-carrier MSE is worst. This is non-ideal as theNp×Np IDFT Q∗

p cannot be used with a non-uniform pilot spacing. Furthermore, theypresent no method of establishing the optimal pilot locations.

Yang et al. pose a more rigorous solution in a paper dedicated to this problem [27].Their approach involves both time-domain and frequency-domain windowing; however,the windows they propose vary with the SNR level. Not only does this require a SNRestimate, but the function that provides the window is of high complexity, and alsorequires knowledge of RHH . For these reasons, and due to project time constraints, thisapproach has also been rejected.

Instead, the solution that has been chosen is to use a block pilot pattern, as this resultsin minimal error on all sub-carriers. This will evidently lead to problems in more time-variant channels as described in the previous section; this trade-off is examined in theimplementation of the live system (see Section 12.4.3).

6 The use of VSCs results in an oversampled time-domain signal at the transmitter output. If thebaseband simulation employs a channel model that is sample-spaced for the transmitter output samplerate, then, in general, this will result in a non-sample-spaced effective channel response when the signalis decimated at the receiver. So whilst Morelli and Mengali are correct in stating that VSCs are a causeof the degradation in estimator performance, they have not correctly identified the root cause.

54


Figure 9.6: (a) DFT window coincides with OFDM block; any positive errorwill result in ISI. (b) DFT window position negatively biased; positive and

negative error possible without ISI.

It should be noted that none of the approaches described above mitigates the ISI andICI problems with the non-sample-spaced channel (as described in Section 5.3). Fur-thermore, from a survey of the available literature, it would appear that no one hasdescribed or attempted to address these problems.

9.5 Incorporation of timing synchronisation

As mentioned in Section 8.1.2, a timing offset is equivalent to a frequency-domain phaserotation that alters linearly with sub-carrier frequency, hence it will be implicitly cor-rected by the equaliser, so long as the offset does not move the DFT window beyondthe circular convolution region.

If the receiver is designed so that the DFT window nominally coincides exactly with theblock section as in Figure 9.6(a), then any positive error will push the window into theCP of the next symbol, which will lead to a BER of 50%. Far better performance will beobtained if the nominal DFT window position is negatively biased as in Figure 9.6(b),as it will allow a certain level of error in either direction without introducing ISI.

Once the frequency-domain channel estimate H has been obtained for a particular block,we may explicitly estimate the timing offset in terms of the difference, ∆, between theexpected and actual block start positions. This information may be used to place theDFT window for the next block, as illustrated in Figure 9.7.

The following sections describe three methods that have been developed for identifyingthis offset; the first operates in the frequency domain, the other two in the time domain.

55


Figure 9.7: Placement of DFT window based on timing offset estimatederived from previous block. Once ∆ has been identified, N + L + ∆ samples

should be skipped between DFT window start indices.

9.5.1 Timing-offset identification using phase rotations

Each of the channel estimates at pilot locations will have an angular contribution fromthe timing offset, another from the phase response of the channel itself, and anotherfrom the noise contribution, thus:

∠Hkpi=

2πkpi

Nν + θkpi

+ εkpi(9.15)

where ν is the offset in samples, and θkpiis the channel phase response for the i-th pilot.

The first term is a linear relationship; the other terms are both noise-like. Therefore,we can use linear regression to obtain a LS estimate of the angular contribution of ν.

However, this approach involves explicitly calculating arctangents, a task involving con-siderable resources; regression is also computationally demanding; hence, this is unlikelyto be used in an embedded system.

9.5.2 Timing-offset identification using peak detection

In a channel with a strong line-of-sight component, there is likely to be a strong peakin the time-domain channel response. Therefore, we can search for this peak, and useit as a reference point, i.e.:

ν = arg maxn|h[n]| (9.16)

Clearly, the success of this approach depends on there being a strong line-of-sight com-ponent (or at least some other strong peak), and also on the peak being strong enoughto be correctly identified, even in the presence of AWGN.

9.5.3 Timing-offset identification using moments

The major problem with the previous technique is that of noise corrupting the identifi-cation of the channel response peak. Instead of using maxn|h[n]| as the metric, we can

56


n

h[n

]

n

h′[n

]

0 Np − 1 Np − 10

(a) (b)

Figure 9.8: (a) Example of an effective channel response that wraps aroundfrom (Np − 1) to 0. (b) Channel response after a circular rotation of Np/2.

use the first moment of |h[n]|2, to identify the “mean” of the power distribution.

The problem is complicated, however, by the implicit periodicity in h[n], which couldlead to false identification in situations such as that of Figure 9.8(a). In this example, thechannel response wraps around; a standard first moment of |h[n]|2 would give ν ≈ Np/2,when in fact it should be closer to 0.

This may be resolved by first forming a modified channel response, h′[n], by circularlyrotating h[n] by Np/2 as in Figure 9.8(b). The first moment and second central momentof each should then be found, using:

νA =1E

∑n

n|h[n]|2 (9.17)

νB =1E

∑n

n|h′[n]|2 (9.18)

σ2A =

1E

∑n

(n− νA)2|h[n]|2 (9.19)

σ2B =

1E

∑n

(n− νB)2|h′[n]|2 (9.20)

where E =∑

n|h[n]|2 is the total energy of the channel response.

min{σ2A, σ2

B} will correspond to the non-wrapped channel response, and then ν can beformed from the corresponding first moment.

9.5.4 Performance comparison

The MSE in estimated offset has again been used as the metric for performance com-parison. A frequency-selective channel was simulated, with three similar sized peaks inthe impulse response. The results are shown in Figure 9.9. At extremely low SNR, the

57


−15 −10 −5 0 5 10 15 20

10−4

10−2

100

102

104

SNR (dB)

MS

E (

sam

ples2 )

Phase rotationsPeak detectionMoments

Figure 9.9: Performance comparison of three timing-offset identificationmethods, with Np = 128.

phase-rotation method performs considerably better; at high SNR, the peak-detectionmethod performs almost as well. For this reason, and for its simplicity, peak-detectionhas been chosen for the timing estimator.

9.6 Conclusion

It has been identified in Section 8 that a channel estimator is required, and as such,non-differential modulation will be used. Some existing estimator categories have beenidentified; a ML frequency-domain, pilot-based estimator has been chosen. It has beenshown how this estimator may be implemented efficiently with an FFT and IFFT, foreither a comb or block pilot pattern.

The effects of a non-sample-spaced channel have been discussed, along with some so-lutions proposed in the literature. These solutions have been rejected due to timeconstraints; instead, it has been identified that these effects will be minimised by use ofa block pilot pattern.

The rationale for performing timing synchronisation with the estimator has been dis-cussed. Three appropriate methods have been designed and compared; a peak-detectionmethod has been chosen for its simplicity, although it may not perform well in a non-line-of-sight channel.

58

Section 10

Signal acquisition

The timing and channel estimation algorithms discussed thus far are iterative, in thatthe success or failure of the estimate for the m-th symbol depends on a valid timingreference from the estimate for the (m− 1)-th symbol. Clearly, this leaves the problemof where the first estimate derives its reference from; in other words, how the receiveracquires an initial lock on the signal. This problem can be ignored in simulations byproviding the receiver with a priori knowledge (implicitly or explicitly) about the timingoffset of the signal. However, for the live system, an acquisition procedure is required.

A common solution to the acquisition problem is to divide the transmission stream intoframes. Each frame consists of a number of OFDM symbols, and is prefixed by anacquisition preamble, designed with specific characteristics that enable the receiver tolock onto it.1

One such preamble scheme is presented in a paper [28] by Schmidl and Cox, as dis-cussed in the Initial Report. This section first covers the theory behind the Schmidl-Coxmethod, and poses a suitable algorithmic structure. This is followed by a discussion ofa pilot-based extension to the acquisition stage which provides a better timing referencefor the first data frame.

10.1 The Schmidl-Cox acquisition method

The acquisition procedure proposed by Schmidl and Cox [28] is a joint signal detectionalgorithm and timing/CFO estimator. As has been discussed, CFO considerations havebeen ignored, allowing considerable simplifications.

The acquisition procedure operates in the time domain on the sampled received wave-form, and requires a dedicated training symbol at the start of the transmission sequence,

1 In some broadcast applications such as DVB, acquisition information is broadcast in parallel withpilots and data within the OFDM symbol stream [15]. This is possible because in these applications, theclient may “connect” at any time, and has no way of signalling to the transmitter that an acquisitionphase is required. In a bursty datagram application, this is obviously of no use; if the receiver has notlocked onto the transmission at its start, data will have been lost.

59

Section 10: Signal acquisition

Figure 10.1: SYNC1 symbol time-domain layout, showing effect of afrequency-selective channel (length=2) on pair-wise correlations. Correlated

pairs share the same label.

which will be denoted the SYNC1 symbol (the reason for the suffix “1” will become ap-parent in Section 10.2). This symbol contains energy only on the even sub-carriers, sothat the first half is identical to the second half in the time domain (essentially, thefrequency of the implied periodicity has been doubled).

In an AWGN channel, it is clear that each sample in the first half of the SYNC1 block iscorrelated with the corresponding sample in the second half (separated by N/2 samples).The same applies to the samples in the CP. However, all other sample pairs with thisseparation will be uncorrelated.

In a frequency-selective channel, the start of the CP does not undergo the circularconvolution effect, so the range of samples over which the pair-wise correlation exists isreduced by the sampled channel length, as illustrated in Figure 10.1.

Therefore, from the autocorrelation function given in (8.1), ryy[n, ν] is always maximisedwhen n falls the first half-block of SYNC1, and ν = N/2. Again, the SNR of this metriccan be maximised by summing ryy[n, N/2] over N/2 consecutive samples, resulting in asliding windowed autocorrelator function, in a similar form to that of (8.2) for the vande Beek timing estimator:

γ[n] =N/2−1∑i=0

y[n− i

]y∗

[(n− N

2

)− i

](10.1)

As the received signal power level is not fixed, the autocorrelator output magnitudemust be normalised by a time-localised estimate of the signal power. This is obtainedby summing the energy found in the last N/2 samples, i.e.:

E[n] =N/2−1∑i=0

∣∣y[n− i]∣∣2 (10.2)

Therefore, the normalised metric, M [n], is given by:

M [n] =∣∣∣∣ γ[n]E[n]

∣∣∣∣ (10.3)

60


0

0.2

0.4

0.6

0.8

1

n

M[n]

E[n]

CP 1st halfof SYNC1

2nd halfof SYNC1

CP widthNoise−induced

rise in M[n] CP width

Figure 10.2: Typical graphs of M [n] and E[n] before and during SYNC1symbol.

Figure 10.3: Modified Schmidl-Cox acquisition structure.

A typical graph of M [n] is shown in Figure 10.2; the value of n that maximises M [n] canbe used as a timing reference. Note that due to noise, use of M [n] alone will give manyfalse positives. Therefore, we must also check that the signal energy E[n] has passed aset threshold before using M [n].

A block diagram implementation of this procedure is shown in Figure 10.3.

10.1.1 Similarity to van de Beek estimator

The structure of this algorithm is very similar to that of the van de Beek estimator ofSection 8.1. Indeed, in an AWGN channel, the van de Beek estimator coupled with asignal power metric could be used for acquisition, without the need for a SYNC1 symbol.However, it has already been noted that its performance is significantly degraded in afrequency-selective channel, so the Schmidl-Cox method is preferred.

61


Figure 10.4: Symbol structure of transmission sequence.

10.2 Improved timing acquisition

The timing used to window the first data frame is derived from the timing estimateproduced by the acquisition stage. However, due to additive noise, the arg max operationof Figure 10.3 could identify the maximum as anywhere in the CP region, which is lessthan optimal. Although the receiver will recover from any initial timing error such asthis, the first data frame may be corrupted by ISI.

Therefore, to obtain a more reliable timing estimate for use on the first data frame,a second training symbol has been added, containing pilots on all sub-carriers, anddenoted the SYNC2 symbol. This requires a second stage of acquisition, which performsblock pilot-based timing estimation as described in Section 9.3. Provided that the SNRis sufficiently high, then the improved timing estimate should be adequate for datareception.

This results in a transmission sequence as shown in Figure 10.4.

10.3 Conclusion

The justification for a signal acquisition scheme has been presented. A suitable schemehas been found in the literature, and has been modified and extended to improve itsaccuracy. The modified scheme requires that the transmitted signal is prefixed with atwo-symbol preamble sequence.

62

Part III

System implementation

63

Section 11

Baseband integration

The estimators and algorithms described in the previous sections had been developedlargely independently. As a first step towards creating a live modem, these parts neededto be assembled into a complete baseband system, as the task of synchronising MATLABcode with audio playback and capture could then be tackled separately. This approachwould also test that everything worked together successfully in a real-time system.

11.1 System design

Initial baseband simulations and test beds for the various estimators and algorithmsdescribed in previous sections were written in an independent fashion, although theyall relied on the same basic OFDM modulation and demodulation functions. When allalgorithms were ready to be integrated into a complete system, a decision was madeto re-write them, in order to create a modular software structure to make further workeasier. The aim of this was to define a common set of interfaces, so that any two modulescould be “plugged” together with minimal effort. These interfaces and the operation ofthis structure are described in more detail in Section 15.2.

A secondary aim of this design was to allow easier configuration of the system. Alluser-definable parameters were collected into a single MATLAB data structure, SETTINGS,whose values are set from a single source file. Each module was designed to automaticallyconfigure itself based on the values stored in this structure. This approach means thatexperimenting with different settings can be achieved without having to edit multiplesource files.

11.2 Baseband testing

The fundamental metrics of most communication systems are data rate and error ratio.For any set of OFDM parameters, data rate can be calculated a priori; this leavesmeasurement and estimation of error ratio as the goal of performing system tests.

64

Section 11: Baseband integration

5 6 7 8 9 10 11 1210

−8

10−7

10−6

10−5

10−4

10−3

10−2

10−1

100

Eb/N0 (dB)

BE

R

BPSK/QPSK8−PSKSim BPSKSim QPSKSim 8−PSK

Figure 11.1: BER performance of baseband system in an AWGN channel.N = 1024, L = 128, Np = 128.

BER can be estimated using Monte Carlo simulation; the MATLAB BER AnalysisTool (in the Communications Toolbox) automates this process. Its default setting is tostop the simulation when 100 errors have been observed; this gives a 95% confidenceinterval of less than 1 dB in Eb/N0, which is more than adequate for the purposes of thesemeasurements.

Figure 11.1 shows the BER performance of the baseband system operating in an AWGNchannel at various values of Eb/N0, and with various PSK constellations. Theoreticalcurves for these constellations (with perfect channel estimation and no CP) are alsoshown for comparison.

In all cases, there is considerable discrepancy between the theoretical minimum BERand the actual system performance. This is due to two factors. Firstly, as shown inAppendix B, there is a degradation in SNR when a CP is used, leading to a right shift of10 log10(N/(N+L)) (in Figure 11.1 this value is roughly 0.5 dB). Secondly, and more im-portantly, channel noise leads to a noisy channel estimate, which in turn imparts furthernoise on each sub-carrier symbol. It should be noted that this noise is multiplicative,not additive.

11.3 Conclusion

The complete physical-layer modem has been implemented at baseband in a modularsoftware structure. Its performance in an AWGN channel has been tested using MonteCarlo methods, with BER as the metric. It has been found that performance is somewhatworse than the theoretical minimum; this has been attributed to wasted signal powerand the noisy channel estimator.

65

Section 12

Live system integration

Following on from the implementation of an operational baseband system in simulation,the next step was to convert it to live passband operation. This transition was madeparticularly simple by the introduction of the modular software structure.

This section first discusses the theory of converting a critically-sampled baseband systemto a passband system operating in continuous time, and also some of the practical detailsof achieving this in a MATLAB implementation. Then the results of a set of tests aresummarised; these tests were both to verify correct operation, and to characterise BERperformance in a live environment.

Appendix C lists the equipment used to perform these tests.

12.1 Forming a passband system

In a traditional RF transmitter, the baseband signal x(t) is normally up-converted tothe passband signal s(t) using a time-domain mixer, as in Figure 4.2; alternatively x(t)may first be up-converted to an intermediate frequency (IF), where further processingis performed before a final conversion to the passband signal s(t) at the RF carrierfrequency.

In the system being designed for this project, analogue reconstruction occurs at thesoundcard DAC, after which no further processing can occur. Therefore, up-conversionmust be performed before analogue reconstruction, i.e. it must be done in MATLABitself.

Up-conversion must therefore be performed at the output sampling rate, so samplingrate conversion (interpolation) of x[n] is also required. The interpolation factor, Λ, canbe calculated as follows:

If the OFDM symbol rate is rs, and the soundcard sampling rate is fs, then the numberof output samples per OFDM symbol is fs/rs. Each baseband OFDM symbol is formed

66

Section 12: Live system integration

from (N + L) baseband samples. The interpolation factor is therefore:

Λ =fs

rs(N + L)(12.1)

For simplicity of implementation, an integer value of Λ is preferred, placing some limi-tations on the combinations of {fs, rs, N, L} that can be used. The values available forfs are determined by the soundcard, and ideally, the values of the OFDM parameters{N,L} should be completely flexible. Therefore, rs is constrained:

rs =fs

Λ(N + L), Λ ∈ Z+ (12.2)

In practice, this is not a problem, as a precise symbol rate is not usually mandatory.Instead, a desired symbol rate, rsdes

, may be converted to an actual symbol rate asfollows:

rs =fs⌈

fs

rsdes(N+L)

⌉(N + L)

(12.3)

12.1.1 Problems with time-domain interpolation

Conceptually, interpolation is performed in the time-domain by up-sampling (inserting(Λ−1) zeros between each sample), and then convolving with a windowed sinc waveform.In practice, there are other ways of achieving the same effect. However, whatever methodis used, time-domain interpolation is less than optimal in an OFDM system.1

Firstly, a windowed sinc waveform in the time-domain is equivalent to frequency-domainconvolution of a rectangular function with the frequency response of the window, asillustrated in Figure 12.1. The finite frequency-domain roll-off, Figure 12.1(f), implieseither that the sub-carriers at the edge of the transmission band will be attenuated, orthat the bandwidth of the filter must be increased, which requires VSCs to be introduced.

Secondly, time-domain interpolation must clearly take place after the CP has beenadded, and OFDM symbols concatenated into the discrete data stream x[n]. Applyinga filter at this point increases the effective channel length, and therefore increases therequired length of the CP.

In a practical RF system, these problems will be dealt with by using VSCs and a longerCP. In a low-frequency AF system, however, there is a practical alternative solution,discussed below.

1 Curiously, this non-optimality is not addressed in any of the literature surveyed for this project.Typically, the issue of interpolation is conveniently encapsulated into the DAC block on a system dia-gram, and nothing more said on the matter e.g. [1, p. 48].

67


(a)

(b)

(c)

(d)

(e)

(f)

⇔

⇔

⇔

= =

× ∗

Figure 12.1: Windowed interpolation filter. (a) Sinc filter. (b) von Hannwindow. (c) Windowed sinc filter. (d), (e), (f) Fourier transforms of

(a), (b), (c) respectively.

12.1.2 Forming passband signal in the frequency domain

The complete operation of interpolation and up-conversion of a periodic sequence x[n]may be performed in the frequency domain by appropriate zero-padding of Xk, asdemonstrated in Figure 12.2.

As mentioned above, this approach only works for periodic sequences. As each OFDMsymbol has implied periodicity which is then extended by the CP, the interpolation mustbe performed separately on each block before the CP is added. Therefore, a transmitterusing this approach can be represented by the block diagram of Figure 12.3.

It should be noted that this process is exactly equivalent to the addition of VSCs; inthis case the VSCs are added asymmetrically around the transmission band.

In an RF system, this approach would be impractical, as it would require an IDFTwindow of millions or billions of samples. However, in an AF system, the values of Λare far lower, and therefore achievable using this approach.2

An equivalent process may be used in the receiver, based on stripping away the frequency-domain zeros. This is represented in Figure 12.4.

In a traditional mixer-based receiver, an image-rejection filter is required to eliminateimage frequencies that would otherwise alias into the baseband signal. The frequency-domain approach described above implicitly implements the optimal BPF, so no image-rejection filter is needed.

2 It is also worth noting that this approach is considerably faster than performing interpolation inthe time-domain using MATLAB’s interp() function.

68


Figure 12.2: Zero-padding interpolation and up-conversion. (a) Originalunpadded frequency-domain representation. (b) Asymmetric zero-padding on

either side to interpolate by Λ and up-convert to complex passband.

Figure 12.3: Block diagram of an OFDM transmitter with zero-paddinginterpolation and up-conversion.

Figure 12.4: Block diagram of an OFDM receiver with zero-strippingdown-conversion and decimation.

69


12.1.3 Spectral limiting

In an RF communication system, the bandwidth of the transmitted spectrum must betightly controlled to minimise interference to systems on neighbouring bands. Sidelobesmust be included in this consideration, and their power kept below a certain threshold.This is normally achieved by implementing a BPF with very steep roll-off before thetransmitting transducer.

In this system, the filtering required for spectral limiting cannot be implemented pre-IFFT. The sidelobes are caused by the abrupt transitions between OFDM symbols; thesecannot be suppressed with pre-IFFT frequency-domain filtering as the IFFT works ona block-by-block basis, and so has no control over the inter-symbol transitions. Conse-quently, spectral limiting would require a time-domain filter operating at the samplingrate.

There is no requirement for sidelobe-suppression in this system; consequently, the extracomplication and computational burden of spectral limiting will not be implemented.

12.2 Choice of modulation scheme

In a single-carrier system, amplitude-shift modulation schemes such as QAM are oftenavoided, as they increase the need for power-amp linearity in the transmitter. Similarly,standard PSK is often avoided in favour of constant-modulus (or near constant-modulus)versions, such as GMSK, MSK or π/4-QPSK. In an OFDM system, there is already aninherently large PAPR, so there is no need to limit the choice of modulation scheme inthis manner. However, QAM has been avoided because it would require automatic gaincontrol (AGC) in the receiver. Therefore, only PSK-based schemes have been consideredfor the purposes of this project.

The Initial Report [6] suggested that a differential PSK scheme should be used, as thiswould eliminate the need for a channel estimator in a time-invariant environment. Asalready shown in Section 8.1.1, a channel estimator has been found to be necessaryfor the purpose of improved timing synchronisation. This being the case, there is nolonger any need to limit the modulation to DPSK (with its associated 3 dB drop in SNRperformance); instead, standard PSK may be used.

In an uncoded system, choosing the number of constellation points, M , involves thestandard trade-off of data rate against error ratio; the performances of QPSK, 8-PSKand 16-PSK in AWGN are shown for reference in Figure 12.5 (for an CP-less OFDMsystem in AWGN without channel estimation, these curves are correct; more realisticcurves were found in the baseband simulations of Figure 11.1). The performance analysisof an OFDM system in a frequency-selective channel is more complicated than for asingle-carrier system in AWGN, as BER is usually dominated by the sub-carriers with

70


0 5 10 1510

−8

10−6

10−4

10−2

100

Eb/N0 (dB)

BE

R

QPSK8−PSK16−PSK

Figure 12.5: Comparison of BER performance of various PSK modulationschemes in an AWGN channel. Generated by MATLAB bertool.

the lowest SNRs, as discussed in Section 4.5.2.

12.3 Working with audio

The base MATLAB 7.0.1 package does not offer suitable support for live audio stream-ing; however, the Data Acquisition Toolbox provides advanced control of soundcardcapture and playback. This functionality was used to create system modules capableof independent capture or playback, and another module for simultaneous capture andplayback on a single PC. The design and verification of these modules are covered indepth in Section 15.1.

Further modules were written that could write directly to and read directly from a PCMwave file. These could be used to, for instance, run the transmitter once and record theincoming sound to a wave file. This file could then be used to test various receiverconfigurations in complete silence, at a far faster rate than real-time.

These audio modules were all written to the common interface discussed in Section 11.1,so they could act as drop-in replacements for each other.

12.4 Running live tests

When performing software Monte Carlo simulations, as in Section 11.2, narrow con-fidence intervals can easily be achieved even at low BER, as MATLAB running on amodern PC can simulate several hundred OFDM symbols per second. In comparison,the symbol rate in live testing is obviously constrained to real-time; to test 104 OFDMsymbols takes roughly 11/2 hours at 2 symb/s, for instance. Finding a suitable environmentto perform tests of this length with no external noise has been difficult. Due to these

71


limitations, wider confidence intervals have had to be accepted, but for a qualitativecharacterisation of the system, this is not a significant problem.

Although the purpose of the modem is to transfer data from one PC to another, themajority of tests can be performed on a single PC connected to both a speaker and amicrophone. As only one soundcard is being used, the signal will not be subjected toCFO, but it has already been ascertained that this effect is negligible (see Section 7.2).This approach speeds up the development cycle, as there is no need to keep two copiesof the code and parameter settings synchronised.

The following sections describe the various live tests that were performed, in roughlychronological order. All tests were carried out in the room of Figure 6.2.

12.4.1 OFDM parameter settings

There is no inherent limit on the transmission bandwidth used by the system (other thanthe soundcard sampling rate), implying that bit rate could be increased indefinitelysimply by using more sub-carriers. To allow a basis for comparison, all tests in thissection will be run with a total of 1024 sub-carriers at a spacing of 2 Hz, giving a main-lobe bandwidth of roughly 2 kHz.

CP length, L, was chosen as 128, equivalent to a time of 62.5 ms, which is more thanadequate for the combination of the acoustic channel length and synchronisation bias.

Standard soundcard sampling rates are 8 kHz, 11.025 kHz, 22.05 kHz and 44.1 kHz.Higher multiples of 44.1 kHz may also be available, as well as DAT-related rates (24 kHz,48 kHz, 96 kHz, etc.). For the purposes of this project, only standard rates will be used,to maximise portability of the code. Initial tests were performed at the lowest rate,8 kHz, as this minimises computational requirements.

With these choices, the range for fc is roughly 1 kHz to 2 kHz. For simplicity, the meanhas been used, 1.5 kHz, as this avoids near-DC frequencies where the AC-coupling of thesoundcard DAC will begin to roll off, and also avoids near-Nyquist frequencies, wherethere may be issues with the interpolation filter used in the soundcard for resampling.3

12.4.2 Testing acquisition and synchronisation

Before BER measurements could be performed, it was necessary to ensure that theacquisition and synchronisation algorithms worked effectively in a live setting.

With the system as described above, band-pass filtering and baseband decimation ofthe incoming signal does not occur in the receiver until the DFT. As the Schmidl-Coxacquisition algorithm operates in the time-domain, it must therefore operate on the

3 Many soundcards always resample the incoming signal to the highest rate they can handle, as thisminimises the complexity of the analogue reconstruction circuitry.

72


BER Nominal spectral efficiencyConstellation Comb Block (bit/s/Hz)

BPSK 4.8× 10−4 1.3× 10−4 0.8QPSK 4.9× 10−3 2.9× 10−4 1.68-PSK 2.1× 10−2 9.5× 10−4 2.416-PSK 6.7× 10−2 3.9× 10−3 3.2

Table 12.1: Comparison of live system BERs. Other parameters are as givenin Section 12.4.1. Each run consisted of 106 bits.

unfiltered un-decimated passband signal. This is undesirable for two reasons. Firstly,it is subject to wideband noise, which decreases the effective SNR of the correlator.Secondly, many soundcard DACs will have a non-zero DC offset, which will not onlyincrease the level of the energy term, E[n], but also the correlator term, γ[n], possiblyleading to false triggering.

The alternative is to apply time-domain band-pass filtering (and possibly decimationas well) before the synchronisation algorithm. However, there has not been sufficientproject time to investigate the effectiveness of this approach.

12.4.3 Initial BER measurements

The first tests performed compared system performance with various PSK constellations,and with comb and block pilot patterns, see Table 12.1. The spectral efficiency, η, foreach constellation is also specified for reference, defined here as the ratio of the bit rateand main-lobe bandwidth.

These results are essentially as predicted in Section 9.4; for every constellation, theblock pilot pattern is far superior to the comb pattern. There were no mobile scatterersin the room when these measurements were made, so the channel was essentially time-invariant; it is predicted that the superiority would be reversed in a time-variant channel,although there is no practical way of testing this at present.

12.4.4 Finding optimum centre frequency

In a frequency-selective environment with frequency-dependent interference or noise, theaverage sub-carrier SNR will vary with the overall centre frequency, fc. Therefore, inany given environment, there will be an optimum choice of fc. fc is of course limited bythe sampling frequency, fs, and the signal bandwidth (approximately N/T). As alreadydiscussed, for the settings used thus far, fc is limited to approximately 1 kHz – 2 kHz].To allow greater flexibility, the sampling frequency was therefore increased to 22.05 kHz.

The optimum fc will be specific to a particular environment and transducer placementand orientation. However, as an example of how performance is affected, a set of BERmeasurements were performed at various values of fc, with all other factors kept con-

73


0 2 4 6 8 1010

−6

10−5

10−4

10−3

10−2

fc (kHz)

BE

R

Figure 12.6: Live system BER performance at various centre frequencies.QPSK constellation, block pilot pattern. Each run consisted of 106 bits.

stant; the results are shown in Figure 12.6.

As the graph shows, the optimum values are 3.5 kHz and 9.5 kHz; all subsequent testshave therefore been carried out at 9.5 kHz.4

12.4.5 Finding optimum signal power

The transmitted signal was found to have an average PAPR of approximately 13 dB. Ata low enough signal power level, the non-linearities of the amplifier and loudspeaker willbe negligible, so BER will generally drop as power increases. This relationship will nothold indefinitely the increasing IMD will appear as interference, raise the effective noisefloor, and BER will begin to increase again.

Tests have been performed to investigate this relationship. Power was increased byadjusting the gain slider on the audio mixer - this ensures that any change in non-linearity is due to the audio amplifier and speaker; if gain was adjusted in software thenthis would also change quantisation distortion. There is no easy way to measure signalpower in absolute units (such as Watts); instead, dimensionless units have been used,specified in dB relative to the maximum power used. Note that these are “desired”powers, read from the markings on the mixer sliders; the actual acoustic power is notnecessarily linearly related, due to compression. The results are shown in Figure 12.7.

12.4.6 PC-to-PC communication

At this stage, it had been established that the system performed well when both trans-mitter and receiver were executed on a single PC, where it could be guaranteed thatthere was zero sampling rate offset. When attempting to transmit from one PC to an-

4 9.5 kHz is preferable to 3.5 kHz, as it is less objectionable to listen to.

74


−30 −20 −10 010

−6

10−5

10−4

Power (dB)

BE

R

Figure 12.7: Live system BER performance at various output powers. Eachrun consisted of 106 bits.

other, however, the acquisition algorithm did not achieve lock. Whilst it detected theenergy term E[n] correctly, the correlation term γ[n] remained at an extremely low levelduring the SYNC1 symbol.

There was not sufficient time left to investigate what the cause of this failure was;however, it is suspected that the small sampling rate offset found in Section 7.2 is theroot of the problem, as it is the only factor that is different in the PC-to-PC scenario.

12.5 Conclusion

A frequency-domain method for converting baseband OFDM symbols to passband hasbeen identified; this method is possible due to the low sampling rates being used.

Other decisions on the system design have been made in order to simplify implementa-tion; namely, no spectral limiting filters have been used, and the constellations employedhave been limited to PSK only.

A set of live passband tests have been performed on a single PC, in order to charac-terise system performance, using BER as the metric. Various constellation sizes werecompared, along with both block and comb patterns; as expected, the block patternperformed significantly better due to the non-sample-spaced channel problem. Variouscentre frequencies and power levels were also compared; as expected, performance var-ied with both factors due to the frequency-dependent SNR of the channel and the highwaveform PAPR, respectively.

A PC-to-PC transmission has been attempted; this failed due to the acquisition algo-rithm not identifying the SYNC symbol. This may be attributable to the sampling-rateoffset, but there has not been time to confirm this hypothesis.

75

Section 13

Sending useful data

One of the aims of the project was to produce a visual demonstration of the modem inaction. A simple way of achieving this is to provide the ability to transmit visual data,such as text files and images. Separate modules have been written for this purpose; thissection covers the principles involved, and the implementation used.

13.1 Datagram principle

The system operates in simplex mode only, i.e. there is no response path availablefor the receiver, so acknowledgements or requests for re-transmission are impossible.Consequently, all transmissions of useful data will be connectionless datagrams.

An individual datagram needs to contain metadata that describes the “user” data beingcarried, including the data type and length. This metadata should appear as close to thestart of the transmission as possible, so that the receiver can begin specific processing forthe incoming data as early as possible. Figure 13.1 shows a suitable generic datagramstructure, where Acquisition represents the SYNC symbols described in Section 10. TheHeader section contains the datagram metadata.

If an error occurs in the reception of the header, the receiver will have incorrect in-formation about the user data. Of particular importance is the data length; if this isinterpreted incorrectly, then the receiver will either truncate the incoming transmission,or will continue receiving for too long and attempt to demodulate noise.

Therefore, even in an uncoded baseband system, the datagram header fields should beprotected with dedicated FEC coding. Even for a low rate code, the impact on overallspectral efficiency will be minimal, as the header will usually be significantly shorter

Figure 13.1: Generic datagram structure.

76

Section 13: Sending useful data

Figure 13.2: Datagram header structures. (a) Text header. (b) Imageheader.

than the user data.

13.2 Implementation

The datagram protocol is implemented by the Source (transmitter-side) and Handler

(receiver-side) classes. They have been designed to transmit raw ASCII text files (.txtextension) and Windows bitmap image files (.bmp extension), but could be extended inthe future to send other data formats. The data in each is taken on a block-by-blockbasis and fed to the OFDM transmitter module; image files are first converted to 24-bitnon-indexed format.

13.2.1 Structure of text and image datagram headers

The header structures for text and image datagrams are shown in Figure 13.2.1

A one-byte Type field has been used to distinguish between the two data types, withvalues 0x55 identifying text, and 0xAA identifying an image, these values being separatedby the maximum possible Hamming distance. The one-byte field allows other types tobe introduced in the future.

In the case of text files, the only information of relevance is the file length (in bytes). Inthe case of image files, the image dimensions (in pixels) are required as well. The Length,Width and Height fields are all two-byte big-endian fields, allowing a maximum value of65,536.

These headers are FEC encoded before being inserted into the data stream. The MAT-LAB block decoding functions are completely unoptimised; they perform ML decodingby checking the received word against every possible combination of codeword + errorpattern. Therefore, truncated convolutional coding has been used instead, based on therate 1/2, K = 4, coder structure of Figure 13.3 (taken from [29, p. 455]). The headersare recovered at the receiver with a hard-decision Viterbi decoder.

1 The fields marked RESERVED were for further work which was not completed in time.

77

Section 13: Sending useful data

Figure 13.3: Convolutional coder used for datagram headers.

(a) (b) (c)

Figure 13.4: Examples of transmitted images sent on differentconstellations, with N = 1024, L = 128, Np = 128, block pilot pattern,

fc = 5kHz and ∆f = 2Hz. (a) QPSK. (b) 8-PSK. (c) 16-PSK.Original image © 2003, http://auta5p.car.cz

13.3 Example output

Figure 13.3 shows the same image as transmitted by the system using three differentconstellations. Errors have been highlighted in white, for ease of reference.

13.4 Conclusion

A simple datagram protocol has been implemented so that text and image files maybe transmitted to demonstrate the operation of the system. The datagram contentsare identified by metadata stored in a header; the headers are protected with a simpleconvolutional code. Text and images have been successfully transmitted using thisprotocol.

78

Section 14

The GUI

A MATLAB GUI has been developed that allows a user to select text and image files,set system parameters, and perform transmission and reception. The system can beset to act as a transmitter, a receiver, or both simultaneously (loopback operation).Alternatively, it may be set to “receive” from a pre-recorded WAVE file. The GUIcode automatically configures the correct modules and “connects” them together; seeSection 15.2.1 for details on how this is achieved.

The GUI also contains an output log to display debug messages from various codemodules, and also graphs of the current channel estimate in frequency-domain andtime-domain form.

Figure 14.1: Screenshot of the demonstration GUI.

79

Section 15

Program design

This section covers some of the practical issues involved in implementing a real-timeaudio-based system in MATLAB, and then discusses the modem program structure.

15.1 Audio input and output

For real-time operation, a system is required that allows manageable chunks of audiodata to be streamed to and from the PC soundcard.1

The base MATLAB 7.0.1 package has two sets of routines that offer audio-handlingfunctionality:

• wavplay() and wavrecord() functions

• audioplayer and audiorecorder objects

Both of these are suited for “one-shot” block capture and playback; i.e. they are designedto capture or play a single, fixed-length waveform vector, but not to stream arbitraryamounts of data to or from the soundcard.

Taking the receiver as an example, one solution would be to perform a series of shortwavrecord()/audiorecorder captures, each of a fixed length, and then concatenate theresults. This approach was described by Terence Withers in his project report [30], whereit was noted that it did not, in general, provide contiguous recording between capturesdue to the latency involved in initiating a capture. A workaround was proposed thatinvolved overlapping captures, and then identifying and discarding repeated sections.Whilst this was found to be effective, it consumed excessive CPU time (in order toidentify the overlaps), was potentially unreliable (due to local periodicity being falselyidentified as an overlap), and was not a particularly elegant solution.

1 In theory, the entire transmission waveform could be computed and sent to the soundcard asa single vector. Equally, the entire received waveform could be captured in a single vector and thenprocessed. However, this would require an area of memory proportional to the transmission length, andwould give a latency lower-bounded by the transmission length.

80

Section 15: Program design

A better solution can be found in the MATLAB Data Acquisition Toolbox, which offerssupport for buffered, streaming audio.

15.1.1 The Data Acquisition Toolbox

This toolbox provides two relevant objects; analogoutput for playback, and analoginput

for capture. The key advantages of these objects are:

• The analogoutput object provides a buffer that allows chunks of data to be queuedasynchronously, as shown in Listing 15.1 below.

ao = analogoutput(’winsound’); % Create analogoutput objectaddchannel(ao, 1); % Set mono output

putdata(ao, data); % Queue some data for playbackstart(ao, data); % Commence playback

while (true)... % Do some processing here

putdata(ao, data); % Queue more data for playbackend

Listing 15.1: Asynchronous playback

• Captured data is buffered in the analoginput object, and can be extracted asyn-chronously, as shown in Listing 15.2 below.

Note that whilst the getdata() method is blocking, the analoginput system is stillasynchronous in the sense that data extraction does not have to be synchronisedwith soundcard acquisition.

ai = analoginput(’winsound’); % Create analoginput objectaddchannel(ai, 1); % Set mono input

start(ai, data); % Commence capture

while (true)data = getdata(ai, len); % Get len bytes of data.

% getdata() blocks until this% data is available.

... % Do some processing hereend

Listing 15.2: Asynchronous capture

• Callbacks can be set up so that a user-defined function is executed whenever acertain amount of data has been played or captured.

With careful timing of the putdata() and getdata() method calls, it is possible to useboth an analogoutput and an analoginput simultaneously on a single PC, as is done in theLiveChannel class (see Section 15.2.9).

81


Figure 15.1: Class inheritance tree.

15.2 Program structure

The final modem code is based on a modular, object-oriented structure, whose inheri-tance tree is shown in Figure 15.1.

15.2.1 DataSource and DataSink interfaces

All major signal-handling components derive from two base classes, DataSource andDataSink, as shown in the inheritance tree of Figure 15.1. A DataSource is an objectthat provides data via its read(), peek() and skip() methods, whereas a DataSink can beregarded as an object that accepts data via its write() method.

Deriving in this way means that all components share a common read/write interface,and so any two suitable components may be “connected” together with a single lineof interface code. For instance, a basic modem simulation can be achieved with thefollowing code:

tx = Transmitter(SETTINGS, source); % Create transmitterrx = Receiver(SETTINGS, tx); % Create receiver[rx, data] = read(rx);

If the effect of the channel is to be simulated, a further line of code may be added:

tx = Transmitter(SETTINGS, source); % Create transmitterchannel = SimChannel(SETTINGS, tx); % Create channel simulatorrx = Receiver(SETTINGS, channel); % Create receiver[rx, data] = read(rx);

If a live system running on a single PC is desired, then the SimChannel may be swappedfor a LiveChannel:

tx = Transmitter(SETTINGS, source); % Create transmitterchannel = LiveChannel(SETTINGS, tx); % Create live channelrx = Receiver(SETTINGS, channel); % Create receiver[rx, data] = read(rx);

82


To run the transmitter and receiver on separate PCs, the following code should be usedon the transmitter PC:

tx = Transmitter(SETTINGS, source); % Create transmitterspeaker = Speaker(SETTINGS, tx); % Create speaker handlerrun(speaker);

and the following code on the receiver PC:

mic = Mic(SETTINGS); % Create microphone handlerrx = Receiver(SETTINGS, mic); % Create receiver[rx, data] = read(rx);

It should be noted that all modem components operate in a pull model, i.e. the receiveractively pulls data from its source, which in turn pulls data from its own source, and soon.

DataSource and DataSink are both abstract base classes.2 DataSource exposes the methodsin Table 15.1 (implemented in terms of abstract method genRead()), and the abstractmethods in Table 15.2. DataSink exposes the methods in Table 15.3 (implemented interms of abstract method genWrite()), and the abstract methods in Table 15.4.

Method Behaviour

[obj, data] = read(obj, len) Reads data from the object, and advances its in-ternal read pointer. The len specifies the num-ber of entries to be returned, and is optional. Ifomitted, all available data is read.

[obj, data] = peek(obj, len) Obtains data from the object, but does not ad-vance the internal read pointer. The len specifiesthe number of entries to be returned, and is op-tional. If omitted, all available data is obtained.

obj = skip(obj, len) Advances the object’s internal read pointer for-ward. The len specifies the number of entriesto be skipped, and is optional. If omitted, allavailable data is skipped.

Table 15.1: DataSource exposed methods.

15.2.2 CircularBuffer class

The CircularBuffer class derives from both DataSink and DataSource, so that data can bewritten to and read from it by other components.

2 Whilst MATLAB allows classes to be derived from base classes, the language does not include theconcept of abstract base methods, i.e. methods that must be overriden by derived classes. They can,however, be simulated by throwing an error in all base class methods for which this behaviour is desired.

83


Method Behaviour

len = available(obj) Returns the number of entries available in theobject’s buffer.

[obj, output]

= genRead(this, len,

shouldUpdate, shouldExtract)

Performs all operations required to provideread(), peek() and skip() functionality.

Table 15.2: DataSource abstract methods. Must be overriden in derivedclasses.

Method Behaviour

[obj, lenWritten]

= write(obj, data)

Writes data to the object, and advances its in-ternal write pointer. lenWritten is the number ofentries that were actually written.

Table 15.3: DataSink exposed methods.

Method Behaviour

len = space(obj) Returns the amount of space in the object’sbuffer.

[obj, lenWritten]

= genWrite(this, data)

Performs all operations required to providewrite() functionality.

Table 15.4: DataSink abstract methods. Must be overriden in derivedclasses.

The CircularBuffer class is used to implement a First-In, First-Out (FIFO, or queue) datastructure. This is achieved using a normal fixed-length linear array, and maintaining aread pointer (iRead) and a write pointer (iWrite). Whenever a read or write operationis performed, the relevant pointer is advanced in a modulo-L fashion (where L is thelength of the array), so that they circulate round the buffer indefinitely.

This is illustrated in Figure 15.2. (a) represents an initialised but unused buffer. In(b), 5 blocks have just been written to the buffer, so the write pointer advances. In(c), 3 blocks are read, so the read pointer advances. Finally, in (d), another 12 blocksare written, so the write pointer advances, and wraps around to just behind the readpointer.

Overlap safety is managed by the class; i.e. if the write pointer catches up with theread pointer, then the current write operation is truncated (and vice versa for a readoperation).

84


Figure 15.2: Operation of circular buffer

15.2.3 Transmitter and Receiver classes

These implement the OFDM transmitter and receiver. A Transmitter object takes abinary source, and creates a baseband or passband OFDM waveform, including theSYNC symbols. A Receiver object takes a waveform source, attempts to acquire a signaland synchronise to it; and creates a binary output if successful.

15.2.4 DatagramSource and DatagramHandler classes

These implement the datagram protocol layer. DatagramSource takes the filename of aASCII text file (*.txt) or Windows bitmap file (*.bmp), creates an FEC-encoded header(see Section 13.2.1), and may then be read as a binary stream. DatagramHandler acceptsa binary source, attempts to decode a header, and processes the incoming data.

15.2.5 PilotGenerator class

The PilotGenerator class generates pilot symbols and patterns. In its current state, it iscapable of producing comb and block patterns, but is designed to be extendible to otherpatterns.

A PilotGenerator object acts like an N × Lpat matrix representing the time-frequencylattice (see Section 9.2), where Lpat is the pilot pattern period in OFDM symbols. The

85


following code demonstrates the use of this matrix:

pg = PilotGenerator(SETTINGS); % Create PilotGenerator object

pg.indices % Logical matrix; pilot locations indicated by logical truepg.dataindices % Logical matrix, data locations indicated by logical truepg.values % Matrix containing complete pilot pattern

% (with 0 at non-pilot locations)

Note that if there are no VSCs, then pg.indices == ~pg.dataindices.

15.2.6 Estimator interface

As discussed in Section 9, there are many possible approaches to channel estimation inOFDM, with varying degrees of latency. In order to minimise changes needed to thereceiver code, all estimator modules derive from the Estimator base class, which exposesthe two abstract methods described in Table 15.5, which must be overridden.

Method Behaviour

latency = getLatency(obj) Returns the maximum latency of the estimator(measured in OFDM symbols).

[obj, estimates, nPeak]

= process(obj, Y)

Performs the next estimation iteration, with anew OFDM symbol vector Y. estimates is an ar-ray of the returned estimates for previous OFDMsymbols, and nPeak is the estimated timing offset,or -1 if no estimate.

Table 15.5: Estimator abstract methods.

The receiver may use these methods as follows:

latency = getLatency(estimator);buffer = CircularBuffer(latency, N); % Create a FIFO buffer

% to store previous OFDM symbols

while (true)... % Receive next OFDM symbol (Y)buffer = write(buffer, Y); % Store in buffer

[estimator, estimates, nPeak] ...= process(estimator, Y); % Pass the new symbol to estimator

% Use each estimate returned from the estimator to correct% the corresponding OFDM symbol stored in the FIFO buffer.for est = estimates

[buffer, Y_old] = read(buffer, 1); % Get the next old OFDM symbol

X_est = Y_old(est.iS) .* conj(est.H); % Obtain estimate of% transmitted symbols

end... % Use nPeak to move FFT window

end

86


15.2.7 SimChannel class

The SimChannel class is designed to be placed between a a Transmitter object and a Reciever

object, and simulates a baseband channel, with a specified impulse response and noiselevel. Note that it does not currently simulate fading, although this feature would besimple to add in the future, using the rayleighchan() and ricianchan() objects availablein the Communications Toolbox.

15.2.8 Speaker and Mic classes

These are automated wrappers for the speaker and microphone, and use the analogoutput

and analoginput objects, respectively. The data flow of each is shown in Figure 15.3.

When first created, a Speaker object sets up an analoginput object, and queues threechunks of source data. The analoginput is given a callback method, so that every timeone chunk’s worth of data has been played, a new chunk is obtained from the sourceand queued. This method ensures that there is always adequate data in the analoginput

buffer, even whilst the callback is being processed.

When first created, a Mic object sets up an analoginput object, and also a CircularBuffer.Every time genRead() is called, the amount of data in the CircularBuffer is checked; ifit is less than one chunk, another chunk is read from the analoginput and added to thebuffer. Read/write/skip operations are then carried out on the CircularBuffer.

15.2.9 LiveChannel class

The LiveChannel class derives from both Speaker and Mic, provides simultaneous live audioplayback and capture on a single PC, and is intended to be placed between a Transmitter

object and a Reciever object. In this sense, it can be used as a drop-in replacement forthe SimChannel channel-simulation class.

15.2.10 SETTINGS structure

All relevant parameters are stored in the SETTINGS data structure. User-defined parame-ters may be edited in getParams.m, or by the GUI if it is being used. Further “derived”

Figure 15.3: Internal data flow of (a) Speaker and (b) Mic classes.

87


parameters are set by setDerivedParams().

15.3 Use of the profiler

MATLAB offers a code profiler, which measures, amongst other things, the amount oftime spent in each function and on each line of code. This allows, if desired, aggressivecode optimisation. Whilst for real-time operation of the modem this is largely unneces-sary (processing a symbol rate of ≈ 2 symb/s places little burden on the CPU), for longBER simulations, large amounts of time may be saved.

The profiler highlighted particular areas as processing bottlenecks; the correspondingcode sections were then optimised. Some of the bottlenecks were caused by certainMATLAB functions; pskmod() and pskdemod() were particularly problematic, as theywrap general modulation functions which perform inefficiently. Therefore, they havebeen re-written as bin2PSK() and PSK2bin(), which perform significantly faster, and alsoincorporate Gray coding; see Appendices D.13.3 and D.13.4.

Some optimisations may significantly reduce code legibility; this is undesirable in a pro-gram that is undergoing constant modifications and experimentation. Therefore, certainpotential optimisations have been sacrificed for this reason. The modular structure ofthe code is one example of this; CircularBuffer objects were found to be the biggestbottleneck, but were retained as they abstracted the implementation of FIFO data han-dling.

In its current state, a baseband simulation of 106 bits (with N = 1024, L = 128 andNp = 128) may be processed in 7.5 s, giving an average processing rate of approximately133 kbit/s, or 140 symb/s.

88

Part IV

Final comments

89

Section 16

Further work

Due to project time constraints, a number of important issues were not investigated,and some technical problems were not resolved; a fully functional modem would requirethese to be resolved. This section first summarises the most relevant of these, and thenprovides some suggestions for follow-on work and future project topics.

16.1 Unresolved issues

PC-to-PC operationNo explanation has been found for the failure of the system when transmitterand receiver are executed on separate PCs. The CFO (or more correctly, samplingfrequency offset) measurements discussed in Section 7 imply that this effect shouldbe negligible. However, all other things being equal, this seems to be the onlypossible cause of the failure.

FEC codingFEC coding and bit or symbol interleaving are now considered an integral partof an OFDM PHY. This project has only characterised the “raw” uncoded BERperformance of this system; there has not been time to consider aspects of codingand interleaving at all, except for the simple truncated convolutional code used inthe datagram header.

Whilst a moderate increase in performance could be achieved simply by passingthe entire data stream through a similar encoder before being OFDM modulated,or by using an independent encoder on each sub-carrier, this would not be optimal;the high correlation of neighbouring points in the channel lattice would tend tolead to burst errors. If bit-interleaving is used, a form of diversity is achieved, asneighbouring bits in the coded stream(s) no longer map to neighbouring points inthe lattice, and ideally undergo uncorrelated fading. This approach has its routesin the work on bit-interleaved coded modulation (BICM) for single-carrier systems(e.g. [31, 32]), but extended to two dimensions.

90

Section 16: Further work

Investigation of these properties and designing a good coding scheme for OFDMis conceivably an entire project in itself.

PAPR reductionIt was found, as expected, that at high signal powers the performance of the systemwould be limited by PAPR. This in turn places limits on the microphone–speakerseparation distance, and therefore the usefulness of this system in a practicalapplication.

Some potential solutions are summarised by van Nee and Prasad [1, Ch. 6]; theseinclude judicious signal clipping, generating superimposed waveforms which cancelthe peaks, and coding with a word set that has the minimum PAPR. This finalapproach is extended by work such as that of Tarokh and Jafakhani [33], who pro-pose applying carefully-selected phase rotations to the individual symbols outputfrom the FEC encoder, with the advantage that there is no further decrease inspectral efficiency.

Channel estimationThe channel estimator is critical to the operation of the receiver, as it is required forboth correct symbol detection and timing synchronisation. There is considerablescope to improve this estimator beyond that currently used.

A one-dimensional DFT-based ML channel estimator was used in this project;this presented a problem in non-sample-spaced channels. A paper was found thatclaimed to reduce this problem at the expense of increased complexity and apriori knowledge of the channel statistics [27]; the method proposed may be worthinvestigating more closely.

Alternatively, a better solution may be found by moving to an LMMSE estimation,or an approximation thereof. These are again more complex than the estimatorsused here, but potentially offer better performance in non-sample-spaced channels[34], as well as superior performance in frequency-selective, time-variant channelswhere scattered pilots may be more appropriate.

Duplex operationIntroducing full- or half-duplex communication brings up a range of interestingtopics. There is first the question of how duplexing would be achieved at theair interface level; in other words, whether time- or frequency-division duplexingwould be used. Duplexing would also allow the receiver to send channel estimatedata back to the transmitter; this would permit adaptive power distribution orbit-loading to be used, which moves the system closer to channel capacity [7, pp.716-718].

A MATLAB-based implementation presents a serious problem, however, as themodules available in the Data Acquisition Toolbox are not designed for this sort

91

Section 16: Further work

of use. Whilst it has already been demonstrated that simultaneous playback andcapture are possible, the analogoutput callback is executed in a separate thread(or so it would appear), with its own copy of the data; it is not known whetherit would be possible to interact with data in other threads to make a useful mo-dem transceiver, as MATLAB uses pass-by-value rather than pass-by-referencesemantics.1

16.2 Future projects

As discussed in the report introduction (Section 1), there are some situations where sucha modem would be highly practical. It would be beneficial to further develop the systemto suit one of these applications, with the aim being to develop a usable product orframework. The two application areas mentioned were underwater communication andaudio watermarking. Designing a system to suit one or other of these areas would requireconsiderable investigation; certainly enough work to sustain a future MEng project.

Creating an underwater system, for instance, would require characterisation of the chan-nel (namely water), selection of acoustic transducers followed by a more thorough inves-tigation into their non-linearities, and then development of a suitable channel estimatorand PAPR-reduction scheme.

The design of a system for embedding data into existing audio would probably requiremore focus on aspects of the human psychoacoustic response, and methods for shapingthe signals to be inaudible.

A less practical – but nevertheless involved – project would be to extend the modem toduplex operation. If this were achieved, it would become possible to implement existingnetwork layers over the system, such as TCP/IP. If multiple nodes (transceivers) wereintroduced, then a multiple-access scheme would be required. The resulting OFDMAsystem could have practical applications, such as for mesh networks of underwater sen-sors, for instance.

1 Pass-by-value means that whenever a variable is supplied to a function as a parameter, its valueis passed to the function, rather than the variable itself. For example, when function foo(x) is called,foo() operates on a copy of x, rather than the original. This is problematic because any changes madeto variables during analogoutput/analoginput callback functions will not be reflected in the originalvariable.

92

Section 17

Conclusion

This project has aimed to construct an operational demonstration of an OFDM modemover an acoustic channel. The key theoretical areas of potential difficulty were identifiedas frequency and time synchronisation, channel estimation, and signal acquisition; afterexamination of the existing academic literature, various algorithms were selected forfurther study, implementation, and evaluation.

An initial aim of the project was to develop a pilot-less implementation, so as to increasespectral and power efficiency. Whilst it was found that this would have been possibleusing a blind timing algorithm, and a differential modulation scheme to render channelestimation redundant, it was felt that this approach would have given worse systemperformance overall.

A DFT-based, pilot-based channel estimator was selected for the receiver due to itsrelative simplicity; its performance is less than optimal in several senses, particularlywith respect to the problem of a non-sample-spaced channel response. The estimatorworks with both comb and block pilot patterns; the comb pattern performed poorly ina continuous channel, so in the relatively time-invariant environment, the block patternprovided better performance. Explicit timing estimation with a separate algorithmwas found to be unnecessary, as the same effect could be achieved using the channelestimator.

Measurements were taken of the relative sampling-rate discrepancy between the sound-cards of two PCs; the relative offset was in the order of 10−6. Theoretical analysis fromthe literature implied that this value would result in negligible interference, and hencethat frequency tracking and correction would not be required at the receiver.

A signal acquisition algorithm has also been implemented; this requires the transmissionsequence to be prefixed by a dedicated SYNC symbol, whose structure is highly corre-lated. This algorithm was found to work well at baseband; however, in the live system,its performance was degraded due to the lack of band-pass pre-filtering. Nevertheless,this arrangement was found to be adequate.

93

Section 17: Conclusion

Various environmental factors were investigated and characterised; this allowed an in-formed design process to be used, as well as selection of suitable system parameters.

Software has been developed to implement a complete system, for both baseband simu-lation, and also for various live operation configurations. The software has been writtento a modular architecture using a set of common interfaces, in order to allow easy mod-ification to the system design. All software modules were developed in MATLAB 7.0.1,requiring the Signal Processing, Communications, and Data Acquisition toolboxes.

A series of tests were performed in a small residential room, with a line-of-sight path be-tween transmitter and receiver, and both the transmitter and receiver modules runningon the same PC, in the same instance of MATLAB. With the main-lobe bandwidth ar-bitrarily constrained to approximately 2 kHz, an uncoded data rate of 3.2 kHz has beenachieved at a BER as low as 5× 10−6 (95% confidence interval [1.6× 10−6, 1.2× 10−5])using QPSK, equivalent to a raw spectral efficiency of 1.6 bit/s/Hz. Relaxing the band-width constraint allowed a proportionally higher bit rate. The performance was found,as expected, to vary with centre frequency; this is attributed to the frequency response ofthe channel, and the frequency-variant nature of the environmental noise. Performancein outdoor or non-line-of-sight scenarios has not been explored.

Successful operation was not obtained when the transmitter and receiver were runningon separate PCs; the acquisition algorithm did not detect the correlated structure ofthe SYNC symbol. There has not been time to investigate this issue any further, but itis assumed that it must be due to sensitivity to the sampling rate offset.

System performance is limited by hardware non-linearities; the OFDM waveforms usedexhibit an average PAPR of 13 dB. This limits the acoustic transmitter power levels thatmay be used; in turn, this limits the useful speaker–microphone separation distance.

A simple datagram protocol layer has been implemented over the physical layer modemto demonstrate its usage, and is capable of transmitting text and bitmap image data,identified with an FEC-encoded header. A GUI wrapper for the modem has also beendeveloped, allowing a user to configure various system parameters, select text and imagefiles for transmission, and observe the output of the channel estimator in real-time.

Finally, further areas of investigation have been identified; these include solving theproblems identified with the current system, extending system performance with toolssuch as FEC coding, and practical applications as topics for future MEng projects.

17.1 Acknowledgements

The author would like to thank Dr. Yuriy Zakharov and Prof. Alister Burr for theirhelpful advice on aspects of this project, and guidance on the content and structure ofthis report.

94

Appendices

95

Appendix A

Derivation of the channelestimator MSE

This appendix presents a derivation of the MSE of the DFT-based ML comb estimatorof Section 9.3. The derivation is based on those by Negi and Cioffi [26] and Morelliand Mengali [25], but considerably adapted to suit the DFT-based implementation andnotation.

The error covariance matrix of the estimator is given by:

∆H = E|H −H|2 (A.1)

where H and H are defined by (9.4) and (9.13), repeated here for reference:

H = Q

[IL

0

]hL (A.2)

H =

√N

NpQ

[IL 0

0 0

]Φ∗Q∗

pHp (A.3)

We also collect the pilot symbol relationships of (9.2) into vector form:

Hp = X∗pYp

= Hp + X∗pVp

= Hp + V ′p (A.4)

where Xp = diag{Xp0, Xp1, · · · , Xp(Np−1)} contains the transmitted pilot symbols, Yp

is a vector containing the received pilot symbols, and Vp is a vector of the i.i.d. noise onthe pilot sub-carriers, with covariance E|Vp|2 = σ2

V INp , where σ2V is the noise variance.

96

Appendix A: Derivation of the channel estimator MSE

Substituting (9.8) for Hp:

Hp = Ψ2hL + V ′p

=

√Np

NQp Φ

[IL

0

]hL + V ′

p (A.5)

Substituting into (A.3) for Hp, we get:

H = H +

√N

NpQ

[IL 0

0 0

]Φ∗Q∗

pV′

p (A.6)

Substituting into (A.1), we get:

∆H =N

NpQ

[IL 0

0 0

]Φ∗Q∗

p E |Vp|2 QpΦ

[IL 0

0 0

]Q∗

=σ2

V N

NpQ

[IL 0

0 0

]Q∗ (A.7)

The MSE for the k-th sub-carrier is given by the k-th diagonal entry of ∆H , i.e.:

MSEk =σ2

V N

Np

N−1∑α=0

[Q]k,α

N−1∑β=0

[IL 0

0 0

]α,β

[Q∗]β,k

=σ2

V

Np

L−1∑α=0

L−1∑β=0

Wk[β−α]N δ[β − α]

=σ2

V L

Np(A.8)

97

Appendix B

Derivation of some SNRrelationships for baseband OFDM

In this appendix, the effects of including pilots and a CP on the SNR of a basebandOFDM system are demonstrated. In the following, it is assumed that the system isoperating in a non-frequency-selective channel, and that the receiver has perfect channelestimation.

B.1 Baseband OFDM

Starting with the following relationship:

y[n] = x[n] + v[n] (B.1)

where the noise power is given by E |v[n]|2 = σ2v , and the transmitted signal, x[n], is

given by:

x[n] =1√N

N−1∑k=0

Xk ej2πkn

N (B.2)

where we will assume that the symbol values are constrained to |Xk| = 1.

The time-domain signal power, S, is given by:

S =1N

N−1∑n=0

|x[n]|2

=1

N2

N−1∑n=0

∣∣∣∣∣N−1∑k=0

Xk ej2πkn

N

∣∣∣∣∣2

=1

N2

N−1∑n=0

N−1∑k1=0

Xk1 ej2πk1n

N

N−1∑k2=0

X∗k2

e−j2πk2n

N

98

Appendix B: Derivation of some SNR relationships for baseband OFDM

=1

N2

N−1∑k1=0

N−1∑k2=0

Xk1X∗k2

N−1∑n=0

e−j2π[k1−k2]n

N

=1N

N−1∑k1=0

N−1∑k2=0

Xk1X∗k2

δ[k1 − k2]

= 1 (B.3)

Therefore, the time-domain SNR is:

SNR =E |x[n]|2

E |v[n]|2=

1σ2

v

(B.4)

We also have the frequency-domain equivalent of (B.1):

Yk = Xk + Vk (B.5)

The noise power on the {Yk} (which is also equivalent to the noise spectral density, N0)is given by:

E |Vk|2 = E

∣∣∣∣∣ 1√N

N−1∑n=0

v[n] e−j2πkn

N

∣∣∣∣∣2

=1N

E

{N−1∑n1=0

N−1∑n2=0

v[n1]v∗[n2] ej2πk[n2−n1]

N

}

=1N

N−1∑n1=0

N−1∑n2=0

E {v[n1]v∗[n2]} ej2πk[n2−n1]

N

=σ2

v

N

N−1∑n1=0

N−1∑n2=0

δ[n1 − n2] ej2πk[n2−n1]

N

= σ2v (B.6)

Therefore, the sub-carrier symbol SNR is:

SNRsc =E |Xk|2

E |Vk|2=

1σ2

v

(B.7)

This demonstrates that for a pilotless, CP-less critically-sampled OFDM system, thetime-domain SNR is equal to the sub-carrier symbol SNR.

99

Appendix B: Derivation of some SNR relationships for baseband OFDM

We also have:

SNR =Signal powerNoise power

=

(Signal energy

Time

)Noise power

(B.8)

=

(NEsc

N

)σ2

v

=Esc

N0= log2(M)

Eb

N0(B.9)

where Esc is the energy per sub-carrier symbol, Eb is the energy per bit, and M is theconstellation size.

B.2 Inclusion of pilots

If we now convert some of the sub-carriers to pilots (i.e. using a comb pattern), there willbe no change in (B.3), (B.6) or (B.9), so the equality of time-domain and sub-carrierSNRs remains, and the relationship between SNR and Eb/N0 still holds. Therefore,inclusion of pilots does not alter the SNR.

B.3 Inclusion of CP

If we now add a CP of length L samples, the equality between the time-domain andsub-carrier SNRs remains the same, as none of {E |x[n]|2 ,E |v[n]|2 ,E |Xk|2 ,E |Vk|2} areaffected.

However, the time factor in (B.8) is now (N + L), which means that the relationshipbetween SNR and Eb/N0 is now:

SNR = log2(M)(

N

N + L

)Eb

N0(B.10)

100

Appendix C

Equipment used

MATLAB 7.0.1 (Student Edition) was run under Windows XP SP2, on a platform withan AMD Athlon64 3500+ processor and 2 GB of RAM.

Live performance testing and environment characterisation measurements were per-formed with the following equipment:

• M-Audio Audiophile 2496 soundcard

• Behringer MX 1604A mixer

• Shure Beta 57A microphone

• Sony CMT-CP11 stereo system and speakers

The Initial Report suggested that the system should be designed to work with standardconsumer-grade audio equipment, which the soundcard and microphone listed aboveclearly are not. This digression was for two reasons: firstly, this equipment was readilyavailable for use; secondly, higher-quality equipment gave better performance early onin system development, when verification of the algorithms was more important thanattempting operation with inferior equipment.

Figure C.1: Typical frequency response of Shure Beta 57A microphone.Image © 2003, Shure Inc.

101

Appendix D

Code listings

This appendix contains complete code listings for all modules that comprise the single-PC and two-PC modem. Other modules and test code can be found on the projectCD-ROM.

D.1 class DatagramSource

DatagramSource.m

function this = DatagramSource(filename)%DATAGRAMSOURCE DatagramSource object.% DATAGRAMSOURCE(FILENAME) creates a datagram source object from the% specified ASCII text (*.txt) or Windows bitmap (*.bmp) file specified% by FILENAME.% The DATAGRAMSOURCE object can then be read as a binary data source.

% Author: Oliver Charlesworth% Copyright (c) 2006, University of York

% Get type definitionsgetTypeDefs;

% Figure out what type of file this is[dummy1, dummy2, ext] = fileparts(filename);switch (ext)

case ’.bmp’% Read image and colour-map (palette)[img, map] = imread(filename);if (numel(map) > 0)

error(’Cannot send colour-mapped image!’);end

% Calculate dimensionswidth = size(img, 2);height = size(img, 1);

% Calculate buffer size requiredlenBuffer = numel(img) * 8;

% Set up header

102

Appendix D: Code listings

widthLo = mod(width, 256);widthHi = (width - widthLo) / 256;heightLo = mod(height, 256);heightHi = (height - heightLo) / 256;header = [ID_IMG; widthHi; widthLo; heightHi; heightLo; 0; 0];

data = reshape(double(img), [], 1);

case ’.txt’% Read filehFile = fopen(filename, ’r’);if (-1 == hFile)

error([’Error opening file "’ filename ’".’]);enddata = fread(hFile);fclose(hFile);

% Calculate buffer size requiredlenBuffer = length(data);

% Set up headerlenLo = mod(lenBuffer, 256);lenHi = (lenBuffer - lenLo) / 256;header = [ID_TXT; lenHi; lenLo; 0; 0; 0; 0];

otherwiseerror(’Unknown file type!!’);

end

% Turn into a class (using CircularBuffer as a base-class)this = class(struct, ’DatagramSource’, ...

CircularBuffer((lenBuffer + 14) * 8));

% Rate 1/2, constraint length 4 convolutional codertrellis = poly2trellis(4, [13, 15]);

% Write headerthis = write(this, ...

convenc(reshape(de2bi(header, 8)’, 1, []), trellis));

% Write datathis = write(this, ...

reshape(de2bi(data, 8)’, 1, []));

end

103


D.2 class DatagramHandler

DatagramHandler.m

function this = DatagramHandler(SETTINGS, source)%DATAGRAMHANDLER DatagramHandler object.% DATAGRAMHANDLER(SETTINGS, SOURCE) creates a datagram handler,% configured with the user-defined and derived parameters in the SETTINGS% structure, reading signal from the specified DataSource SOURCE.


this.SETTINGS = SETTINGS;this.source = source;

this.type = []; % Unknown type to start withthis.data = []; % Uninitialised datathis.specifics = struct; % Uninitialised data

% Convert to class objectthis = class(this, ’DatagramHandler’);

end

run.m

function this = run(this)%RUN Run DatagramHandler object.% this = RUN(this) runs the DatagramHandler object, which attempts to% collect enough binary data from its source to reconstruct the original% text or image.


% Get type definitionsgetTypeDefs;

% Obtain header[this.source, header] = read(this.source, 14 * 8);if (length(header) < (14 * 8))

error(’Could not read header data!’);return;

end

% Decode headertrellis = poly2trellis(4, [13, 15]);header = bi2de(reshape(vitdec(header, trellis, 5, ’trunc’, ’hard’), 8, [])’);

% Perform the correct initialisationswitch (header(1))

case ID_TXTthis.type = ’Text’;[this, len] = initText(this, header);

case ID_IMGthis.type = ’Image’;[this, len] = initImage(this, header);

104


otherwiseerror(’Unknown datagram type!!’);

end

% Set an empty data vector of the correct lengththis.data = zeros(1, len);

cRX = 0; % Bytes read so farbufBits = CircularBuffer(8); % Buffer for storing spare bits

% Obtain the rest of the datawhile (cRX < len)

% Read some more data[this.source, dataSource] = read(this.source, (len - cRX) * 8);if (0 == length(dataSource))

error(’Could not read enough data!’);return;

end

% Prepend existing bits[bufBits, bits] = read(bufBits);dataSource = [bits, dataSource];

% Find how many "spare" bits there arenSpare = mod(length(dataSource), 8);if (0 < nSpare)

bufBits = write(bufBits, dataSource((end - nSpare + 1):end));end

% Convert to bytesbytes = bi2de(reshape(dataSource(1:(end - nSpare)), 8, [])’)’;

% Store in data vectorthis.data(cRX + (1:length(bytes))) = bytes;cRX = cRX + length(bytes);

% Debug outputcomplete(this.SETTINGS.DEBUG, 100 * cRX / len);

endend

%-------------------------------------------------------------------------%function [this, len] = initText(this, header)

len = (header(2) * 256) + header(3);

log(this.SETTINGS.DEBUG, [’@DatagramHandler: Receiving text [’ ...num2str(len) ’ bytes]’]);

end

%-------------------------------------------------------------------------%function [this,len] = initImage(this, header)

this.specifics.width = (header(2) * 256) + header(3);this.specifics.height = (header(4) * 256) + header(5);len = (this.specifics.width * this.specifics.height * 3);

log(this.SETTINGS.DEBUG, ...[’@DatagramHandler: Receiving image [’ ...

105


num2str(this.specifics.width) ’,’ num2str(this.specifics.height) ’]’]);

end

subsref.m

function vals = subsref(this, S)%SUBSREF Overloaded method to handle subscripted references.% VALS = SUBSREF(this, S) allows access to:% obj.type% obj.data% If type == ’image’, then the following are also accessible:% obj.width% obj.height


% Action depends on data typeswitch (this.type)

case ’Text’switch (S(1).subs)

case ’type’vals = this.type;

case ’data’if (2 == length(S))

vals = char(this.data(mod(S(2).subs{1} - 1, ...length(this)) + 1, S(2).subs{2}));

elsevals = char(this.data);

endend

case ’Image’switch (S(1).subs)

case ’type’vals = this.type;

case ’width’vals = this.specifics.width;

case ’height’;vals = this.specifics.height;

case ’data’vals = uint8(reshape(this.data, this.specifics.height, ...

this.specifics.width, 3));end

endend

106


D.3 class Transmitter

Transmitter.m

function this = Transmitter(SETTINGS, source)%TRANSMITTER Transmitter object.% TRANSMITTER(SETTINGS, SOURCE) creates an OFDM Transmitter object,% configured with the user-defined and derived parameters in the SETTINGS% structure, taking data from the specified DataSource SOURCE.



% Create PilotGenerator objectthis.pg = PilotGenerator(this.SETTINGS);

% Calculate number of input bits per processing block, as product of:% * number of bits per sub-carrier symbol% * number of usable sub-carriers per processing block.this.nInputBitsPerProcBlock ...

= this.SETTINGS.K * length(find(this.pg.dataindices));

% Calculate number of output samples per processing block, as product% of:% * OFDM symbols per processing block% * Baseband samples per OFDM symbol% * Up-sampling factor.this.nOutputSamplesPerProcBlock ...

= length(this.pg) * SETTINGS.B * SETTINGS.AF.C;

% Create an output bufferthis.buffer = CircularBuffer(2 * this.nOutputSamplesPerProcBlock);

if (SETTINGS.ACQ.ACTIVE)this.state = ’Init’;

elsethis.state = ’Active’;

end

% Convert to class objectthis = class(this, ’Transmitter’, DataSource(1));

end

genRead.m

function [this, output] = genRead(this, len, shouldUpdate, shouldExtract)%GENREAD Generic read-related functionality for Transmitter.% [this, OUTPUT] = GENREAD(this, LEN, true, true) reads LEN entries from% the Transmitter output buffer. If data available is less than LEN,% then all data in buffer will be read.%% [this, OUTPUT] = GENREAD(this, LEN, false, true) reads LEN entries from% the Transmitter output buffer, but does not update the read pointer.% If data available is less than LEN, then all data in buffer will be

107


% read.%% [this, OUTPUT] = GENREAD(this, LEN, true, false) skips the read pointer% of the Transmitter output buffer ahead by LEN entries, or by all data% if less than LEN. OUTPUT contains the length of data skipped.%% If LEN == [] in any of the above cases, then all data in output buffer% is read/peeked/skipped.%% This function should normally be called by internal functions only.


if (isempty(len))% If no length argument supplied, attempt to read/skip/peek all% datalen = this.nOutputSamplesPerProcBlock;

else% Limit length argument to pilot pattern’s worth of datalen = min(this.nOutputSamplesPerProcBlock, len);

end

% Actions performed depend on current Transmitter state.switch (this.state)

case ’Init’% Initialisation, therefore we must create a SYNC preamble,% consisting of:% * SYNC1 symbol, with random data only on even sub-carriers.% * SYNC2 symbol, which is a block pilot symbol.

% Create empty baseband frequency-domain SYNC blockblock_bb = zeros(this.SETTINGS.N, 2);

%%%%%%%%%% SYNC1%%%%%%%%%

% Random datadata = randint(1, this.SETTINGS.N_tc * this.SETTINGS.K / 2);

% Multiply constellation radius by sqrt(2), because only half% the sub-carriers are being used, but we need constant energy.block_bb(2:2:end, 1) = sqrt(2) * bin2PSK(data, this.SETTINGS.M);

%%%%%%%%%% SYNC2%%%%%%%%%

% Create pilot symbol, using a temporary PilotGenerator,% initialised with a temporary SETTINGS structure.SETTINGS = this.SETTINGS;SETTINGS.PILOTS.PATTERN = ’Acquisition’;SETTINGS.PILOTS.N_b = this.SETTINGS.N_tc;pg = PilotGenerator(SETTINGS);block_bb(:, 2) = pg.values.’;

% Insert block into output bufferthis = insertBlock(this, block_bb);

108


this.state = ’Active’;

case ’Active’% Active mode; don’t currently do anything special here.

end

% Check output buffer for amount of data still to be read. If not% enough, create some more.if (available(this.buffer) < len)

% Process a pilot pattern’s worth of data, zero-padding if required[this.source, data] = read(this.source, this.nInputBitsPerProcBlock);if (length(data) > 0)

data = [data, ...randint(1, this.nInputBitsPerProcBlock - length(data))];

% Create baseband frequency-domain block, and insert pilotsblock_bb = this.pg.values.’;

% Insert data (after constellation mapping)block_bb(this.pg.dataindices’) = bin2PSK(data, this.SETTINGS.M);

% Insert block into output bufferthis = insertBlock(this, block_bb);

endend

% Read/peek/skip necessary data from output buffer[this.buffer, output] = genRead(this.buffer, len, ...

shouldUpdate, shouldExtract);end

%-------------------------------------------------------------------------%function this = insertBlock(this, block_bb)% this = INSERTBLOCK(this, BLOCK_BB) is a helper function that takes the% baseband frequency-domain block BLOCK_BB and performs the following% actions:% * Upsample and uponvert to passband% * Convert to time-domain% * Add CP% * Insert into output buffer.

% Create full-bandwidth blockblock = zeros(this.SETTINGS.AF.C * this.SETTINGS.N, size(block_bb, 2));

% Insert baseband block in the corresct placeiCentre = round(size(block, 1) ...

* (0.5 + this.SETTINGS.AF.F_c / this.SETTINGS.AF.F_s));block(iCentre ...

+ (((-0.5 * this.SETTINGS.N) + 1):(0.5 * this.SETTINGS.N)), :) ...= block_bb;

% Create time-domain blockblock_t = ifft(ifftshift(block, 1), [], 1);

% Prepend CPblock_t = [block_t((end - (this.SETTINGS.AF.C * this.SETTINGS.L) + 1):end, :); ...

block_t];

109


% Add to bufferif (this.SETTINGS.AF.ACTIVE)

this.buffer = write(this.buffer, real(reshape(block_t, 1, [])));else

this.buffer = write(this.buffer, reshape(block_t, 1, []));end

end

available.m

function len = available(this)%AVAILABLE Length of data available in Transmitter.% AVAILABLE(this) returns the length of data available for reading from% the Transmitter.


% Always return processing block length, unless we’ve exhausted sourceif ((available(this.buffer) > this.nOutputSamplesPerProcBlock) ...

|| (available(this.source) > 0))

len = this.nOutputSamplesPerProcBlock;else

len = 0;end

end

110


D.4 class Receiver

Receiver.m

function this = Receiver(SETTINGS, source)%RECEIVER Receiver object.% RECEIVER(SETTINGS, SOURCE) creates an OFDM Receiver object,% configured with the user-defined and derived parameters in the SETTINGS% structure, reading signal from the specified DataSource SOURCE.



this.isSynched = false;

% Create a channel estimatorthis.estimator = Estimator(SETTINGS);% Create a buffer for storing FFT resultsthis.bufferFFT ...

= CircularBuffer(getLatency(this.estimator), SETTINGS.N);% Create an output bufferthis.buffer = ...

CircularBuffer(2 * getLatency(this.estimator) ...

* SETTINGS.NUM_BITS_PER_BLOCK);

% Convert to class objectthis = class(this, ’Receiver’, DataSource(1));

end

genRead.m

function [this, output] = genRead(this, len, shouldUpdate, shouldExtract)%GENREAD Generic read-related functionality for Receiver.% [this, OUTPUT] = GENREAD(this, LEN, true, true) reads LEN entries from% the Receiver output buffer. If data available is less than LEN,% then all data in buffer will be read.%% [this, OUTPUT] = GENREAD(this, LEN, false, true) reads LEN entries from% the Receiver output buffer, but does not update the read pointer.% If data available is less than LEN, then all data in buffer will be% read.%% [this, OUTPUT] = GENREAD(this, LEN, true, false) skips the read pointer% of the Receiver output buffer ahead by LEN entries, or by all data% if less than LEN. OUTPUT contains the length of data skipped.%% If LEN == [] in any of the above cases, then all data in output buffer% is read/peeked/skipped.%% This function should normally be called by internal functions only.

% Author: Oliver Charlesworth

111


% Copyright (c) 2006, University of York

% On the first call, we need to perform synchronisationif (~this.isSynched)

if (this.SETTINGS.ACQ.ACTIVE)% Perform synchronisation stepsthis = doSYNC1(this);log(this.SETTINGS.DEBUG, ’@Receiver: Synched’);this = doSYNC2(this);log(this.SETTINGS.DEBUG, ’@Receiver: Pilot locked’);

else% No synchronisation required, so this must be a simulation. In% which case, just skip ahead to the bias point.[this.source, lenSkipped] = skip(this.source, ...

(this.SETTINGS.L - this.SETTINGS.RX.BIAS + 1) ...

* this.SETTINGS.AF.C);end

this.isSynched = true;end

% Check output buffer for data available, and get more if requiredwhile (available(this.buffer) ...

< (getLatency(this.estimator) * this.SETTINGS.NUM_BITS_PER_BLOCK))

% Obtain next time-domain block[this.source, block_t] ...

= read(this.source, this.SETTINGS.N * this.SETTINGS.AF.C);if (length(block_t) < (this.SETTINGS.N * this.SETTINGS.AF.C))

break;end% Convert to frequency-domainblock = fftshift(fft(block_t.’));

% Remove out-of-band componentsiCentre = round(size(block, 1) ...

* (0.5 + this.SETTINGS.AF.F_c / this.SETTINGS.AF.F_s));block = block(iCentre ...

+ (((-0.5 * this.SETTINGS.N) + 1):(0.5 * this.SETTINGS.N)));

% Store blockthis.bufferFFT = write(this.bufferFFT, block);

% Let the estimator work on this block.% The estimator may return a set of estimates, and also a peak% estimate.[this.estimator, estimates, nPeak] = process(this.estimator, block);

% Apply estimates.% For each estimate provided, pull a frequency-domain block from% the buffer, and correct it with the estimate.for est = estimates

[this.bufferFFT, block] = read(this.bufferFFT, 1);block = block.’;

% Correct for channel, demodulate, and append to output buffer.% NOTE: For PSK, we can multiply by conj(H_est), rather than% dividing by H_est.if (0 < length(est.H))

112


data = PSK2bin(block(est.iS) .* conj(est.H), this.SETTINGS.M);

this.buffer = write(this.buffer, data);end

end

% Increment buffer offset using peak informationif (-1 == nPeak)

% If nPeak == -1, it means no peak information was returned,% so we have to assume that it was perfectly synchronised.lenSkippedReq = this.SETTINGS.L * this.SETTINGS.AF.C;

else% Otherwise, skip by one block, and correct for% perceived error.lenSkippedReq = (this.SETTINGS.L ...

+ (round(nPeak * this.SETTINGS.N / this.SETTINGS.N_tc) ...- this.SETTINGS.RX.BIAS)) * this.SETTINGS.AF.C;

end[this.source, lenSkipped] = skip(this.source, lenSkippedReq);

end

% Read data from output bufferlenRead = min(available(this.buffer), len);[this.buffer, output] ...

= genRead(this.buffer, lenRead, shouldUpdate, shouldExtract);end

%-------------------------------------------------------------------------%function this = doSYNC1(this)% this = doSYNC1(this) is a helper function that attempts to locate the% SYNC1 symbol, and synchronise to it, using the Schmidl-Cox algorithm.

% Processing chunk lengthLEN_CHUNK = this.SETTINGS.N * this.SETTINGS.AF.C / 2;

% Pre-fill buffers with zerosbufCorr = zeros(1, LEN_CHUNK);bufMovSumCorr = zeros(1, LEN_CHUNK);bufMovSumEnergy = zeros(1, LEN_CHUNK);bufMovSumCorrFB = 0;bufMovSumEnergyFB = 0;

maxMetric = 0;iMax = 0;

% Initialise algorithm statestate = ’Search’;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Loop through received signal %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%while (true)

% Obtain a block.% We peek first, and skip later. This is so that we do not% lose the first symbol once the algorithm has synchronised.[this.source, data] = peek(this.source, LEN_CHUNK);

113


if (length(data) < LEN_CHUNK)% TODO: failure?break;

end

% Push through correlatordataCorr = data .* conj(bufCorr);bufCorr = data;

% Get energydataEnergy = abs(data).^2;

% Push into moving sumsdataMovSumCorr = dataCorr - bufMovSumCorr;bufMovSumCorr = dataCorr;[dataMovSumCorr, bufMovSumCorrFB] = filter(1, [1, -1], ...

dataMovSumCorr, bufMovSumCorrFB);

dataMovSumEnergy = dataEnergy - bufMovSumEnergy;bufMovSumEnergy = dataEnergy;[dataMovSumEnergy, bufMovSumEnergyFB] = filter(1, [1, -1], ...

dataMovSumEnergy, bufMovSumEnergyFB);

% Calculate metric functiondataMetric = abs(dataMovSumCorr ./ dataMovSumEnergy);

i = 1;

% If we are in ’Search’ mode:% * Look for the signal energy to rise above the threshold% parameter.% * Then look for the correlation metric to rise above the high% hystereis threshold parameter.% * Once this has occurred, we move to ’Track’ mode.if (strcmp(state, ’Search’))

% Test energy thresholdtmp = max(dataMovSumEnergy);disp([’Energy = ’ num2str(tmp)])

if (tmp > this.SETTINGS.ACQ.THRESHOLD_ENERGY)% Find index of first value that exceeds thresholdi = find(dataMetric > this.SETTINGS.ACQ.THRESHOLD_METRIC_HIGH, 1);disp([’Above energy threshold... Energy = ’ num2str(tmp) ...

’, Correlation = ’ num2str(max(dataMetric))])

if (~isempty(i))state = ’Track’;

elsethis.source = skip(this.source, LEN_CHUNK);

endelse

this.source = skip(this.source, LEN_CHUNK);end

end

% If we are in ’Track’ mode:% * Look for the correlation metric to fall below the low% hysteresis threshold parameter.% * Then search between the threshold-crossing indices, and look% for the maximum value of the correlation metric.

114


% * This is used as the synchronisation point, and the function% returns.if (strcmp(state, ’Track’))

% Find index of first value that falls below thresholdi = find(dataMetric(i:end) < this.SETTINGS.ACQ.THRESHOLD_METRIC_LOW, 1);if (~isempty(i))

% We’ve found resultsif ((1 + iMax + this.SETTINGS.L * this.SETTINGS.AF.C) < 0)

error(’Trying to skip backwards in sync algorithm!’)end

this.source = skip(this.source, ...iMax + ((this.SETTINGS.L + this.SETTINGS.RX.BIAS) ...

* this.SETTINGS.AF.C));return;

else% Update maximum metric value found[maxMetricLocal, iMaxLocal] = max(dataMetric);if (maxMetricLocal > maxMetric)

maxMetric = maxMetricLocal;iMax = iMaxLocal;

endiMax = iMax - LEN_CHUNK;

this.source = skip(this.source, LEN_CHUNK);end

endend

end

%-------------------------------------------------------------------------%function this = doSYNC2(this)% this = doSYNC2(this) is a helper function that improves synchronisation% using the SYNC2 symbol.

% Obtain frequency-domain block[this.source, block_t] = ...

read(this.source, this.SETTINGS.N * this.SETTINGS.AF.C);if (length(block_t) < (this.SETTINGS.N * this.SETTINGS.AF.C))

% TODO: failure?return;

endblock = fftshift(fft(block_t.’));

% Remove out-of-band componentsiCentre = round(size(block, 1) ...

* (0.5 + this.SETTINGS.AF.F_c / this.SETTINGS.AF.F_s));block = block(iCentre ...

+ (((-0.5 * this.SETTINGS.N) + 1):(0.5 * this.SETTINGS.N)));

% Create estimator for pilot symbol, using a temporary SETTINGS structureSETTINGS = this.SETTINGS;SETTINGS.PILOTS.PATTERN = ’Acquisition’;SETTINGS.PILOTS.N_b = this.SETTINGS.N_tc;estimator = Estimator(SETTINGS);

[estimator, estimates, nPeak] = process(estimator, block);log(this.SETTINGS.DEBUG, [’@Receiver: Sync peak index = ’ num2str(nPeak)]);

115


% Increment buffer offsetif (-1 == nPeak)

% If nPeak == -1, it means no peak information was returned,% so we have to assume that it was perfectly synchronised.lenSkippedReq = this.SETTINGS.L * this.SETTINGS.AF.C;

else% Otherwise, skip by one block, and correct for% perceived error.lenSkippedReq = (this.SETTINGS.L ...

+ (round(nPeak * this.SETTINGS.N / this.SETTINGS.N_tc) ...- this.SETTINGS.RX.BIAS)) * this.SETTINGS.AF.C;

end% lenSkippedReq = this.SETTINGS.L * this.SETTINGS.AF.C;

[this.source, lenSkipped] = skip(this.source, lenSkippedReq);

end

116


D.5 class LiveChannel

LiveChannel.m

function this = LiveChannel(SETTINGS, source)%LIVECHANNEL LiveChannel object.% LIVECHANNEL(SETTINGS, SOURCE) creates an LiveChannel object, capable of% simultaneous audio playback and capture. The object is configured with% the user-defined and derived parameters in the SETTINGS structure,% taking an audio signal from the specified DataSource SOURCE.


% Initialisation flagthis.isInit = false;

% Convert to class objectthis = class(this, ’LiveChannel’, ...

Mic(SETTINGS), Speaker(SETTINGS, source));end

genRead.m

function [this, output] = genRead(this, len, shouldUpdate, shouldExtract)%GENREAD Generic read-related functionality for LiveChannel.% [this, OUTPUT] = GENREAD(this, LEN, true, true) reads LEN entries from% the LiveChannel output buffer. If data available is less than LEN,% then all data in buffer will be read.%% [this, OUTPUT] = GENREAD(this, LEN, false, true) reads LEN entries from% the LiveChannel output buffer, but does not update the read pointer.% If data available is less than LEN, then all data in buffer will be% read.%% [this, OUTPUT] = GENREAD(this, LEN, true, false) skips the read pointer% of the LiveChannel output buffer ahead by LEN entries, or by all data% if less than LEN. OUTPUT contains the length of data skipped.%% If LEN == [] in any of the above cases, then all data in output buffer% is read/peeked/skipped.%% This function should normally be called by internal functions only.


% This section is only executed the first time.if (~this.isInit)

this.Speaker = run(this.Speaker);this.isInit = true;

end

% Use parent function[this.Mic, output] = genRead(this.Mic, len, shouldUpdate, shouldExtract);

end

117


D.6 class Speaker

Speaker.m

function this = Speaker(SETTINGS, source)%SPEAKER Speaker object.% SPEAKER(SETTINGS, SOURCE) creates a Speaker object, capable of audio% playback. The object is configured by the user-defined and derived% parameters in the SETTINGS structure.


% Set up analogoutput objectthis.ao = analogoutput(’winsound’);addchannel(this.ao, 1:2);this.ao.SampleRate = SETTINGS.AF.F_s;this.ao.TriggerType = ’Manual’;% Set up callbacksthis.ao.StopFcn = @stopTX;this.ao.SamplesOutputFcn = @loadTX;this.ao.SamplesOutputFcnCount = SETTINGS.CHANNEL.LEN_CHUNK;

% Store data inside analogoutput objects.SETTINGS = SETTINGS;s.source = source;this.ao.UserData = s;

% Queue first three playback blocksloadTX(this.ao);loadTX(this.ao);loadTX(this.ao);

% Convert to class objectthis = class(this, ’Speaker’);

end

%-------------------------------------------------------------------------%function loadTX(ao, event)% LOADTX(AO, EVENT) is a callback function used by the analogoutput% object, called every time a block of data has been played.%% More data is requested from the source, and queued for playback.

% Get structure stored in analogoutput objects = ao.UserData;

% Read more data from the source[s.source, data] = read(s.source, s.SETTINGS.CHANNEL.LEN_CHUNK);

% Queue data (to one channel only)if (strcmpi(s.SETTINGS.AF.CHANNEL, ’Left’))

putdata(ao, ...[data’ * s.SETTINGS.AF.GAIN, zeros(length(data), 1)]);

elseputdata(ao, ...

[zeros(length(data), 1), data’ * s.SETTINGS.AF.GAIN]);end

118


% Put structure back into analogoutput objectao.UserData = s;

% If no more data, we may kill the sourceif (0 == length(data))

kill(s.source);end

end

%-------------------------------------------------------------------------%function stopTX(ao, event)% STOPTX(AO, EVENT) is a callback function used by the analogoutput% object, called when data is exhausted.%% Object is automatically released.

% Get structure stored in analogoutput objects = ao.UserData;

delete(ao);disp(’ANALOGOUTPUT OBJECT HAS BEEN DELETED.’)

end

run.m

function this = run(this)%RUN Run Speaker object.% this = RUN(this) runs the Speaker object, commencing audio playback.% When playback has completed, resources are automatically released.


% Start analogoutput objectstart(this.ao);trigger(this.ao);

end

119


D.7 class Mic

Mic.m

function this = MIC(SETTINGS)%MIC Mic object.% MIC(SETTINGS) creates a Mic object, capable of audio capture. The% object is configured by the user-defined and derived parameters in the% SETTINGS structure.


this.SETTINGS = SETTINGS;

% Create an output bufferthis.buffer = CircularBuffer(2 * SETTINGS.CHANNEL.LEN_CHUNK);

% Initialisation flagthis.isInit = false;

% Set up analogue inputthis.ai = analoginput(’winsound’);addchannel(this.ai, 1);this.ai.SampleRate = SETTINGS.AF.F_s;this.ai.Timeout = 2 * SETTINGS.CHANNEL.LEN_CHUNK / SETTINGS.AF.F_s;this.ai.SamplesPerTrigger = Inf;this.ai.TriggerType = ’Manual’;this.ai.ManualTriggerHwOn = ’Trigger’;

% Convert to class objectthis = class(this, ’Mic’, DataSource(1));

end

genRead.m

function [this, output] = genRead(this, len, shouldUpdate, shouldExtract)%GENREAD Generic read-related functionality for Mic.% [this, OUTPUT] = GENREAD(this, LEN, true, true) reads LEN entries from% the Mic output buffer.% If data available is less than LEN, then all data in buffer will be% read.%% [this, OUTPUT] = GENREAD(this, LEN, false, true) reads LEN entries from% the Mic output buffer, but does not update the read pointer.% If data available is less than LEN, then all data in buffer will be% read.%% [this, OUTPUT] = GENREAD(this, LEN, true, false) skips the read pointer% of the Mic output buffer ahead by LEN entries, or by all data% if less than LEN. OUTPUT contains the length of data skipped.%% If LEN == [] in any of the above cases, then all data in output buffer% is read/peeked/skipped.%% This function should normally be called by internal functions only.

120



% This section is only executed the first time.if (~this.isInit)

% Start capturestart(this.ai);trigger(this.ai);

this.isInit = true;end

% If not enough available, pull more RX data from analogue inputif (available(this.buffer) < this.SETTINGS.CHANNEL.LEN_CHUNK)

data = getdata(this.ai, this.SETTINGS.CHANNEL.LEN_CHUNK)’;this.buffer = write(this.buffer, data);

end

% Read data from output bufferlenRead = min(available(this.buffer), len);[this.buffer, output] ...

= genRead(this.buffer, lenRead, shouldUpdate, shouldExtract);

end

available.m

function len = available(this)%AVAILABLE Length of data available in Mic output buffer.% AVAILABLE(this) returns the length of data available for reading from% the LiveChannel output buffer.


% Find out how much is available in the bufferlen = available(this.buffer);

end

121


D.8 class CircularBuffer

CircularBuffer.m

function this = CircularBuffer(len, width)%CIRCULARBUFFER CircularBuffer object.% CIRCULARBUFFER(LEN) creates a circular buffer of length LEN and% width 1.%% CIRCULARBUFFER(LEN, WIDTH) creates a circular buffer of length% LEN and width WIDTH.


switch (nargin)case 0

% If no arguments, set default length and widthlen = 256;width = 1;

case 1% If only length supplued, set default widthwidth = 1;

end

this.data = zeros(width, len); % Data bufferthis.len = len;this.iWrite = 0; % Next location to write tothis.iRead = 0; % Next location to read fromthis.isReadWrap = true; % Has read pointer wrapped round to write pointer?this.isWriteWrap = false; % Has write pointer wrapped round to read pointer?

% Convert to class objectthis = class(this, ’CircularBuffer’, DataSource(width), DataSink(width));

end

genRead.m

function [this, output] = genRead(this, len, shouldUpdate, shouldExtract)%GENREAD Generic read-related functionality for CircularBuffer.% [this, OUTPUT] = GENREAD(this, LEN, true, true) reads LEN entries from% the CircularBuffer, and updates the read pointer. If data available is% less than LEN, then all data will be read.%% [this, OUTPUT] = GENREAD(this, LEN, false, true) reads LEN entries from% the CircularBuffer, but does not update the read pointer. If data% available is less than LEN, then all data will be read.%% [this, OUTPUT] = GENREAD(this, LEN, true, false) skips the read pointer% ahead by LEN entries, or by all data if less than LEN. OUTPUT contains% the length of data skipped.%% If LEN == [] in any of the above cases, then all data is% read/peeked/skipped.%% This function should normally be called by internal functions only.

122



if (isempty(len))% If no length argument supplied, attempt to read/skip/peek all% datalen = this.len;

end

% Calculate how much data should be writtenlenRead = min(available(this), len);

if (shouldExtract)% Read data from bufferoutput = this.data(:, ...

mod(this.iRead + (1:lenRead) - 1, this.len) + 1);else

output = lenRead;end

if (shouldUpdate)% Update read pointerthis.iRead = mod(this.iRead + lenRead, this.len);

% Update wrap-around flagsif (lenRead > 0)

this.isWriteWrap = false;if (this.iWrite == this.iRead)

this.isReadWrap = true;end

endend

end

available.m

function len = available(this)%AVAILABLE Length of data available in CircularBuffer.% AVAILABLE(this) returns the length of data available for reading in a% CircularBuffer.


len = checkLength(this, ’read’);end

genWrite.m

function [this, lenWritten] = genWrite(this, data)%GENWRITE Generic write-related functionality for CircularBuffer.% [this, LENWRITTEN] = GENWRITE(this, DATA) writes DATA into the% CircularBuffer, and updates the write pointer. If space available is% less than the length of the input data, the data is truncated.% LENWRITTEN contains the number of entries written.

123


%% This function should normally be called by internal functions only.


% Calculate how much data should be writtenlenWritten = min(space(this), size(data, 2));

% Write new data into bufferthis.data(:, mod(this.iWrite + (1:lenWritten) - 1, this.len) + 1) ...

= data(:, (1:lenWritten));

% Update write pointerthis.iWrite = mod(this.iWrite + lenWritten, this.len);

% Update wrap-around flagsif (lenWritten > 0)

this.isReadWrap = false;if (this.iWrite == this.iRead)

this.isWriteWrap = true;end

endend

space.m

function len = space(this)%SPACE Length of space available in CircularBuffer.% SPACE(this) returns the length of space available for writing in a% CircularBuffer.


len = checkLength(this, ’write’);end

124


D.9 class DataSource

DataSource.m

function this = DataSource(width)%DATASOURCE DataSource object.% DATASOURCE(WIDTH) creates a DataSource object of width WIDTH.%% DataSource is an abstract base class, and as such should never be% instantiated explicitly.


this.width = width;

% Convert to class objectthis = class(this, ’DataSource’);

end

genRead.m

function [this, lenWritten] = genRead(this, len, shouldUpdate, shouldExtract)%GENREAD Abstract method, to be overriden by derived classes.% GENREAD acts an abstract method, and as such should never be called.% If it is called, an error is thrown.


error(’DataSink:AbstractCall’, ...[’Method "’ mfilename ’" should be overriden.’]);

end

available.m

function len = available(this)%AVAILABLE Abstract method, to be overriden by derived classes.% AVAILABLE acts an abstract method, and as such should never be called.% If it is called, an error is thrown.



end

read.m

function [this, data] = read(this, len)%READ Peek data available in DataSource derived object.% [this, DATA] = READ(this, LEN) reads LEN entries of data available in% the DataSource derived object, updating any internal pointers.

125


%% If LEN == [], then all data should be read.


if (nargin == 1)len = [];

end

% Use overriden method to get data and update state[this, data] = genRead(this, len, true, true);

end

peek.m

function [this, data] = peek(this, len)%PEEK Peek data available in DataSource derived object.% [this, DATA] = PEEK(this, LEN) peeks LEN entries of data available in% the DataSource derived object, without updating any internal pointers.%% If LEN == [], then all data should be peeked.



end

% Use overriden method to get data and update state[this, data] = genRead(this, len, false, true);

end

skip.m

function [this, lenSkipped] = skip(this, len)%READ Peek data available in DataSource derived object.% [this, LENSKIPPED] = SKIP(this, LEN) skips LEN entries of data in% the DataSource derived object, updating any internal pointers.%% If LEN == [], then all data should be skipped.



end

% Use overriden method to get data and update state[this, lenSkipped] = genRead(this, len, true, false);

end

126


D.10 class DataSink

DataSink.m

function this = DataSink(width)%DATASINK DataSink object.% DATASINK(WIDTH) creates a DataSink object of width WIDTH.%% DataSink is an abstract base class, and as such should never be% instantiated explicitly.


this.width = width;

% Convert to class objectthis = class(this, ’DataSink’);

end

genWrite.m

function [this, lenWritten] = genWrite(this, data)%GENWRITE Abstract method, to be overriden by derived classes.% GENWRITE acts an abstract method, and as such should never be called.% If it is called, an error is thrown.



end

space.m

function len = space(this)%SPACE Abstract method, to be overriden by derived classes.% SPACE acts an abstract method, and as such should never be called.% If it is called, an error is thrown.



end

write.m

function [this, lenWritten] = write(this, data)%WRITE Writes data into a DataSink derived object.% [this, LENWRITTEN] = WRITE(this, DATA) writes DATA into the% DataSink derived object. LENWRITTEN contains the number of entries

127


% written. The width of the data should match the width of the DataSink% object.


% Check width matchesif (size(data, 1) ~= this.width)

error(’DataSink:WidthMismatch’, ...’Supplied data does not match buffer width’);

end

% Call overriden method in derived class[this, lenWritten] = genWrite(this, data);

end

128


D.11 class Estimator

Estimator.m

function this = Estimator(SETTINGS)%ESTIMATOR Estimator object.% ESTIMATOR(SETTINGS) creates a channel estimator object, configured by% parameters in the SETTINGS structure.


this.SETTINGS = SETTINGS;this.cBlocks = 0; % Count of blocks processed so far

% Sort out pilot-related stuffthis.pg = PilotGenerator(SETTINGS);this.iC = [(1 + (SETTINGS.N_vc / 2)):(SETTINGS.N - (SETTINGS.N_vc / 2))];

% Calculate Phiswitch (SETTINGS.PILOTS.PATTERN)

case ’Comb’iP = getIndices(this.pg);% First pilot index (relative to used sub-carriers only)i1 = find(iP(this.iC), 1, ’first’) - 1;

case ’Block’i1 = 0;

case ’Acquisition’i1 = 0;

endthis.Phi = exp(j * 2 * pi * i1 * [0:(SETTINGS.PILOTS.N - 1)] / SETTINGS.N_tc);

% Create circular buffer to be used as a moving average FIFOthis.buffer = CircularBuffer(SETTINGS.RX.DEPTH, SETTINGS.PILOTS.N_b);this.buffer = write(this.buffer, zeros(SETTINGS.PILOTS.N_b, SETTINGS.RX.DEPTH));

% Convert to class objectthis = class(this, ’Estimator’);

end

getLatency.m

function latency = getLatency(this)%GETLATENCY Get processing latency of channel estimator.% GETLATENCY(this) returns the processing latency of the channel% estimator, measured in OFDM symbols.


latency = length(this.pg);end

129


process.m

function [this, estimates, nPeak] = process(this, block)%PROCESS Process channel estimation on new data block.% [this, ESTIMATES, NPEAK] = PROCESS(this, BLOCK) runs the channel% estimator algorithm on the incoming baseband frequency-domain block.% Any block estimates are returned in an array of structures in% ESTIMATES, otherwise ESTIMATES == [].% If peak estimation is performed, then this is returned in NPEAK.% Otherwise, NPEAK == -1.%% The structure of each member of ESTIMATES is:% H - vector of estimated channel in frequency-domain, for data% sub-carriers only.% iS - logical vector indicating data sub-carrier indices.


% Increment block counterthis.cBlocks = this.cBlocks + 1;

% Behaviour depends on the pilot patternswitch (this.SETTINGS.PILOTS.PATTERN)

case ’Comb’% For a comb pattern, every OFDM symbol contains pilots, so an% estimate can be formed every time.

[this, H_est, nPeak] = calcEstimate(this, block);

iS = this.pg.dataindices(1, :);

estimates.H = H_est(iS(this.iC)); % Channel estimateestimates.iS = iS; % Data sub-carrier indices

% Draw debug graphs if requiredif (shouldDrawGraphs(this.SETTINGS.DEBUG))

drawGraphs(this, H_est);end

case ’Block’% For a block pattern, pilot symbols appear periodically, so we% can only do processing when these symbols occur (hence the% need to keep track of the total number of blocks received).

% Check if this is a pilot symbolif (0 == mod(this.cBlocks, length(this.pg)))



% Form an array of estimates for all symbols between this% pilot symbol and the next.estimates(1:(length(this.pg) - 1)) = struct(’H’, H_est, ’iS’, iS);% Indicate last block as pilot block, i.e. do not processestimates(length(this.pg)) = struct(’H’, [], ’iS’, []);


drawGraphs(this, H_est);

130


end

else% Indicate no peak or estiamte information availablenPeak = -1;estimates = [];

end

case ’Acquisition’% An acquisition pattern is a special case; we may process% immediately, and return a single estimate.



estimates.H = H_est(iS(this.iC)); % Channel estimateestimates.iS = iS; % Data sub-carrier indices


drawGraphs(this, H_est);end

endend

%-------------------------------------------------------------------------%function [this, H_est, nPeak] = calcEstimate(this, block)% [this, H_EST, NPEAK] = CALCESTIMATE(this, BLOCK) is a helper function% which creates channel and peak estimates for any pilot pattern.

% Calculate estimated H for pilotsH_p_est = block.’ .* this.pg.values(this.cBlocks, :);

% Get time-domain estimateh_est = ifft(ifftshift(H_p_est(this.pg.indices(this.cBlocks, :))));

% Perform correctionif (strcmp(this.SETTINGS.PILOTS.PATTERN, ’Comb’))

h_est = h_est .* this.Phi;end

% Identify "peak" location[dummy, nPeak] = max(abs(h_est));

% Insert into circular buffer of estimatesthis.buffer = skip(this.buffer, 1);this.buffer = write(this.buffer, circshift(h_est, [0 (nPeak - 2)]).’);

% Calculate mean from circular buffer of estimates[this.buffer, h_est_raw] = peek(this.buffer);h_est = zeros(1, this.SETTINGS.N_tc);h_est(1:this.SETTINGS.PILOTS.N_b) ...

= circshift(mean(h_est_raw, 2).’, [0 (2 - nPeak)]);

% Convert back to frequency-domainH_est = fftshift(fft(h_est));

end

131


drawGraphs.m

function drawGraphs(this, H_est)%DRAWGRAPHS Draw graphs of estimated channel response.% DRAWGRAPHS(this, H_est) draws frequency-domain and time-domain graphs% of estimated channel response.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Frequency-domain estimate %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

axes(getAxes(this.SETTINGS.DEBUG, 1));clahold onplot(this.iC, abs(H_est), ’b.-’);xlim([1, this.SETTINGS.N])ylim(’auto’)set(gca, ’XGrid’, ’off’)set(gca, ’YGrid’, ’on’)

drawnow

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Time-domain estimate %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

h_est = ifft(ifftshift(H_est));

axes(getAxes(this.SETTINGS.DEBUG, 2));

clahold onxlim(’auto’)xlim([1, this.SETTINGS.PILOTS.N])plot(real(h_est), ’b.-’);plot(imag(h_est), ’r.-’);grid on

drawnowend

132


D.12 class PilotGenerator

PilotGenerator.m

function this = PilotGenerator(SETTINGS)%PILOTGENERATOR PilotGenerator object.% PILOTGENERATOR(SETTINGS) creates a pilot generator object, configured% by parameters in the SETTINGS structure.


this.SETTINGS = SETTINGS;

% Convert to class objectthis = class(this, ’PilotGenerator’);

end

length.m

function len = length(this)%LENGTH Overloaded method to find pilot pattern length.% LENGTH(this) returns the length of the pilot pattern.


switch (this.SETTINGS.PILOTS.PATTERN)case ’Comb’

len = 1;case ’Block’

len = this.SETTINGS.N_tc / this.SETTINGS.PILOTS.N;case ’Acquisition’

len = 1;end

end

subsref.m

function vals = subsref(this, S)%SUBSREF Overloaded method to handle subscripted references.% VALS = SUBSREF(this, S) allows access to:% obj.indices% obj.dataindices% obj.values


switch (S(1).subs)case ’indices’

iP = getIndices(this);

if (2 == length(S))vals = iP(mod(S(2).subs{1} - 1, length(this)) + 1, S(2).subs{2});

else

133


vals = iP;end

case ’dataindices’iP = getIndices(this, true);

if (2 == length(S))vals = iP(mod(S(2).subs{1} - 1, length(this)) + 1, S(2).subs{2});

elsevals = iP;

end

case ’values’iP = getIndices(this);

nP = length(find(iP));

s = rand(’state’);rand(’state’, 0);

block = zeros(size(iP));

block(iP) = randint(1, length(find(iP))) * 2 - 1;

rand(’state’, s);

if (2 == length(S))vals = block(mod(S(2).subs{1} - 1, length(this)) + 1, S(2).subs{2});

elsevals = block;

end

otherwiseerror(’PilotGenerator:UnknownMember’, ...

[’Unknown member "’ S(1).subs ’"’]);end

end

getIndices.m

function i = getIndices(this, forData)%GETINDICES Get pilot indices.% I = GETINDICES(this) returns the indices for pilot locations in the% time-frequency lattice as a logical matrix.%% I = GETINIDCES(this, true) returns the indices for data locations% instead.


% Default to pilot locationsif (1 == nargin)

forData = false;end

switch (this.SETTINGS.PILOTS.PATTERN)

134


case ’Comb’i = false(1, this.SETTINGS.N);% Calculate first pilot indexi1 = ceil((this.SETTINGS.N - (this.SETTINGS.PILOTS.N - 1) ...

* floor(this.SETTINGS.N_tc / this.SETTINGS.PILOTS.N)) / 2);

% Set evenly-spaced pilotsi(i1 + ([0:(this.SETTINGS.PILOTS.N - 1)] ...

* floor(this.SETTINGS.N_tc / this.SETTINGS.PILOTS.N))) ...= true;

case ’Block’% All non-VSCs are pilots in the pilot blocki = false((this.SETTINGS.N_tc / this.SETTINGS.PILOTS.N), this.SETTINGS.N);i(end, ((this.SETTINGS.N_vc / 2) + 1):(end - (this.SETTINGS.N_vc / 2))) ...

= true;

case ’Acquisition’% Same as blocki = false(1, this.SETTINGS.N);i(1, ((this.SETTINGS.N_vc / 2) + 1):(end - (this.SETTINGS.N_vc / 2))) ...

= true;end

if (forData)% Convert to data indicesi(:, (1 + this.SETTINGS.N_vc / 2):(end - this.SETTINGS.N_vc / 2)) ...

= ~i(:, (1 + this.SETTINGS.N_vc / 2):(end - this.SETTINGS.N_vc / 2));end

end

135


D.13 Helper functions

D.13.1 getParams.m

function SETTINGS = getParams%GETPARAMS Get user-defined OFDM modem parameters.% SETTINGS = GETPARAMS returns user-defined OFDM modem parameters in a% nested structure.%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Basic OFDM parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Total number of sub-carriers (including VCs and pilots)SETTINGS.N = 1024;% Number of VCsSETTINGS.N_vc = 0;% Cyclic prefix length (samples)SETTINGS.L = 128;% Number of constellation pointsSETTINGS.M = 4;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Pilot parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Average number of pilot sub-carriers per blockSETTINGS.PILOTS.N = 128;% Pilot patternSETTINGS.PILOTS.PATTERN = ’Block’;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Audio Frequency (AF) parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Should we use passband?SETTINGS.AF.ACTIVE = false;% System sampling frequency (Hz)SETTINGS.AF.F_s = 22050;% Centre frequency (Hz)SETTINGS.AF.F_c = 9500;% Approximate block period (s)SETTINGS.AF.T = 0.5;% Speaker channel to use (’Left’ or ’Right’)SETTINGS.AF.CHANNEL = ’Right’;% Transmitter gainSETTINGS.AF.GAIN = 20;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Receiver parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Averaging depth of RX channel estimatorSETTINGS.RX.DEPTH = 1;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Processing parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

136


% Length of processing chunks (in blocks)SETTINGS.PROC.BLOCKS_PER_CHUNK = 1;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Acquisition parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Should a sync symbol be usedSETTINGS.ACQ.ACTIVE = true;% Normalised energy thresholdSETTINGS.ACQ.THRESHOLD_ENERGY_NORM = 2e-7;% Low correlation thresholdSETTINGS.ACQ.THRESHOLD_METRIC_HIGH = 0.6;% High correlation thresholdSETTINGS.ACQ.THRESHOLD_METRIC_LOW = 0.55;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Simulation parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Handles to dummy graphsSETTINGS.DEBUG = DummyDebug(subplot(2, 1, 1), subplot(2, 1, 2));% Eb/No (dB)SETTINGS.SIM.EbNo = 100;% Channel impulse responeSETTINGS.SIM.h = [1 -0.4 0.2 0.3 0 0.2 -0.1];

end

D.13.2 setDerivedParams.m

function SETTINGS = setDerivedParams(SETTINGS)%SETDERIVEDPARAMS Set derived parameters from user-defined parameters.% SETTINGS = SETDERIVEDPARAMS(SETTINGS) configures OFDM modem parameters% derived from user-defined parameters in the SETTINGS structure, and% returns the updated structure.%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Basic OFDM parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Total OFDM symbol length (in samples)SETTINGS.B = SETTINGS.N + SETTINGS.L;% Number of non-VSC sub-carriersSETTINGS.N_tc = SETTINGS.N - SETTINGS.N_vc;% Number of bits per sub-carrier symbolSETTINGS.K = log2(SETTINGS.M);% Average number of bits per OFDM symbolSETTINGS.NUM_BITS_PER_BLOCK = ...

SETTINGS.K * (SETTINGS.N - SETTINGS.N_vc - SETTINGS.PILOTS.N);

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Pilot parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Number of pilots in pilot symbolsswitch (SETTINGS.PILOTS.PATTERN)

137


case ’Comb’SETTINGS.PILOTS.N_b = SETTINGS.PILOTS.N;

case ’Block’SETTINGS.PILOTS.N_b = SETTINGS.N_tc;

end

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Receiver parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Offset bias into CP for RX FFT block (samples)SETTINGS.RX.BIAS = SETTINGS.L / 2;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Audio Frequency (AF) parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Upsampling ratioif (SETTINGS.AF.ACTIVE)

SETTINGS.AF.C = ceil(SETTINGS.AF.F_s * SETTINGS.AF.T / SETTINGS.N);else

SETTINGS.AF.F_c = 0;SETTINGS.AF.C = 1;

end

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Acquisition parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Denormalised energy thresholdSETTINGS.ACQ.THRESHOLD_ENERGY = ...

SETTINGS.ACQ.THRESHOLD_ENERGY_NORM * SETTINGS.N^2;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Simulation parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

if (isfield(SETTINGS, ’SIM’))% SNR (dB)SETTINGS.SIM.SNR = SETTINGS.SIM.EbNo + 10*log10(SETTINGS.K);

% Zero-padded channel vectorsSETTINGS.SIM.h = ...

[SETTINGS.SIM.h zeros(1, (SETTINGS.PILOTS.N - length(SETTINGS.SIM.h)))];SETTINGS.SIM.H = ...

fft([SETTINGS.SIM.h zeros(1, SETTINGS.N - length(SETTINGS.SIM.h))]);end

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Channel parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Length of processing chunks (in samples)SETTINGS.CHANNEL.LEN_CHUNK = ...

SETTINGS.PROC.BLOCKS_PER_CHUNK * SETTINGS.B * SETTINGS.AF.C;

end

138


D.13.3 bin2PSK.m

function symbols = bin2PSK(data, M);%BIN2PSK Convert binary vector to PSK symbols.% SYMBOLS = BIN2PSK(DATA, M) converts binary vector DATA into PSK symbols% (constellation size M).


K = log2(M);

% Convert to symbol indicesinds = graycode(bi2de(reshape(data, K, []).’, ’left-msb’));

% Create complex constellation symbolssymbols = pskmod(inds, M);

end

D.13.4 PSK2bin.m

function data = PSK2bin(symbols, M);%PSK2BIN Convert PSK symbols into binary data.% DATA = PSK2BIN(SYMBOLS, M) converts noisy PSK symbols (constellation% size M) into binary data.


K = log2(M);

% Doing our own PSK demodulation, because it’s 3 times faster than% pskdemod() !!demod = mod(floor(0.5 + (M / (2*pi)) * angle(symbols)), M);

% Doing inline Gray decoding, because it’s much faster!decode = rem(cumsum(de2bi(demod, ’left-msb’), 2), 2);

% Reshape datadata = reshape(decode.’, 1, []);

end

D.13.5 MLS.m

function data = MLS(K, isBipolar)%MLS Create maximal-length sequence (MLS, or M-sequence).% X = MLS(K) creates a unipolar {0,1} MLS, using a shift-register of% length K, giving a sequence of length 2^K - 1.%% x = MLS(K, true) creates a bipolar {-1,+1} MLS.


if (1 == nargin)isBipolar = 0;

end

139


% Set feedback polynomial "taps"% Taken from Proakis, "Digital Communications," 3rd ed., p. 435switch (K)

case 2, taps = [ 1, 2 ];case 3, taps = [ 1, 3 ];case 4, taps = [ 1, 4 ];case 5, taps = [ 1, 4 ];case 6, taps = [ 1, 6 ];case 7, taps = [ 1, 7 ];case 8, taps = [ 1, 5, 6, 7 ];case 9, taps = [ 1, 6 ];case 10, taps = [ 1, 8 ];case 11, taps = [ 1, 10 ];case 12, taps = [ 1, 7, 9, 12 ];case 13, taps = [ 1, 10, 11, 13 ];case 14, taps = [ 1, 5, 9, 14 ];case 15, taps = [ 1, 15 ];case 16, taps = [ 1, 5, 14, 16 ];case 17, taps = [ 1, 15 ];case 18, taps = [ 1, 12 ];case 19, taps = [ 1, 15, 18, 19 ];case 20, taps = [ 1, 18 ];case 21, taps = [ 1, 20 ];case 22, taps = [ 1, 22 ];case 23, taps = [ 1, 19 ];case 24, taps = [ 1, 18, 23, 24 ];case 25, taps = [ 1, 23 ];case 26, taps = [ 1, 21, 25, 26 ];case 27, taps = [ 1, 23, 26, 27 ];case 28, taps = [ 1, 26 ];case 29, taps = [ 1, 28 ];case 30, taps = [ 1, 8, 29, 30 ];case 31, taps = [ 1, 29 ];case 32, taps = [ 1, 11, 31, 32 ];case 33, taps = [ 1, 21 ];case 34, taps = [ 1, 8, 33, 34 ];otherwise, error(’Maximum MLS length is 34.’);

end

seq = [zeros(1, K - 1) 1]; % Start with 000...0001data = zeros(1, (2^K - 1)); % Create empty output vector

% Rotate through structure (2^K - 1) timesfor k = 1:(2^K - 1)

data(k) = seq(1); % Obtain next outputfb = mod(sum(seq(taps)), 2); % Calculate feedback valueseq = [seq(2:K) fb]; % Shift!

end

% Convert to bipolar signalling if requiredif (isBipolar)

data = (data * 2) - 1;end

end

140

Summary of mathematicalnotation

Below is a summary of the mathematical notation used throughout this report.

Z set of integersZ+ set of positive integers

m scalar variableM matrix or vector variable

.T matrix or vector transpose.∗ complex conjugate for scalars; Hermitian transpose for matrices

or vectors

diag{M} column vector of diagonal entries of M

|M |2 MM∗ for a column vector, M∗M for a row vector

δ(t) Dirac delta functionδ[n] Kronecker delta function0 zero vector or matrixIn n× n identity matrix

E{x} expected value of x

Rxy E{xy∗}; covariance matrix of column vectors x and y

x ∗ y convolution of x and y

x~N y circular convolution of x and y, over a domain of length N

In general, three types of indexing are used, and are distinguished as follows:

x(t) value of continuous-time variable x at time t

x[n] value of discrete-time variable x at sample number n

xk k-th value of discrete (not time) variable x

141

Glossary of abbreviations

All abbreviations in this report are defined the first time they are used. For reference,all abbreviations are defined here as well.

ADSL Asymmetric digital subscriber lineAGC Automatic gain controlBER Bit error ratioCP Cyclic prefixDAB Digital Audio BroadcastingDVB Digital Video BroadcastingFDM Frequency division multiplexingFIFO First-in first-outGUI Graphical user interfaceICI Inter-carrier interferencei.i.d. Independent and identically distributedISI Inter-symbol interferenceLMMSE Linear minimum MSELO Local oscillatorLS Least squaresLTI Linear time-invariantMCM Multi-carrier modulationML Maximum likelihoodMLS Maximum-length sequenceMSE Mean square errorOFDM Orthogonal frequency-division multiplexingOFDMA Orthogonal frequency-division multiple accessPAPR Peak-to-average power ratioPHY Physical layerPSK Phase-shift keyingQAM Quadrature amplitude modulationSER Symbol error ratioSNR Signal-to-noise ratioVSC Virtual sub-carrier

142

References

[1] R. van Nee and R. Prasad, OFDM for wireless multimedia communications. ArtechHouse, 2000.

[2] H. Harada and R. Prasad, Simulation and software radio for mobile communica-tions. Artech House, 2002.

[3] S. Franz, M. Vajapeyam, and N. Shah, “Acoustic OFDM modem,” Project report,University of Southern California, Los Angeles, USA, 2005. [Online]. Available:http://www-scf.usc.edu/~sfranz/OFDMReport.pdf

[4] F. Bastidas, R. Kopikare, and G. Protat, “Wireless coherent OFDMmodem,” Project report, Cornell University, New York, USA, 2002. [On-line]. Available: http://people.ece.cornell.edu/scaglione/acousticmodem_files/acousticmodemreport2002.pdf

[5] H. Holma and A. Toskala, Eds., WCDMA for UMTS: Radio Access for Third Gen-eration Mobile Communications. Wiley, 2000.

[6] O. Charlesworth, “Software radio prototype: An acoustic communication systemusing OFDM signals,” MEng initial report, University of York, 2006.

[7] J. G. Proakis, Digital Communications, 4th ed. McGraw-Hill, 2000.

[8] T. Rappaport, Wireless Communications: Principles and Practice. Prentice Hall,2001.

[9] L. L. Scharf, Statistical Signal Processing: Detection, Estimation, and Time-SeriesAnalysis. Addison-Wesley, 1991.

[10] A. H. Sayed, Fundamentals of Adaptive Filtering. Wiley, 2003.

[11] I. A. Glover and P. M. Grant, Digital Communications, 2nd ed. Prentice Hall,2004.

[12] Air interface for fixed broadband wireless access systems, IEEE Std. 802.16, 2004.

143

http://www-scf.usc.edu/~sfranz/OFDMReport.pdf

http://people.ece.cornell.edu/scaglione/acousticmodem_files/acousticmodemreport2002.pdf

http://people.ece.cornell.edu/scaglione/acousticmodem_files/acousticmodemreport2002.pdf

References

[13] C. Cordeiro, K. Challapali, D. Birru, and S. Shankar, “IEEE 802.22: The firstworldwide wireless standard based on cognitive radios,” in Proc. IEEE Conf. DyS-PAN, Nov. 8–11, 2005, pp. 328–337.

[14] Asymmetrical Digital Subscriber Line (ADSL) transceivers, ITU Std. G.992.1, 1999.

[15] Digital Video Broadcasting (DVB); Framing structure, channel coding and modula-tion for digital terrestrial television, ETSI Std. EN 300 744, Rev. 1.5.1, 2004.

[16] Radio broadcasting systems; Digital Audio Broadcasting (DAB) to mobile, portableand fixed receivers, ETSI Std. EN 300 401, Rev. 1.3.3, 2001.

[17] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifi-cations, IEEE Std. 802.11, 1999.

[18] B. Le Floch, M. Alard, and C. Berrou, “Coded orthogonal frequency division mul-tiplex,” Proc. IEEE, vol. 83, pp. 982–996, June 1995.

[19] T. Pollett, M. van Bladel, and M. Moeneclaey, “BER sensitivity of OFDM systemsto carrier frequency offset and Wiener phase noise,” IEEE Trans. Commun., vol. 43,pp. 191–193, Feb./Mar./Apr. 1995.

[20] J. van de Beek, M. Sandell, and P. Börjesson, “ML estimation of time and frequencyoffset in OFDM systems,” IEEE Trans. Signal Processing, vol. 45, pp. 323–334, July1997.

[21] H. Bölcskei, “Blind estimation of symbol timing and carrier frequency offset inwireless OFDM systems,” IEEE Trans. Commun., vol. 49, pp. 988–999, June 2001.

[22] J. van de Beek, M. Sandell, M. Isaksson, and P. Börjesson, “Low-complex framesynchronization in OFDM systems,” in Proc. IEEE Conf. UPC, Nov. 6–10, 1995,pp. 982–986.

[23] R. Heath and G. Giannakis, “Exploiting input cyclostationarity for blind channelestimation in OFDM systems,” IEEE Trans. Signal Processing, vol. 47, pp. 848–856,Mar. 1999.

[24] O. Edfors, M. Sandell, J. van de Beek, S. Wilson, and P. Börjesson, “OFDM channelestimation by singular value decomposition,” IEEE Trans. Commun., vol. 46, pp.931–939, July 1998.

[25] M. Morelli and U. Mengali, “A comparison of pilot-aided channel estimation meth-ods for OFDM systems,” IEEE Trans. Signal Processing, vol. 49, pp. 3065–3073,Dec. 2001.

[26] R. Negi and J. Cioffi, “Pilot tone selection for channel estimation in a mobile OFDMsystem,” IEEE Trans. Consumer Electron., vol. 44, pp. 1122–1128, Aug. 1998.

144

References

[27] B. Yang, Z. Cao, and K. B. Letaief, “Analysis of low-complexity windowed DFT-based MMSE channel estimator for OFDM systems,” IEEE Trans. Commun.,vol. 49, pp. 1977–1987, Nov. 2001.

[28] T. Schmidl and D. Cox, “Robust frequency and timing synchronization for OFDM,”IEEE Trans. Commun., vol. 45, pp. 1613–1621, Dec. 1997.

[29] S. Lin and D. J. Costello, Error Control Coding, 2nd ed. Prentice Hall, 2004.

[30] T. Withers, “Software radio prototype: An acoustic communication system,” MEngthesis, University of York, 2004.

[31] E. Zehavi, “8-PSK trellis codes for a rayleigh channel,” IEEE Trans. Commun., pp.873–884, May 1992.

[32] G. Caire, G. Taricco, and E. Biglieri, “Bit-interleaved coded modulation,” IEEETrans. Inform. Theory, pp. 927–946, May 1998.

[33] V. Tarokh and H. Jafarkhani, “On the computation and reduction of the peak-to-average power ratio in multicarrier communications,” IEEE Trans. Commun.,vol. 48, pp. 37–44, Jan. 2000.

[34] J. van de Beek, O. Edfors, M. Sandell, and S. W. P. Börjesson, “On channel es-timation in OFDM systems,” in Proc. IEEE Conf. VTC, July 25–28, 1995, pp.815–819.

145

Software radio prototype: An acoustic...

Documents

Transcript of Software radio prototype: An acoustic...