I have just made available version 2.1 of KComm for Windows, my logging and digimode program for Elecraft transceivers (K2, K3, KX3).
There are no major changes in this version. I have added a couple of modes (JT9 and DV) on the logging side, and fixed a handful of very minor bugs.
The latest Linux version remains at 2.03 until someone makes a new binary for 2.1.
Showing posts with label KComm. Show all posts
Showing posts with label KComm. Show all posts
Wednesday, May 01, 2013
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.
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.
Thursday, January 24, 2013
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.
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.
Monday, January 07, 2013
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?
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?
Saturday, December 15, 2012
A periodic problem
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.
Tuesday, December 11, 2012
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!
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!
Wednesday, November 14, 2012
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.
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.
Wednesday, September 12, 2012
Programming again
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.
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.
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!
 |
| The Lazarus IDE |
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 |
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!
Sunday, March 11, 2012
First HF Opera QSO
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.
Monday, November 29, 2010
Minor update for KComm
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.
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.
Wednesday, November 03, 2010
KComm updated
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.
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.
Tuesday, September 28, 2010
QRP spot
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.
Sunday, June 13, 2010
Back to front
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.
Friday, May 21, 2010
QRZ.com to offer logbook
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.
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.
Monday, February 15, 2010
Are there too many digital modes?
I have been thinking quite a lot recently about the various digital modes from the point of view of which ones are worth supporting in a program. My own software KComm developed for the Elecraft K2 and K3 supports only PSK natively, mainly due to the existence of AE4JY's PSK Core DLL which makes it easy to add PSK31/63/125 support to any Windows program. I can always use Fldigi or another program if I want to use other modes. But you get used to using a particular program and there is a certain challenge in adding support for other modes, which is why I have been spending time wondering whether it would be worthwhile to do so.
The more I think about it the more I tend to the conclusion that PSK31 is the only digital mode that is really worth bothering with. Its usage greatly exceeds everything else including, I suspect, RTTY. It has achieved 'critical mass' which means there are always new stations to work including exotic DX locations. This single point outweighs any of its disadvantages, such as the fact that the phase shift information gets messed up by disturbed paths, it's harder to set up to give a clean signal or that some MFSK modes such as Olivia that have redundancy and error correction are more reliable with weak signals. PSK31 is a narrow band mode and the benefit of that is often overlooked. I think things would be getting pretty ugly in the digital mode band segments right now if all the people who currently use PSK31 were instead trying to use much wider modes like RTTY, MFSK or Olivia.
RTTY. RTTY was the first digital mode I ever used, way back in the days before sound cards, so I have nothing personally against it. I suspect it is the second most popular digital mode after PSK31. I don't think RTTY use has died off, so much as it simply hasn't enjoyed the growth in popularity that PSK31 has. RTTY would be my main candidate for the next digital mode to support in my program. Except that in the last decade or so I have hardly ever felt any inclination to use it.
One reason is that RTTY is a grossly inefficient mode. It occupies a lot of bandwidth for its data rate, due to the fact that it was designed long before computers and DSP were invented and had to be decoded using an analog frequency discriminator. It has a limited character set geared to the Teletype devices it was meant to be used with, and requires a shift character to go between letters and numerals which adds to the likelihood of receiving gibberish if this character is not received whenever it is sent. Consequently RTTY users adopt the sledgehammer approach and run very high power to maximize their chances of good copy. RTTY really is an outmoded mode that has absolutely no advantages or benefits and instead of encouraging its continued use perhaps we should be persuading people to change to more modern alternatives.
MFSK. MFSK was developed by ZL1BPU and IZ8BLY in the early 2000's and I was an enthusiastic user and advocate of it for quite some time. MFSK16 seemed to give more reliable copy than PSK31 at the same power level. It also had a nice feature for exchanging small bitmap images, similar to SSTV. However in recent years it seems to have fallen out of favour and these days you rarely hear it.
Other multi-FSK modes have also come and (in most cases) gone, such as DominoEX, MT63 and Olivia. The benefits of all these different variations on MFSK escapes me, though I'm sure at least some of them do have benefits, however they have never caught on and would probably die out altogether if they did not live on as options in the menus of programs like HRD, Fldigi and MixW providing temptation for every new convert to digimodes to try them.
All these modes seem to achieve is confusion and a proliferation of "What's this mode?" threads on QRZ.com. There just aren't enough users to make many contacts with them, and anyone calling CQ using one of these modes is heading for disappointment unless they happen to be spotted by a PSK31 user who manages to guess what mode it is and takes pity on the poor caller. These modes should really be consigned to the bit bucket of history.
JT65A. A mode currently enjoying a surge of popularity on HF is JT65A, thanks in part to the easy to use JT65-HF software written by W6CQZ. I tried this myself recently and made a couple of contacts before starting to wonder what was the point of it? As Wikipedia explains it, JT65A was developed to allow contacts to be made over slowly varying paths where signals are expected to be weak, such as EME or long distance troposcatter contacts on VHF. Such contacts are likely to be prearranged skeds over paths where no other mode except high power CW is likely to make it.
However the use of this mode to make random contacts on HF seems pointless. People frequently seem to be making contacts when signals are strong enough that the contact could be completed more quickly, with the exchange of a lot more information, using PSK31 or one of the other digimodes. Signals on HF tend to vary quite a bit, so that even if they are very weak some of the time there are periods when they are strong enough to support "regular" modes. Do the problems that JT65A was designed to overcome actually occur on HF? I don't think so.
Conclusion. The conclusion I came to after the ponderings I have tried to summarize above is that PSK31 is really the only digital mode worth supporting if the aim is to make the maximum number of contacts. RTTY would be worth supporting for legacy reasons because it is still quite popular, although nowadays it seems to be little used outside of contests. From a technical perspective RTTY is arguably a mode that ought to be phased out.
The other modes I listed - and some that I haven't - are so esoteric that that they are not worth bothering with because there isn't a critical mass of users to ensure a good number of contacts. These modes may be interesting to try out, but as such they ought to remain within the realm of their own specialized programs - much like the original IZ8BLY Stream MFSK software of a decade ago - so that users are forced to make a conscious decision to use these modes and hopefully find out a bit about the purpose behind them, instead of just picking them from a menu because they are there.
No doubt there will be many who read this far (if anyone reads this far!) who will disagree with my conclusions. But from now on I expect to stick exclusively to the PSK modes on the HF bands and stop worrying about the other twiddly noises I occasionally hear on the airwaves.
The more I think about it the more I tend to the conclusion that PSK31 is the only digital mode that is really worth bothering with. Its usage greatly exceeds everything else including, I suspect, RTTY. It has achieved 'critical mass' which means there are always new stations to work including exotic DX locations. This single point outweighs any of its disadvantages, such as the fact that the phase shift information gets messed up by disturbed paths, it's harder to set up to give a clean signal or that some MFSK modes such as Olivia that have redundancy and error correction are more reliable with weak signals. PSK31 is a narrow band mode and the benefit of that is often overlooked. I think things would be getting pretty ugly in the digital mode band segments right now if all the people who currently use PSK31 were instead trying to use much wider modes like RTTY, MFSK or Olivia.
RTTY. RTTY was the first digital mode I ever used, way back in the days before sound cards, so I have nothing personally against it. I suspect it is the second most popular digital mode after PSK31. I don't think RTTY use has died off, so much as it simply hasn't enjoyed the growth in popularity that PSK31 has. RTTY would be my main candidate for the next digital mode to support in my program. Except that in the last decade or so I have hardly ever felt any inclination to use it.
One reason is that RTTY is a grossly inefficient mode. It occupies a lot of bandwidth for its data rate, due to the fact that it was designed long before computers and DSP were invented and had to be decoded using an analog frequency discriminator. It has a limited character set geared to the Teletype devices it was meant to be used with, and requires a shift character to go between letters and numerals which adds to the likelihood of receiving gibberish if this character is not received whenever it is sent. Consequently RTTY users adopt the sledgehammer approach and run very high power to maximize their chances of good copy. RTTY really is an outmoded mode that has absolutely no advantages or benefits and instead of encouraging its continued use perhaps we should be persuading people to change to more modern alternatives.
MFSK. MFSK was developed by ZL1BPU and IZ8BLY in the early 2000's and I was an enthusiastic user and advocate of it for quite some time. MFSK16 seemed to give more reliable copy than PSK31 at the same power level. It also had a nice feature for exchanging small bitmap images, similar to SSTV. However in recent years it seems to have fallen out of favour and these days you rarely hear it.
Other multi-FSK modes have also come and (in most cases) gone, such as DominoEX, MT63 and Olivia. The benefits of all these different variations on MFSK escapes me, though I'm sure at least some of them do have benefits, however they have never caught on and would probably die out altogether if they did not live on as options in the menus of programs like HRD, Fldigi and MixW providing temptation for every new convert to digimodes to try them.
All these modes seem to achieve is confusion and a proliferation of "What's this mode?" threads on QRZ.com. There just aren't enough users to make many contacts with them, and anyone calling CQ using one of these modes is heading for disappointment unless they happen to be spotted by a PSK31 user who manages to guess what mode it is and takes pity on the poor caller. These modes should really be consigned to the bit bucket of history.
JT65A. A mode currently enjoying a surge of popularity on HF is JT65A, thanks in part to the easy to use JT65-HF software written by W6CQZ. I tried this myself recently and made a couple of contacts before starting to wonder what was the point of it? As Wikipedia explains it, JT65A was developed to allow contacts to be made over slowly varying paths where signals are expected to be weak, such as EME or long distance troposcatter contacts on VHF. Such contacts are likely to be prearranged skeds over paths where no other mode except high power CW is likely to make it.
However the use of this mode to make random contacts on HF seems pointless. People frequently seem to be making contacts when signals are strong enough that the contact could be completed more quickly, with the exchange of a lot more information, using PSK31 or one of the other digimodes. Signals on HF tend to vary quite a bit, so that even if they are very weak some of the time there are periods when they are strong enough to support "regular" modes. Do the problems that JT65A was designed to overcome actually occur on HF? I don't think so.
Conclusion. The conclusion I came to after the ponderings I have tried to summarize above is that PSK31 is really the only digital mode worth supporting if the aim is to make the maximum number of contacts. RTTY would be worth supporting for legacy reasons because it is still quite popular, although nowadays it seems to be little used outside of contests. From a technical perspective RTTY is arguably a mode that ought to be phased out.
The other modes I listed - and some that I haven't - are so esoteric that that they are not worth bothering with because there isn't a critical mass of users to ensure a good number of contacts. These modes may be interesting to try out, but as such they ought to remain within the realm of their own specialized programs - much like the original IZ8BLY Stream MFSK software of a decade ago - so that users are forced to make a conscious decision to use these modes and hopefully find out a bit about the purpose behind them, instead of just picking them from a menu because they are there.
No doubt there will be many who read this far (if anyone reads this far!) who will disagree with my conclusions. But from now on I expect to stick exclusively to the PSK modes on the HF bands and stop worrying about the other twiddly noises I occasionally hear on the airwaves.
Monday, December 14, 2009
DX on 20m
It doesn't take much to liven up the HF bands. An SSN of 14 and a flux of 76 and I heard (and worked) several US stations and an Indonesian.
I was monitoring on 14.070 with KComm's PSK Browser open and saw that I was decoding YC1FWO from Depok in Indonesia. I double-clicked on his call to put myself on his frequency. During the previous contact he mentioned that he was running 50W so I increased my power to match, and when he finished the QSO I called him. He came right back and we had a solid contact, my first on PSK31 with Indonesia. (I worked the country once before, a year ago, on CW during the CQ WW contest.)
Listening again after that contact was over I saw someone's station details scroll by and noted that they were using an Elecraft K3 like I was. It took a little while to get Paul NF8J from Alto, Michigan in the log. The first time I called, he replied to a German station whom I couldn't hear. I waited on frequency but an Italian, who possibly couldn't hear Paul, kept calling CQ on top of him. When he signed with the German I waited a little while for the other station to send his final goodbyes and then called. Another Italian station then called me! I called again and this time Paul came back to me and we had a nice contact that didn't just consist of macro exchanges.
A bit later on I heard Carl K4RH from Murfreesboro, Tennessee calling CQ DX. Again, the first time I called him he returned to someone else. While he was half way through sending their signal report a Spanish station kept calling him! When he finished the contact I called again. Carl heard the signal from my attic dipole and a short but solid contact was completed. I think Tennessee is a fairly rare state so I was pleased to work him.
I was monitoring on 14.070 with KComm's PSK Browser open and saw that I was decoding YC1FWO from Depok in Indonesia. I double-clicked on his call to put myself on his frequency. During the previous contact he mentioned that he was running 50W so I increased my power to match, and when he finished the QSO I called him. He came right back and we had a solid contact, my first on PSK31 with Indonesia. (I worked the country once before, a year ago, on CW during the CQ WW contest.)Listening again after that contact was over I saw someone's station details scroll by and noted that they were using an Elecraft K3 like I was. It took a little while to get Paul NF8J from Alto, Michigan in the log. The first time I called, he replied to a German station whom I couldn't hear. I waited on frequency but an Italian, who possibly couldn't hear Paul, kept calling CQ on top of him. When he signed with the German I waited a little while for the other station to send his final goodbyes and then called. Another Italian station then called me! I called again and this time Paul came back to me and we had a nice contact that didn't just consist of macro exchanges.
A bit later on I heard Carl K4RH from Murfreesboro, Tennessee calling CQ DX. Again, the first time I called him he returned to someone else. While he was half way through sending their signal report a Spanish station kept calling him! When he finished the contact I called again. Carl heard the signal from my attic dipole and a short but solid contact was completed. I think Tennessee is a fairly rare state so I was pleased to work him.
Monday, November 23, 2009
KComm 1.8 released
I have just released version 1.8 of my logging and digital modes software for Elecraft transceivers, KComm.
Although the new software is on the site, the tedious and boring job of updating the online documentation pages to reflect the changes will take a bit longer, so woe betide anyone who emails to point out that the screenshot and description on the help page doesn't match the software!
Although the new software is on the site, the tedious and boring job of updating the online documentation pages to reflect the changes will take a bit longer, so woe betide anyone who emails to point out that the screenshot and description on the help page doesn't match the software!
Sunday, November 15, 2009
OK OM
The OK/OM DX CW Contest has just finished. I made three contacts on 80m last night in half an hour between TV programmes, and a further 55 on 20m and 40m after breakfast this morning for a total of 2494 claimed points.
I have a particular affinity for this contest for no other reason than the Czech Republic is one of my favourite countries. As always for me with contests this was a "just for fun" entry working down each band and trying to contact each OK or OM station I found. I'm not going to win any awards but I won't be quite as close to the bottom of my category as last time.
KComm performed well, keying the K3 using the serial command protocol - the only logging program that is specifically designed to do this. It's not a dedicated contest logger but it is fine for this kind of operation. It warned me before I could make a duplicate contact, its generic statistics capability gave me the counts of contacts and multipliers so I could easily calculate my claimed score and it allowed me to export my log in the requested Cabrillo format.
Well that's enough radio for one weekend. After posting this I'm going to stay out of the shack for a bit.
I have a particular affinity for this contest for no other reason than the Czech Republic is one of my favourite countries. As always for me with contests this was a "just for fun" entry working down each band and trying to contact each OK or OM station I found. I'm not going to win any awards but I won't be quite as close to the bottom of my category as last time.
KComm performed well, keying the K3 using the serial command protocol - the only logging program that is specifically designed to do this. It's not a dedicated contest logger but it is fine for this kind of operation. It warned me before I could make a duplicate contact, its generic statistics capability gave me the counts of contacts and multipliers so I could easily calculate my claimed score and it allowed me to export my log in the requested Cabrillo format.Well that's enough radio for one weekend. After posting this I'm going to stay out of the shack for a bit.
Subscribe to:
Posts (Atom)