i

Abstract

Digital Radio Mondiale (DRM) is a new digital radio standard designed to operate over the

frequencies currently occupied by AM, i.e. radio frequencies below 30 MHz. DRM offers improved

audio quality along side of transmission of multimedia data such as text and images.

The purpose of this project ‘DRM – Advanced Software Radio’ was to set up a DRM

reception/simulation facility using both hardware and DRM radio software and to use this facility to

evaluate the DRM system, test the comparative performance of two separate software packages and

to attempt to optimise the performance of one of the software packages by making modifications

directly to the source code.

A successful reception facility was realised using a R2-DRM multi channel receiver PCB in

conjunction with either the Official DRM receiver software or ‘Dream’, an open source receiver

package. DRM reception was found to be dependent on both the state of the ionosphere and the

format of the transmitted signal.

Modifications were made to the Dream software that implemented a frame estimation technique.

The results showed that the changes filled other wise silent periods and provided a slight

improvement to the overall performance when decoding a poor quality signal.

ii

Acknowledgements

I would like to thank Dr Graham Wade (supervisor: semester 1) who proposed this project and

offered valuable assistance in the area of channel modeling and Dream modifications. I would also

like to thank Dr Jamil Khan (supervisor: semester 2) who took over the academic supervision role

for this project after the departure of Dr Graham Wade.

List of Key contributions

• Research of the DRM system.

• Set up of a DRM reception facility capable of receiving an international DRM broadcast.

• Set up DRM simulation facility.

• Simulated and evaluated recorded Bonaire DRM signal and internet DRM test files.

• Developed and implemented HF channel models.

• Simulated and evaluated DRM wav files that were subjected to the channel models.

• Refined and tested interpolation modifications to the Dream software.

David Nelson

Jamil Khan (Supervisor)

iii

Table of Contents Chapter 1: Introduction 1.1 AM Broadcasting and DRM………………………………………………………………...1 1.2 DRM - Advanced Software Radio…………………………………………………………..3 Chapter 2: Technical Information/Literature Review 2.1 DRM Overview……………………………………………………………………………..4 2.2 DRM Technical Information………………………………………………………………..5 2.3 The HF Channel……………………………………………………………………………10 2.4 DRM Reception…………………………………………………………………………….13 2.5 Future…………………………………………………………………………………….…13

Chapter 3: Methodology and Results 3.1 Reception……………………………………………………………………………….…..14 3.11 Bonaire…………………………………………………………………………….14 3.12 Software……………………………………………………………………….…...15 3.13 Hardware…………………………………………………………………………..15 3.14 Reception Arrangement……………………………………………………………18 3.15 Results……………………………………………………………………………..19 3.2 Simulation………………………………………………………………………………….24 3.2.1 Simulation Arrangement..........................................................................................24 3.2.2 DRM Software Radio………………………………………………...……………25 3.2.2.1 Overview.....................................................................................................25 3.2.2.2 Results.........................................................................................................26 3.2.3 Dream……………………………………………………….……….……29 3.2.3.1 Overview……………………………………………………………….…29 3.2.3.2 Results…………………………………………………………………….30 3.2.4 Extended Simulation Loop………………………………………………….……..35 3.3 Channel Modeling.................................................................................................................37 3.4 Dream Modifications.............................................................................................................48 3.4.1 Overview…………………………………………………………………………..48 3.4.2 Implementation……………………………………….…………………….……..49 3.4.3 Results……………………………………………….…………………...……….54 Chapter 4: Conclusions 4.1 Conclusions………………………………………………………………………………...55 4.2 Extensions………………………………………………………………………………….56 References…………………………………………………………………………………..…..57 Appendices……………………………………………………………………………………...59

1

Chapter 1 – Introduction

1.1 AM Broadcasting and DRM

Conventional AM radio, as we have come to know it is a radio broadcasting technology that

although is extremely common is regarded as being inferior in terms of audio quality when

compared to modern day standards. AM broadcasting is an old technology, around 80 years in fact.

The AM frequencies are still universally used for the following reasons. Firstly there are literally

millions of AM receivers all over the world, ensuring listeners. Secondly, spectrum constraints

mean that if the AM frequencies were abandoned there would simply not be enough bandwidth to

accommodate the former AM users on the higher radio frequencies. Finally, AM frequencies have

particular signal propagation characteristics that appeal to broadcasters and listeners alike. These

propagation characteristics referred to result in broadcasts capable of large coverage areas and

relatively little impairment from environmental surroundings [1]. Refraction through the ionosphere

even allows internationally broadcasting, overcoming the curvature of the earth (figure 1).

Figure 1: International broadcasting [2]

2

Ideally a radio system that could boast audio quality comparable to FM and still use these

‘broadcast friendly’ frequencies would revitalise the AM bands. Designed to operate over the AM

frequencies, i.e. below 30MHz, Digital Radio Mondiale or DRM aims to do just that. As the name

suggests DRM is a digital scheme, developed by the DRM consortium, formed in 1998. The digital

format allows signal processing techniques to be employed that improve audio quality and

transmission reliability. DRM provides service and multimedia data streams together with the audio

and has been designed to fit the current AM spectral allocations.

3

1.2 DRM - Advanced Software Radio

The aim of this project was to set up a DRM reception/evaluation facility capable of receiving a live

broadcast from South America (Bonaire) and performing off line simulations using hardware and

two existing software radio packages. Using this facility analysis of DRM reception and important

system parameters was carried out, allowing the evaluation of the equipment/software and

ultimately the evaluation of DRM from a personal experience.

The software receivers can be run on any reasonably modern PC. A suitable front end was required

to receive and down convert the analogue RF signal to a frequency appropriate to drive the PC

sound card input. This can be done by modifying an existing short wave receiver or by using a

receiver/down converter designed for exactly this purpose.

The first software package used was the official DRM Software Radio. It is limited in analysis tools

however as the official software receiver for DRM, its performance was of interest and set a

suitable benchmark to compare other software.

The second software receiver used was an open source package (C++) called Dream. This package

was a focus point in the project. The Graphical User Interface (GUI) for this program allowed for a

much more detailed analysis of the received DRM signal. Options allowed for alterations of some

of the advanced receiver parameters, subsequently simulation results demonstrated the importance

and nature of these parameters.

Further exploration of the DRM system lead to some basic HFchannel modelling. In particular

channel models that would implement both delay spread and Doppler spread.

Using the open source code for the Dream package the software implementation of a DRM receiver

was studied. Modifications were made to the code with the aim of optimising the receiver. Modified

versions of the code were compiled, tested and compared to the default program. The DRM system

is quite complex and this is reflected in the code. As such even a minor modification to the receiver

operation was a significant undertaking.

4

Chapter 2 –Technical Information/Literature Review

2.1 DRM Overview

Digital Radio Mondiale is a coding and modulation scheme designed for digital transmission in the

broadcasting bands below 30MHz [1]. It was developed in 1998 by a consortium of the same name,

consisting of broadcasters, research organisations, manufactures and the like. It has since been

standardised by European Telecommunications Standard Institute (ETSI), which defines and

specifies the system. The DRM consortium maintains the official website containing all the latest

news and information concerning DRM.

Along with the broadcasting of audio information the system facilitates the transmission of channel

information, text data and even images. The prime advantage of the system though is improved

audio quality and reliability over the idyllic broadcasting bands below 30MHz. Implementation of

DRM is possible in conjunction with existing AM broadcasts as it has been designed as to not

disrupt current spectral allocations, thus making a gradual introduction of the technology possible.

A variety of source coding options are available, a Multi Level Coder (MLC) is used for channel

coding and transmission is based on Coded Orthogonal Frequency Division Multiplexing

(COFDM).

5

2.2 DRM Technical Information

The primary source for DRM technical specifications and operation is the ETSI standard: “Digital

Radio Mondiale (DRM); System specification”. Any specific technical information in this section

has originated or been summarised from this standard.

To overcome the disadvantages associated with analogue AM broadcasting and the HF channel,

DRM employs digital signal processing transmission and reception techniques. A simplified flow

diagram for the digital transmission of an audio signal is shown in figure 2:

Audio Tx RF Signal Signal

Figure 2: Digital transmission of an audio signal.

Explanation of figure 2: The first stage in the process is an analogue to digital conversion (A/D).

Source coding is applied to the data stream to compress the audio information, reducing the data

rate. Channel coding then has the effect of increasing the data rate. Channel coding is necessary to

strengthen the signal, reducing the probability of bit errors. The resulting data stream is modulated

onto an RF signal for transmission. This procedure is repeated in a reverse fashion at the receiver to

obtain the desired audio signal.

DRM transmission is more complicated than this of coarse, however the process outlined above is a

basic and generic overview of the transmission stages of the digital signal. To meet the

requirements of DRM this model is developed and begins to become a little more complicated. A

transmission block diagram for DRM is shown in figure 3 [1]. It can be seen that although it is more

complex, it encompasses all the basic elements of figure 2.

A/D Channel Coder

RF Modulator

Source Coder

6

Figure 3: DRM Transmission Block diagram [1]

There are three main channels that constitute a DRM signal. These channels are the Main Service

Channel (MSC), the Fast Access Channel (FAC) and the Service description channel (SDC). The

MSC carries the audio and data information, the FAC carries service selection information while

the SDC provides channel configuration information. The MSC channel is encoded separately from

the FAC and the SDC to provide extra robustness to the data contained within [3].

An option of three source coding modes with the addition of Spectral Band Replication (SBR) is

available to provide optimal audio quality at a given bit rate. The source coding techniques

employed are:

• Advanced Audio Coding (AAC)

• MPEG CELP coding

• MPEG HVXC coding

AAC is the generic audio coder used for DRM. The audio signal is sampled at either 12 KHz or 24

KHz to form 80 ms and 40 ms AAC frames respectively. The AAC frames are encompassed by an

audio super frame of constant length 400 ms, i.e. five 80 ms AAC frames (12 KHz) or ten 40 ms

AAC Frames (24 KHz).

7

CELP coding provides a coding scheme suitable for reasonable speech quality at low bit rates. The

advantage of this option is it provides for multiple speech applications over the one DRM channel

or extremely robust transmission of speech.

HVXC provide speech quality audio at extremely low bit rates. This option allows the addition of

features such as the addition of speech services beside audio services and Multi language

applications.

DRM channel coding uses a multilevel coding (MLC) scheme. This is where channel coding and

modulation are jointly optimised. The idea is that more error prone bit positions in the Quadrature

Amplitude Modulation (QAM) mapping are serviced with a higher level of protection from the

channel coding [4].

The mapping strategy used for the channels (MSC, SDC & FAC) is dependent on the robustness

mode being used. Data cells are 4-QAM, 16-QAM or 64-QAM (figure 4a-c). FAC always uses 4-

QAM mapping and is thus relatively robust and reliable.

Figure 4(a): 64-QAM SM [1]

64-QAM bit ordering: {i0 i1 i2 q0 q1 q2} = {y’0 y’1 y’2 y’3 y’4 y’5}

8

Figure 4(b): 16-QAM SM [1]

16-QAM bit ordering: {i0 i1 q0 q1} = {y’0 y’1 y’2 y’3}

Figure 4(c): 4-QAM SM [1]

4-QAM bit ordering: {i0 q0} = {y’0 y’1}

9

Although the information is coded in a digital format, digital signals are impractical to transmit

because they require an infinite bandwidth. The actual transmitted signal is analogue. DRM

transmission uses a form of Orthogonal Frequency Division Multiplexing (OFDM), a multiplexing

technique where the transmitted data is spread across a number of closely spaced carriers [5]. By

varying coding rates, QAM constellations and OFDM symbol parameters, various robustness

