WSPR Results with Two Different Sound Cards

I’ve been running WSPR non-stop for the past 3 weeks remotely on a Giada N3 computer connected to a Softrock Ensemble II RX. In the middle of the period, I switched from the Giada’s internal sound card to a 24-bit external USB sound card. WSPR was hopping the entire period between the 7, 10, and 14MHz bands. The antenna used was my wideband active loop.

To compare the two cards, I compared the log files two consecutive 1-week periods, one with the internal sound card and the other with the external card. The periods were February 7 to 14 and February 14 to 21.

The results suggest that the external card delivers better results, but not by a huge margin. The internal card collected 3148 spots in a week; the external card collected 3825. The vast majority of the spots are of European stations. The other spots include 89 from the US and 20 from Australia with the internal card, versus 117 and 38 with the external card.

The results are not completely scientific. Activity of transmitting stations might have been a bit different in the two weeks, and the level of interference might have been different (some major contests sometimes cause interference to WSPR, but I don’t think any took place during these two weeks). The weather might have played some role too, because the Si570 synthesizer drifts a bit with temperature, which can causes WSPR to search for signals at the wrong frequency if it’s very warm or very cold. Temperatures here have not been extreme enough to move WSPR completely off-band, but perhaps I lost some spots near the band edges. (I tried to run frequency calibration every half an hours or so, but the scheduling code does not work reliably yet.)

Still, I think that it’s safe to draw two qualitative conclusions: (1) the built-in internal card on the Giada N3 is not as good as a high-quality sound card, but (2) it’s quite usable nonetheless for WSPR and similar digital modes.

I was very happy to see the outdoor setup work non-stop for 3 weeks. Things did get quite hot at times, but it kept working. This morning it crashed around 10:30am. I am not sure why; maybe it overheated. I turned it back on and it’s working fine again. But I don’t think I’ll be able to leave the computer outside in the summer; it will get too hot. I’ll have to find an indoors place for the computer and radio.

Now that this experiment is over, I modified the remote setup slightly. A added a passive antenna splitter and a crystal-controlled 7MHz Softrock Lite II receiver. This receiver monitors the 7MHz band continuously, and the Ensemble II RX is hopping between the 3.5, 10, 14, 21, and 28MHz bands, running two copies of WSPR concurrently. Since this morning, I already collected spots on all of these bands, and from both receivers.

Adding PTT Activation to the Serial and Sound-Card Interface

One of the things I’d like to try soon is the JT65 digital mode. Like WSPR, it works even with very weak signals, but unlike WSPR, it allows two-way communication rather than beaconing. When trying out WSTJ, the program that runs JT65, I discovered that it switches the transceiver from receive to transmit modes using the DTR or RTS signals on a serial port, not using CAT commands (multi-byte commands through the serial port). JT65-HF, another program that supports JT65, does the same.

I therefore decided to add receive-transmit switching (PTT) to the serial/sound-card interface I hacked together for the FT-857D. I checked the DTR and RTS signals on the FT232R breakout board and discovered that both were active high, meaning that they are high most of the time, but when a program like WSPR or WSJT wants to transmit, it activates DTR or RTS, which brings them low, to near 0V. The PTT connection in the transceiver should be driven by an open-collector transistor (e.g., an NPN transistor with the collector connected to the PTT line and emitter to ground), and it’s easier to drive the transistor with an active-high logic signal. Fortunately, the maker of the FT232R, FTDI, makes available a utility called MProg that can configure these signals to active-high. I ran it, configured the chip, and the signals indeed got inverted. I added the NPN transistor to the strip board, it’s base connected to RTS via a 2.2kΩ transistor (PN2222). Now these programs can switch the transceiver to transmit using the RTS signal.

I didn’t have time to try JT65 yet (there’s a learning curve there), but I’m now ready, hardware wise.

A Simple Serial and Sound-Card Interface for the Yaesu FT-857D

