Transmitting (and Receiving) DVB-T on 1.2 GHz

What interesting stuff can you do with a wideband software-defined transceiver? This question started bugging me when I got access at work to an N200 USRP with a WBX daughter board. The N200 is a DAC/ADC motherboard that can stream up to 50M samples per second to/from a computer using a gigabit Ethernet cable, and the WBX is an up/down converter that covers 50 to 2200 MHz. Together, they can receive and transmit signals with bandwidth of up to about 25 MHz almost anywhere in the VHF and UHF bands.

The coolest thing I could think of is to transmit digital television in a standard format that could hopefully be received by normal televisions, set-top boxes, and USB TV dongles. I almost succeeded, and this post tells the story. (For the impatient, here is the summary: I managed to transmit digital TV to a standard dongle, but in order to do this both legally and ethically, I had to hack its driver a bit; the video is jumpy, but it’s there.)

Standard and Frequency Selection

Choosing a digital video standard to transmit was easy. The on-the-air TV stations here transmit DVB-T (a widely-used standard for terrestrial digital TV), and I already had a DVB-T USB donble (which I used as an SDR receiver up to now), so the obvious choice was DVB-T.

Selecting a frequency to transmit is more of a problem, because the easy choice is not a good choice. Terrestrial digital TV is transmitted in VHF and low-UHF channels, from 50 to 862 MHz. DVB-T channels are 6, 7, or 8 MHz wide. The only amateur band within this range that is wide enough is the 430-440 MHz band, and it’s only 10MHz wide here; in other parts of the world it covers 420-450 MHz. If I transmit DVB-T within these 10 MHz, I will transmit over many other signals, including satellites, repeaters, and simplex channels, so this band is really not an option. The next band up is 1240-1300 MHz, which is both wide enough and almost completely unused here, except for some EME usage near 1296 MHz. So the choice is easy; I have to transmit at 1.2 GHz. But DVB-T receivers won’t tune that high, given that all of the channels are at 862 MHz or below, so it’s a choice with a problem.

Still, I knew that my DVB-T dongle can physically tune up to 1700 MHz (this is also true for many other dongles, and I image also for many set-top boxes and built-in tuners in TVs). So I decided to transmit at 1.2 GHz and to try to force the dongle to tune.

I thought that it would be easier to convince the dongle to receive at 1.2 GHz on Linux than on Windows. I managed to do it on Linux and it was not hard; I still don’t know if this is possible at all on Windows, and if it’s possible how difficult it is. But the main thing for now is that it’s manageable on Linux.

Preparing for DVB-T Reception on Linux

My dongle is based on the Realtek RTL2832U demodulator chip (and on the Elonics E4000 tuner chip). I wanted to use it on a computer running Ubuntu 12.04; the Linux kernel in Ubuntu 12.04 does not support this dongle. This turned out to be a blessing in disguise, however.

Hubert Lin’s blog shows how to install the driver on Ubuntu 12.04 (and using a somewhat different procedure, on 12.10). I tried to follow the instructions but the processed failed at some point. Fortunately, Chris Merrett packaged the driver in an easier to install format called DKMS, and he explained how to install it in a comment in Hubert’s blog. I followed the instructions and everything worked just fine. A DKMS driver is installed in a source-code format and this source code is compiled for every version of the kernel that you use. This turned out to be very useful. Installing the driver is very easy:

$ sudo apt-add-repository ppa:chrisfu/rt2832u-dkms
$ sudo apt-get update
$ sudo apt-get install rtl2832u-dkms

With the driver installed, I installed an Ubuntu package called dvbt-apps, which contains a necessary channel-enumeration utility, and I was ready to try receiving the local on-the-air DVB-T transmissions.

The process starts with a utility called scan. It takes a file containing tuning information for local stations and tries to tune the dongle to them. The station information includes the center frequency, the modulation format, and a bunch of parameters that specify how the transmission is encoded. A DVB-T transmission (station) can transmit multiple channels (simultaneous programs), and scan lists all the channels that it finds within the transmission. I found a file listing the parameters for the local transmissions (at 514 and 538 MHz, transmitting the same channels), ran scan, and it found about 5 TV channels and more than 10 radio stations within the transmissions. Here is the input file to scan (for Israel):