modes are available that provide a trade off between data rates and robustness against channe l

interference and distortions . There are four different OFDM robustness modes (A, B, C and D),

allowing quality of service to be maintained under different signal propagation conditions. Mode B

and D are of special interest in the context of this project, i.e. they are the appropriate modes to

provide the necessary protection over channels effected by significant Delay and Doppler spread

and are the modes used for the received Bonaire signals.

The transmitted DRM-OFDM signal is structured in to transmission super frames (1.2 sec) made up

of three transmission frames (Tf = 400ms) and a transmission frame in turn is made up of a number

of OFDM symbols, each symbol being made up of pilot, control and data cells spread across K

OFDM carriers. An OFDM cell is the sine wave portion of duration Ts of an OFDM carrier, where

Ts is the OFDM symbol period. Thus one OFDM symbol is made up of K cells, where K would be

the number of OFDM carriers.

10

2.3 The HF Channel

The HF band (3 MHz – 30 MHz) is useful for long distance communications with out the use of

repeater stations due to the ability of the band to utilise sky wave reflection off the ionosphere.

However it is often regarded as the most challenging radio propagation media [6]. Undesirable

effects resulting from this form of channel are delay spread (Tm) and Doppler spread (fd). These two

parameters are of interest when examining the quality of the DRM signal and receiver as the

Bonaire signal will be subjected to this type of HF channel.

The DRM signal received from Bonaire is transmitted as a sky wave that is refracted through the

ionosphere back towards earth giving the appearance of a reflection (figure 5). Using this sky wave

capability long distance international broadcasting is possible without the use of repeater stations.

The behaviour of the ionosphere is quite complex, but can be explained and thought of as consisting

of different layers [6]. Ionisation in these layers varies with the intensity of solar radiation. Greater

solar radiation increases the amount of ionisation in the ionosphere and generally results in

improved conditions for sky wave propagation [7]. The layers of interest for radio propagation are

the E and F layers, the E layer being the lower of the two. The F layer exists as a singular layer

during the night and splits to form two separate layers during the day. The higher the layer being

utilised for sky wave reflection the greater the skip distance that can be achieved. This is important

for long distance transmissions as the signal strength is reduced with each skip.

Figure 5: Ionosphere Refraction [6]

11

Adding to the fray is the D layer, which exists only of the daytime below the E layer. Absorption is

greatest at lower frequencies and when the ionisation is highest. The D layer absorbs almost all

signals below 4MHz [7]. This explains why distant AM broadcasts can be received of a night but

not during the day.

The usable frequencies for HF sky wave propagation vary with the condition of the ionosphere. The

range of usable frequencies is defined by the Lowest Usable Frequency (LUF) and the Maximum

Usable Frequency (MUF). Below the LUF the signal energy is absorbed and above the MUF

reflection will not occur. The idea is to use the highest possible frequency that will still reflect [7].

Bonaire broadcasts at 15.4 MHz fit into this fluctuating range for daytime transmission, excluding

extreme or on usual ionosphere conditions.

Doppler shift occurs due to rapid fluctuations within the ionosphere [8]. Values of Doppler shift

values can be as high as 5 Hz with typical values around 1 Hz [9].

Delay spread arises from the reception of a multi path signal. For our DRM channel the source of

this multi path comes from the reflection of the sky wave off the different layers within the

ionosphere and from the reception of multiple hop paths [10]. For long distance communications

generally only one hop is received [11]. This is an assumption I have made about the propagation

path of the Bonaire signal.

Figure 6: Multiple skips

12

The result of multi path can be more easily understood by looking at the impulse response of our

long distance HF channel. The dispersion of the impulse over time is due to the reception of the

multi path signal mentioned above. This dispersion is what is known as delay spread (Tm). For the

case shown in figure 7, Tm = 4.31 ms indicated graphically by the black dotted lines.

Intersymbol (ISI) begins to occur if the delay spread is greater than the OFDM guard interval, i.e.

Tm > Tg. Increasing the size of the OFDM guard interval is one safeguard to ensure Tm < Tg.

Increasing Tg comes with the cost of reducing the transmission rate of information bits.

For the DRM mode seen in figure 7 (mode B) the delay spread must be less then 5 1/3 ms in order

to avoid ISI. This is shown in the graphic by the red dotted lines, which correspond to the size of the

OFDM guard interval. In the case that multiple paths vary by a multiple of half the wavelength of

the signal the received signals can totally cancel each other out. Delay spread values can range up to

6 ms with typical values around 2 ms [9].

Figure 7: Impulse response of HF channel

13

2.4 DRM Reception

Currently the easiest way to receive a DRM signal is to use DRM radio software on a PC with a

sound card. The only other requirement is to have a front end capable of receiving the desired

station frequency and down converting the signal to an appropriate frequency and voltage level to

input to a sound card. This can be achieved by using a modified short wave receiver or a specialised

DRM receiver/down converter.

2.5 Future

The future of DRM is promising, DRM is a far superior technology compared to conventional AM,

however the change over is likely to be slow due to a number of reasons. A DRM signal can not be

received with a conventional AM radio. To receive DRM, a specialised DRM receiver is required.

This brings about an interesting problem. Commercial broadcast radio will be reluctant to convert to

DRM transmissions with few receivers owned by the public. On the other hand consumers will not

spend money on DRM receivers if there are no broadcasters, and so the circle continues.

There are currently around 60 DRM stations being broad cast world wide [12]. These broadcasts are

predominantly in Europe however most parts of the world are serviced with at least one station.

The first DRM hardware receivers have recently been developed, however until they are widely

available and a modest price, analogue AM will continue to dominate radio broadcasting below

30MHz. I believe that there will always be analogue AM due to the shear number of receivers

residing world wide, however it has been said that in a decade it will likely become the exception

rather than the rule [5].

14

Chapter 3 – Methodology & Results

3.1 Reception

3.1.1 Bonaire Currently the only DRM reception possibility in Australia comes from Bonaire, a radio station in

Antilles, South America that transmits a DRM broadcast to New Zealand and south-eastern

Australia for one hour twice a week. The current target area and broadcast schedule can be seen in

and figure 8 and table 1 respectively.

Bonaire: 12 06’ N Latitude, 68.19’ W Longitude.

Newcastle: 32 55’ S latitude, 151 46’ E Longitude.

Hence the approximate signal propagation distance is ˜ 15400 km. Transmission over this distance

without the use of repeater stations is typically only possible via sky wave transmission.

Figure 8: Bonaire DRM broadcast target [12]

Table 1: Bonaire Broadcast Schedule UTC Days KHz Beam Target Power Programme Language Site 0400-0500

Sat/Sun 15400 230 NZ + SE Australia

10 RNWB English Bonaire

15

At the commencement of the project Bonaire were broadcasting at 15.255 MHz but have since

changed to 15.4 MHz. These changes resulted in failed reception in initial trials due to the reception

facility being designed to receive the original frequency. As a result the receiver had to be adjusted

to adapt to the change (see Section 3.1.3).

3.1.2 Software

Readily available DRM software radio that runs from any relatively modern PC is used to decode

the DRM signal. Two different packages were used for this project, ‘DRM Software Radio’ which

is the official receiver software for DRM and ‘DReaM’. Both packages decode the DRM signal,

display the input spectrum and create a data log (see section 3.2.2), however Dream also includes

decoder settings and additional evaluation displays. The package was downloaded free in the form

of open source code (C++). So changes and modifications to suit the purpose of the project can be

made directly to the code. More detail on both packages is provided in the simulations section of

this report (section 3.2).

3.1.3 Hardware A DRM-R2 receiver (figure 9) is used to receive the desired broadcast frequency and convert it to a

frequency appropriate to feed a PC 16-bit sound card. The receiver is capable of receiving up to

four different channels within the bandwidth of its input filter (13.7MHz to 17.6MHz in the case of

the input band filter option ordered for this project). The RF signal frequency received is a function

of the frequency of the crystal oscillators. It is possible to connect a function generator to one of the

crystal sockets and thus receive any available broadcast within the bandwidth of the input filter.

However by using a crystal with this receiver the phase noise generated by a function generator or

by using a modified shortwave (SW) receiver is avoided. As Bonaire is the only broadcast of

interest for this project only one crystal was ordered, hence only one channel is obtainable

(Bonaire). To add up to four channels simply add more crystals.

16

The full specification can be found in the DRM-R2 Manual available through the Broadcast

Partners website (www.broadcastpartners.nl) or with the purchase of the product [13]. The

important specifications have been summarised below.

• DC Supply voltage = 15V - 25V

• Current consumption = 0 – 100 mA

• Receiving band input filter = 13.7 MHz - 17.6 MHz

• Output frequency = 12 KHz

• Sensitivity = 10uV

• Adjustable output level = 0 – 500mV

• Audio BW = 6 – 18 KHz

• Length = 148 mm

• Width = 100mm

Crystal Oscillators

Figure 9: R2-DRM Multi Channel Receiver [13]

17

The first down conversion from the station frequency is to 10.7 MHz. As a result the frequency of

the crystal needs to be 10.7 MHz higher than the station frequency of interest. Thus to receive the

Bonaire broadcast (15.4 MHz) the crystal used was 26.1 MHz. However, when the receiver was

first ordered Bonaire was broadcasting on 15.255 MHz, hence the crystal ordered was 25.955MHz.

It was not until a failed attempt to receive a signal from Bonaire that it was discovered that they had

changed their broadcast frequency. The solution was simple, the crystal needed to be changed.

Figures 10a-10b illustrates the concept behind the crystal frequency selection. The 15.4 MHz signal

frequency is mixed with 26.1 MHz using a balanced modulator and a 10.7 MHz band pass filter

only passes the modulated mirror signal.

15.4 MHz fig 10b 10.7 MHz

26.1 MHz (Crystal)

Figure 10a: First Down Conversion Stage

-15.4 10.7 15.4 26.1 41.1

Frequency (MHz)

Figure 10 b: Balanced Modulator Output

10.7 MHz Band pass

Filter

X Balanced

Modulator

18

3.1.4 Reception Arrangement The arrangement was set up as seen in figure 11 with the output of the R2 receiver connected to the

input of the PC soundcard with the receiver software input and output settings configured to that

same sound card.

RF signal IF Signal (12 KHz)

Figure 11: DRM reception arrangement An antenna is an integral part of any good receiver. Initially a wire antenna, approximately one to

two metres in length was trialled and reception was generally poor. A more precise quarter

wavelength long wire antenna was predominantly used and proved to be satisfactory to receive the

Bonaire broadcast. The long wire antenna was made to be 4.87 m in length, i.e. one quarter of the

signal wavelength (?).

Station frequency ( )f = 15.4 MHz

Signal velocity ( )v = 8103 × m.s-1

fv

=λ

48.19=λ m

∴ λ41

= 4.87m

Recordings of the live DRM signal were made using a sound recorder program included with a

SoundBlaster Live sound card. However any sound recorder program capable of recording to a wav

16-bit 48 kHz format would suffice. The 48 KHz sample rate is essential for the DRM software.

Rx/Down converter

Power Supply

19

3.1.5 Results

The Bonaire signal was successfully received on a number of occasions with reception ranging from

unavailable to good. Both software packages appeared to offer similar reception performance,

however it was noticed that when the received signal is extremely weak the Dream software is

capable of at least detecting the DRM signal when the official software cannot. A comparative

analysis of the software was carried out in simulation (Section 3.2). What was of interest with live

reception were the characteristics of the DRM signal and HF channel. When good reception or an

interesting signal was received the signal was recorded to a wav file for later simulation and further

investigation. The recoded signals are summarised in table 2 and the tabulated simulation results

can be viewed in the appendices.

