abstract - the university of newcastle, australia
TRANSCRIPT
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])