# Initial scan config for Israel
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T  538000000 8MHz 2/3 NONE QAM16 8k 1/32 AUTO
T  514000000 8MHz 2/3 NONE QAM16 8k 1/32 AUTO

The output looks like this (chopped here for conciseness; the first two programs are TV and the other two are radio):

Ch 1:538000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2561:2562:1
Ch 2:538000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2593:2594:2
...
88FM:538000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:2897:26
MUSICA:538000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:2913:27
...

Next, I ran the vlc video viewer, providing it with the file that scan produced. I was able to view TV. I also recorded the video+audio stream of one of the channels using vlc in a format called a transport stream in order to try to transmit it later.

Tuning the Dongle to 1.2 GHz

At this point I created a copy of the scan input file and changed the center frequency to a frequency in the 1.2 GHz band. Scan failed; it could not tune the dongle to this frequency. I knew that the dongle can physically tune that high so I assumed that some piece of software was aware of the allocation of DVB-T frequencies and did not allow tuning any higher. I tried various frequencies until I realized that the dongle tunes up to 862 MHz. I searched for this number in the sources of the driver and found one C file that contained the number 3 or 4 times. It was the value for a field called frequency_max in structures that describe the capabilities of the dongle for several digital TV formats, including DVB-T.

I changed the value from 862000000 to 1700000000 and tried to get the driver to re-compile. It took me a while to figure out that the correct process is to remove the driver entirely and then to rebuild and install it.

$  sudo dkms remove -m rtl2832u/3.0.1 --all
$  sudo dkms add -m rtl2832u -v 3.0.1
$  sudo dkms build -m rtl2832u -v 3.0.1
$  sudo dkms install -m rtl2832u -v 3.0.1

Now the dongle tuned to 1.2 GHz. Scan obviously did not find any transmissions there, but I was now ready to receive my transmissions.

If somebody can figure out how to get these dongles to tune to 1.2 GHz under Windows, please let me know.

Producing the DVB-T Baseband Signal

There are several software packages on the web that produce a DVB-T baseband signal from an MPEG stream. I used a package called gbDVB written by Giuseppe Baruffa. It comes in binary format only for Windows and Linux, and it can produce (and decode) DVB-T in pretty much any format and modulation. It is fast: it works faster than real time on my desktop (with an i7 processor). I used version 3.3; the latest is 3.4, but it requires a somewhat complicated registration procedure. I did register it, but on Windows, not Linux; I plan to register on Linux and upgrade.

Another option I considered is OpenDVB by Gordon Cichon, which comes in source form and is written in Matlab. It is somewhat harder to use. I plan to try it out in the future.

Before you can use either of them, you need an MPEG (video or audio) file in a format called a transport stream. I generated several of these, always using vlc, a viewer that can also write the movie to a file in various formats. To save a transport stream, I used

vlc movie --sout=file/ts:movie.ts

I called dvbtenco (part of gbDVB) with options that told it to generate a DVB-T transmission using the same format and modulation as the local broadcasts, which I knew work with my dongle.

gbdvb/dvbtenco -i movie.ts -M 16 -m 2k -d t -l movie.log -o movie

This command generates a file called movie.bin with complex baseband samples at a sampling rate of 9.142857 M samples/s. The USRP cannot transmit at that rate (it needs a rate that divides 100 M samples/s), so I used a simple gnuradio-companion program to upsample the signal to by a 70/64 to 10 M samples/s, using a rational resampler.

Putting it all Together

That was basically it. I used a USRP utility to tx_samples_from_file to transmit the 10 M samples/s baseband file at 1.2GHz (actually near 1.3) and I called scan with an input file telling it to look for a DVB-T transmission there. Scan found my USRP transmission and produced an ouput that allowed vlc to tune and display the video I transmitted!

