AmateurRadio.com

There was not much life on 10m this morning but 15m was really hopping. I started off using PSK31 and my first QSO was with a Ukrainian YL named Olga! Her call was US5UFF and her QSL shows that she is (X)YL of UR4UHE. I think the UFF stands for Ukrainian Flora and Fauna which seems to be a popular award scheme over in Ukraine.

I was calling CQ and worked a whole string of east European and Russian stations. Calling CQ is a good way to fill the log but not a good way to work much DX as if any DX did reply it would likely be lost under the strong local stations calling.

As the hour approached lunch time I did some search and pouncing and managed to nab HS4ESF from Mahasarakham University in Thailand. I don’t think it’s the first time I have worked Thailand on PSK but it was nice nonetheless, and he has a nice QSL.

I’ve often noticed from my beacon monitoring that the time around midday to lunch time is a good time to work DX on the higher HF bands. I didn’t work any other DX today but I was pleased to see on Propagation Reporter that my 40W of PSK31 to an attic dipole had been decoded near Sydney in Australia! Perhaps I’ll work VK on PSK31 one day!

PSK31 spots of G4ILO on 15m

I tried JT65A briefly but the band segment was full of the same stations I could easily work using PSK31 so I thought I would try CW instead. I “shook hands” (as John N8ZYA puts it) with Z320K, a special call to commemorate 20 years of the Z3 prefix (Macedonia.)  I then had a real QSO with Bill, WA1HMW who is an ex-Royal Navy. That QSO taxed my receiving abilities a bit so I decided to call it a day.

I have found the solution to a problem that had been bugging me for ages: Omni-Rig did not work with JT65-HF. It was not a major bother for me as it could be worked around by the simple expedient of setting the frequency manually. But after an episode yesterday when I thought I was on 15m and was actually on 20m I decided to look at the issue again.

The solution turned out to be very simple and I stumbled across it by accident. You must start OmniRig before you start JT65-HF! That may seem obvious, but in fact other programs that use Omni-Rig manage to do so without it being run first. Which is why it never occurred to me to try that before. Doh!

Unfortunately the communication between the programs only works one way. JT65-HF can read the frequency from the rig using Omni-Rig but it can’t set it. As I have the JT65-HF source I took a quick look to see if I could fix the problem, but it would not be easy. A major discouragement to tinker with the source code is the fact that the newly-compiled program breaks the link between HT65-HF and JT-Alert. So I am not going to venture down that road. When it comes down to it I’d rather have my alerts than have rig control.

I was on 15m PSK31 and in the process of calling PY3ED when a vicious jamming signal started up.

Jamming on 21MHz

As you can see, it did a good job of obliterating all signals. It seemed to be centered around 21.070MHz and extended for 50kHz or so in either direction.

I don’t know how long it stayed on for because it was lunch time so I went to have something to eat. When I came back the interfering signal had gone.

Was it something local to me or has anyone else seen it?

Thanks to some excellent support from JT-Alert’s author, Laurie VK3AMA, I now have my alerts fully working and have gone back to JT65A with renewed vigour. I was getting a bit frustrated as many DX stations that I could decode clearly were not returning my calls. Is there something wrong with my setup? Perhaps it was just because it was the weekend and busier than usual so that others whom I couldn’t hear were replying to the same call and the DX couldn’t decode any of us. A few times the station I called replied to someone else.

I still managed to work several DX stations on 10m and 15m using 30 watts of power. Best contact of the day was with KC2WUF who said that he was running 3 watts to an attic dipole. (Actually he sent “3W ATIC DP” but I got the message!) It’s a pity I wasn’t running QRP this end as it would have been good to have a 2-way QRP QSO attic to attic!

CheckSR result at 48kHz with internal sound card

I have several radios connected to my shack PC. For the audio interfacing I have several sound cards or sound devices since most of them are not internal cards but use USB ports. I wanted to make sure the rig I mostly use for digimodes used the best sound card I had so I thought I would do some tests.

Some people believe it’s better to use a high end sound card for radio work. I don’t think there is any benefit for HF use as the noise level will be much higher than even the poorest sound card. There is no advantage to using a device capable of more than 48kHz sample rate unless you are using SDR software and need the extra bandwidth.

The one factor that can really made a difference is the accuracy of the sample rate. Most digimode software uses either 11025Hz or 48000Hz. There is no theoretical advantage to using a faster than 11025Hz rate for terrestrial digimodes. A 48kHz sample rate should not give any benefit and will need more CPU cycles to transfer and process the extra samples.

Sample rate accuracy is important because it affects both the pitch of playback and the data rate. It’s like playing an LP at the wrong speed. If you play a 33rpm LP at 45rpm the music is played at a higher pitch and a faster tempo. If played at a lower speed the sound is lower pitched and slower. This is analogous to what happens if the sample rate of your sound card is not exactly what your digimode software expects it to be.