I bought a new Yaesu FT-857D transceiver and needed a computer interface for it. Yesterday I put together a quick interface, which you can see in the picture. The serial interface to the transceiver (which is called a CAT interface) uses an FT232R USB-to-serial bridge chip on a breakout board (made by sparkfun). The audio connections are simply wired directly: the audio out and audio in lines of the transceiver are connected to two 3.5mm stereo jacks (but the audio is mono, not stereo). The jacks are salvaged ones from the motherboard of an old Apple eMac.

The stereo jacks have pins that won’t fit nicely on a prototyping board. They had a metal cover, so eventually I decided to solder their metal cans to a piece of scrap PCB. This held them in place, and I soldered the audio in/out wires to their pins, which now point to the sky.

The serial breakout board can be wired for either 3.3V or 5V logic. It was originally wired for 3.3V; I removed the solder bridge that configures it to 3.3V and soldered a wire between the VCCIO and VCC pins to configure it to 5V, which is the logic level of the FT-857D. I then secured it to the scrap PCB with screws and spacers.

Finding the 6-pin mini-DIN connector for the audio connection to the transceiver was easy; I just used the cable from an old PS/2 keyboard. The 8-pin mini-DIN connector for the serial CAT connection was harder to find. I ended up buying an antique serial cable made for an Apple IIc, which had the 8-pin mini-DIN on one side and a full size 5-pin DIN connector on the other. I cut out the 5-pin DIN connector and thought I was all set. It turned out that in both cables not all the pins of the mini-DIN connectors were connected. But luckily, all the connections I needed were wired. This includes the serial in and out lines, the audio in and out lines, and also the PTT line, which I have not yet used but I might. The 13.8V supply from the transceiver is also available, in case I want to power an accessory.

That’s about it. I soldered the wires coming from the transceiver to a piece of strip board that I soldered to the base PCB and connected the audio lines to the stereo jacks. I left the serial connections open, in case I made some mistake in figuring out which wire is which (13.8V applied to the FT232R would have killed it). I connected the transceiver and verified the voltages on coming out on the wires. The 13.8V was where it should have been, and the serial lines were pulled up to 5V. I connected the remaining wires, connected the laptop to the USB-to-serial bridge, and fired Ham-Radio Deluxe (HRD), the free and slick transceiver control program that I wanted to use. It worked! I then fired up DM780, the digital-modes program that comes with HRD and was pleased to see that the audio-in line indeed carried the signals I expected. DM780 decoded many PSK31 signals. The audio out line also worked fine.

It was pretty late in the evening, so I tried to contact stations using PSK31 on 7MHz, using the coax loop. The loop tunes fine on 7MHz, but is pretty inefficient there. One station heard me, but not well enough to make a contact. I switched to WSPR, received a few stations, and then tried to transmit. A station in Ukraine heard me immediately. This was the first time, I think, that this antenna transmitted on 7MHz.

This interface is not something that you would want to build if you had to buy the parts; the breakout board costs almost as much as a ready-made USB-to-serial cable with a connector specifically made for this transceiver. But I had all the parts at hand, and I wanted to connect the laptop to the transceiver as quickly as possible.

A final note: most of the sound-card interface designs I found on the web for both this transceiver and other ones used 1:1 audio isolation transformers. Many of the same designs make the serial connection without isolation, meaning that the radio ground is connected to the computer ground. Given that the grounds are already connected, I didn’t see any reason to use isolation on the audio paths, so I just wired the transceiver audio directly to the sound card. I also verified that my laptop ground is floating. That is, even when it is connected to the AC mains through its power supply, the DC connections of the power supply are isolated from the AC ground connector. An isolated interface is safer, but it would also require isolating the serial connection using opto isolators or RF isolators. Without the serial isolators, I think that the audio isolation is not useful.

Remote WSPR and Quisk on a Remote Nettop Computer

I’ve been trying for a while to get WSPR to work on a remote computer, and I finally managed to get the setup to work. The initial attempt was with an embedded PC, and it was not successful because of various problems that all resulted from the fact that its processor was old (an NSC SC1100 x86 processor). I tried again with a new small-form-factor PC (apparently they are called nettops), and this attempt succeeded.

