KComm 1.6 released

This weekend I had hoped to mount my 2m Moxon beam on the rotator I recently bought. But on Saturday morning I was bending down and suddenly experienced a sharp pain at the base of my spine, which went down my left leg. This pain has been reluctant to go away. So I have spent the entire weekend horizontally polarized on the bed.


The weather has been fine which is not that common an occurrence in these parts, so it is particularly frustrating to be kept indoors. I hate being confined to bed as I get bored very quickly. Fortunately it is not a complete waste of time because I have a laptop bed rest something like the one shown on the left, so I can at least use a computer and go on the Internet. I can access the shack computer using Remote Desktop and work datamodes if I want. But instead of that I decided to use the time to update all the KComm online documentation and make a public release of KComm 1.6, my Elecraft K2 and K3 logging program.

It has been over six months since I released the last version, so I have somewhat lost track of all the changes. The main changes I can think of are:

• Can now use Fldigi as a datamodes engine, controlled through KComm user interface;
• Can use MRP40 Morse decoder;
• Built-in support to use Griffin PowerMate USB knob;
• Can now send spots from DX Cluster client;
• Now supports JUMA TRX2 native command protocol;
• Can now import data to log in ADIF format;
• Window size now a netbook-friendly 600px height;
• Numerous bug-fixes and small changes.

KComm probably won't be of much interest to many other people even if they are Elecraft (or JUMA) users, and it isn't intended to be. It is something I wrote primarily for my own use. It does exactly what I want, and that's the whole point of it. If anyone else finds it useful too, that's just a bonus.

JUMA goes home

Last night I had an email from Gerd, DF9TS, who had returned from his business trip and wanted to know if I had managed to finish my evaluation of the JUMA TRX2 transceiver, and was I planning to keep it. I told him that I had enjoyed trying it out, I really liked the sound of the receiver, but I found numerous little annoyances with it.

The filtering is not very flexible, with only three filter widths for all modes. And with the lower filter edge fixed in position, you can't choose the centre frequency for CW or data. Although the receiver has been designed to give exceptionally high dynamic range, the AGC can't be turned off, so you still lose a weak signal that's close to a strong one.

No provision was made for data modes in the original design, and although the JUMA community is developing mods to provide this facility, it is still a bit of a kludge, as it was for the Elecraft K2 (which at least had the excuse that it was designed in 1998 before sound card data modes took off in popularity.) There are also questions as to whether the PA and driver components are adequately heat-sinked for high duty cycle operation such as data modes.

Gerd probably sensed that I was a bit luke-warm about the JUMA, and replied that I should feel under no obligation to keep the radio if I didn't really want it. During successful QRP /P operations while on his trip, he had changed his mind about buying an FT897 which had been his reason for wanting to sell the JUMA in ther first place. So I have decided to send it back to him. I will, of course, pay for the cost of sending it to me in the first place.

I am very glad to have had the opportunity to try the JUMA TRX2. It is still a very nice radio, especially if you are an SSB user (or even CW, if you can adapt to having a spot frequency of 400Hz to get the narrowest filter.) But I am spoiled with the K3, plus too many other QRP radios, for it to be worth buying given the shortcomings I mentioned.

Clean bill of health

I'm glad to say that Dr. Web gave my shack PC a clean bill of health after the scare over the JUMA web server virus attack. Hopefully everyone else who visited the site also avoided infection.

JUMA server virus alert

I just received an email from the webmaster of the JUMA website, informing me that their web server had been hacked some time on Monday 20th April and some files had been infected by a virus.

To say that I was displeased was an understatement. Most of the computers in our house run Linux, precisely for the avoidance of such troubles. But the shack PC runs Windows - after a determined attempt to use Linux - because Windows has so much better options for ham radio and related software. What's more, I don't run any anti-virus software on it, because it's not a very powerful computer and anti-virus software slows it down far too much. I never visit any of the usual disreputable sites, go in for file sharing or download illegal software, so I consider I'm pretty unlikely to get any malware.

I was also displeased because I have mentioned JUMA quite a bit in my blog during the last few days, with the result that many people will have visited the website, and possibly got infected, just because of me. Thanks, guys.

In order to see whether my computer had been infected, I thought I would try to install and run an on-demand virus scanner - one that would just sweep the hard drive and check everything once only, rather than one that sits eating up memory and CPU cycles all day long every day. But on-demand virus scanners are like hen's teeth these days.

First, I tried BitDefender Free. I was a bit unhappy that it required my email address in order to get a download link. It took ages to install, ran like a slug, and required me to create an account giving loads of details before it would update itself with the latest virus definitions. So I deleted it without even getting as far as scanning my hard drive.