Actually, the video was very jumpy. I think this happened because tx_samples_from_file did not manage to read the baseband file and to send it to the USRP quickly enough. I managed to improve things a bit by converting the baseband file from a floating-point representation (8 bytes per sample) to short integers (4 bytes per sample), but it was still jumpy. Maybe the disk is not fast enough. I’ll try to transmit with a 6MHz bandwidth rather than 8 and hopefully the sampling rate can be reduced, which will shrink the rate at which the samples need to be read from the file and sent to the USRP. I need to investigate.

As I wrote above, dvbtenco runs faster than real time on my desktop, so in theory, I may be able to transmit live video with this setup. But the gnuradio resampler is very slow; maybe I can optimize it and run the whole thing live. But the first step should be to transmit a video from a file without jumps.

Another thing that is still missing is an identification of the program that is being transmitted. This information needs to be multiplexed into the transport stream. I am trying to learn how to do that.

A High-Performance Sound-Card AX.25 Modem

My APRS RF-to-internet gateway (iGate) had been running  a sound-card modem called soundmodem by Thomas Sailer. The software modem caused various problems and I have not found a suitable replacement. Eventually, I decided to try to implement my own sound-card-based software modem. The results have been very good, in spite of the fact that I do not have much background in digital signal processing.

I’ve been using the modem for many months now in my iGate. The modem is run is a component of javAPRSsrvr, not as a separate program. It’s working reliable non-stop.

An article that I wrote for QEX explains how the modem works and how I designed and optimized it. It is also available on my university web site.

All-Mode VHF/UHF Reception with a Low-Cost TV Dongle

Balint Seeber’s new software supports not only the USRP, but also a range of low-cost USB dongles designed for receiving DVB-T television signals. When I read about this, I felt that I can’t not try one, so I ordered an ezcap dongle for $20 from a Chinese seller on eBay. It arrived a couple of days ago, and my experience so far is very positive.

The dongle I ordered was listed as an ezcap dongle, which is one of the models supported by Balint’s software. The dongle that arrived is exactly the one that was shown in the picture on eBay; inside, it was labeled as EzTV666. It came with a 15cm whip antenna, so I plugged in the antenna, plugged in the dongle, configured the driver using Zadig, and started up HDSDR. Balint’s library for the USRP and the TV dongles was already installed, so all I had to do is tell the software that I wanted to use a TV dongle and it worked without a problem. I didn’t have to install any new software.

I was immediately able to receive some local narrow-band FM traffic. I ran the dongle with a bandwidth of 1.6 MHz, so you can see a nice piece of spectrum on the screen at once. It goes up to 3.2 MHz, but Balint warns that high bandwidths cause some signal degradation. In the screenshot below you can see shorts bursts from a hand-held trancseiver at the input frequency of a local repeater and the repeater’s output 600 kHz higher. The repeater output bursts are longer because the repeater controller adds a “tail” to each transmission. It’s pretty neat to see both the input and the output of a repeater at the same time. The dongle’s frequency is a bit off, so the displayed frequency is incorrect (about 10 kHz too high), but this is easy to correct in HDSDR (Options -> ExtIO Frequency Options).

I installed the software that came with the dongle on another computer. Reception of local broadcast FM stations was good, but I was not able to receive DVB-T television signals, even with the bundled whip antenna outside the window.

Clearly, I needed better antennas if I was to receive more interesting stuff. To use better antennas, I needed some way of connecting them to the dongle. From the picture on eBay it was not easy to determine the type of RF connector used on the dongle; it did not seem to be the IEC 169-2 connector that is used in some of the other SDR-capable DVB-T dongles, but I didn’t know what it was. When the dongle arrived, I realized that the connector is an MCX connector. I didn’t have any cables with MCX connectors or any MCX adapters, so my initial thought was to cut the cable from the rather useless whip and terminate it with a BNC, but before I did that a friend gave me an MCX-to-N patch cable that he bought at a surplus store. That was good enough to connect any of my existing antennas, so I continued the experiments.