I first experimented with a borrowed Giada N10 running Linux (Ubuntu 10.04). The owner already installed Linux, so all I had to do was to install WSPR and try it out. It worked without any serious problems; I installed the prerequisite software, downloaded the sources, and compiled it.

On the N10 I tried, Wifi networking did not work. I probed a bit and discovered that the wifi card is a USB card for which Ubuntu does not have built-in drivers. You can download a driver from the manufacturer’s web site and install it, but it’s a hassle. Also, I didn’t like the fact that it only had an internal wifi antenna with no connector for an external antenna. So instead of ordering an N10, I ordered a Giada N3, which is similar (dual core Atom 330 processor and Nvidia Ion graphics card), but has an external wifi antenna. The N3 is also a bigger (more than twice the thickness of the N10), but still small enough for my purposes. This turned out to be a good move, because the N3 has a wifi card that’s better supported on Linux. When I installed Ubuntu (from a USB stick that I prepared with UNetbootin), it detected the Ralink wifi card and installed a driver.

I installed WSPR on the N3 and tried out the installation with an external USB sound card. It worked right out of the box. I tried WSPR using the internal sound card, and it also worked. The only analog audio connectors on the N3 are headphones out and microphone in, so I connected the Softrock’s output to the microphone input. The fact that this works is not obvious, because on many computers the microphone input jack only supports mono, which means that the computer cannot demodulate the radio signals properly. But on the N3 the sound card’s microphone input is a stereo input, so it worked just fine. Internal sound cards are not always very good. I did not measure the sound card, but it can certainly decode WSPR signals (perhaps it fails on more signals than a high-end sound card; I didn’t check).

What type of sound card is it? ALSA, the Linux sound subsystem reports different card types in different programs. The ALSA utilities reports that it is an Nvidia ALC622. The ALC622 is a codec chip made by Realtek. It has 20-bit ADCs and DACs and supports sampling rates of up to 96ks/s. ALSA does support 96ks/s and the analog bandwidth is indeed around 96kHz (more on this later). In other places ALSA reports the audio card to be an Nvidia MCP79 or MCP7A. I guess that the analog interfaces indeed use the Realtek ALC662, and that the digital audio interfaces (HDMI and S/PDIF) might be part of the Nvidia chip.

Here is the Softrock (in it’s cool paper enclosure) hooked up to the N3.

The N3’s power consumption is specified as 23W, and it is powered by a 12V 5A power supply brick. A fan cools the N3; as far as I can tell, it’s on all the time, and it does not seem to slow down. It is fairly loud, which is annoying when you use the unit in a quiet room. It’s really unfortunate that the manufacturer did not do more to quiet down the unit; dissipating 23W should not require a noisy fan. And when you are not watching video or playing games, it probably consumes a lot less than 23W. Too bad, but for use as a remote computer it’s not that important.

As I was testing WSPR on the N3, I realized that I also need a software radio application that shows a wide spectrum in real time. On my Windows XP laptop, I use SDR-Radio for this purpose. I fire it up, wander between the bands, and check if I see any signal on the spectrum display. If something goes wrong, such as a missing power supply to the Softrock or the active antenna, I discover this very quickly. If I only rely on WSPR, it takes a long time to figure out that something is wrong; each receive cycle takes 2 minutes, and it does not necessarily receive something in the first 2-minute period. A real-time spectrum display is really useful.

