Posts Tagged ‘KComm’
Spring is here!
Testing a new build of WSJTX for K1JT I hopped on to 10m and was surprised to see a strong signal. It soon revealed itself to be SM6NZV who gave me a +8dB report on my 5 watts.
This reminded me that it is May 1 today, the start of Spring and usually also the start of the Sporadic-E season. I tuned around on 6m and heard a couple of weak stations on my dipole, also a couple of stronger GMs working stations I could not hear.
I thought about installing the SDR-4+ as a panadapter for the K3 which had been one of the things I had intended to use it for. But something was amiss and I didn’t have control of the receiver’s frequency. I think the settings had got hosed, probably when I was playing around with using a USB DVB dongle as an SDR. I have no idea how to get it working again and I started getting stressed about it so I decided to abandon the idea.
SDRs are not for me, or at least not those that use a PC for a user interface. Windows is just too fragile, though if Linux is any better it’s only because there are fewer things to install on it in the first place!
Instead I will set up scanning on the K3 to scan a section of the 6m band. I always forget how to do this so I had to dig out the manual. Load the start frequency into VFO A and the end frequency in VFOB, make sure the mode and frequency are what you want and store it in a memory. I used memory 6 for 6m scanning.
To start a scan you just recall memory 6 (M>V, 6) and press and hold SCAN. I’ll probably forget that sequence of button presses as well so I looked up the CAT commands in the K3 Programmers Reference (SWT23;SWT29;SWH41;) and stored it in a KComm shortcut. I’ll probably make one for 2m as well though the chances of hearing any 2m Es up here are slim indeed. Last year I don’t think here was a single opening that extended this far north on 2m.
A PSK Core DLL mystery
The runaway success of the Elecraft KX3 has resulted in a sharp increase in the number of users of KComm. Even those who use a full-featured logging program in the shack find the simplicity of KComm and the compactness of its user interface (which was designed to fit a netbook) better suited to portable operating.
I received an email from a KComm user in Vienna, Wolfgang OE1MWW who wrote that he found the option to “Use PSK modem” (which uses AE4JY’s PSK Core DLL to operate PSK31 using the sound card) was disabled on his laptop running Windows XP SP3 though it was enabled on his desktop running Windows 7 64-bit. Wolfgang eventually found that replacing the file PSKCore.dll that was installed by KComm with one dowloaded from AE4JY’s website cured the problem.
I am surprised and a bit mystified as to why this occurred. My shack PC also runs Windows XP SP3 (I prefer to stay as far from the bleeding edge as possible) and it uses the same version of PSKCore.dll as is installed with KComm.
KComm’s version is much smaller so I’m hazarding a guess (since I can no longer remember) that it may have been compressed using UPX, an executable file compressor. I used to have a bit of a mania for compressing executable files so I could claim how small they were compared to certain other ham radio bloatware, but in these days of 100GB hard drives it’s probably rather fatuous. Possibly the compression caused an issue with some security software?
Whatever the reason, I’m grateful to Wolfgang for discovering a solution. I have added a note to KComm’s Troubleshooting page and updated the installer package to include AE4JY’s copy of the PSKCore.dll so hopefully new users will not encounter this problem.
Hamlib and virtual serial ports
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?
A periodic problem
I had an email from a KComm user from Russia today. He reported that when he clicks on a spot in the DX Cluster window the message “Invalid floating point operation” appears.
I guessed immediately what the cause of this was. It’s a problem that has been the bane of my life ever since I started programming as a hobby. In most of Europe the character used for the decimal point is a comma, not a dot (or period as our American friends say.) If your program is being used in a European country, adopts the correct regional settings and then reads some data expressed in the US or British way (such as the frequency in a DX Cluster spot) when it tries converting data to a binary floating point value it will come up with an error. If the European Union was actually any use you might think they would have standardized the representation of numbers by now, but hey…
If you are affected by this issue then a workaround is to use the Regional Settings in Control Panel to change the decimal separator to a dot instead of a comma. I’ve looked at the KComm source code and fixing the problem doesn’t look as if it is going to be easy so a solution may be a little while in coming.
A bug in KComm
Today started off with me continuing to compare the two morse decoders MRP40 and CW Skimmer in view of PC4T Paul’s insistence that the latter was the better morse decoder. When I heard someone calling CQ with no takers I took pity on them and returned their call. JY4NE and C6AKQ went into the log very quickly, in fact so quickly I was left wondering if I had actually worked them. Some people moan that all digital mode operators do is exchange macro files, but in a lot of CW QSOs you barely exchange anything!
Next I replied to a Russian station who was a bit more chatty. Unfortunately my logging program KComm locked up in mid-QSO. It was embarrassing because I was sending from the keyboard and didn’t even have a key plugged into the transceiver so I couldn’t continue. I’m sure there will be people who would add me to a blacklist for this, but these days I tend to treat CW as just another digital mode. Hence my interest in good decoder programs. 🙂
KComm has a feature where you can insert the answer to a multiple choice question into the outgoing text. It is expressed like this: %?question|answer 1|answer 2|answer3? which would cause a box to pop up saying “Question” and you click on the answer you want inserted. It was this feature that was causing the program to lock up.
After a couple of hours tracing code in the debugger I could not see what the error was, unless it was a bug in the Lazarus library software. The feature had been in KComm since many versions ago, but this current version was compiled with a new version of Lazarus, so that was a possible explanation. Eventually I managed to modify my program code to avoid the error, with the result that this afternoon there is now a version 2.02 of KComm.
I tested the update by having a QSO with Mik EW8O in Belarus. Then I decided it was time for a rest – I find debugging code these days is mentally exhausting!
KComm is 2.0!
I have taken advantage of the poor propagation conditions – the WSPR application waterfall has been blank all day and just two stations have spotted my 10m beacons, while APRS on 30m is only just beginning to receive any other stations – to make available a new version of my logging program for Elecraft transceivers, KComm, which is now version 2.0.
The main difference in the new version is that the Elecraft KX3 is supported (though it could be used in older versions by pretending it is a K3.) I have also added an option for specifying alternative URLs such as QRZCQ.com for looking-up callsigns, so you can now say goodbye to logging in to QRZ.com every five minutes if you want to.
The other changes are all minor bug fixes and small improvements that probably no-one will notice.
My regrets to Linux users but I no longer have a Linux system available so I cannot provide a Linux archive of the new version. I really need a Linux user to install Lazarus and compile the source code then send me a new tar.gz file to put on the web site.
Recently I downloaded the latest version of Lazarus, the rapid application development tool that uses Free Pascal. It’s a clone of Delphi but open source and cross platform. I’ve used it for hobby program development for the last few years, when I was no longer able to get free copies of Delphi. But now I actually prefer Lazarus to Delphi. It’s like how Delphi used to be.
|The Lazarus IDE|
In Lazarus I have been making a few changes to my logging program for Elecraft transceivers, KComm. Programming again marks another milestone in my return to normality, though in all honesty the time it takes and the number of stupid mistakes I make show that my brain still isn’t firing on all cylinders.
Why write my own logging program when there are so many good alternatives available? For one thing it is the same motivation that makes people build their own gear. For another, it allows me to use a program that works the way I want. If I want a certain feature then I get on and implement it. By limiting its use to the Elecraft community I avoid the troubles encountered by, say, the developers of Ham Radio Deluxe: the problem of dealing with thousands of users. There are probably only a handful of users of KComm, but that’s all right because I’m mainly developing it for my own use.
|KComm can speak Russian|
An example of what writing my own software allows me to do can be seen in the screenshot above. KComm supports user choice of character set for digital modes. So that if someone sends me a message in Russian (for instance) I can see what they sent (and copy and paste it into Google Translate, since I don’t speak Russian.)
This should not be taken as a sign that I will start writing new programs again. I’m just making a few changes to programs I use myself. I have downloaded the source code to the last released version of JT65-HF (which happens to have been developed in Lazarus too.) Perhaps one day I’ll see if I can make a few tweaks to that!