FineWare Main

[About FineWare]
[Frequently Asked Q's]
[Contacting FineWare]

[Smart Gnome Ctrl]
[Damned Viruses!]
[DRM Info]
[SCA Info]
[Vint Hill Farms Station]
[I Hate Snow!!!]
nothing
 

FineWare
Software Geared to the Shortwave Hobbyist

Experimenting with DRM

10 Feb 2004 (updated 01 Apr)

Background.
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
Frequency   center frequency +1 to +3.5kHz
Mode   CW
Bandwidth   AUX (12kHz)
AGC   Slow
Passband   -2000 Hz
CW Offset (BFO)   -5000 Hz

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 12kHz bandwidth.

Software Selection.
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:

Required Software Libraries
Library/Package   Windows   Linux
Dream   Source: http://sourceforge.net/projects/drm/
Pre-compiled: Dream.exe
  Source: http://sourceforge.net/projects/drm/
Qt v2.x   Source: QtWin230-NC
Pre-compiled: qt-mt230nc.dll
  Source: http://www.trolltech.com
(Qt v2 and v3 are built-in to Linux)
FFTW v2.1.x   Source: http://www.fftw.org
Pre-compiled: WinFFTWInst.zip
  Source: http://www.fftw.org or
fftw-2.1.4-fr1.src.rpm
Qwt Widgets v4.2.0   Source: http://qwt.sourceforge.net/
Pre-compiled: WinQWTInst.zip
  Source: http://qwt.sourceforge.net/
(Needs both the QWT and QWT-devel packages)
FreeImage v3.3.0   Source: http://freeimage.sourceforge.net/
Pre-compiled: WinFreeImageInst.zip
  Source: http://freeimage.sourceforge.net/
FAAD2 v2-Final   Source: http://faac.sourceforge.net/
Pre-compiled: None
  Source: http://faac.sourceforge.net/
NewsService Journaline®   Source: WinFhGJourLib.zip
Pre-compiled: WinFhGJourLib.zip
  Source: libjournaline-0.20040318-1.src.rpm
Hamlib   Source: http://hamlib.sourceforge.net/
Pre-compiled: hamlib-win32-1.2.1.zip
  Source: http://hamlib.sourceforge.net/

Building Dream.
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
   # 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
   # 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
   # make install

Journaline via bit eXpress

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
   [ 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
   # 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 building Dream.

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

bit eXpress via Dream

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

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.

Winterfest Demonstration.
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 powerful.

Conclusion.
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 transmission information.

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
Receiver   Provided by  
Tuning Offset
 
Mode
 
Filter
 
AGC
 
Passband
 
CW Offset (BFO)
AOR 7030 (1)   Guido Schotmans  
+5 kHz
 
CW
 
9.5 kHz
 
Slow
 
-4.2 kHz
 
0.0 kHz
AOR 7030 (2)   Guido Schotmans  
-5 kHz
 
CW
 
9.5 kHz
 
Slow
 
+4.2 kHz
 
0.0 kHz
Icom IC-R75   Mark Fine  
+3 kHz
 
RTTY
 
15/15 kHz
 
Slow
 
0.0 kHz
 
0.0 kHz
JRC NRD-525   Guido Schotmans  
+3 kHz
 
CW
 
(Tone CW)
 
Slow
 
(PBS CCW)
 
(BFO CCW)
Racal RA1792   Peter Thompson  
-4.7 kHz
 
CW
 
16 kHz
 
--
 
--
 
-8 kHz
TenTec RX340D   TenTec Web Site  
-12 kHz
 
--
 
16 kHz
 
--
 
+2.0 kHz
 
--

DRM Visual Logbook.
All screen captures using GIMP in Linux:

RNW Flevo on 9850 at ~1230
Radio Netherlands via Flevo transmitter on 9850 at ~1230UT, 16-QAM/no SBR.

DW Sines on 17710 at ~1145
Deutsche Welle via Sines Portugal on 17710 at ~1145UT, reduced-rate 16-QAM/no SBR.

DW Sines on 15440 at ~1200
Deutsche Welle via Sines Portugal on 15440 at ~1200UT, 64-QAM/w SBR.

DW Wertachtal on 3995 at ~0200
Deutsche Welle via Wertachtal on 3995 at ~0200UT, 16-QAM/no SBR.

R Kuwait on 11675 at ~2310
Radio Kuwait via Sulaibiyah on 11675 at ~2315UT, 16-QAM/no SBR.

Sackville, Canada on 9800 at ~2330
Sackville, Canada carries Vatican R, R Netherlands, R Canada Int'l, Deutsche Welle and R Sweden daily on 9800, 64-QAM/w SBR.

RTL Junglinster, Luxemborg on 6095 at ~2135
RTL via Junglinster Luxemborg on 6095 at ~2135UT, 16-QAM/no SBR.

Rampisham, England on 6040 at ~0210
VT Merlin test transmission to NAm via Rampisham England on 6040 at ~0210UT, 16-QAM/no SBR.

RNW Bonaire, Neth. Antilles on 15525 at ~2245
Radio Netherlands via Bonaire on 15525 at ~2245UT, 64-QAM/w SBR.

TDF Issoudun on 15790 at ~1045
TDF via Issoudun on 15790 at ~1045UT, SM 64-QAM/w SBR.

TDPRadio via Sackville on 11900 at 1600
TDPRadio via Sackville on 11900 at ~1600UT, SM 64-QAM/w SBR - P-Stereo!

HCJB via Quito Ecuador on 15375 at 2330
HCJB via Quito Ecuador on 15375 at ~2330UT, SM 64-QAM/w SBR - P-Stereo!

[Back to Main] [Up to Top]

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.

webmaster @ fineware-swl.com
Last Updated: 17 November 2007.