SDR-Radio only works on Windows, and the same is true for Rocky. So I decided to give quisk a try. I never used it before, but I was able to download it and build it without any significant difficulties. Like WSPR, it is a Python program that also uses some C code that needs to be compiled. Unlike WSPR, you need to edit a configuration file; you can’t configure it using menus and dialogs. It’s less convenient, but James Ahlstrom, the author, provides many sample configuration files. When I ran quisk, it shows signals, but I quickly realized that it was not actually changing the Softrock’s frequency when I told the program to change bands. I just kept seeing the same signals. I modified the Python code that controls the Softrock to figure out what was going on, and eventually discovered that the code was not converting correctly the data that it was sending to the Softrock through the USB interface. I fixed the problem and quisk started to work fine. As I wrote above, the internal sound card supports 96ks/s sampling rate, which allows you to see almost 100kHz of radio spectrum simultaneously. This is very cool, and was a new experience for me (my USB sound card does not work well at 96ks/s, so I always use 48ks/s).

At this point, I had both WSPR and quisk working when the N3 was connected to a monitor. But the idea was to run the N3 remotely. So I switched to using these programs from another computer using ssh and X11 forwarding. Ssh (secure shell) allows you to log in to a Linux machine from another Linux machine or from Windows or a Mac. When you log in from another Linux machine, you can forward X11, the graphics environment, to the machine you are connecting from. I connected to the N3 from an Ubuntu installation running in a virtual computer (using the free VirtualBox) running under Windows XP on my laptop. I could run both WSPR and quisk on the N3 and see the graphical user interface on the Laptop’s screen. WSPR ran just fine, but quisk did not. When I was listening to a station, the audio stuttered. Initially I thought that the Atom CPU was not fast enough to perform the DSP in real time, but after thinking about this for a while I realized it might stutter because it fails to update the display fast enough through the X11 forwarding. I wrote to James asking for advice, and he replied that the quisk configuration file has an option that controls the display refresh rate, whose default is 7Hz. I slowed it down to 1Hz and then to 0.5Hz. The stuttering was gone, but I was still able to see stations on the spectrum display and to tune them.

Now that both WSPR and quisk were working when the computer was working without a monitor, I moved it and the Softrock to a box on the roof. The box has power and an Ethernet connection. Having quisk really helped, because the first power supply I used for the Softrock did not work. The next one did, and everything was working. I am now WSPRing remotely. Here is a screen shot from the remote installation.

When you run these program with the graphical user interface, you need to maintain the ssh connection. I wanted to run WSPR for long periods when my laptop is not connected to the remote N3, so I hacked a version of WSPR that does not open any windows or dialogs. I run this version using screen, a Linux utility that allows you to disconnect from a command window (possibly running a program) and reconnect later. Very convenient.

Re-Crystaling a 10MHz Softrock Receiver

A few weeks ago I helped Nir Israeli diagnose a problem with his Softrock RXTX 6.2 transceiver. The transceiver is crystal controlled and covers portions of the 10MHz and 7MHz bands. While looking at the schematics I realized that Tony Park, the designer of the kit, used a 40.5MHz crystal to cover the 10MHz band. I had a partially built Softrock 6.2 receiver, and I decided to convert it to 10MHz using a 40.5MHz crystal that I ordered from GenesisRadio (along with 9 other crystals; they offer good frequency selection and low prices). The receiver is the “upgraded” version, which means it has lower noise and higher gain opamps than 6.2 receivers for lower frequencies. I only partially built it because I tried to use it with an Si570 synthesizer and a switched bandpass filter; this setup did not work so well.

I removed the components I added to the board for the experiment, wound the toroids for 10MHz, installed them, installed the oscillator circuit and the new crystal, and tried it out. It works very well with WSPR (it again took me a while to figure out the fiq setting, but I eventually got it right). I can now cover most of the 10MHz band with this unit. It joins the 7MHz receiver I used previously for WSPR, the 14MHz receiver (which unfortunately does not cover the WSPR sub-band), and the Si570-driven Ensemble II RX receiver.

The use of the 40.5MHz crystal should make the receiver more sensitive than the crystal that Tony Park ships with the kit, because the original 13.5MHz crystal relies on subharmonic sampling (it does not sample the radio signal at every cycle, but only once every 3 cycles). I did not compare them directly, however. I am not sure why Tony used the 40.5MHz crystals in transceivers but not in receivers.