I first tried a 145 MHz dipole (1m end to end). It improved the reception of local UHF and VHF narrow-band FM dramatically, and it also worked very well for DVB-T (which is at 514 MHz here); I was able to watch TV on the computer. It also worked reasonably well for air-band signals. The next stage was to try to receive satellite signals. I experimented previously with a borrowed FUNcube dongle and I new that the FUNcube was very capable of receiving satellite signals. The FUNcube dongle uses the same tuner chip as the ezcap (an Elonics E4000, but its analog-to-digital converter is higher resolution than the ezcap’s; the FUNcube also has a low-noise preamplifier ahead of the tuner, and I am not sure if the ezcap uses one (if somebody knows, let me know).

A satellite called VO-52 was supposed to fly over last night, so I turned my cheap Yagi towards it and listened. Initially, I attached a preamplifier between the antenna and the dongle, but I later discovered that it did not make a huge difference. VO-52 has both a Morse beacon and a linear transponder. The beacon came through very clearly. In the screenshot on the right you can see the beacon’s signal move down in the audio passband due to Doppler shift. It it well above the noise and easy to hear. Next, I checked whether I can receive SSB signals in the transponder’s passband; I could. Here is a short recording of one Greek station (the Doppler shift causes the speaker’s voice to become lower over time).

While I was listening to VO-52, the local FM repeater sprang into activity. It is only about 100kHz away from the satellite’s signal; when the repeater was transmitting, it was causing pretty severe distortion of everything else the dongle was receiving. The satellite still came though, but not as well. You can see the effect in the screenshot on the right. I discovered that this was caused by too much gain in the preamplifier+dongle chain. There are two ways to solve this: to not use a preamplifier, or to drastically lower the gain of the dongle (you can set the gain with a slider).

The main benefit of the preamplifier in my setup is that it includes a good bandpass filter. Without the preamplifier, strong-out-of band signals sometimes overwhelm the dongle. With it, reception is much more consistent. But the dongle does work reasonably well even without anything between it and the antenna.

Another interesting thing that you can see in the last screenshot is the strong CTCSS tone coming out of the repeater, at 91.5 Hz. It is clearly visible in both the audio spectrum display and in the audio waterfall.

Using the USRP with HDSDR

Balint Seeber developed a software library that links HDSDR, a software-radio receiver program (and a few other related programs) with USRPs, a family of FPGA-based radios. I have a USRP1, the original USB-based motherboard, a BasicTX and a BasicRX daughter boards (which are basically just transformers linking the input coax connectors to the amplifiers that feed the ADCs), and an RFX400 transceiver (up/down converter to 400-500Mhz).

The USRP radios are best supported by GNU Radio, an open-source signal-processing toolkit. I have already used GNU Radio. The software is very capable, but it is somewhat difficult to install and it does not come with complete sophisticated radios. There are also drivers that interface USRPs to Matlab/Simulink; I was unable to get them to work. Therefore, I was delighted to learn that Seeber wrote the library that allows USRPs to be used with HDSDR and decided to give it a try.

HDSDR is a radio program that was derived from earlier programs (Winrad and WinradHD). It supports a wide range of RF frontends through the use of software libraries called ExtIOs. Seeber wrote an ExtIO library that can control the USRP and can transfer RF samples from it.

Downloading and installing Seeber’s ExtIO library and HDSDR was easy, thanks to an installer that Seeber wrote. Seeber’s software can also switch the USB-based USRP between two different drivers, which is a very useful (my experience in trying to switch these drivers manually has not been good).

After installation, I gave the software a quick try by tuning to a UHF and checking that the RFX400 can receive a signal from a handheld transceiver; it did.

I decided to try to USRP on HF next. I connected one of my amplified receiving loop antennas to a bias tee, then from there to a low-pass filter, and from it to the input of the BasicRX board. The low-pass filter is a high-quality 39 MHz surplus unit. It’s role is to eliminate aliasing of VHF signals into the HF spectrum. Ideally, the stopband should have started at 32 MHz (since the USRP samples at 64M samples/second), but a 39 MHz unit was all I had. I was not sure whether I would receive many signals, since between the BasicRX input and the input of the ADC there are only 20dB of amplification. In the picture you can see the USRP (in the background, in a cardboard box), the filter, the bias tee, and the 12V supply that feeds the bias tee. The USRP and the antenna are shown at the bottom of the post.

It turned out that this is sufficient to receive a great number of interesting signals all over MF and HF. Here are some screenshots. In the first screenshot I was listening to BBC World at 1323 kHz, an AM medium-frequency station. The USRP digitally down-converts the high-rate RF samples and decimates the RF samples, in this screenshot to 250k complex samples per second, so we see 250kHz of RF spectrum.

In the next screenshot, the radio is tuned to a station at the low end of the AM range, but the decimation is set to a lower value. We now see a full MHz of spectrum, all of the AM range plus a bit to spare. Very neat; all the AM stations on one waterfall display.

Next, we see the entire 14MHz amateur band. The band is densely populated at this early-evening hour. On the left we see a bunch of CW stations, PSK stations near 14070 kHz, and a large number of SSB stations starting at 14100 kHz.

I was able to receive distant stations all over the HF range, all the way up to 28 MHz. Here is the antenna I used; it is mounted fairly low in an urban area.

A few days later I tried UHF reception with the RFX400 daughter board. Local FM stations were received well. Satellites proved to be more of a challenge. I was not initially able to receive satellites with fairly weak signals like FO-29 and CO-58 (which I can hear reasonably well with the FT-857D), but I was able to receive the CW beacon of RS-22, as you can see in the following screenshot. The Doppler shift is clearly visible both in the RF waterfall display and in the audio waterfall. You can also see the very narrow signal in the audio spectrum display. The signal was received with my small VHF/UHF Yagi.

A second attempt to receive FO-29 was more successful. I was able to hear both SSB and CW signals clearly enough to understand them. Linking HDSDR to the satellite tracking program of Ham Radio Deluxe via DDE provided automatic Doppler correction, which worked out very nicely. Still, the RFX400 is probably not ideal for receiving UHF satellites. Its noise figure is not documented but I don’t think it’s particularly good, and its response rolls off below 440 MHz and above 460 MHz (as reported by Patrik Eliardsson and others). An external preamplifier would probably help.

Seeber’s library also supports a low-cost USB dongle that can sample RF signals between 64 and 1700 MHz. The dongle is sold as a digital-TV and radio receiver, but somebody discovered a way to cause it to send to the PC unprocessed RF samples, which can then be processed in programs like HDSDR and GNU Radio. I ordered a such dongle for about $20 from eBay and I’m looking forward to trying it out. Its analog-to-digital converter provides only 8 bits per sample, a lot less resolution than the much more expensive FUNcube dongle, but it supports much higher sampling rates than the FUNcube dongle.

Building an APRS Tracker

I’ve been running an APRS RF-to-internet gateway for a few months now. It uses javAPRSSrvr as the gateway program and soundmodem as a soundcard modem, both running on a remote Linux machine. Both programs are very reliable, running for months without a fault. I spent a bit of time trying to get the two programs to communicate over a virtual serial port, but this did not work, so I eventually switched to AX25 kernel-mode support, which worked out of the box on Ubuntu Linux.

I want to track myself using APRS, so I needed a tracker.There are several published hardware and software designs on the Internet, and I originally considered building a tracker based on one of these designs. But I eventually decided to build a tracker that is not based directly on any existing design. Mostly, I wanted to end up with a high-quality and flexible code that could be easily ported to different hardware platforms and to different uses. I’m not yet there, but I’ve got a working prototype that’s running my own code.

One thing I knew I wanted to do was to avoid a modem chip. Some APRS trackers and digipeaters use a modem chip, normally the mx614. A modem microcontroller would be able to produce and decode a 1200b/s AX25 signal in software. There are several trackers that do that already, like Gary Dion’s WhereAVR and Byonics‘ TinyTrak3 and TinyTrak4.

The prototype is running on an microcontroller development board that I use at work for teaching a course on embedded computing. It has an LPC2148 microcontroller, which has an ARM processor, and lots of on-board peripherals. The tracker currently uses almost none of the on-board peripherals except for the LCD screen. The board is connected to a GPS module and to a VHF radio. The GPS is a NEO-5Q module from ublox; it’s mounted on a board that also has a microcontroller and a bunch of other components (a prototype from an old wifi-based tracker project I participated in), but I’m only powering and using the GPS module on this board. The GPS is connected to an external active patch antenna. The radio I’m using is a Baofeng UV-3R, which I bought mainly for this purpose. It cost less than $50 including shipping, considerably cheaper than some dedicated VHF tracker transmitters. The radio is connected to the microcontroller through a little interface board that I built. Both this interface board and the GPS module are currently stuck into a breadboard, with wires connecting the microcontroller board to the breadboard.

The interface board performs 3 functions. It connects the DAC output of the microcontroller to the microphone input of the radio. This signal is routed through a trimmer resistor, to adjust modulation in the radio (it needs a much smaller amplitude than the DAC produces), and though a DC blocking capacitor. The board also routes the audio output of the radio to an ADC pin of the microcontroller, but I haven’t tested this yet. Finally, an open-collector NPN transistor switches the radio to transmit. I had some trouble with this transmit-receive switch: RF would get into the circuit and would keep the radio transmitting long after the microcontroller tried to turn the transistor off. I solved this with two 0.01μF decoupling capacitors on both the base and the collector of the switching transistor.

I used my own software drivers for the microcontroller (for it’s UARTs, DAC, etc.), but I used code from other APRS open-source projects for building up packets and for producing the audio output of the modem. I will release the software once it is more or less stable. I used three codes: Tracker2’s code by Scott Miller of Argent Data, the AX25 code in BeRTOS (a real-time operating system), and soundmodem. I have a lot of positive experience with soundmodem running on the Linux box, so hopefully it will work well on an embedded system. Fortunately, it uses fixed-point arithmetic, rather than floating point which is not supported in hardware on small microcontrollers, so it should work. But I have not tested the demodulator yet. The parts of soundmodem that I’m already using required quite a bit of hacking, unfortunately. I initially tried to keep the modem code as is, but I gave up after a while; the over structure does not work too well in an embedded setting.

I’ve been working on the tracker for a few days, and yesterday it got to the point where it was working on the bench: parsing GPS data, producing packets, and sending them to the radio. The packets were well-formed and my gateway decoded them (actually just some of them;  I’m not sure if the 2W signal from the radio was too weak, or the transmitted audio is not good for some reason). It was time to take the tracker for a ride. I took it to the car and hooked it to the cigarette-ligher’s socket. The LPC2148 board can be powered by up to 15V, and it can produces enough 3.3V power for the GPS, so I assumed everything would work. It did for a while (you can see some position spots in the aprs.fi map on the right), but after a few minutes the tracker started rebooting itself every second or so. I touched the regulators on the board and they were pretty warm, so I’m assuming that one of them overheated, shut down, and caused the system to reset. I guess I can’t power this unit directly from the car’s battery; I’ll need to drop the voltage with an off-board regulator first.

Next, I’m going to work on the AX25 demodulator, hopefully producing a tracker that can also decode packets.

HF Email using Winlink 2000

So far I’ve used three digital modes on the HF bands: PSK (mostly PSK31), WSPR, and JT65A. PSK is fun, in that you see signal phenomena in real time, and you see them both visually and in the ability or inability to decode the signal. If the signal fades, you see it fade; if two stations transmit on the same frequency, you can see that too. It allows you to chat with other stations and write whatever you want. But because PSK31 does not have any error correction or automatic acknowledgements, you sometimes receive only part of a transmission. To me, this feels low-tech. I expect digital transmissions to be almost perfect when communication is possible. PSK31 is not.

WSPR and JT65A incorporate strong error correcting codes, so transmissions are usually error free (not always, but almost). But neither of these is good at actually sending information. In WSPR the only information transmitted is station identification and location; you can’t say anything other than who and where you are. JT65A allows you to send a bit of free text, but it’s cumbersome; mostly, it’s also just for establishing the ability to communicate, not for actually communicating information.

Yesterday I finally succeeded in using another digital mode called WINMOR, which really feels like high-tech on HF. WINMOR is part of Winlink 2000, a system that is mostly designed to send and receive regular internet email through HF, VHF, and UHF radios.  It is used by radio amateurs, emergency organizations, and NGOs to communicate by email from places that do not have internet connections (like yachts, jungles, etc.). Winlink initially used an HF digital mode called PACTOR, which is very adaptive and efficient. PACTOR requires a dedicated hardware modem; the protocol is proprietary and the modems are expensive. A couple years ago Rick Muething designed WINMOR, an HF sound-card protocol for Winlink 2000 (on VHF and UHF Winlink uses AX25). I downloaded the software a while back but didn’t manage to connect to an HF radio gateway, and forgot about it.

Yesterday I decided to give it another try. The software uses a propagation prediction program and a list of active gateways to suggest gateways that are likely reachable. I tried to connect to the one that was supposed to be best, in southern Russia (on 14MHz). I heard the gateway respond and got a message that I was connected, but when the software tried to deliver an email message I sent, the gateway failed to respond and the connection was broken. I tried a few times and gave up. I also tried gateways in the Netherlands and Germany, but they did not even respond to me. In the afternoon conditions on 14MHz seemed to have improved, so I tried again. It worked! I received the mail I sent myself via HF! I replied and connected again to the radio gateway, and the response was delivered to me over the radio. Very cool.

I was later able to also connect to the radio gateway in the Netherlands, and to upload position reports to Winlink 2000, not just email. The Winlink web site shows the position of all the stations that uploaded position reports recently, and you can also view all the recent positions of particular stations. It’s quite interesting; many stations upload position reports from the middle of the ocean, as you can see here.

Winlink and WINMOR are really interesting. They deliver a useful service. Most of the time, sending email via WiFi, cellular, or wired networks makes much more sense than sending email over HF or VHF radios. But in emergencies and when you’re in the middle of the ocean, Winlink is a really useful service.  The protocol is very sophisticated, but you can sort of see some of what it is doing. You hear and see acknowledgements, retransmissions, and other protocol actions. But the biggest difference between WINMOR and many other HF digital modes is that it is an all-or-nothing protocol; it either delivers the data perfectly with no errors, or it fails completely. You don’t get garbled text. This is how modern communication works.

It’s not easy to set up radio gateways; the Winlink 2000 folks want gateways to run continuously (24 hours a day, every day), so setting up a gateway is not something to just experiment with, like I did with WSPR and APRS.

But WINMOR also has a peer-to-peer mode that allows you to communicate outside the Winlink system; perhaps I’ll try that.

First Steps with GNU Radio

GNU Radio is a package of DSP building blocks for constructing software radios. It is also the support software for a range of radio front ends from Ettus Research. You can also use GNU Radio with other radio front ends; I was able to easily use it with a Softrock receiver.

These radio front ends are a modular system containing motherboards and daughter boards. The motherboards have high speed ADCs, high speed DACs, and an FPGA for high-speed DSP. In most cases the FPGA does relatively little (but at high sample rates): decimation and digital down conversion on receive, and digital up conversion and interpolation on transmit. The rest of the signal processing is done in software on a PC (some motherboards have an embedded PC running Linux). The daughter boards typically contain transceivers or receivers that move the baseband signals produces or consumed by the motherboard to higher frequencies. I have the oldest motherboard, a USRP1, and a few daughter boards: BasicTX and BasicRX, which are just transformers that allow you to access the baseband signals directly, and an RFX400, which is an old transceiver for 400-500MHz. Newer transceiver boards cover much wider frequency ranges. Obviously, GNU Radio contains signal blocks that transfer samples to/from the hardware front ends (actually there are two versions of these blocks; I used the newer ones, called UHD).

GNU Radio (the software) consists of three main parts. One is a library of signal processing blocks (filters, demodulators, etc) written in C++. The second part is Python wrappers for these blocks. The Python wrappers allow you to connect the DSP blocks into a signal flow graph in Python, which is easier than connecting them in C++. The third part is GNU Radio Companion (GRC), a graphical environment for constructing these signal flow graphs. It allows you to construct interesting and working radios visually, without writing a single line of code. Very cool.

First, you need to install GNU Radio. The software has many dependencies, so installing it is definitely not easy. I installed it several times, on both Linux and Wiindows. Each time, some of the software worked but some did not. I don’t bore you with all the details. What worked best eventually was installing on Windows using Josh Blum’s detailed instructions. Even after I completed the install, GRC would not start; a dialog box suggested that I need to set two environment variables, PYTHONPATH and LD_LIBRARY_PATH. This turned out to be misleading, because on Windows you need to set PATH, not LD_LIBRARY_PATH. Once I figured this out and how to set the variables (by digging the sources to see what they were supposed to point to), GRC worked.

There are some blocks (some important) that do not work or do not fully work under Windows: The WX GUI blocks (which many GNU Radio example codes use), and the audio source and sink. As far as I can tell, the audio source does not work at all. The audio sink does work, but you can’t specify an audio device (which is possible in Linux). Also, in the other set of GUI blocks, the Qt blocks (which Josh added to GNU Radio), the slider does not work, which is fairly annoying.

On Ubuntu Linux, you can install GNU Radio and GRC from existing packages, but then the installation contains neither the UHD driver and blocks nor the Qt blocks. I tried to live with this, but the WX blocks did not work well, so I switched to an alternative installation method. In this method, you run a script that installs everything. The script worked well for me, installing a version with both UHD and Qt support.

With the software installed, I started experimenting with GRC (I actually started by trying to run the Python examples that came with GNU Radio, but they did not work because of some problem with the WX GUI blocks, so I switched to GRC experiments). To get started, I mostly used the tutorials by Sharlene Katz and the GRC examples by Alexandru Csete. Sharlene’s examples use the old USRP driver, not UHD, and they use the WX GUI blocks, so I could not use them as it, but her tutorials were very helpful. Alexandru’s examples are available for both the old USRP driver and for UHD, so they were mostly usable as is.

Here is a simple SSB/CW receiver that uses a Softrock as a front end. There is no tuning control (I controlled the center frequency of the Softrock from another application), but the receiver works and I was able to hear some CW signals on 14MHz. I think that writing a controller that would be able to tune the Softrock should not be that hard (since another Python program, Quisk, already knows how to do that).

My second GRC radio is a bit more complex: a narrow-band FM transceiver. I use it with the RFX400 transceiver, connected to the 430-440MHz home built Yagi. I can hear many FM voice signals, some from quite a distance. I was also able to communicate with Avishay Ginzburg, who lives about 4km away. It’s not that far, but the RFX400 only puts out about 100mW. Avishay complained that my audio was pretty bad, but he was able to understand me. There is also some problem with switching from transmit back to receive which I still have to investigate. In theory, when the USRP has no outgoing samples to send, it switches off the transmitter in the daughter board, allowing the daughter board to receive from the same antenna connector. I stop the samples from going out during receive using a signal processing block called a valve. In practice, the transmitter sometimes stays on, preventing the receiver from functioning properly. I don’t know if it’s a bug in my GRC radio or a bug in the valve or on the UHD driver. Anyway, here is one version of this transceiver (I keep modifying it).

My next plan is to see if I can hear satellites using this radio. I’m basically waiting for a satellite pass with a strong signal that I can easily hear using the FT-875D; once I hear one, I’ll switch the antenna to this software radio and see if I can see the signal on the spectrum display and hear the audio.