The general trend of reception quality from my personal experience is as follows. On many

occasions reception was possible however the audio channel (MSC) was extremely poor. I believe

that this had as much to do with the transmitted DRM format as it did the propagation and reception

conditions. On rare occasions reception was not possible, the reasons for this can only be theorised

as no reception means no information or data.

The Bonaire signal is not always broadcast in the same mode or format. What is varied is the

transmission mode, degree of channel coding, audio sampling and bit rate, and consequently the

parameters associated with accommodating the type of audio service. I discovered that under the

varied conditions reception was mostly only available at the lower bit rates, i.e. the more robust

DRM signal. 64-QAM channels were almost always unavailable while 4-QAM and 16-QAM

signals were almost always available.

Table 2: Recorded Bonaire DRM signals File

Number File

Name Mode Audio type Bit rate

(kbps) Bandwidth file length

(min) Comments

1 June19-1 B AAC/12kHz 11.64 10 11.05 OK 2 June19-2 B AAC/12kHz 11.64 10 17.25 OK 3 July_11 B AAC/12kHz 14.56 10 10.3 Very poor 4 July_17 B AAC/12kHz 14.48 10 10.14 Very poor 5 August_8 D AAC/12kHz 14.5 10 15.1 Poor 6 Sept12-1 B AAC/24kHz 14.4 10 16.32 OK 7 Sept12-2 B AAC/24kHz 14.4 10 28.58 OK

20

The SDC/MSC mode used is related to the service and protection requirements. By examining the

constellation diagrams of received DRM signals (fig 12(a)-12(d)) the above reception observations

can be clearly explained. The SDC/MDC modes used by DRM are 4-QAM / 16-QAM for the lower

bit rates and 16-QAM / 64-QAM for the higher bit rates.

Figure 12(a): MSC 16-QAM Figure 12(b): SDC 4 -QAM

Figure 12(c): MSC 64-QAM Figure 12(d): SDC 16QAM

21

The dots on the diagram indicate the amplitude and phase of the received OFDM cells. Due to the

imperfect nature of the channel the amplitude and phase of a transmitted signal are distorted,

indicated by the spread of the blue dots. A perfect channel would show a clumping of dots in the

centre of each modulation state on the constellation diagrams. If a signal transmitted with a

particular amplitude and phase is distorted enough to fall into the region defined by another

modulation state, it will be decoded incorrectly therefore introduce bit errors into the receiver. This

is exactly the case when the MSC mode used by Bonaire is 64-QAM. More modulation states

reduce the tolerance for amplitude and phase distortions as the regions defined for a given state are

effectively smaller. This is the primary reason why during reception the SDC channel is often

received perfect while the MSC channel cannot be received at all.

Received signals from Bonaire were generally in transmitted in robustness mode B, however

occasionally in mode D. Some of the important parameters that define these modes have been

summarised below.

Mode B: Guard interval (5.33 ms), carrier spacing (46 7\8 Hz), Kmin= -44. Kmax=44. where

k∈[Kmin, Kmax], k=0 being the DC carrier [1].

Mode D: Has a larger guard interval (7.33 ms), carrier spacing (107 1\7 Hz), smaller Tu. Kmin= -44.

Kmax=44 [1].

The signal to noise ratio (SNR) was monitored over the length of the recorded wav file for all

recorded Bonaire signals, to find evidence of fading. Figure 13 shows the variation of SNR over

time for a signal received on the 19th June 2004. Note that the SNR was measured twice to confirm

results. This result was typical for most of the received signals thus only the one result was

included. The variations seen are most likely due to noise fluctuations and have little effect on

reception. There are no deep or long fades present that would be due to severe delay or Doppler

spread.

22

SNR

0

2

4

6

8

10

12

14

16

18

20

0 25 50 75 100

125

150

175

200

225

250

275 300

325

350

375

400

425

450

475

500

525

550

575

600

625

650

Time (s)

SN

R (

dB)

SNR1

SNR2

Figure 13: SNR: RNWB -19th June

Delay Spread (Tm) was generally around 2 – 4ms, however occasionally Tm exceeded the OFDM

guard interval (Tg). Multi path signals with considerable Tm can result in destructive signal

interference and ISI at the receiver. On the 12th September 2004 the received Bonaire DRM signal

exhibited such properties. Frequently through out the broadcast the signal would fade out and then

back in again. These fades occurred exactly when Tm exceeded Tg for the given mode (Mode B:

Tg=5.33). Figure 14a shows the variation of SNR over the length of the recorded signal. Figure 14b

is an enlarged portion of 14a to more clearly show the fades. The maximum Tm unfortunately could

not be recorded as the maximum value of Tm displayed by the Dream software is Tg.

23

SNR

0

5

10

15

20

25

time

SN

R (

dB

)

SNR

0

2

4

6

8

10

12

14

16

18

20

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 113 120 127 134 141 148 155 162 169 176

Time (sec)

SN

R (

dB)

Fig 14b

Figure14a: SNR: RNWB-12th Sept

Tm ˜ Tg Tm > Tg

Tm > Tg

Figure 14 b: SNR-12th Sept

The major factors contributing to good quality reception are antenna, antenna location, atmospheric

conditions and the degree of service and protection the DRM broadcast is providing. Reception was

average to poor if any of these conditions were unsatisfactory. It is important to remember however

that Bonaire is transmitting a complex signal at a relatively low power (10 kW) over an extremely

long distance. Thus it is unfair to make the assumption that the DRM signal is weak or reception is

generally difficult.

24

3.2 Simulation

3.2.1 Simulation Arrangement

A DRM input signal can be recorded straight into a wav file or DRM test files can be obtained from

the Dream website [14].The Internet test files were used along with the recorded Bonaire signals for

offline simulations. The first purpose of simulation was to further investigate the characteristics of

received DRM signals detailed and recorded in section 3.1. The second objective was to overview

and evaluate the official DRM software radio and the free open source package, ‘Dream’.

Simulation was achieved with the use of two 16-bit sound cards (figure 15), with soundcard 1

impersonating the DRM input signal. The output volume of soundcard 1 needs to be adjusted to an

appropriate level else the DRM input signal is too strong and will cause problems with reception.

Typically the volume needs to be set quite low. The PC and software settings are shown in table 3.

The arrangement was kept consistent for simulations for both software packages.

Figure 15: DRM simulation

Table 3: PC and Software Receiver Settings for Simulation DRM Software Receiver settings PC Settings

INPUT: SB-Live (Soundcard 2) OUTPUT: SB-Live (Soundcard 2)

PREFERED PLAYBACK DEVICE: SoundBlaster 16-bit (Soundcard 1)

DRM.wav file

Soundcard 1

DRM Software

Soundcard 2

25

3.2.2 DRM Software Radio

3.2.2.1 Overview DRM Software Radio is the official decoder software for DRM (figure 16). As such it was an

obvious choice to use it for this project. The software can be obtained at a cost from the DRM

receiver project website [15].

The Graphical User Interface (GUI) is limited in respect to evaluation tools but it does provide for

some statistical analysis in the form of a data log. The evaluation window displays the input

spectrum of the DRM signal and provides LED’s which indicate the audio, data and sync status. A

multimedia window is made available when receiving an appropriate multimedia service. The data

log however is the primary means of obtaining simulation results. Results set a suitable benchmark

to compare with the Dream package and modifications of Dream.

Figure 16: DRM Software Radio System Requirements

Operating system: Windows 98, 2000 and XP.

Processor: 500 MHz Pentium or equivalent.

RAM: 64 MB.

Sound card: 16-bit sound card (48 KHz sampling capability).

26

Data Log The data log is a text file generated by the software that records some reception statistics on a

minute-by-minute basis. A sample data log can be viewed in the appendicis. The contents of the

data log and its definitions are as follows [16]:

• MINUTE: Minute of recording for which the corresponding results were obtained.

• SNR: Average signal to noise ratio in the given minute.

• SYNC: Number of frames in the minute where the FAC and the CRC were ok.

• AUDIO: Number of error free frames for the minute/Number of audio frames per

transmission frame.

• TYPE: Audio coding type. Usually ‘0’ for this project. Corresponding to Advanced Audio

Coding (AAC).

One obvious problem with using the test files to create a data log is that the log generates its data on

a minute-by-minute basis and all but one of the files is under a minute in length. Therefore in all the

simulations run with the aim of obtaining a data log, the test files are run on a continuous loop for a

period of ten minutes.

3.2.2.2 Results

Internet Test Files The Details of the test files are summarised in table 3. Note that the length of the wav files is

relatively short, all less than one minute. This is because the recorded DRM signal needs to have

been sampled at 48 KHz, hence the sizes of the files are quite large. A one minute recording would

be approximately 6 MB in size.

Table 4: Internet Test Files

Test File Bouquet Flevo NL

Deutschland Radio DW ProjectQoSAM RTL

Voice of Russia

Robustness Mode

B A B C B B

Bit Rate (kbps)

14.48 23.62 20.8 N/A 17.38 17.38

Length of File (sec)

39 36 44 54 40 62

27

All six DRM files were tested under the same conditions and data logs were generated. The results

were tabulated (Appendix) and some further statistics were derived. Some of the more interesting

results are shown in figure 17a-17b.

Average SNR

19.7

31.9

1719

16.7

00

5

10

15

20

25

30

35

Test Files

SN

R (

dB

)

VoR

Deut

DW

Bouq

RTL

QoS

Figure 17a: Average SNR

Decoded Audio Frames (%)

88

53.4

81.87 82.0777.73

00

10

20

30

40

50

60

70

80

90

100

Test Files

Aud

io (

%)

VoR

Deut

DW

Bouq

RTL

QoS

Figure 17 b: Average decoded audio frames

28

What can be concluded from these results is that the Voice of Russia file is of the best quality with a

signal-to-noise ratio significantly better than the other files and a high percentage of decoded audio.

Although the file Deutschland Radio has a SNR similar to three of the other test files, considerably

less audio was decoded. The reason for this is that the file has a higher bit rate then any of the files

and the transmitted mode (Mode A) provides the lowest degree of protection. This file would

require a higher SNR to experience the same audio performance as the Mode B test files.

The ProjectQoSAM file (mode C) was unable to be decoded at all so no data log could be created.

The input spectrum for this file was appeared to be off centred. Further investigation with this

abnormality was carried out with the dream package (Section 3.2.3).

Only modest amounts of information can be derived from these results when viewed on their own,

as the results are influenced by the coding parameters, quality of the wave file and the performance

of the software. The extent of each factor on the result can not be clearly distinguished, however

these results will become more significant in drawing conclusions when evaluating the Dream

software.

29

3.2.3 Dream 3.2.3.1 Overview Dream is a free DRM software receiver package that was released as public domain open source

code (C++). This package is of particular interest for this project as it allows variations of some of

the receiver’s parameters, has numerous evaluation displays and is capable of creating a data log in

the same way as the official DRM software. Two version of the Dream software have been trialled,

the original version (figure 18a) and the latest updated version (figure 18b).

Figure 18a: Dream_1 – Evaluation Window Figure 18 b: Dream_1.0.6 – Evaluation window System Requirements: The same as the DRM Software Receiver (according to the Dream author).

In actual fact, I found that this was very much dependent on the receive r parameter settings.

Installation: To compile the downloaded source files requires Visual C++ 6.0 with Service pack 5

and Trolltech QT 2.x. Full installation instructions and support can be found on the Dream website

[14].

The latest release of Dream is very similar to it original in both look and operation. It has some

extra parameter settings and is more user friendly with the addition of the option to record the

decoded audio to a wav file. This is a useful addition as to do this before was awkward, requiring

the use of a second PC or soundcard. It also creates a long log to an excel file that generates signal

