I had two projects this weekend, one involving microwave and the other involving HF. The microwave project is now firmly attached to the kitchen cabinet and works fine at reheating pizzas. The HF project took more doing. My goal was to set up my Softrock Lite II as a 30m reporting station for the reverse beacon network. I’ve found the RBN useful, and wanted a chance to participate in it from the server rather than the client end.
Last year, I put together a Softrock Lite II, a less than $20 kit that could be built for a single band. I built mine for the 30 meter band. I tried it out with a laptop and could resolve cw signals, but I realized that with a mono input, I would not be able to get any image rejection. The whole value of resolving the signal into quadrature components was lost. I tried using a Mac, which I knew had stereo input, but it was too much to expect this time-critical application to work well in emulation. In these attempts, I noted that there was a lot of noise around the local oscillator frequency, but I didn’t make much of it because there were so many competing issues. I did note that the noise was much better when the unit was run on battery, though.
In the interest of running more advanced sound modes on my aging laptops, I thought it would be helpful to buy an external sound card that would not load down the CPU. In searching for the sound card, I had in mind both the Soft Rock Lite II project and the future construction of a SoftRock Ensemble Transceiver that I had purchased as a kit last year.
I purchased an EMU 0204, an external USB “sound card” ADC/DAC that can take a left and right input and sample at up to 192 kHz. The card has been around for a while and is known to work well under WinXP with system requirements commensurate with the state of the art about five years ago. The laptop I had in mind was the nc6000 that I had salvaged a few months back. The machine has a Pentium M CPU clocked at 1.8 Ghz, 1.5 gigabytes of memory, and is running XP SP3. The machine came with USB 2.0 ports, which are required by the EMU 0204.
I plugged in the EMU 0204, loaded up the drivers, and downloaded updates from Creative Labs. The rear of the EMU 0204 has two inputs: the left input is a hybrid XLR microphone and quarter-inch TRS jack, the other is a quarter-inch TRS jack. The asymmetry of the ports looks odd, but the primary market is musicians, who are more likely to want to plug in a microphone and an instrument rather than the I and Q channel of an SDR radio.
There is a standard 1/4″ jack on the front for headphones, two line out jacks on the back for left and right out, and a 3.5mm stereo jack on the back for external speakers. I plugged some old powered computer speakers into that jack.
The Softrock was built with a stereo 3.5mm jack as output, so I put together a Y-cable that took the tip and ring and distributed it to the tip of a left channel and right channel quarter-inch plug. I had 3-terminal jacks and plugs on hand, so that is what I used. I expected everything to work right off, and of course, it didn’t.
I fired up the SDR program “Rocky” and set the input to the EMU 0204, with sample rate 48 kHz. What I saw was a huge bump in the middle of the spectrum, at the local oscillator frequency. Clicking on it produced horrible feedback. I did see some cw signals buried, but everything was mirrored around the center frequency, meaning I had no image reject, just as if I had only one signal going in. I recalled that running on battery had made things better the first time, and that did clear up some of the noise, but the image reject problem remained.
There is an LED for each channel on front of the EMU 0204, and it is green when the sound source is in a good range for sampling, red when there is too much overdrive and the signal is going into clip. Even with the EMU-0204 dialed up all the way, the signal was never strong enough to turn on the green lights. I thought this was strange, but maybe the Softrock just didn’t have a lot of output, or perhaps the band was legitimately quiet, and there wasn’t any signal in the first place.
I closed Rocky and fired up audacity, which showed some signal on the left channel, but low level on the right channel. Plugging into another source (like my ipad playing music) showed that the cabling was intact. I wondered if perhaps one of the channels was out on the softrock board. I was able to confirm that the local oscillator was working and that the divider was supplying clock pulses with the correct phasing to the mixer. All the voltages on ICs checked out, so I became suspicious of the transformer that takes an input signal at the antenna and picks up signal to feed to the I and Q channels. I pulled the transformer, rewound it, and stuck it back in. No change. I traced the signal as best I could, made sure all the surface mount capacitors were passing signal, and came to the conclusion that the softrock seemed to be fine.
Then it occurred to me that the EMU0204 is meant for professional sound work and that it was expected balanced inputs by default. But surely, a typical electric guitar isn’t a balanced input. Then I realized that the EMU must detect an unbalanced line by seeing continuity between sleeve and ring. I revised my Y-cable, and now everything worked fine: solid audio levels on both I and Q inputs, barely detectable signal artifact at the LO frequency on the spectral dislplay, and strong image rejection. I made sure that I got the right/left side matched up with I/Q by sending a test signal with the K3 on a dummy load, and saw the signal detected at approximately the right frequency. I saw only a hint of the signal on the other side of the LO, which was reasonable considering how strong the signal was.
Connecting the softrock to a power supply created hash, particularly near the center frequency. Not unexpectedly, it was worse on the SS30 switched power supply than the Astron RS-30 linear supply, but I was surprised it was an issue at all on the Astron. I wondered if the problem could related to a ground-loop (the softrock’s antenna is isolated, but audio out ground has continuity with power), but playing with the EMU ground pull-ups did not fix it. I may play around a bit more with the power input and see if some line filtering fixes it. I’m not sure what effect adding isolation transformers on the audio out would have in terms of increased impedance at higher frequencies needed for SDR decoding. Meanwhile, since the softrock pulls less than 30mA, I can run it off one of the rechargeable batteries in the shack just about until the heat death of the universe (rounding up).
Even with this set-up, I was not able to run with Rocky set to 96 kHz sampling. Trying to do so resulted in some stuttering. I also managed to crash rocky by going beyond the band edges in the waterfall display. I had a much better experience using CW skimmer, by the same author. Presumably, it is a later iteration built on the same code base, but it works much smoother. Without changing anything else in the set up, its waterfall was much cleaner, even without cutting in the noise blanker and key click suppressor.
For both Rocky and CW skimmer, one of the set up parameters is the local oscillator frequency. I had chosen 30m because I thought I might only be able to sample at 48 kHz with my original setup, and the band is only 50 kHz wide. Softrock uses a 13. 5 Mhz oscillator, which is divided down by four, and then the third harmonic, 10.125 Mhz becomes the center frequency, so I figured that 10.125+/-24 kHz would get me all but the edges of the band. While building the softrock, I sampled the crystal output as 13.497 Mhz using a lab grade HP counter, albeit one that hadn’t been calibrated in years. Similarly, I measured the divided frequency as the expected 3374 kHz. Both readings were confirmed by my freqmite. Consequently, I calculated the center frequency as 10.122 Mhz, and I entered this into the CW skimmer.
I let the skimmer go for a while, identifying stations in order to compare its frequency read out with others on the reverse beacon network. Noting that I was a few kHz off, I aligned my center frequency to 10,123,150 Hz to bring readings into line with other stations, who I assumed were more calibrated.
CW Skimmer has an integrated telnet server, with a default port of 7300. I set up the skimmer to send its readings to that port. I then sent over to the laptop that I use for contesting and launched N1MM. N1MM can import spots from packet or telnet and add them to the bandmap. I created a new telnet shortcut to the laptop running the skimmer, opened the telnet session, and was pleased to see that N1MM began correctly importing stations identified by the skimmer.
Going back to the skimmer computer, I downloaded the Reverse Beacon Network aggregator. To run it, I also had to download the Microsoft .NET 4.0 framework, which required a reboot. I unpacked the aggregator into the cw skimmer directory, as instructed and launched the skimmer. Next, I launched the aggregator. Setting up the aggregator was mostly intuitive, putting in my name, call sign, etc., but getting the skimmer to submit hits to the RBN required going back into the skimmer and checking the “Allow SKIMMER commands” box.
The aggregator talks to the cw skimmer on the localhosts’s port 7300, but makes data available to port 7550. I was able to re-establish a telnet session from the contest computer to the aggregator using that port, and the bandmap populated correctly.
At this point, I was able to see AI4SV listed as a skimmer station on the reverse beacon network search page. After letting the skimmer run for a while, I searched for stations reported by AI4SV (i.e., I set the “DE” to AI4SV) and got a list. I noticed that there was an annotation in the aggregator that my frequency spots had been adjusted by 0.1 Khz to correct for slight skew versus the majority of reporting stations.
Here’s what it looks like to be on the *other* side of the reverse beacon network: