Software Geared to the Shortwave Hobbyist
Experimenting with DRM
10 Feb 2004 (updated 01 Apr)
DRM stands for Digital Radio Mondiale, a fairly recent development in audio
streaming over shortwave and mediumwave. Technically, these signals are transmitted using interleaved data streams using
multi-phase quadrature amplitude modulation over a typical AM channel. Once demodulated by the receiver, a software
application must provide further demodulation to convert the digital stream back to audio. The signal can be received using
normal shortwave radios with one catch. The total signal bandwidth is approximately 10kHz wide. This requires that a receiver
have a filter that is wide enough to capture the full bandwidth of the signal. Several receiver models have been modified to
accommodate this bandwidth issue, primarily by means of picking off one of the intermediate frequencies, and modulating down
to a 12kHz center frequency.
Receiver Selection and Settings.
Upon looking at the DRM specifications, it was determined that it was theoretically possible for us to do a DRM receiving
test without having to modify a receiver. We have a couple of receivers that have the required output bandwidth. The Drake
R8A has a 12kHz filter, which is automatically switched in for FM demodulation. However, the radio signal must be first
demodulated using AM or SSB to be effective. We had contemplated modifying the Drake R8A so the FM filter would work for
the AM modes. Since this is our primary receiver that option was quickly ruled out. Another receiver capable of wideband
output was our NRD 535D, which has an approximately 12kHz wide AUX filter. This is sufficient to get the signal through,
however, the signal would have to be "moved" into the correct offset frequency for any software to operate. It was
thought that we could get the full width of the signal by putting the receiver into a sideband mode and de-tuning by 5 to 8kHz.
A better solution was to make use the receiver's internally selectable CW offset. This worked fairly well. But, the rolloff of
the filter was a bit much to get any reliable software decoding. Moving the passband in the direction of the signal helped to
alleviate that problem. A summary of the settings used for the NRD-535D are as follows:
|JRC NRD-535D Receiver Settings
||center frequency +1 to +3.5kHz
|CW Offset (BFO)
By using the above settings, we were able to get a signal that was within 10dB between the lowest and highest frequencies in the
SSB-demodulated signal. Since CW on the NRD-535D is a lower-sideband mode, we opted to experiment with the tuning frequency to
simulate a guard band. Depending upon signal strength, this meant tuning 1 to 3.5 kHz above the DRM's center frequency. For
example, afternoon transmissions from Sackville are currently on 9800kHz between 2055-2400 UT. For this, we would actually tune
the receiver to between 9801 to 9803.5kHz to create to desired effect. Since the CW Offset is set to -5kHz, this actually moves
the center frequency of the DRM signal -6 to -8.5kHz from the receiver's displayed frequency, and is well within the filter's
Currently, there are only two options for decoding a DRM stream. The DRM Consortium sells a product called the
DRM Software Radio for 32-bit Windows operating systems that costs 60€ (~US$60 depending on exchange rates).
There is also a version called Dream that was developed by a couple
of teaching students, Volker Fischer and Alexander Kurpiers, at Darmstadt University of Technology, Germany. Dream is provided
under the GNU-General Purpose License in the form of C++
source code for both 32-bit Windows and Linux. A SourceForge project has been set up for this at
http://sourceforge.net/projects/drm/, where the latest
cvs versions can be downloaded. Dream requires a few libraries to be built and installed before it can be created. Dream was
designed for Trolltech's Qt v2, which is common to both Windows and
Linux. We used Qt3 for our Red Hat 8 installation, which was already
built-in. This and other required libraries are as follows:
For experimental purposes, we attempted to build all of the parts of Dream under Red Hat 8. This also presented some problems,
since the application did not properly interface to our Soundblaster Audigy card. The program would hang during initialization
even though the application (and drivers) were properly built. Dream can be built to use either the standard Open Sound System
(OSS) drivers, or with the Advanced Linux Sound Architecture (ALSA).
After spending a few days getting ALSA to work under KDE, we had realized that the problem wasn't the sound card. The problem
was an undetermined conflict with KDE's
Analog Realtime Synthesizer (aRts) system, which was apparently
blocking the card's recording capability. The problem could be quickly rectified by disabling aRts, or by running under
GNOME. We decided to stick with GNOME.
Experimenting with Dream.
Dream is an interesting and complicated application. It uses the soundcard to "read" the digital signal, then decodes
it into the several DRM control, information and audio streams. It first performs time and frequency synchronization to
determine if it is receiving DRM or just noise, as well as to provide the appropriate channel estimation and tracking mechanisms.
Once synchronization has occurred, it decodes three QAM signals: the Fast Access Channel (FAC) in 4-phase QAM, Service
Description Channel (SDC) in 4 or 16-phase QAM, and the Main Service Channel (MSC) in 16 or 64-phase QAM. The FAC is what tells the DRM
receiver the primary content and format of the main stream, and how to decode it. The SDC provides secondary information
about the sender and any other text data, similar to Radio Data
System (RDS) on FM broadcast stations. The MSC is the audio and data stream content, which is typically a 12 or 24-bit
Advanced Audio Coding (AAC) signal, with optional
Spectral Band Replication (SBR) encoding.
Dream also provides iterative multi-level channel coding techniques for each stream, which provides forward error correction
for moderately noisy signals. It also employs various channel estimation and synchronization methods that can suit varying
channel conditions and computer processing power.
Dream provides several displays as the signal is being acquired to evaluate signal quality and aid in tuning. During
synchronization and channel estimation, Dream takes the captured audio and determines the center frequency of the DRM signal. It
then shifts it to 6kHz for further decoding, using fast fourier transforms. The application provides two displays for this: a
real-time spectral display and a power-shifted display. Once synchronized, it provides three constellation plots to display the
phase purity of each of the FAC, SDC and MSC streams. Dream also provides signal quality meters and "stoplight-style"
status bars for each stream. However, we found that the constellation plots were more informative, if not enjoyable to watch.
We had some problems with our initial Linux installation of Dream. The application would acquire the data properly. However,
it would only properly decode the FAC and SDC portions. This was primarily using the Sackville transmissions of 9800 at
2055-2400, 6015 at 0000-0059, 6140 at 0100-0159, and 6010 at 0400-0459. All of the received signals were strong, although
fluttery at times due to varying geomagnetic conditions over the test period. We were able to get a received 27dB signal to
noise ratio (SNR), a very clean MSC constellation display, some occasional bleeps and burps, but the application refused to
decode any audio. It is quite possible that there were reticent soundcard problems, an incompatibility with the FAAD2 library
that was used, or a combination of both. At times it was thought that the problem could have been that the theory of using an
unmodified receiver could be an issue, since the input audio spectrum was not flat. This could create phasing errors even though
Dream corrects somewhat for selective fading.
After a couple of weeks of experimenting with the Linux version, we attempted to try the compiled Windows version and
accompanying Qt dynamically linked library (DLL). After a lot less experimentation, we were finally able to hear a DRM signal
originating from the Deutsche Welle transmitter in Sines, Portugal (15440 at 0800-1400 UT). The reception wasn't great, but it
was generating a lot more intelligible audio than the Linux setup. With a fair signal, Dream only lost synch a few times and
quickly recovered. What was interesting is that the MSC constellation did not have to be perfectly clean in the Windows version
in order to generate clean audio. Upon looking at Dream's log files, the Windows version was correctly decoding over 800 packets
for 10 received AAC data frames. The signal was reported as a fairly low SNR of 15-20dB. In sharp contrast, the Linux version
was receiving clean signals of 25-27dB SNR and had only correctly decoded less than 60 packets per 10 received frames.
18 Feb 2004 (updated 21 Apr)
Success under Linux.
We were finally able to get the Linux version operational. The problem we were having getting Dream to decode audio was due to
two issues: an incompatibility of faad2-RC3 with the new DRM standard and problems with the way faad2 is built. In order to
get Dream to properly decode the latest DRM standard you will need the "final" release of faad2-2.0, dated 9 Feb
2004. Note that there are some additional issues with this release that will create a defective Makefile. The following is the
way we were able to get it built correctly (as root) after unarchiving the source tarballs (comments in brackets):
[ build faad2, use the top of your own source tree for the next line ]
# cd faad2
# sh ./bootstrap
[ need to set c and c++ compiler flags, because of inconsistency in the configure script ]
# export CFLAGS="-g -O3 -DDRM -march=i686"
# export CXXFLAGS="-g -O3 -DDRM -march=i686"
[ we also use XMMS so, we're building with the other two package settings ]
# ./configure --prefix=/usr --with-drm --with-xmms --with-mp4v2
[ edit Makefile since it's broken ]
# emacs Makefile
[ rem out the rpm: section at the end, and save the Makefile ]
[ make sure all old stuff is out of there before building faad2 ]
# make clean
# make install
05 Aug 2004 (updated 07 Aug)
(Optional) You can now build Dream to use the latest faad2 code from the sourceforge cvs repository.
This new faad2 code incorporates the parametric stereo standard used by some DRM broadcasts:
[ build faad2, use the top of your own source tree for the next line ]
# cd faad2
[ reconfigure ]
# sh ./bootstrap
[ need to set c and c++ compiler flags, note addition of DRM_PS declaration ]
# export CFLAGS="-g -O3 -DDRM -DDRM_PS -march=i686"
# export CXXFLAGS="-g -O3 -DDRM -DDRM_PS -march=i686"
# ./configure --prefix=/usr --with-drm
[ now change to the libfaad directory ]
# cd libfaad
[ make sure all old stuff is out of there before building libfaad ]
# make clean
# make install
Now build Dream:
[ use the top of your own source tree for the next line ]
# cd ~/DRM/drm-1.0
[ we use ALSA so... ]
# ./configure --prefix=/usr --enable-alsa
[ make sure all old stuff is out of there ]
# make clean
# make install
To build Journaline under Linux, download and install the SRPM listed above. You will need to move the
resulting zip and patch files from your SRPMS directory into it's own build directory. Once the zip file is unarchived, use
the following steps:
[ build journaline, use the top of your own source tree for the next line ]
# cd WinFhGJourLib/journaline_20040318
[ apply the patch file to Makefile, then run make ]
[ make the library ]
# make libfhgjournaline.so
[ there is no install, so you need to install it manually ]
[ some prefer the /usr/local prefix, I don't ]
# mv libfhgjournaline.so.0 /usr/lib
# ln -s /usr/lib/libfhgjournaline.so.0 /usr/lib/libfhgjournaline.so
[ now install the includes ]
# mkdir /usr/include/journaline
# mv *.h /usr/include/journaline
[ now rebuild Dream, use the top of your own source tree for the next line ]
# cd ~/DRM/drm-1.0
[ reconfigure with the --with-journaline switch ]
# ./configure --prefix=/usr --enable-alsa --with-journaline
[ make sure all old stuff is out of there ]
# make clean
# make install
Building under Windows. (added 20 Mar)
Like the Linux version, we decided to try building the Windows version. At first we tried emulating a Linux setup using various
Linux-on-Windows tools, such as MinGW/MSYS and
Cygwin. These are nice tools, however the build environment (unix for some
things, Win32 for others) is not supported within the source code available. We were only able to get the code to build using
Microsoft Visual C++ v6. Workspace and other development
support files for compiling under VC++ is included in all of the Windows source packages.
Upon using Visual C++ we found two particular issues. First, the compiler had problems with the includes from the installed Qt
interface package. This was solved by installing Service Pack 3 (SP3). SP3 was included with our Visual C++ distribution. It
didn't seem to need it at first so it was never installed. Other experimenters also have claimed problems and installed SP5,
which is now available on the Microsoft web site. Our second problem was a bit more complicated. The faad2 code uses the
ALIGNED modifier in several places within the code, which is intended to bit-align several memory tables. Simply tabbing through
the errors listed in the compiler and removing the 200+ ALIGNED modifiers allowed faad2 to be built. We did not attempt to
compile the other required packages. We opted to just copy the pre-compiled libraries and header files for FFTW, Qwt and
Journaline® into the drm/libs directory. Once faad2 is built, you must also copy it's resulting library and header file prior to
20 Feb 2004
DXing with DRM.
Who says you can't DX with DRM? We decided to try some real-time DXing using the
DRM Live Broadcast Schedule. We already
mentioned the DW transmission from Sines on 15440. It is somewhat irregular in reception, but does produce audio for the most
part. In addition to Sines, we were also able to receive a very clean Radio Kuwait transmission originating from Sulalbiyah, on
13620 at around 1200-1300 UT in Arabic. The transmitter power is not stated, but the audio was fairly easy to decode, given that
the MSC is only 16-QAM. We were also able to receive the 35kW Voice of Russia transmission from Taldom in French on 12060 at
approximately 1700 UT. However, the audio was very irregular and was only decoded in fits and starts.
The best catch by far, was a 30-100W transmission of from Erlangen, Germany, on 15896 at around 1400 UT. The transmission is from
bit eXpress, which is apparently intended to be an on-campus transmission
from Friedrich-Alexander University in Erlangen-Nürnberg, Germany. bit eXpress makes full use of the four available content
streams in the DRM specification: "bit eXpress" (music and variety), "bit eXpress News", and two data
streams. The two audio portions are in Parametric Stereo (P-Stereo), and are streamed at a 27.28 kbps raw bit rate. The two data
portions consist of slide shows that are transmitted at a 4.08 kbps raw bit rate, called "bit visuAlity" and
Fraunhofer’s NewsService Journaline®. bit eXpress is listed as transmitting 24-hours a day. Given the low power, location,
and frequency of the broadcast we suspect that it's best received just after dawn on the East Coast of North America. This
reception window will shift to later times (e.g., as late as 20-23 UT) as the Summer approaches. The signal occasionally lifts
out of the noise during local daylight hours. However, this makes it hard for Dream to consistently obtain time and frame
Effects of Interference.
Throughout most of these experiments we have found the standard tenets of shortwave reception are more critical with DRM.
Typical analog broadcasts would be difficult to hear when the signal is just above the noise level, but potentially still very
intelligible. There is no noise or interference with decoded DRM audio. Either you hear it or you don't. This first seems to
require a signal with an SNR of between 10-15 dB, depending upon the encoding of the MSC. 16-QAM encoded signals with low raw
bit rates will be easier to decode than a standard 64-QAM channel, as we found with the Radio Kuwait broadcast. Some
synchronization may occur at levels as low as 5 dB SNR. This may also allow a few SDC packets to be captured, providing a nice
visual ID of the transmitting station and the content.
Another factor that seems to be much more critical with DRM is the amount of in-band and adjacent channel interference. When
listening to an analog signal, local carriers and other interference are merely an annoyance. They can be usually excised using
filtering and notching techniques. However, DRM is especially sensitive to these things. Interference can mean the difference
between hearing something and hearing nothing. Although the signal is spread 10 kHz wide, any narrow in-band or adjacent
carriers that are 5 dB above the DRM signal tend to disrupt the phasing that is required. This appears as a rippling effect on
the envelope of the signal's spectrum and creates intermodulation and an artificially induced selective fading. It disrupts
overall phasing and increases the apparent delay of the received signal. Dream will not decode any audio if it calculates that
greater than approximately 5ms of delay exists.
It is doubtful that anyone can do anything about in-band interference, since notching would also remove critical portions of the
data. As well, the position of the adjacent interferer is more critical in our ad hoc receiving equipment. First, we are
decoding the signal within the rolloff portion of the NRD-535D's AUX filter. Therefore, a carrier closer to the receiver's
center frequency would be much more disruptive than one further away. We have also found that interferers on that higher end of
the spectrum can be somewhat controlled by moving the NRD-535D's PBS closer to 0. This will attenuate the interference, but may
also disrupt the spectral balance of the signal's sidebands. Adjusting the PBS too close to 0 will cause one sideband to be much
lower than the other, decreasing the probability that it can be reliably decoded. We suspect that receivers that are designed (or
modified) for DRM, such as the TenTec RX-320D/350D and AOR 7030 use much better filtering for rejecting adjacent channel
01 Apr 2004
Improvements in Dream.
In the month and a half of experimenting with Dream, we have seen several marked improvements in the application. Volker
Fischer, one of the primary developers has been hard at work listening to comments from the users and making incremental
progress on a daily basis. In addition to several performance improvements, Volker has also added several user friendly
improvements as well. In addition to DRM, Dream also has a software-based AM demodulation feature, which allows you to tune a
normally modulated AM or SSB signal. This has been vastly improved by allowing you to "tune" to a peak in the
spectral display and select the appropriate mode and bandwidth. Also included is support for Fraunhofer’s NewsService
Journaline®. There is also a capability to start Dream as a transmitter, rather than a receiver, so that amateur radio
hobbyists can likewise experiment with the technology.
Volker has also included a DRM station selection window, which may be periodically updated from the DRM web site. The station
window allows you to see which stations are on at a given time and is automatically updated. Clicking on a station also allows
you to re-tune a select set of receivers: WinRadio G3, AOR 7030, or an Elektor 03/4. We have been working with Volker to also
add code for the JRC NRD-535D (using our tuning process above) and the TenTec RX-320D. Support for other DRM-compatible
receivers may follow.
With the assistance of VOA's Dr. Kim Elliot, we have demonstrated the use of Dream with the NRD-535D at the recent
SWL Winterfest on March 12-13 2004. We were able to set up next to another DRM
display, using the WinRadio with a built-in DRM capability. Although reception on the same antenna system was similar, there
were many instances where Dream decoded heavily faded signals, where the WinRadio would not. Since these applications are
heavily based in software, the power of the hosting computer system is a large factor. We were using a Gateway 400S laptop,
which uses a 2GHz Pentium 4 mobile processor and an ESS-1989 (Allegro) soundcard. The WinRadio setup may not have been as
Our success with both the Windows and Linux versions conclude that DRM can be decoded with a standard receiver that is capable
of wideband output. The TenTec RX-340 can be made to tune DRM signals using a procedure very similar to one we have been using
with the NRD-535D, which is openly advertised on their web site. Caution should be taken that this procedure may be only true
for the Dream software, which performs an integrated frequency shifting function. The DRM Software Radio firmly requires a 12kHz
IF output to operate properly. It does not include the extra frequency shifting, which requires more real-time processing power.
One of the recurring themes at the Winterfest was "how to save the shortwave listening hobby". The High Frequency (HF) spectrum
has surely come under a time of turbulence and constant transition. The end of the Cold War saw a change in the end of many
shortwave stations as Communist propaganda waned, countries "reorganized", and many stations left the air. Other
stations envision more cost effective means by which to get their message out as an alternative to shortwave. A case in point
is the recent departures of WSHB (formerly known as Monitor Radio) and Swiss Radio International. Other deterrents such as CODAR
and Broadband Over Power Lines (BPL) have certainly made shortwave listening (as a hobby) extremely challenging. There is also
the argument that streaming over the internet and satellite radio has made shortwave obsolete and a lot less technically
exciting. The BBC even used declining listenership as its argument when it decided to cease direct transmissions to North
America and Australia. The BBC was targeting "decision makers" rather than a small contingent of hobbyists.
There is no doubt that listenership is declining and the average age of die-hard shortwave listeners is increasing. All of these
facts point to an obvious conclusion: the hobby is dying because the media is dying. It is no longer a question of saving
shortwave listening as a hobby. We must first save the medium of HF Broadcasting or there will be no hobby. It is our belief
that in order to do this, shortwave must be made more attractive to a general audience. First, shortwave has to be listenable by
the average person. This not only means improved content, but also means that it also needs to sound like an average person's
FM radio. A common complaint by non-hobbyists is: "How can you listen to all that noise?" Second, it has to be made technically
exciting again. Today, radio in itself is bland and commonplace. Not many people really care where it comes from or how it got
there. The number of communications engineers (such as myself) have quickly become a number of software and computing engineers.
It is my firm belief that the technology of DRM solves a lot of these issues. It provides a method by which broadcasters and
listeners alike can enjoy quality reception. The sound provided by the new AAC/SBR encoding is as crisp and clear as an FM
station. More specifically, it is as good as streaming over the internet, but as receivers are built it will be more portable.
Because of the wideband nature of the technology, it also has the potential to be made less prone to adjacent and co-channel
interference from standard AM carrier channels. What has yet to be tested is interference from adjacent or co-channel DRM
transmissions. DRM is a new, cost effective, and truly exciting technology that is the "next big thing" in
communications. If developed carefully, it will surely be the technology that revitalizes the shortwave medium [and the hobby].
Further information about DRM and Dream can be found using all of the links provided in the above text. With the number of DRM
transmissions constantly changing, it is especially worthwhile to frequently check the
DRM Live Broadcast Schedule for any updated
09 Apr 2004
Experimenting with Other Unmodified Receivers.
Other DXers have similarly experimented with an unmodified receiver with varying amounts of success. Below is a list of the
tuning parameters that they used to receive DRM. If your receiver is not listed, please feel free to tell us how you did it.
We'll post it here.
|Settings for Other Receivers
||CW Offset (BFO)
|AOR 7030 (1)
|AOR 7030 (2)
||TenTec Web Site
DRM Visual Logbook.
All screen captures using GIMP in Linux:
Radio Netherlands via Flevo transmitter on 9850 at ~1230UT, 16-QAM/no SBR.
Deutsche Welle via Sines Portugal on 17710 at ~1145UT, reduced-rate 16-QAM/no SBR.
Deutsche Welle via Sines Portugal on 15440 at ~1200UT, 64-QAM/w SBR.
Deutsche Welle via Wertachtal on 3995 at ~0200UT, 16-QAM/no SBR.
Radio Kuwait via Sulaibiyah on 11675 at ~2315UT, 16-QAM/no SBR.
Sackville, Canada carries Vatican R, R Netherlands, R Canada Int'l, Deutsche Welle and R Sweden daily on 9800, 64-QAM/w SBR.
RTL via Junglinster Luxemborg on 6095 at ~2135UT, 16-QAM/no SBR.
VT Merlin test transmission to NAm via Rampisham England on 6040 at ~0210UT, 16-QAM/no SBR.
Radio Netherlands via Bonaire on 15525 at ~2245UT, 64-QAM/w SBR.
TDF via Issoudun on 15790 at ~1045UT, SM 64-QAM/w SBR.
TDPRadio via Sackville on 11900 at ~1600UT, SM 64-QAM/w SBR - P-Stereo!
HCJB via Quito Ecuador on 15375 at ~2330UT, SM 64-QAM/w SBR - P-Stereo!
FineWare is an independent entity, and has no relationship whatsoever with Fineware Systems, Inc.
Copyright © 2005, FineWare. All rights reserved.
Other products and trademarks are owned by their respective copyright holders.
We reserve the right to deny access to unauthorized web robots, spiders, harvesters, and other web agents that target and/or abuse this web site.
Last Updated: 17 November 2007.