information such as SNR on a second by second basis.

30

3.2.3.2 Results Evaluation – System Parameters

As part of the evaluation process the advanced system parameters of the Dream package were

explored. This was achieved both subjectively and by taking a number of simulations with the same

wav file and comparing the data generated by the log. Table 5 shows the parameter settings for

each simulation. The average percentage of audio frames decoded will be used as the primary result

to make comparison as from a user’s point of view it is of course the most important.

Table 5:Dream_v1 simulation settings for test file: RNWB 19th june-1 Sim No# Iterations Time Interpolation FreqInterpolation Time Sync Tracking

1 (Default) 1 Wiener Wiener Guard Energy 2 0 Wiener Wiener Guard Energy 3 2 Wiener Wiener Guard Energy 4 3 Wiener Wiener Guard Energy 5 4 Wiener Wiener Guard Energy 6 1 Linear Wiener Guard Energy 7 1 Wiener Linear Guard Energy 8 1 Wiener DFT Zero Pad Guard Energy 9 1 Wiener Wiener First Peak 10 4 Linear Linear Guard Energy

The results can be viewed in table form in the appendices and are summarised below in figure 19a-

c. What can be concluded from the data logs is that ultimately variation of these parameters has a

negligible effect on decoding performance. What can be concluded from an observational point of

view is the effect the parameter variations have on the PC’s system resources. The simulations were

carried out on a PC that met the system requirements for the official DRM Software Radio and the

Dream package when run with the default settings. However it was discovered that under particular

settings that the PC processor was simply not fast enough. Increasing the number of iterations

performed by the Multi Level Coder (MLC) dramatically increases the load on the processor. Once

the processor starts operating at over 90% capacity an adverse effect on decoding occurs. The

results show the poor decoding performance when 3 and 4 iterations are used, this is entirely due to

the processor limitations. On the other hand utilising the linear interpolation settings apposed to the

wiener settings takes load off the processor and increases the speed of the software. Simulation 10

shows perfectly how the overall performance can be balanced out by using the linear methods if a

high number of iterations are being used. On a sufficiently fast PC increasing the number of

31

iterations improves the decoding performance with the most significant improvement comes with

the first iteration. Setting the software to one iteration is the recommended setting [17].

Average sync count (Dream_v1)

18.79

10.96

98.83 98.7597.92 98.13 98.17 97.71 97.92 97.88

0

10

20

30

40

50

60

70

80

90

100

Syn

c (%

)

Sim1

Sim2

Sim3

Sim4

Sim5

Sim6

Sim7

Sim8

Sim9

Sim10

Figure 19a: SYNC Count (%)

Average Decoded Audio (Dream_v1)

95.58 94.79 94.55

16.47

8.30

96.25 94.61 94.11 95.45

84.88

0

10

20

30

40

50

60

70

80

90

100

Au

dio

(%)

Sim1

Sim2

Sim3

Sim4

sim5

sim6

sim7

Sim8

Sim9

Sim10

Figure 19b: Audio Frames Decoded (%)

32

Audio Decoded

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Time intervals (minutes)

aud

io(%

)

0 iterations

1 iteration

2 iterations

3 iterations

4 iterations

Figure 19c: Audio Frames Dec oded (%)

Internet Test Files

Using the test files (table 4) the procedure carried out using the DRM Software Radio was repeated

using Dream_1 and Dream_1.0.6 and a similar set of results was recorded.

All the test files were simulated and the full results can be viewed in the appendices, however only

one set of results was retained for the report. The reason being is that the Dream seemingly

performed at least as well as the official software, but comparing the data logs shows that Dream

was significantly worse (table 6). This was unexpected and lead to the conclusion that the two

software packages record the data log differently. The official software only records to the data log

when the signal is being decoded and recording pauses if the signal drops out, while the Dream

records the data log regardless of whether a DRM signal is present or not. In the simulations the test

files, less than one minute in length were looped for a period of ten minutes. When the file loops

around there is a short drop out period from the time when the file finishes playing until the

software locks onto the signal again. Under these circumstances the data log created by Dream is a

misrepresentation of the actual performance of the Dream software. To get a true indication, a long

test file would be required or simply a live transmission where there are no signal dropouts. This

problem meant that a comparative analysis of the software using these test files can only be done

subjectively.

33

The performance of Dream from an observational point of view was at least as good the official

software. In the case of the ProjectQoSAM file it was much better, playing the file with reasonable

quality while the official DRM Software Radio software could not decode the signal at all (figure

20a-20b).

Table 6: Simulation Results for Test File-DW Software SNR Sync Sync (%) Audio Audio (%) Dream_1 15.08 42.43 28.29 391.57 26.10

DRM Software Radio 19 141.7 94.47 1228 81.87

Table 7: ProjectQoSAM Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 28 18.67 115 15.33 0 1 16 39 26.00 171 22.80 0 2 14 148 98.67 713 95.07 0 3 16 67 44.67 310 41.33 0 4 16 84 56.00 397 52.93 0 5 16 95 63.33 452 60.27 0 6 14 147 98.00 702 93.60 0 7 14 44 29.33 185 24.67 0 8 16 37 24.67 167 22.27 0 9 14 149 99.33 711 94.80 0

Averages 15.30 83.80 55.87 392.30 52.31

Figure 20a: ProjectQoSAM Input spectrum Figure 20b: ProjectQoSAM Input spectrum DRM Software Radio Dream

34

To derive a reliable Dream data log that would allow for a direct comparison between the two

software packages, the file ‘RNWB_June19th-1.wav’ (table 2) was used. This file is 11.05 minutes

in length, experiences average audio quality and has no signal drop outs. Therefore the data log

problem previously outlined is not encountered.

Comparative simulations were carried out a number of times and what was discovered was in terms

of decoding performances the differences were negligible, with no one package consistently out

performing the other. Figure 21 shows the results of such simulations. The full results can be

viewed in table form in the appendices.

Decoded Audio (%)

67.76 68.97 67.25

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Au

dio

(%)

DRM Software Radio Dream_1 Dream_1.0.6

Figure 21: Audio Frames Decoded (%)

35

3.2.4 Extended simulation loop The simulation set up described only relies on the DRM software, thus an attempt was made to set

up a simulation that includes hardware (figure 23). To achieve this some adaptations needed to be

made to the existing set up and the addition of a mixer (up converter) is required (figure 22).

The primary problem involved in connecting the mixer to the R2 receiver for simulation is the input

band pass filter is 13.7MHz to 17.6 MHz. The 12 kHz soundcard output of a wav is up converted to

an RF frequency, the problem is that the up converter obtained for the project outputs 10.7MHz.

Therefore the output of the mixer had to be connected to the R2 receiver at a point after the first

down conversion stage but before the 10.7 MHz band pass filter (figure 24).

The mixer is essentially a balanced modulator, i.e. the carrier signal is suppressed. It is important

that the connection is made before the 10.7 MHz band pass filter as the Upper Side Band (USB) is

not suppressed (figure 25). There is a 10.7 MHz test pin on the receiver that might suffice for the

connection. Another possibility considered was to replace the crystal with a new crystal with a

frequency that would provide an output with in the range of the input band pass filter of the R2

receiver, allowing connection directly to the input. The PC and software setting remain the same

except that the software must be set to flip the input spectrum as the 10.7 MHz output of the up

converter is inverted.

Figure 22: Transmitter Mixer

12 KHz Figure: 23 Audio

Figure 23: Expanded DRM Simulation

R2 Receiver

Up converter

36

Figure 25

Figure 24: R2 receiver schematic [13]

fc

fm

12 KHz 10.7 MHz 10.724 MHz

10 .712 MHz (Crysta l Oscillator)

Figure 25: Balanced modulator output

37

3.3 Channel Modelling

Limited DRM live transmissions have increased the importance of simulations and variations in

simulations. For this reason an attempt to model the channel for a DRM transmission was made. As

such a DRM signal could be tested under specified channel conditions.

A simplistic approach was taken, as developing a perfect channel model was not in the scope of this

project. The idea was to create a basic channel model with some controllable parameters that can be

applied to a recorded wav file as to gain an insight into the effects on DRM reception resulting from

variations in the channel parameters. The models were implemented using Matlab.

The starting point for modelling the DRM channel can be view in equation (1) and is based on the