I tested a number of sound devices using CheckSR.exe. This is a utility that is distributed with the MixW digimode software, but you can probably find it on its own if you Google it. To use it you simply select sound devices for input and output and set the sample rate you wish to test. You then run it until the measured sample rate settles on a stable figure.

I tested the Realtek sound cards built into my shack PC (HP) and a laptop (Dell) using both 11025Hz and 48000Hz sample rates. Both sound cards were as close to the specified sample rate as makes no difference.

CheckSR result at 11025Hz with USB device

I then tested a number of USB devices ranging from a $1 audio ‘dongle’ to a $10 model with surround sound and SP-DIF inputs and outputs. The drivers for these devices had names like ‘USB sound device’, ‘Generic USB sound device’ and  ‘USB headphone set’. These devices were also close to spot-on at 48000Hz.

But at 11025Hz every single USB device had a measured sample rate of 11100Hz – 1% faster than specified. This would make a 1kHz audio tone play at 1010Hz, whilst a 1200baud APRS packet would be transmitted at a rate of 1212baud. This error is more than enough to prevent decoding of an FSK packet signal. Other digimodes are also subject to sample rate errors. If you have ever seen a PSK or Olivia  signal that is strong and clear yet decodes as garbage, an incorrect sample rate (at one end or the other) is the reason.

I was surprised that the sample rate error at 11025Hz was consistent across all USB device samples. This suggests to me that the measured rate of 11100Hz is a factor of the drivers for these devices which may not run at the speed you select but instead resample down from a native speed of 48kHz. It would be interesting to see the results of running CheckSR on some branded USB devices or SignaLink USB interfaces that have their own drivers.

I ran some tests on USB devices at other sample rates. There was no consistency. At 8000Hz the measured rate was fast by a significant amount, but 16000Hz it was slower.

The results suggest that USB audio devices are only as good as internal sound cards if a 48000Hz sample rate is used. The use of lower sample rates with USB devices should be avoided.

If you have been following my attempts to set up beacon monitoring using a software defined radio (SDR) then you may remember that I had found that Omni-Rig, the radio control software used by Faros, the beacon monitoring software, would not talk to the virtual serial port created using VSPE in order to control the SDR-Radio software. I thought there was a problem with SDR-Radio’s emulation of the Kenwood control protocol. In fact, that turned out not to be the case at all.

A reader asked if I had tried DDUtil, a.k.a. VSP_Manager, a program by K5FR so I got hold of a copy. The instructions made my hair stand on end as it seemed very complicated. But I managed to set up a virtual port pair between COM8, the control port that SDR-Radio was using, and COM9 which would be used by Faros. VSP_Manager threw up a few error boxes but it still seemed to have done what I asked. I then tried setting up Omni-Rig. The first attempt failed, but I decided to try again as the help files actually showed VSP Manager being used with Omni-Rig and sure enough I had Faros changing bands and frequencies of SDR-Radio.

My joy was boundless, but not for long. I fell at the next hurdle which was using a Virtual Audio Cable (VAC) to pipe the audio from SDR-Radio into Faros. VAC also looked complicated to set up, but what I was attempting to do was the simplest application of it. I created a virtual audio port and set the SDR-Radio output to use it. As soon as I connected this to Faros’ input Faros began spitting out “divide by zero” message boxes so fast that I couldn’t close them quick enough to get back to the Settings window to change it back again. Another brick wall.

A separate issue was that of creating a serial port splitter to allow two applications to connect to physical port COM3 used by my Elecraft K3. VSPE could do that easily, but yesterday I discovered that WSPR would not talk to the virtual port created by VSPE. However, VSP_Manager does not seem to enable you to split a real port into a pair of virtual ones anyway, so I did not pursue this avenue any further.

If you are confused trying to follow all this you are not the only one! I have abandoned the idea of using an SDR for beacon monitoring and am breathing a sigh of relief that I never decided to go down the road of buying a Flex or other software defined transceiver. SDR will never catch on until connecting the software defined radio to logging programs or digimode software becomes as simple as plugging in a real cable.

Sometimes it seems as if half the posts in this blog relate to trouble with computers.

After I got back from the hospital today I thought I would try some WSPR for a change. Paul PC4T had mentioned that conditions on 80m were good. 80 is not a band I often use so I thought I’d try there. But no sooner than I had tried to change band than the software beeped rudely at me. The console window contained an error message: serial_open: Unable to open COM13 – Invalid argument.

COM13 is a virtual serial port splitter on COM3 which I’d created using Eterlogic’s Virtual Serial Port Emulator, VSPE. I’ve used this utility for years to create virtual serial ports so that more than one program can open my radios’ computer control ports at the same time. I’d used one to try out CW Skimmer with KComm before Christmas. As I’d uninstalled Skimmer I removed the virtual serial port. WSPR, which does its rig control through hamlib, then opened COM3 up just fine.

That’s a temporary solution, but I haven’t given up the idea of running other ham software alongside KComm for good. I think there are other serial port splitters out there (there’s com0com which was far too complicated for me to figure out) but VSPE has always worked for me until now. Don’t you just love computers?