Now I have downloaded, and am currently running, Dr. Web CureIt!, a free utility from the well-known (but not quite as well-known as Kaspersky) Russian anti-virus company. It's running at the moment, using very little memory and making no significant difference to the computer's performance at all. If it finds anything, I'll let you know.

Oh, hum

Yesterday evening I left the Juma TRX2 connected up to my MFJ magnetic loop logging PSK31 spots to Propagation Reporter. This morning I switched to 20m and re-tuned the loop to 14.070MHz and saw some clear vertical lines at 100Hz intervals on the waterfall.


My first thought was "mains hum". I am not using transformer-isolated audio connections from the radio to the computer, though the truth is, I never have done so in 10 years of data modes operation, and the only time I did use an isolated interface it actually caused hum due to the laptop computer "floating", having no ground connection through its power supply.

I de-tuned the loop so I could see the hum lines more clearly and was surprised to find that they reduced in intensity along with the signal. They were definitely audio-derived, though. When I moved the Juma VFO the PSK signal traces snaked about but the thin hum lines stayed put.

I hadn't noticed these hum lines on 30m. It appears that they peak up when the magnetic loop is tuned to 20m. But only on the Juma. When I connect the loop to my Elecraft K3, these lines are not present. And when I connect the multiband dipole to the Juma, they are not present either. So the MFJ loop is somehow picking up strong mains hum when tuned to 20m.