Watterson channel model [18]. This model sums N different paths with the range of jτ = Tm.

)()(1

0j

N

jj tsctr τ−⋅= ∑

−

= (1)

Using (1) as a basis the most simplistic way to implement this idea into software was to ignore the

effect of multi path and simply apply (2), where ks is the kth sample of the recorded wav file and

[ ]1,0∈kc , thus inducing simple fading or attenuation that might be due to adverse channel

conditions.

kkk scr ⋅= (2) Equation (2) was implemented and tested with variations of kc and for varying amounts of time and

tested. The Matlab code can be viewed in the appendices.

What was discovered was exactly as anticipated. Low levels of attenuation over a short period of

time had a negligible effect on reception while total signal attenuation caused short drop outs, the

longer the attenuation period the more damaging to signal reception. The problem with this model is

that there is really no way to relate the receiver decoding performance to any measurable channel

parameter. Equation 2 however was useful tool for corrupting DRM signal recordings, producing

38

short audio dropouts in order to evoke interpolation of bad frames for the testing of Dream

modifications (Section 3.4).

A better model in which the Doppler spread is directly represented is as follows:

Assuming that a DRM signal is represented by (3) and has a complex envelope (4), the received

DRM signal can be expressed as (5), consisting of N received paths and jc is the random

attenuation of the jth path. The delay is represented as a phase shift jφ and jf if the Doppler shift,

which is defined in (6) where jα is a random phase. Equation (7) is simply the discrete time

version of (5) and rearranges to (8). Assuming that the recorded wave file has no multi path or

Doppler shift the kth sample of the wave file can be represented by (9). Given this (8) can be

written as (10)

[ ])(cos)()( tttmts R θ+ω⋅= (3)

∑−

=

π⋅=1

0

/2)(M

i

uTtiji eatm (4)

( ) ( )∑−

=π+φ+θ+ω⋅⋅=

1

02)(cos)(

N

jjjRj tftttmctr (5)

)cos( jDj ff α⋅= (6)

( )kTfkTkTkTmcr jjRjk π+φ+θ+ω⋅⋅= 2)(cos)( (7)

( ) ( ) ( ) ( )[ ]kTfkTkTfkTmc jjkRjjkRkj π⋅φ+θ+ω+π⋅φ+θ+ω⋅= 2sinsin2coscos (8)

( )jkRkjk kTmcwav φ+θ+ω⋅= cos,0 (9)

( ) ( ) ( )kTfwavkTfwavr jkjkk π⋅−+π⋅= 2sin12cos2/1

,02

,0 (10)

39

Equation (10) gives an improved channel model that directly represents Doppler shift. Theoretically

this model should allow fading to be induced into a recorded DRM file. The proof for equation was

summarised from a paper written by Dr Graham Wade [10].

The fading model (10) was implemented using Matlab (see Appendices for code) and evaluated by

looking at the time response to a unit step input. A strict implementation of (10) yields a response

that oscillates between 1 and –1 (figure 26a). This is due to the fact that the mathematical model

neglects to consider the time period for the fade, i.e. the time that the wav file should be subjected

to the mathematical model. The negative values are also a problem, as instead of attenuating the

signal giving the effect of fading they will flip the polarity of the wav samples and cause significant

errors. There are a number of options to solve this problem, all of which were considered and

attempted. The first solution was to limit the active period of the channel mode l to T/4, thus

eliminating the negative (figure 26c). The second was to set the active period to the value of T/2

and set negative values, to zero (figure 26d). The final solution was to use a period of T and to set

the negative values to zero (figures 26e-f).

Note with figures 26b-f that the channel model is not applied at time equals zero. This is not just for

clarity of the output in the figures. The fade is not applied for at least ten seconds into the file

because the receiver needs time to lock onto the signal and commence decoding. A premature fade

should be avoided for this reason.

After applying the channel model to a wav file which is represented by sample values in the range

between 1 and -1, it was discovered that there was a major problem with the model. Figure 27

certainly does not show a fading effect.

T/2

Figure 26a: Unit step response Figure 26 b

40

T/4 T/2 Figure 26c Figure 26d

T T Figure 26e Figure 26f

Figure 27: DRM wav file response to channel model

41

The figures shown in figures 26a-f are the channel responses to a unit step input of magnitude 1. It

was discovered after further investigation that the shape of the response varies (time shifts) with

different input magnitudes. The output actually amplifies from the input value (which in the case of

a wav file is always less then one) to 1 before it then fades, hence why the wav file showed a gain

effect and not a fading effect. This can be observed by looking at the channel response to a unit step

input of magnitude 0.5 (figure 28).

Figure 28

The problem seems to exist in the second term of the equation. If this is dropped so I now have

equation 11, the basic shape of the desired fade is mainta ined for all input magnitudes (Figure 29a -

b). The period of the fade cycle is also retained.

Although equation (11) was largely formulated through trial and error, it will at least simulate a

controllable fade in a wav file (figure 30).

( )kTfwavr jkk π2cos,0 ⋅= (11)

42

Figure 29a: equation 10 (red), equation 11 (blue)

Figure 29b: equation 10 (red dashed), equation 11 (blue)

T/4

Figure 30: Fade d DRM wav file

43

After further reading and a suggestion from Dr Graham Wade it was decided that a more accurate

fade using equation (2) would be achieved if the model allowed a full fade out and fade in. The

dashed line in figure 31 shows the unbounded time response of equation (11). By utilising the

encircled section of the response (green line) and shifting it in the positive direction to obtain the

response show by the blue line, a complete fade out and fade in with a period that relates to the

Doppler shift can be modelled (figure 32).

Figure 31

T/2

Figure 32: Faded DRM wav file

44

The results obtained are summarised in table 8 and figure 33. What they show is that reception was

not greatly effected by the fade, i.e. the results for a fast fade are similar to that of a long fade. The

explanation for this should probably have been anticipated. The deterioration of reception only

happens for the small amount of time when the signal value is close to zero. This is a result of the

simulation conditions and assumptions made about the nature of the original DRM recording. The

DRM test files are the recordings of the received signal and hence include added noise. When the

test file is faded the noise on the signal is faded as well, thus during a simulated fade the SNR is

largely unchanged. In reality Doppler fading occurs due to fluctuations in the ionosphere and acts

on the transmitted signal, the additional external noise picked up by the receiver is unaffected by

these changes in the ionosphere, hence the resulting SNR changes throughout the fade. Looking at

figure 33 it would be expected that there would be a trend in the direction of the arrows. However

the recorded SNR do not follow this trend and it seems that there is little correlation between the

fading and the SNR. The trends for the sync count and decoded audio show similar results. The

statistics of any one simulation can vary and differences in the results would be mostly due to these

variations.

Table 8: Fading Channel Results

File (Fade Period) Minute SNR Sync Sync (%) Audio Audio (%) Type

max SNR

VoR VoR (40) 0 18 94 62.67 650 43.33 0 25.3 VoR (20) 0 18 135 90.00 1110 74.00 0 22.1 VoR (10) 0 18 139 92.67 1160 77.33 0 20.9 VoR (5) 0 20 137 91.33 1020 68.00 0 24.2 VoR (1) 0 16 140 93.33 1100 73.33 0 19.6

RNWB (40) 0 13 128 85.33 540 72.00 0 14.7 RNWB (20) 0 10 137 91.33 485 64.67 0 12.3 RNWB (10) 0 10 133 88.67 465 62.00 0 12.9 RNWB (5) 0 11 140 93.33 455 60.67 0 12.2 RNWB (1) 0 12 130 86.67 550 73.33 0 13.6

RNWB 0 12 140 93.33 530 70.67 0 15.3

45

0

5

10

15

20

25

VoR

VoR(4

0)

VoR(2

0)

VoR(10

)Vo

R(5)

VoR(1

)

RNWB(4

0)

RNWB(2

0)

RNWB(1

0)

RNWB(5

)

RNWB(1

)RN

WB

Figure 33: Audio frames decoded (% )

Considering external noise would improve on the fading model, however the objective of our model

was simplicity and to provide a method to test the fading aspects of DRM reception in the absence

of sufficient test files. Artificial fades may be introduced in the described way, however due to the

deficiencies described and the assumptions made on the nature of the input file I believe that only

authentic Doppler fading obtained with an actual received DRM transmission should be considered

when evaluating DRM’s robustness against Doppler spread.

The channel modelling described in equations 10 & 11 designed to introduce fading resulting from

Doppler shift and was not entirely successful. From the first stage of its development the model

completely neglected the effect of delay spread and noise.

Delay spread is an important parameter that greatly affects the performance of the receiver. A

separate channel model that only induces delay spread into a recorded DRM wave file would allow

simulations that test the DRM signal and receiver performance as the delay spread approaches and

exceeds its maximum limits.

To implement the delay spread I went back to equation (1). This model sums N different paths with

the range of jτ = Tm. The idea was to consider the recorded wave file as the most direct signal and

apply no further signal attenuation. The degree of attenuation on the subsequent paths is

proportional to jτ , i.e. the larger the signals delay the longer the path and therefore one would

46

assume the greater the attenuation on the signal. The model was implemented using Matlab and the

associated code can be viewed in appendix.

Figures 34a-b shows the impulse response of the channel model when five multi paths are

considered (N=5). Appling the same model to a DRM test file yields figure 35.

Figure 34a: Input Impulse Figure 34 b: Impulse response (5 paths)

Figure 35: DRM wav recordings

47

Audio (%)

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

VoR(Original)

VoR (2ms) VoR (3ms) VoR (4ms) VoR (5ms) VoR (7ms) VoR (10ms) VoR (20ms) VoR (5ms50-paths)

From the inspection of figure 35, it can be seen that the superposition of the multi paths has a small

amplification effect. This is due to the multi path interference. The successes of the model will be

determined by whether or not the software recognises the multiple paths and hence delay spread.

The delay spread model was applied to the VoiceofRussia test file for a one off period of 15

seconds. The results of the increased delay spread are presented in figure 36.

Tm<Tg Tm>Tg

Figure 36 What the above results confirm is that while ever Tm is less than Tg, reception is unaffected by the

delay spread, i.e. the guard interval protects against ISI. Simulations in which a large Tm was

induced for a longer period shows that reception is still possible at levels slightly above Tg. Taking

into consideration the typical values of delay spread on the Bonaire signal, it is reasonable to

suggest that for reliable transmission, mode D is the appropriate robustness mode to use. The trade

off for this extra protection is a reduced data rate and as a result reduced audio quality. My personal

opinion is that the quality of audio achievable using mode D is of a sufficient standard to allow for

the extra insurance that mode D provides over the ultra long distance channel. Mode B signals have

been received, however with Tm close to Tg.

The model and simulations developed were quite successful and the results were reinforced by the

reception results obtained in section 3.1.5. ISI in the DRM system is avoided providing Tm < Tg for

48

a given robustness mode as I had hoped. I found that reception is not only degraded by an increase

in delay spread but also with an increased number of paths. For the propagation path relevant for

this project it is my belief that the number of propagation paths is small and would be multiple

reflections in the ionosphere apposed to multiple skips or local environmental surroundings.

49

3.4 Dream Modifications

3.4.1 Overview

This aspect of the project involved studying the software implementation of a DRM receiver using

the Dream code and testing modifications with the aim of improving the receiver’s performance.

The software is coded in C++ and written in a modular structure. The DRM system is complex and

the Dream code is extensive and complicated, thus modifications attempted were generally minor

adjustments and fine-tuning.

Modifications that were successfully made to Dream involved changes to the way the software dealt

with audio decoding errors within the AAC decoder. The original situation and the nature of these

modifications are as follows: When the audio source decoder decodes consecutive audio frames

with errors, it simply drops these frames. The resulting effect is a very short silent period in the

audio. Rather than having the small dropout, the modified code estimates the sample values of the

previously discarded frames using a linear interpolation technique.

3.4.2 Implementation

Initial work in this area commenced with a modified but untested working version of Dream

provided by Graham Wade, which implemented this idea. I used this version as my starting point to

test and refine this concept.

The interpolation across bad frames is implemented using the mathematical model given in

equation 12.

( )

−−= BA

NK

AC K (12)

Where:

KC = The Kth audio frame in the block of error frames.

A = Error free audio frame before block of errors frames.

B = Error free audio frame after block of errors frames.

N = Number of frames in the block of errors.

50

A number of options are available in the source coding system for DRM, which were explained in

section 2.2. The interpolation modifications have been implemented with regard to AAC, being the

generic audio coder used in the DRM system. To understand the issues involved in implementing

this audio estimation concept, it is first necessary to understand the audio framing structure used for

AAC in the DRM system.

The coded audio stream is composed into audio super frames 400 ms in length. An audio super

frame in turn consists of either ten 40 ms AAC frames or five 80 ms AAC frames, corresponding to

24 kHz or 12 kHz audio sampling respectively. Figure 37 depicts one audio super frame consisting

of 10 (24 kHz) AAC frames.

The process of modifying the Dream software involved making changes to the

AudioSourceDecoder.cpp file. The basic algorithm (figure 38) for the modifications works as

follows. When an error AAC frame is encountered the closest leading and following ‘good’ AAC

frames and found, knowing the relative position of the frames, the linear interpolation equation is

applied to the sample values that make up the frame in question

.

A Ck B

k=1 k=2 k=3 k=4 P P P Î Î Î Î P P P

Figure 37: Audio super frame

51

AAC Frame

‘good’ ‘ ‘bad’

No Yes

No Yes

Yes No

Figure 38: Interpolation Algorithm

End frame found

Interpolate

No Interpolation

Search for good start frame

Search for good end frame

Output AAC frame

No Interpolation

Start frame found

Check CRC Flag

Output AAC frame

Span >

MaxFill

No Interpolation

52

Figure 38 show the basic algorithm, in actual fact the algorithm is more complicated. The input data

to the audio source decoder is passed in one audio super frame at a time but the AAC decoder deals

with one AAC frame at a time. Thus the first requirement of the modifications was to buffer the

entire audio super frame and flag the buffer positions holding AAC frames with errors.

Frame errors will often run across the borders of the audio super frames. When this happens, end

frames can not be found and thus interpolation can not occur. To solve this problem a shift register

was implemented that was capable of buffering three audio super frames (figure 39). However as

mentioned the audio source decoder only processors one audio super frame at a time, thus the

variables associated with this kind of buffering are declared in the main program

(DRMReceiver.cpp), making the buffer global.

Frame: n - 1 n n + 1

Old Frame Current frame being processed New Frame

400 ms 1.2 s

Figure 39: Audio super frame buffering

A limit was imposed on the maximum size of the interpolation gap and is set in the code by the

number of frames. E.g. “MaxFill = 8” AAC frames. As such it was important that the interpolation

modifications considered that two different framing structures can be encountered. The initial

modified version did not consider this, resulting in inconsistent performance depending on the

sampling rate used by the AAC. Therefore “MaxFill” was made to be dependent on the AAC

framing structure to ensure that the maximum interpolation period is the same for both cases.

In the case that only one end frame is located or the size of the interpolation gap is too large there is

still an alternative for estimation of bad frames. In the original software an attenuation technique is

employed that estimates ‘bad’ frames by repeating the last ‘good’ frame, in an exponentially

attenuating fashion. This same method can be used in the cases that a ‘good’ start frame is found

with no end frame and used in a reverse fashion when an end frame is found but not start frame .

53

Forward and backward attenuation methods can be combined in the case that both end frames are

found but the interpolation gap is too large.

The GUI of Dream includes LED’s that indicate the decoding status. Modifications to these LED’s

were made so that they would provide information on when interpolation and attenuation were

taking place, allowing a correlation between what was being heard and what was actually

happening with respect to the interpolation modifications. Under testing conditions the LED

configuration was occasionally altered, however the general configuration is as shown below.

LED

MS_MSC_CRC: Green à Good audio frame

Yellow à Interpolation

Red à Attenuation

MS_FRAME_SYNC: Yellow à Interpolation gap < 6

Red à Interpolation gap > 5

54

3.4.3 Results

Initial testing showed that the interpolation modifications worked, whether or not that they were an

improvement is purely subjective. The modifications only estimate audio sample values where there

would otherwise be no audio, hence that decoding statistics generated by the receiver software are

not effected by the modifications.

My major observations were firstly that the difference is minor and difficult to evaluate, the period

of interpolation being less than 400 ms. Secondly, the attenuation process seemed to be called far

more often than the interpolation, indicating that often both start and end frames could not be found

or the gap was to large. Finally, an occasional ‘chirp’ or ringing effect was heard when the frame

estimation was taking place and it was not obvious whether this was due to the interpolation or

attenuation. Overall I believe that the modifications are at least no worse, whether or not they are an

improvement is a matter of personal opinion.

In order to try to discover the source of the undesirable audible effects of the modifications, three

different versions were compiled (Table 9).

Table 9: Dream-mods .exe Versions

DreamInt.exe Interpolation Forward Attenuation Backward Attenuation

1 ü ü ü

2 ü û û

3 û ü ü

Testing with these files is continuing with variations of the interpolation parameters in order to

arrive at an optimum configuration. Definitive results regarding the modifications will be supplied

at the conclusion of the project.

55

Chapter 4 – Conclusions and

Extensions 4.1 Conclusions The DRM reception/analysis facility setup has successfully allowed for the simulation and

evaluation of DRM test files and is capable of receiving a live transmission from Bonaire (Antilles,

South America). The best reception quality was received using a quarter wavelength long wire

antenna and when the DRM signal was transmitted in a high robustness mode. 64-QAM signals

were almost always unavailable. Investigations thus far have proved DRM to be superior to

analogue AM in audio quality and an impressive system with great future potential.

Evaluation of the software was undertaken using DRM internet test files and DRM signals personal

recorded from Bonaire over the course of the project. From an observational point of view the

performance of both receivers is similar, and in some instances the Dream package out performs the

official software radio. However, the information obtained from the data logs tells a different story

with the reception statistics of the official Software Radio being significantly better than with

Dream. It seems that the reason for this is unrelated to the actual performance of the receiver but to

do with how the data log is recorded. When the Dream software is set to record a data log it does so

regardless of whether it has locked onto a DRM signal or not. The official software on the other

hand pauses the recording of the data log when the signal is not present or temporarily drops out. In

the situation where test files less than one minute in length are being tested and there is a drop out in

the signal when the file loops around, causing discrepancies in results when comparing data logs for

any given test file. Comparative tests using a long DRM file with no signal drop outs showed that

the decoding performance is the same between the different software packages. The differences lay

with the evaluation capabilities and system requirements.

Dream is undoubtingly superior in respect to signal analysis and provides at least as good as

decoding performance as the official DRM Software Receiver, and lets not forget can be

56

downloaded free of charge over the internet. However from a radio user’s point of view who simply

wants to listen to a DRM broadcast, I would recommend the DRM Software Radio for two reasons.

Firstly the software is less demanding on system resources, allowing the software to run in the

background whilst having other applications open. Secondly I personally found the Dream software

to be some what unstable. I experienced instances where the software would not open on some

systems and other instances where the software would cause the system to freeze.

The Dream modifications proved to be challenging as an initial reading and understating of the code

was a time consuming process. Linear interpolation across bad audio frames is one method of

improving the audio performance and is at least no worse then a silent gap however the extent of an

improvement is something that can only be evaluated subjectively . Testing and improvements to the

Dream modifications are continuing and I propose to have more definitive results by the conclusion

of the project.

4.2 Extensions

Analysis of other live broadcasts to Australia when they become available would be interesting to

evaluate and compare how the DRM system performs under different conditions, i.e. different

propagation paths/distances, transmission powers and transmission formats. DRM allows for the

transmission of an AM signal (Vestigial Side Band) in the same channel as a DRM signal. If this

mode was to become available in Australia it would be interesting to directly compare the quality of

the two signals experiencing the exact same channel.

A frame estimation technique used in the audio decoder is an avenue that would greatly improve the

software receiver’s performance. This could possibly be achieved by continuing work on the current

interpolation method or by applying a new frame estimation technique.

The open source Dream package is the one aspect of this project which provides significant room

for extension. Only one small aspect of the decoding process was examined in the context of this

project. Other development areas of interest as expressed by the original author of Dream are

synchronisation and channel estimation. The DRM system is complex and these are just a few of a

number signal processing techniques utilised by the DRM system.

57

References [1] European Telecommunications Standardising Institute, “Digital Radio Mondiale (DRM);

System Specification,” ETSI ES 201 980 v2.1.1, April 2004. [2] J. Stott, “Digital Radio Mondiale: Key Technical Features”, Electronics and

communication Engineering Journal, vol. 28, pp. 4-14, 2002. [3] L. Hallett, “Digital Radio Mondiale”, Nov. 2002. [4] F. Hofmann, C. Hansen, & W. Schafer, “Digital Radio Mondiale (DRM) digital sound

broadcasting in the AM bands”, IEEE Transactions on Broadcasting, vol. 49, pp. 319-328, 2003.

[5] S. Ford, “Digital Radio Mondiale”, QST, vol. 87, pp. 37, 2003. [6] “The Propagation Media”, [Online]. Available: http://www.its.bldrdoc.gov/pub/oa-rpt/hf-

ale/handbook/annex1.pdf [7] “Propagation”, [Online]. Available:

http://www.nzart.org.nz/nzart/examinat/amateur%20radio%20study%20guide/Course%20Files/Propagation%20of%20Radio%20Signals/STUDY%20NOTES%20-%20PROPAGATION.htm. [Accessed: July 14, 2004]

[8] R. Otnes, “Guidelines for Increasing the Availability of Low and Medium Data Rates at

High Latitude HF Channels”, Information Systems Technology Panel Symposium on Military Communications, NATA RTO, Warsaw, Poland, Oct. 8-10, 2001.

[9] W.N. Furman & J.W. Nieto, “Understanding HF Channel Simulator Requirements in Order

to Reduce HF Modem Performance Measurement Variability”, proceedings of HF01, the Nordic HF Conference, Aug. 2001.

[10] G. Wade, “DRM Basics: HF Channel Model”, Aug. 2004. [11] J. Briggs, “Digital Broadcasting below 30 MHz: DRM-A Summery of Field Tests”, Oct.

2003.

58

[12] Official DRM website, [Online]. Available: www.drm.org. [13] R2 Technical Manual, “DRM R2 manual”, Broadcast Partners, April. 2003. [14] Dream website, [Online]. Available:

www.tu-darmstadt.de/fb/et/uet/fguet/mitarbeiter/vf/DRM/DRM.html [15] DRM receiver project website, [Online]. Available: www.drmrx.org. [16] T. Jaumann, G. Kilian, T. Langer, A. Zink, T. Fruhwald & J. Briggs, “DRM Software

Radio PC Based Software for DRM Reception User Manual, version 1.0”, Jan. 2003. [17] Dream Documentation “Dream DRM Receiver Documentation”, Dec. 2003. [Online].

Available: www.tu-darmstadt.de/fb/et/uet/fguet/mitarbeiter/vf/DRM/DRM.html

[18] C.C. Watterson, J.R. Juroshek, W.D. Bensema, “Experimental Conformation of an HF

Channel Model”, IEEE Trans. On Comm. Tech, vol. COM-18, No.6, Dec. 1970.

59

Appendices Appendix A: Simulation Results Sample Data log >>>> DRMSoftwareRadio-MERLIN-00000751 Software Version 2.0.34 Starttime (UTC) 2004-03-31 07:19:10 Frequency 12 kHz Latitude 32°55'S Longitude 151°46'E Label Bouquet Flevo NL Bitrate 14.48 kbps Mode B Bandwidth 10 kHz Comment BouquetFlevoNL-39sec on loop. MINUTE SNR SYNC AUDIO TYPE 0000 17 117 1100/10 0 0001 17 120 1060/10 0 0002 17 141 1330/10 0 0003 16 98 840/10 0 0004 17 139 1340/10 0 0005 17 117 1060/10 0 0006 17 140 1320/10 0 0007 16 120 1020/10 0 0008 16 120 1120/10 0 0009 17 132 1180/10 0 0010 18 143 1360/10 0 0011 17 132 1170/10 0 0012 18 143 1360/10 0 0013 17 108 940/10 0 0014 16 111 1020/10 0 SNR min: 0.0, max: 20.4 CRC: 0xc3b9 <<<<

60

DRM Software Radio - Internet Test Files

Voice of Russia Minute SNR Sync Sync (%) Audio Audio (%) Type

0 32 150 100.00 1450 96.67 0 1 32 140 93.33 1280 85.33 0 2 32 141 94.00 1280 85.33 0 3 31 139 92.67 1280 85.33 0 4 32 140 93.33 1280 85.33 0 5 32 139 92.67 1290 86.00 0 6 32 144 96.00 1340 89.33 0 7 32 141 94.00 1340 89.33 0 8 32 148 98.67 1340 89.33 0 9 32 144 96.00 1320 88.00 0

Averages 31.9 142.6 95.07 1320 88 0

Deutschland Radio Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 142 94.67 710 47.33 0 1 17 134 89.33 780 52.00 0 2 17 133 88.67 890 59.33 0 3 17 143 95.33 740 49.33 0 4 17 130 86.67 820 54.67 0 5 17 133 88.67 1000 66.67 0 6 17 137 91.33 780 52.00 0 7 17 128 85.33 790 52.67 0 8 17 138 92.00 760 50.67 0 9 17 130 86.67 740 49.33 0

Averages 17 134.8 89.87 801 53.4 0

DW Minute SNR Sync Sync (%) Audio Audio (%) Type

0 19 142 94.67 1250 83.33 0 1 19 141 94.00 1280 85.33 0 2 19 135 90.00 1090 72.67 0 3 19 144 96.00 1290 86.00 0 4 19 144 96.00 1300 86.67 0 5 19 138 92.00 1090 72.67 0 6 19 144 96.00 1290 86.00 0 7 19 145 96.67 1300 86.67 0 8 19 140 93.33 1100 73.33 0 9 19 144 96.00 1290 86.00 0

Averages 19 141.7 94.47 1228 81.87 0

61

Bouquet Flevo NL Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 150 100.00 1490 99.33 0 1 17 132 88.00 1200 80.00 0 2 17 150 100.00 1490 99.33 0 3 17 129 86.00 1220 81.33 0 4 17 144 96.00 1360 90.67 0 5 16 107 71.33 900 60.00 0 6 17 141 94.00 1320 88.00 0 7 16 114 76.00 960 64.00 0 8 17 143 95.33 1350 90.00 0 9 16 118 78.67 1020 68.00 0

Averages 16.7 132.8 88.53 1231 82.07 0

RTL Minute SNR Sync Sync (%) Audio Audio (%) Type

0 19 143 95.33 1280 85.33 0 1 20 137 91.33 1050 70.00 0 2 19 133 88.67 1190 79.33 0 3 20 134 89.33 1060 70.67 0 4 20 143 95.33 1290 86.00 0 5 20 136 90.67 1080 72.00 0 6 19 131 87.33 1160 77.33 0 7 20 137 91.33 1150 76.67 0 8 20 143 95.33 1190 79.33 0 9 20 139 92.67 1210 80.67 0

Averages 19.7 137.6 91.73 1166 77.73 0

ProjectQoSAM File could not be decoded!!

62

Dream – Internet Test Files

Voice of Russia Minute SNR Sync Sync (%) Audio Audio (%) Type

0 24 136 90.67 1340 89.33 0 1 25 137 91.33 1340 89.33 0 2 25 137 91.33 1342 89.47 0 3 25 134 89.33 1295 86.33 0 4 26 128 85.33 1235 82.33 0 5 26 122 81.33 1182 78.80 0 6 28 149 99.33 1457 97.13 0 7 24 110 73.33 1064 70.93 0 8 25 104 69.33 1006 67.07 0 9 24 149 99.33 1453 96.87 0

Averages 25.20 130.60 87.07 1271.40 84.76 0

Deutschland Radio Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 66 44.00 617 41.13 0 1 18 21 14.00 165 11.00 0 2 15 65 43.33 586 39.07 0 3 17 58 38.67 527 35.13 0 4 18 25 16.67 196 13.07 0 5 15 54 36.00 495 33.00 0 6 18 40 26.67 345 23.00 0 7 16 66 44.00 616 41.07 0 8 18 41 27.33 356 23.73 0 9 17 63 42.00 575 38.33 0

Averages 16.90 49.90 33.27 447.80 29.85 0

DW Minute SNR Sync Sync (%) Audio Audio (%) Type

0 19 35 23.33 302 20.13 0 1 19 80 53.33 760 50.67 0 2 18 69 46.00 651 43.40 0 3 19 40 26.67 362 24.13 0 4 18 80 53.33 770 51.33 0 5 19 24 16.00 200 13.33 0 6 19 58 38.67 530 35.33 0 7 18 87 58.00 831 55.40 0 8 20 14 9.33 101 6.73 0 9 19 66 44.00 610 40.67 0

Averages 18.80 55.30 36.87 511.70 34.11 0

63

Bouquet Flevo NL Minute SNR Sync Sync (%) Audio Audio (%) Type

0 18 150 100.00 1490 99.33 0 1 16 146 97.33 1430 95.33 0 2 18 150 100.00 1490 99.33 0 3 18 149 99.33 1480 98.67 0 4 18 72 48.00 710 47.33 0 5 18 24 16.00 220 14.67 0 6 18 75 50.00 739 49.27 0 7 18 30 20.00 260 17.33 0 8 18 75 50.00 750 50.00 0 9 18 141 94.00 1410 94.00 0

Averages 17.80 101.20 67.47 997.90 66.53 0

RTL Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 47 31.33 440 29.33 0 1 15 80 53.33 774 51.60 0 2 13 37 24.67 334 22.27 0 3 16 80 53.33 779 51.93 0 4 9 18 12.00 140 9.33 0 5 15 78 52.00 743 49.53 0 6 13 27 18.00 223 14.87 0 7 17 75 50.00 700 46.67 0 8 18 67 44.67 640 42.67 0 9 18 60 40.00 577 38.47 0

Averages 15.10 56.90 37.93 535.00 35.67 0

ProjectQoSAM Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 28 18.67 115 15.33 0 1 16 39 26.00 171 22.80 0 2 14 148 98.67 713 95.07 0 3 16 67 44.67 310 41.33 0 4 16 84 56.00 397 52.93 0 5 16 95 63.33 452 60.27 0 6 14 147 98.00 702 93.60 0 7 14 44 29.33 185 24.67 0 8 16 37 24.67 167 22.27 0 9 14 149 99.33 711 94.80 0

Averages 15.30 83.80 55.87 392.30 52.31 0

64

Dream Evaluation

Sim 1: RNBW: June-19th_1 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 750 100.00 0 1 14 151 100.67 746 99.47 0 2 14 150 100.00 746 99.47 0 3 14 150 100.00 749 99.87 0 4 13 150 100.00 745 99.33 0 5 13 150 100.00 749 99.87 0 6 7 124 82.67 455 60.67 0 7 10 150 100.00 745 99.33 0 8 13 150 100.00 748 99.73 0 9 14 150 100.00 749 99.87 0

10 12 147 98.00 689 91.87 0 11 15 127 84.67 610 81.33 0 12 14 150 100.00 743 99.07 0 13 14 150 100.00 747 99.60 0 14 14 150 100.00 748 99.73 0 15 13 151 100.67 756 100.00 0

Averages 13.06 146.88 97.92 717.19 95.58 0

Sim 2: RNBW: June -19th_1 Dream_1-Iterations: 0 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 749 99.87 0 1 14 150 100.00 746 99.47 0 2 14 150 100.00 748 99.73 0 3 14 150 100.00 741 98.80 0 4 13 151 100.67 742 98.93 0 5 13 150 100.00 737 98.27 0 6 7 125 83.33 432 57.60 0 7 10 150 100.00 738 98.40 0 8 13 150 100.00 739 98.53 0 9 14 150 100.00 752 100.00 0

10 12 147 98.00 638 85.07 0 11 15 131 87.33 632 84.27 0 12 14 150 100.00 735 98.00 0 13 14 150 100.00 757 100.00 0 14 14 150 100.00 748 99.73 0 15 13 151 100.67 750 100.00 0

Averages 13.06 147.19 98.13 711.50 94.79 0

65

Sim 3: RNBW: June -19th_1 Dream_1 Iterations:2 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 749 99.87 0 1 14 150 100.00 746 99.47 0 2 14 150 100.00 746 99.47 0 3 14 151 100.67 752 100.00 0 4 14 152 101.33 756 100.00 0 5 13 148 98.67 738 98.40 0 6 2 129 86.00 450 60.00 0 7 12 152 101.33 758 100.00 0 8 13 150 100.00 747 99.60 0 9 13 155 103.33 780 100.00 0

10 12 138 92.00 654 87.20 0 11 16 130 86.67 625 83.33 0 12 13 171 114.00 848 100.00 0 13 14 135 90.00 674 89.87 0 14 13 144 96.00 717 95.60 0 15 13 151 100.67 750 100.00 0

Averages 12.81 147.25 98.17 718.13 94.55 0

Sim 4: RNBW: June -19th_1 Dream_1-Iterations:3 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 19 34 22.67 152 20.27 0 1 17 37 24.67 168 22.40 0 2 18 37 24.67 165 22.00 0 3 18 21 14.00 85 11.33 0 4 18 31 20.67 133 17.73 0 5 18 34 22.67 146 19.47 0 6 19 32 21.33 140 18.67 0 7 18 38 25.33 167 22.27 0 8 18 36 24.00 161 21.47 0 9 0 0 0.00 0 0.00 0

10 0 0 0.00 0 0.00 0 11 19 46 30.67 212 28.27 0 12 18 4 2.67 0 0.00 0 13 18 33 22.00 144 19.20 0 14 18 37 24.67 165 22.00 0 15 17 31 20.67 138 18.40 0

Averages 15.81 28.19 18.79 123.50 16.47 0

66

Sim 5: RNBW: June -19th_1 Dream_1-Iterations:4 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 19 20 13.33 77 10.27 0 1 18 11 7.33 30 4.00 0 2 18 18 12.00 70 9.33 0 3 18 16 10.67 62 8.27 0 4 18 19 12.67 78 10.40 0 5 19 18 12.00 71 9.47 0 6 18 20 13.33 81 10.80 0 7 17 19 12.67 71 9.47 0 8 19 17 11.33 67 8.93 0 9 16 18 12.00 74 9.87 0

10 17 11 7.33 34 4.53 0 11 19 4 2.67 0 0.00 0 12 19 19 12.67 78 10.40 0 13 12 17 11.33 64 8.53 0 14 19 17 11.33 67 8.93 0 15 18 19 12.67 72 9.60 0

Averages 17.75 16.44 10.96 62.25 8.30 0

Sim 6: RNBW: June-19th_1 Dream_1-time interpolation: linear Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 750 100.00 0 1 12 150 100.00 735 98.00 0 2 13 150 100.00 748 99.73 0 3 14 150 100.00 746 99.47 0 4 13 150 100.00 745 99.33 0 5 12 150 100.00 735 98.00 0 6 6 148 98.67 575 76.67 0 7 11 150 100.00 749 99.87 0 8 12 151 100.67 745 99.33 0 9 13 150 100.00 747 99.60 0

10 12 147 98.00 688 91.73 0 11 15 125 83.33 605 80.67 0 12 12 150 100.00 737 98.27 0 13 13 150 100.00 748 99.73 0 14 14 151 100.67 748 99.73 0 15 13 150 100.00 749 99.87 0

Averages 12.50 148.25 98.83 721.88 96.25 0

67

Sim 7: RNBW: June-19th_1 Dream_1-Frequency Interpolation Linear Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 750 100.00 0 1 13 150 100.00 744 99.20 0 2 13 150 100.00 747 99.60 0 3 13 150 100.00 746 99.47 0 4 13 150 100.00 747 99.60 0 5 12 150 100.00 747 99.60 0 6 6 124 82.67 441 58.80 0 7 10 150 100.00 732 97.60 0 8 13 150 100.00 739 98.53 0 9 13 150 100.00 748 99.73 0

10 11 147 98.00 632 84.27 0 11 15 124 82.67 594 79.20 0 12 13 150 100.00 743 99.07 0 13 13 150 100.00 749 99.87 0 14 13 150 100.00 748 99.73 0 15 13 150 100.00 746 99.47 0

Averages 12.44 146.56 97.71 709.56 94.61 0

Sim 8: RNBW: June-19th_1 Dream_1-Frequency interpolation-DFTzeropad Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 749 99.87 0 1 13 150 100.00 739 98.53 0 2 13 150 100.00 741 98.80 0 3 13 150 100.00 741 98.80 0 4 13 151 100.67 741 98.80 0 5 12 150 100.00 735 98.00 0 6 6 123 82.00 418 55.73 0 7 10 150 100.00 729 97.20 0 8 13 150 100.00 736 98.13 0 9 13 150 100.00 751 100.13 0

10 11 148 98.67 617 82.27 0 11 15 128 85.33 616 82.13 0 12 13 150 100.00 743 99.07 0 13 13 150 100.00 742 98.93 0 14 13 150 100.00 745 99.33 0 15 13 150 100.00 750 100.00 0

Averages 12.44 146.88 97.92 705.81 94.11 0

68

Sim 9: RNBW: June-19th_1 Dream_1-First Peak Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 749 99.87 0 1 14 150 100.00 748 99.73 0 2 14 150 100.00 748 99.73 0 3 14 150 100.00 747 99.60 0 4 13 150 100.00 743 99.07 0 5 13 151 100.67 746 99.47 0 6 7 126 84.00 469 62.53 0 7 10 150 100.00 723 96.40 0 8 13 150 100.00 747 99.60 0 9 13 150 100.00 752 100.27 0

10 12 148 98.67 695 92.67 0 11 15 124 82.67 595 79.33 0 12 14 150 100.00 749 99.87 0 13 14 150 100.00 748 99.73 0 14 14 150 100.00 748 99.73 0 15 13 150 100.00 747 99.60 0

Averages 13.00 146.81 97.88 715.88 95.45 0

Sim 10: RNBW: June -19th_1 Dream_1-4 Iterations-Linear settings Minute SNR Sync Sync (%) Audio Audio (%) Type

0 14 150 100.00 740 98.67 0 1 11 150 100.00 542 72.27 0 2 13 150 100.00 749 99.87 0 3 13 150 100.00 747 99.60 0 4 13 150 100.00 745 99.33 0 5 12 150 100.00 527 70.27 0 6 6 146 97.33 117 15.60 0 7 11 151 100.67 654 87.20 0 8 12 150 100.00 734 97.87 0 9 13 150 100.00 750 100.00 0

10 11 148 98.67 477 63.60 0 11 15 124 82.67 599 79.87 0 12 12 150 100.00 570 76.00 0 13 13 150 100.00 740 98.67 0 14 13 151 100.67 746 99.47 0 15 13 150 100.00 749 99.87 0

Averages 12.19 148.13 98.75 636.63 84.88 0

69

Comparative Simulation Results

Software Comparison-DRM Software Radio Minute SNR Sync Sync (%) Audio Audio (%) Type

0 10 135 90 490 65.33 0 1 12 147 98 545 72.67 0 2 11 148 98.67 605 80.67 0 3 11 150 100 505 67.33 0 4 11 151 100.67 475 63.33 0 5 11 150 100 530 70.67 0 6 11 149 99.33 540 72 0 7 11 149 99.33 605 80.67 0 8 11 150 100 535 71.33 0 9 11 148 98.67 585 78 0 10 11 28 18.67 175 23.33 0

Averages 11 136.82 91.21 508.18 67.76 0

Software Comparison-Dream_1 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 12 142 94.67 581 77.47 0 1 11 149 99.33 546 72.80 0 2 11 148 98.67 608 81.07 0 3 10 145 96.67 579 77.20 0 4 10 150 100 567 75.60 0 5 10 151 100.67 513 68.40 0 6 14 21 14 78 10.40 0 7 11 147 98 686 91.47 0 8 11 149 99.33 619 82.53 0 9 11 148 98.67 642 85.60 0

10 10 147 98 271 36.13 0 Averages 11 136.09 90.73 517.27 68.97 0

Software Comparison-Dream_1.0.6 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 12 139 92.67 564 75.20 0 1 11 148 98.67 559 74.53 0 2 11 148 98.67 569 75.87 0 3 11 147 98 575 76.67 0 4 10 150 100 548 73.07 0 5 10 148 98.67 527 70.27 0 6 17 2 1.33 0 0 0 7 12 148 98.67 675 90 0 8 11 148 98.67 615 82 0 9 11 149 99.33 648 86.40 0 10 10 147 98 268 35.73 0

Averages 11.45455 134 89.33 504.36 67.25 0

70

Recorded RNWB (Bonaire) Data Logs

RNBW: June-19th_1 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 745 99.33 0 1 14 147 98.00 740 98.67 0 2 14 148 98.67 740 98.67 0 3 13 151 100.67 740 98.67 0 4 13 149 99.33 735 98.00 0 5 13 149 99.33 745 99.33 0 6 14 149 99.33 750 100.00 0 7 14 150 100.00 740 98.67 0 8 13 148 98.67 740 98.67 0 9 13 72 48.00 670 89.33 0 10 13 76 50.67 490 65.33 0 11 15 150 100.00 735 98.00 0 12 14 148 98.67 740 98.67 0 13 14 150 100.00 750 100.00 0 14 13 150 100.00 735 98.00 0 15 13 149 99.33 735 98.00 0

Averages 13.625 139.75 93.17 720.625 96.08 0

RNBW: June-19th_2 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 15 150 100.00 750 100.00 0 1 15 150 100.00 755 100.67 0 2 14 149 99.33 715 95.33 0 3 14 149 99.33 730 97.33 0 4 14 150 100.00 735 98.00 0 5 14 150 100.00 730 97.33 0 6 15 150 100.00 735 98.00 0 7 14 150 100.00 745 99.33 0 8 14 150 100.00 745 99.33 0 9 14 150 100.00 720 96.00 0

10 13 148 98.67 690 92.00 0 11 12 149 99.33 680 90.67 0 12 12 149 99.33 690 92.00 0 13 11 150 100.00 545 72.67 0 14 11 150 100.00 355 47.33 0 15 10 149 99.33 50 6.67 0 16 9 149 99.33 30 4.00 0 17 14 113 75.33 475 63.33 0

Averages 13.05556 147.5 98.33 604.1667 80.56 0

71

RNBW: July-11th Minute SNR Sync Sync (%) Audio Audio (%) Type

0 9 147 98.00 10 0.67 0 1 9 147 98.00 30 2.00 0 2 10 148 98.67 20 1.33 0 3 10 149 99.33 10 0.67 0 4 10 149 99.33 20 1.33 0 5 10 100 66.67 60 4.00 0 6 9 26 17.33 0 0.00 0 7 11 150 100.00 160 10.67 0 8 10 141 94.00 0 0.00 0 9 9 149 99.33 50 3.33 0 10 9 144 96.00 10 0.67 0 11 9 147 98.00 30 2.00 0

Averages 9.583333 133.0833 88.72 33.33333 2.22 0

RNBW: July-17th Minute SNR Sync Sync (%) Audio Audio (%) Type

0 4 34 22.67 0 0.00 0 1 9 148 98.67 0 0.00 0 2 9 146 97.33 0 0.00 0 3 8 147 98.00 0 0.00 0 4 8 147 98.00 0 0.00 0 5 7 75 50.00 0 0.00 0 6 7 99 66.00 0 0.00 0 7 7 146 97.33 0 0.00 0 8 7 148 98.67 0 0.00 0 9 8 147 98.00 0 0.00 0

10 10 142 94.67 0 0.00 0 11 9 147 98.00 0 0.00 0 12 9 147 98.00 0 0.00 0 13 8 147 98.00 0 0.00 0 14 8 146 97.33 0 0.00 0 15 8 109 72.67 0 0.00 0

Averages 7.875 129.6875 86.46 0 0.00 0

72

RNBW: Aug-8th Minute SNR Sync Sync (%) Audio Audio (%) Type

0 12 139 92.67 150 20.00 0 1 12 149 99.33 150 20.00 0 2 11 149 99.33 80 10.67 0 3 12 150 100.00 80 10.67 0 4 11 149 99.33 40 5.33 0 5 11 150 100.00 70 9.33 0 6 11 41 27.33 70 9.33 0 7 10 5 3.33 0 0.00 0 8 10 33 22.00 0 0.00 0 9 12 150 100.00 0 0.00 0

10 12 150 100.00 100 13.33 0 11 12 150 100.00 30 4.00 0 12 11 149 99.33 20 2.67 0 13 10 150 100.00 0 0.00 0 14 10 150 100.00 10 1.33 0 15 5 33 22.00 0 0.00 0

Averages 10.75 118.5625 79.04 50 6.67 0

RNBW: Sept-12th_1 Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 145 96.67 1240 82.67 0 1 18 149 99.33 1410 94.00 0 2 18 150 100.00 1350 90.00 0 3 18 150 100.00 1430 95.33 0 4 19 150 100.00 1470 98.00 0 5 18 147 98.00 1460 97.33 0 6 18 150 100.00 1490 99.33 0 7 18 150 100.00 1450 96.67 0 8 17 150 100.00 1420 94.67 0 9 17 150 100.00 1450 96.67 0 10 17 150 100.00 1380 92.00 0 11 18 150 100.00 1410 94.00 0 12 18 150 100.00 1430 95.33 0 13 18 148 98.67 1440 96.00 0 14 17 150 100.00 1310 87.33 0 15 17 150 100.00 1290 86.00 0

Averages 17.6875 149.3125 99.54 1401.875 93.46 0

73

RNBW: Sept-12th_2 Merlin Software. Minute SNR Sync Sync (%) Audio Audio (%) Type

0 17 136 90.67 1230 82.00 0 1 19 150 100.00 1480 98.67 0 2 19 150 100.00 1420 94.67 0 3 20 150 100.00 1440 96.00 0 4 20 149 99.33 1450 96.67 0 5 19 149 99.33 1400 93.33 0 6 19 149 99.33 1410 94.00 0 7 19 149 99.33 1330 88.67 0 8 17 150 100.00 1360 90.67 0 9 18 150 100.00 1390 92.67 0 10 17 148 98.67 1400 93.33 0 11 17 150 100.00 1320 88.00 0 12 18 149 99.33 1350 90.00 0 13 18 150 100.00 1500 100.00 0 14 19 150 100.00 1480 98.67 0 15 19 148 98.67 1460 97.33 0 16 19 149 99.33 1450 96.67 0 17 19 150 100.00 1360 90.67 0 18 19 150 100.00 1470 98.00 0 19 20 150 100.00 1480 98.67 0 20 19 150 100.00 1460 97.33 0 21 19 150 100.00 1470 98.00 0 22 19 149 99.33 1490 99.33 0 23 19 150 100.00 1500 100.00 0 24 20 150 100.00 1470 98.00 0 25 20 130 86.67 1370 91.33 0

Averages 18.76923 148.269 98.84615 1420.769 94.717949 0

74

Appendix B: Matlab code Basic channel model % Author: David Nelson % The code below reads in a wav file named 'input' and inserts % 2 second drop outs into the file ever 10 seconds by attenuating % sample values. The resulting samples are written back to a wav % file named: "output". %implements equation (2) clear all; close all; t = 240000; % Number of samples to be attenuated. a = 0.3162277; % Sample attenuation factor. seperation = 480000; % 10 seconds (480000 samples) b/n dropouts. x=wavread('input'); n=length(x); count = 480000; % 10 seconds into file. while count < (n-t) x(count:(count+t))= x(count:(count+t))*a; count = (count+t) + seperation; end wavwrite(x,48000,'output');

75

Doppler Spread Model % Auther: David Nelson % The following code is intended to simulate a fadding HF channel % to a recorded DRM wave file, then outputing the result as a wav file. % Implements equation 11 clear all; close all; startTime = 480000; fs=48000; T=1/fs; a=0; fd=0.025; Tf=((1/fd)*fs); f=fd*cos(a); s=wavread('VoR'); n=length(s); r=s; x=s; for k=1:n if k>startTime & k<(startTime+(Tf/2)) r(k)= r(k)+ s(k)*cos(2*pi*f*(k-startTime+(Tf/4))*T); else r(k)=s(k); end for k=1:n x(k)= s(k)*cos(2*pi*f*(k)*T); end end wavwrite(r,48000,'drmfile1');

76

Delay Spread Model % Author: David Nelson % The following code introduces Delay spread (Tm) into a % wav file recording of a DRM signal sampled at 48kHz. %Implements equation (1) clear all; close all; %--------------------User Defined Variables------------------------------ Tm=6; % Delay Spread in ms. period=15; % Time Tm is applied to file in sec. paths=5; startTime=480000; % Start after 10 seconds. a=1; % Initialise attenuation level; %---------------------------------------------------------------------------- period=period*48000; s=wavread('drmfile'); TmSize=Tm/1000*48000; % Delay spread given in samples. delay=TmSize/(paths-1); % Period betwwen consecutive paths. a=a-(1/paths); r=s; % Output now contains first path. for n=2:paths, for k=(startTime):(startTime+period), r(k+delay)=r(k+delay)+s(k)*a; end a=a-(1/paths); % Reduce the gain for next path. delay=delay+(TmSize/(paths-1)); end wavwrite(r,48000,'drmfile1'); % Write to wav file . subplot(2,1,1), plot(s) axis([0 1500000 -0.3 0.3]) subplot(2,1,2), plot(r) axis([0 1500000 -0.3 0.3])