AmateurRadio.com

Yes. Opera now has a QSO mode. I had to update KComm to allow the Opera contact to be logged, so I thought I’d add ROS for good measure. You never know. 🙂

eQSL still won’t accept the mode “Opera” as it hasn’t yet been added to the ADIF specification. It remains to be seen whether the mode catches on. It’s an obvious rival to JT65A but the JT mode has a lot more users. Opera is not time-synchronous and allows a bit more free-text flexibility.

By the way, have any of you Blogger users noticed that you can’t insert GIF images into blog posts any more? When I try, I just get an empty box. I have to save all my images as JPG which is not a very efficient format for screenshots.

I have just uploaded a minor update to the Windows version of KComm, my logging and digital modes program for Elecraft K2 and K3 transceivers. Version 1.91 now supports the ability to specify the receive and transmit sound devices using the device name rather than a number which Windows appeared to change at will.

I had been unable to find a way to get the sound card device names from Windows using Free Pascal and happened to mention this during a discussion in the Yahoo digital modes group about how so many sound card programs seemed to lose the sound card settings under newer versions of Windows. Patrick, F6CTE, who is the author of MultiPSK, very kindly responded with some Delphi Pascal code to list the installed sound devices. This has now been incorporated in KComm and makes sound card selection much easier – especially for me as I am always adding and removing USB audio devices on the shack computer which changes the numbering.

My grateful thanks to Patrick for his help with this little problem.

Today I released a new version of my logging and data communications program for Elecraft transceivers, KComm, on my website. The program is developed in Lazarus / Free Pascal and is released under the GPL.

Apart from numerous bug fixes and small improvements I have made in the months since the last release, the new version 1.9 allows the receive and transmit sound devices to be selected separately. This is something that is becoming increasingly necessary, though users will have to play “guess the device number” as I don’t know how to find out the names of the sound devices in Free Pascal in order to display them in a list box. The program also supports the K3 “TB” command which allows it to get the text decoded by the K3 DSP in CW, PSK or RTTY modes and display it on the screen just the same as if you were using a sound card program.

Although I have given up developing ham radio programs in general, I am continuing to update and maintain KComm as it is the only one of my programs that I continue to use regularly. However this will be the last version for which I will be able to provide a compiled Linux binary. The screen of the old Linux laptop that I used to compile it has almost failed so I will not in future have a computer on which I can do this.

Now that I have my K2 connected again for computer control I have found that a few things in KComm that worked with the K3 don’t work with the K2 because the control commands, though they may look the same, don’t all work the same way on both radios. So I spent yesterday evening fixing the problems.

One of the things that didn’t work was the auto-repeat option for CQ calling. I was testing it by sending a CQ on 30m with just 1W output into the magnetic loop in the attic. I didn’t expect anyone to come back to me, and no-one did, but I was surprised that my signal was spotted in Northern Spain by EA1GFY. The effectiveness of that magnetic loop antenna never fails to amaze me.

I don’t think many people use as little as 1W on PSK31 but it would be interesting to see what you could work with such low power. It seems to me that 1000 miles per watt should be perfectly achievable. I’ve made a few contacts using the K2 and 4 or 5 watts over similar distances to what I’d expect using the K3 and 40 watts. I think conditions, more than power, determine how far you can work. More power just makes it easier.

Last night for the first time in a very long time I operated RTTY. I made ten contacts in the BARTG RTTY 75 contest. The reason was that Elecraft had released a beta version of firmware for the K3 that enhances the built-in DSP modems to support the 75baud RTTY mode that was being used in the contest. Now that the K3 also supports a way to get decoded text into a computer program I thought it would be fun to give it a try.

For those unfamiliar with the K3, the transceiver boasts a built-in Morse decoder plus DSP based modems (encoders and decoders) for PSK31, standard 45.5baud RTTY and now 75baud RTTY. As the K3 doesn’t allow direct input from a keyboard, the usual way to use this facility is to send text using a Morse paddle and read received text on a scrolling 7-character window of the K3 display. However, using a program like KComm it is possible to send and receive text using software commands over the CAT interface as well. Since, like most things that require good motor skills, I’m hopeless with a paddle (or key) at anything much above 12wpm, that’s what I did.

I installed the new firmware and it decoded 75baud RTTY signals perfectly, so I waited for the contest to begin. After it did, I soon found that although people were hearing me they weren’t decoding me. I got lots of QRZ?, ??????? and SRI NO PRINT. I started to get frustrated and began thinking that RTTY is an obsolete mode that has no place in the 21st century because I know I could have made contact with these stations easily using PSK31 and a fraction of the power.

I decided to switch to soundcard mode and use Fldigi to try to make some contest contacts, and then found that people were replying to me on the first call! So clearly there was something wrong with the RTTY being generated by my K3.

This morning I tried receiving some of my transmitted RTTY using the FT-817 and Fldigi on my NC-10 netbook. When the RTTY was generated by Fldigi it was received perfectly. However when it was generated by the K3 I received gibberish unless I switched the K3 to REV DATA mode (i.e. reverse sideband.) Since I was receiving the RTTY perfectly OK using the normal sideband I presume that the K3’s transmitted RTTY was reversed. I have reported it to Wayne and await comments.

Unfortunately I did have some problems with KComm as well. After a while, it started aborting the transmission of any macro after the first few diddles. Like many programs, it has grown to the point where it is hard to understand what is going on any more and my interest in programming has fallen off a cliff in the last few months. I don’t know if I will ever get around to fixing the problems and releasing the final version. I do like using it, and KComm is the only program that really supports the K2 and K3 properly because it doesn’t treat them like a Kenwood TS2000 (whose command set it nominally shares) but was written to take account of the way these radios actually work.

QRZ.com has just announced that it will be making available an online logbook. It will also be offering an awards program and will be organizing a contest to recognize the first person to make confirmed contacts with 100 other QRZ users.

I like QRZ.com and think this is a great idea. I don’t know whether they will be providing an API for logging programs to post entries to the log in real time but if they do then I want my program KComm to support it so I have volunteered my services as a tester.