I tried grounding the Juma (which doesn't have a ground terminal) but it didn't make any difference. So I'm somewhat stumped at the moment. I know the Juma TRX2 is a direct conversion receiver. And I vaguely recall reading that direct conversion receivers can suffer from hum problems. But I don't know any more than that. Finding out why is one more item to go on my frighteningly long ham radio "to do" list.

KComm does JUMA

I have just finished adding support for the JUMA TRX2 transceiver to my logging program KComm. This will be available in the next version, 1.6, which will probably be released in the next couple of weeks. It really needs more testing to be sure everything is working as it should, as there are always issues that aren't immediately noticeable or problems that only occur when you do something you don't do very often.

I ordered a new USB to serial port adapter at the weekend after I experienced problems communicating with the JUMA using the ones I had. The new adapter arrived today. This one uses the FTDI chipset, rather than the Prolific chipset used by the other two adapters. I can report that this adapter works perfectly with the JUMA and both KComm and Fldigi. Unfortunately I notice a slight increase in noise in the JUMA receiver when the computer is connected to the radio using this adapter. I didn't check for this when using the other adapter or the real serial port, so I'm not sure at this point if it is an issue with this particular adapter or not.

Darned computers, sometimes I think they are really more trouble than they are worth!

Serial killer

USB killed the serial port. Unfortunately it has not left us with a satisfactory replacement for communicating with radios. USB to serial adapters just don't work, plain and simple.

I have just finished developing a RigCat rig control file for the Juma TRX2 and Fldigi. If you should happen to want it, you can download it from here. (You'll probably have to right-click the link and do a Save As... or your browser will try to read it.) The file requires the TRX2 firmware version 1.06 which is unreleased as of this moment.

As with anything to do with computers, this was much harder to accomplish than you would imagine. The reason being that communication between Fldigi and the TRX2 was not working properly.

Now remember, this was a serial connection that I had used to successfully update the firmware in the radio three times, so I had reasonable expectations of it working. I had an inkling that there could be a problem when I couldn't use HyperTerminal to send commands to the radio manually. However, another terminal program, RealTerm, communicated with it just fine - although it did report that there were "UART framing errors", whatever they are. RealTerm, incidentally, is a much better tool for debugging serial communications problems than HyperTerminal.

Fldigi has a debugging mode that can be useful when problems like this occur. You just run it from a command line and add the switch "--debug-level 9". On closing a status log will be written to its data file in \Documents and Settings\user\fldigi.files. Unfortunately this file doesn't have standard newline characters so it is hard to read in Notepad. I used a programmer's editor. From this I could see that what was coming back from the TRX2 was not what was expected, and not what I was getting back when RealTerm was used either.

In the end I had no alternative but to disconnect my K3 from my one real serial port in order to try that. Everything then worked perfectly. I stole the sound card interface cables from the K3 as well (which is probably now feeling rather unloved and neglected) plugged them straight into the TRX2 and made a couple of PSK31 contacts into Russia using 4 watts output. Hurrah!

So there you have it. It's now possible to use the Juma TRX2 with Fldigi. As long as your computer has a real serial port. I don't know how to make this work if you have a laptop.

But what I find really interesting is that I have proved pretty conclusively that whether or not a USB to serial adapter works depends on the application. Some will work fine, others will receive garbage. It isn't a very satisfactory state of affairs, and one that's almost guaranteed to result in yet more computer-created frustration.

Fast action from Finland

Yesterday I mentioned that I was trying to create a rig control file to enable Fldigi to work with the Juma TRX2 transceiver. The Juma supports two control protocols. One is a small subset of the Yaesu FT-897 CAT protocol. The other is its own native TRX2 protocol. This provides some capabilities not available when the Yaesu protocol is used, such as the ability to set the receiver filter passband. But I noticed that the Juma protocol did not include a PTT command that could be used by software to put the transceiver into transmit. So any software that used this protocol would have to use the serial RTS or DTR signal for PTT control, and I would have to make up a special interface for it.

I mentioned this last night on the Juma forum, and a reply was posted a couple of hours later. I was not around to reply to it, but by the morning in my inbox was an email containing a new version of the firmware to test. Quick work!

One problem that has me scratching my head is that I can't send commands to the TRX2 manually using Windows HyperTerminal. The terminal displays output from the radio, but the radio does not appear to receive anything I type. I know that communication is working because I have updated the firmware three times now using the same serial cable. So to test the commands I had to use my work laptop which runs Linux.

New arrival

There's a new arrival in G4ILO's Shack, rather an unexpected one. It's a Juma TRX2 HF SSB/CW transceiver designed by OH2NLT and OH7SV and built by Gerd, DF9TS.


The Juma was a bit of an impulse acquisition. I was surfing the web looking at QRP transceiver kits and happened to come across the Juma website, which I had not heard of before. I was very interested in the TRX2, which seems very good value for money for us here in Europe, better than an Elecraft K2 to which it is broadly comparable. But I was put off building it by the fact that it is an SMT kit. There are a lot of SMT parts to solder!

However, I kept on thinking about the TRX2, and kept on going back to the site, browsing the wealth of information and photos of the transceiver, and reading through the forum. There I came across a posting from Gerd, DF9TS, who was advertising a TRX2A (that's the all-band version) ready built for less than the cost of an unbuilt kit!

To buy one ready built would really be cheating. In any case the post was about three weeks old. I thought that he would probably have sold it, but it wouldn't hurt to enquire. Well, he hadn't sold it, and what's more he offered to send it to me to evaluate on a try before I buy basis. That was an offer I couldn't refuse, and the result was that the transceiver was delivered to me this morning.

I am going to take some time trying it out and comparing it with my various other radios, but here are some initial impressions.

• The receiver sounds fabulous. There is a sweetness and clarity about the audio that reminds me of the tube based analogue radios of a few decades ago. It sounds even better than the K3, and it seems to hear weak signals just as well as the K3 does, too.
• There are quite a lot of birdies, many of which are not audible even with an antenna connected. They don't bother me, but some people seem to get very wound up about them.
  
• There are only three filters, common for both SSB and CW. They are not as flexible as those in the K3 or most other radios because the low side is fixed at 300Hz. This means that if you want a 400Hz CW filter the high side would be at 700Hz, so the tone frequency would have to be 500Hz.
• The sound even using the narrowest filter is much easier on the ears (without the harsh, 'ringing' sound) of those in the K3.
• SSB transmit audio sounds very nice with the speech processor switched out, but a bit gritty and distorted with it switched in. But conditions are poor at the moment and the TRX2 only produces 10W out, so the only SSB contacts I have made so far have needed to have the processor switched in.
• There is no DATA mode for sound card data operation, and no SSB VOX. Actually, I haven't even figured out how to connect the TRX2 up for data mode operation yet (I'm not sure if there is even a fixed level audio output.)
• The front panel is minimalistic, there are not many controls, but there is everything you need, making the TRX2 pleasingly easy to use.
• The connections make rather an excessive use of 3.5mm stereo jacks. The use of one for the front panel mic connector is particularly perverse. But at least they are cheap and do the job.
• Similar to the Elecraft K2, a lot of the functions of this radio are controlled by firmware. But unlike the K2 the firmware is open source and provided for download. You can compile it using the standard Microchip C compiler. I shall probably be having a go at this later.

I really like what I have found so far. The rig does need some setting up - the S meter is far too generous and the power metering also is a bit optimistic - but this is something I can do once I have finished just playing with it.

Watch this space. I'm sure I'll be writing more about the Juma TRX2.