The lunatics have taken over the asylum

This is a repost  of a posting made in 2009. It is still as true today as it was then.

I received an email a couple of hours ago to tell me that the Windows setup file for VOAProp is reported as containing a trojan at VirusTotal, so I checked for myself. It's true. Thei nstaller is reported as containing a trojan by 8 out of 41 scanners none of which I have heard of or have any reason to take seriously.

I checked the original copy of the KComm setup file that I have here just in case my web site had been hacked and a trojan planted. But the result was the same. I also checked the downloads of a couple of other programs of mine including MorseGen and VOAProp. They produced virtually the same scan results as for KComm.

For years I have advised people that if they have downloaded a file from a source they would trust and their security software flags it as suspicious, they should scan it at VirusTotal to get a consensus of opinion as to whether the file really is a virus, a trojan or spyware, or just a false alarm. Unfortunately, VirusTotal has kept on adding new virus scanners to its armoury regardless of whether they are any good or not. The lunatics are taking over the asylum and as a result, VirusTotal has become useless as a tool for ordinary PC users to check whether a file is suspicious. I recommend jotti.org instead.

Some of my programs that are accused of containing a trojan were last updated several years ago. They have since been downloaded by hundreds or thousands of people. It is inconceivable that they could have contained a trojan that remained undetected all that time. The thing that all the programs have in common is that the installers were all created using the same setup generator. The likelihood is that somebody used the same setup generator to create an installer package for a trojan and the third rate scanners are picking up on something in the installer package that is not unique to the trojan.

I have no desire to waste my time contacting the developers of obscure anti-virus products to inform them about this false reporting of my programs. Nor do I have any plans to repackage all the programs using a different setup generator. I'm sorry, but third rate virus scanners are not my fault and I don't have the time or the inclination to deal with the problems they cause. If you choose to trust your virus scanner instead of me  I won't argue with you.

Some of the scanners are flagging the fact that the files have been compressed using UPX. This is a harmless tool used to make executable files smaller. It is not a malware. But I don't know how users of these scanners are supposed to know that.

Back to Firefox

Goodbye Chrome. It was fun while it lasted. But in the last day or so Google Chrome has become so crash-prone that it is unusable. Suggested solutions amounted to disabling plugins and add-ons but my installation was pretty basic apart from AdBlock. Nevertheless I took the step of uninstalling Chrome completely and then reinstalling again. But it still crashes. Just trying to sign in to Yahoo is enough to crash it.

So it's back to Firefox. I don't have time for flaky browsers.

Krun - a command line utility

Last week when I posted about using the new dual-mode version of WSJT-X I mentioned a utility I had used to put my Elecraft K3 into split mode before starting WSJT-X and returning it to normal operation after finishing. I've been asked to share information about it, so here you are.

The utility is called KRun, from K-Run. K for Elecraft radios (K2, K3 etc.) and Run because you use it to run another program. It was written to use with my Elecraft transceivers but I see no reason why it should not work with other radios that use a similar CAT command syntax such as Kenwoods. Don't ask me if it can  be used with your Yaesu or Icom radios because I know nothing at all about their command format.

If you run the utility it puts up a window listing its command line parameters.

These command line parameters are what tells KRun what you want it to do, so you'll need to know how to create a shortcut containing command line parameters, or use a batch file. You'll also need to know what CAT commands to use, which will require a degree of familiarity with the Programmer's Reference manual for your radio.

The parameters are:

• --com=n where n specifies the serial port used by your radio
• --baud=x where x os the baud rate to use
• --cmd=string specifying the string of CAT commands to send at startup
• --wait=s where s is an optional delay in seconds to give the commands time to execute
• --run="path" the path of the program (e.g. WSJTX) that you want to run
• --arg="args" optional command line parameters for the program specified above
• --ucmd=string optional CAT commands to send on closing

An example invocation is:

C:\Ham\krun\krun.exe --com=3 --cmd=FT1; --run=C:\Ham\WSJT-X2\wsjtx.exe --ucmd=FR0;

where:

• C:\Ham\krun\krun.exe is the location on my computer of the KRun utility
•  --com=3 specifies the com port to use
• --cmd=FT1; is the CAT command to set my K3 into split mode (with terminating semicolon)
• --run=C:\Ham\WSJT-X2\wsjtx.exe is the location on my computer of WSJT-X
• --ucmd=FR0; is the CAT command to cancel split mode (with terminating semicolon)

To create a shortcut to do this, first create a shortcut to KRun itself, then edit the Target to add the command line parameters as given above.

You can download KRun as a zip file which contains KRun.exe, the utility itself, and WSJTX, a shortcut configured as described above. If you try to use the provided shortcut instead of creating one from scratch yourself you will need to change the program paths to suit your own system.

So there you are. It works for me so hopefully it will work for you. If it doesn't then a better solution would be to persuade K1JT to add these CAT commands to WSJT-X!

Yet Another APRS Client

An apt title for this post, but also for the software in question. Yet Another APRS Client (YAAC from now on) is a new program written by Andrew, KA2DDO that has recently entered beta test status. I stumbled across it a few days ago and am now running it on my G4ILO-2 VHF iGate.

YAAC map display with US Geological Survey topographic data.)

YAAC is written in Java so it runs equally well on Windows, Mac and Linux platforms as long as you have a recent Java runtime installed.

YAAC is open source software and uses open source mapping (Open Street Map - OSM). APRSISCE does too, but whereas it uses bitmap tiles, YAAC uses vector-based map data. This makes the maps look a bit different (more as if they were drawn by a spider.) You can easily add topographical data from the US Geological Survey (the screenshot above shows this.) YAAC also supports the use of scanned-in maps but I haven't tried this.

YAAC is very easy to use. There is a wizard to help you set up the program, though there is also an expert mode that allows you to get to all the settings directly. There are far fewer things that can be changed than APRSIS32 has which is one reason it is easier to use, but YAAC's user interface is more standard. A File menu is on the left of the menu bar, Help on the right, and all the configuration settings are on a multi-tabbed dialog box not nested in three levels of menus. YAAC would be an ideal program for someone new to APRS, which is not to belittle the program in any way as it does all the things that most users would be perfectly happy with.

YAAC supports a wide range of TNCs including TNC2 compatibles and the Kenwood mobiles. In APRS mode the Kenwood D700/D710 can only be used receive-only. In Packet mode the Kenwood can be used as a KISS TNC. Believe it or not I hadn't realized it had this capability until Andrew pointed it out to me. Just two commands (KISS ON, RESTART) are needed to put the Kenwood into KISS mode. The other thing that confounded me for quite a while is that the Kenwood TNC expects hardware flow control. Once that setting had been made everything started to run perfectly.

YAAC's "Radio View"

One disadvantage of using the Kenwood D700/D710 in Packet mode is that the rig's display doesn't show any APRS information.However, Andrew has implemented a rather neat "radio view" which emulates the Kenwood display. The only extra thing that would make the emulation complete would be to limit it to only those packets received over the radio. With an APRS feed covering a wide area the display changes too quickly to be readable.

YAAC doesn't provide as much information about APRS objects as APRSISCE does.The window on the right is what you get when you click on one of the G4ILO icons. When two or more stations are co-located the calls overwrite one another making them unreadable. APRSISCE manages to position the calls so they don't overlap at all.

Because YAAC uses vector graphics it does a better job of displaying APRS icons and even orients the icons of moving objects in the direction of motion. Zoom in to street level and you'll discover that icons are provided for points of interest. I was quite impressed when I saw what was displayed for our small town of Cockermouth. I think these objects come from OSM data.

Street-level display of Cockermouth including places of interest

You might get the impression that I really like this new APRS client. It appears to be well designed, well written and is well supported by Andrew, its developer. It's a very impressive piece of software. I originally intended just to try it out for a couple of days but I think I'll stick with it for the time being.

Another Android APRS client

Good news for APRS enthusiasts with Android devices. Lynn Deffenbaugh, KJ4ERJ, is embarking on a port of his popular and successful APRSISCE to the Android platform, called APRSISDR.

I use the words "embarking on" advisedly. Although there is a Yahoo group and a collection of testers (including yours truly) the software is in an embryo stage at the moment. You can see the beginnings of an APRS client starting to form but Lynn is really just testing the Android platform at the moment to see how various key things can be accomplished. I would hazard a guess that it will take several months before something usable appears, though those who were in at the start of APRSISCE development will recall that it advanced in leaps and bounds. It's going to be a fun ride, but for most I think it will be best to wait patiently for more news to emerge. Watch this space!

The case of the disappearing weather objects.

I have just spent what seems like several hours trying to find out why my weather station data sent by Cumulus to the APRS network vanishes without trace. I have tried using the wxnow.txt method of generating APRS weather objects in APRSISCE and that does work, but unfortunately it messes with the MYCALL setting in my Kenwood TM-D710 converse mode TNC. So I thought that I would avoid the problem by getting Cumulus to send the data to APRS-IS directly.

The data packets were being sent but they never showed up on aprs.fi. I produced debug logs for both Cumulus and APRSISCE. These showed the packets being sent. So where did they disappear to?

To cut a long story short, Cumulus was sending the data packet with a path of TCPXX*. This is listed as "deprecated" in the APRS spec but it is actually blocked by the APRS-IS network software. The CWOP (Citizens Weather Observer Program) which I believe runs on an older version of the software, is not so picky so no-one had encountered the problem before. Can you believe that I must be the first person to try sending weather data to the APRS network using the Cumulus software?

JT-Alert for WSJT-X

The eagerly awaited JT-Alert for WSJT-X has finally arrived! You can download it from the Ham Apps website.

This useful accessory will let you know if you have worked a station B4 or whether a station will fill a wanted band or mode slot. It sends spots of JT9 stations to the HamSpots website, providing a useful reverse beacon for the mode. It also logs contacts to  a few of the popular logging programs including MixW which happens to be the same log format used by KComm. Due to some nifty programming this new version of JT-Alert works with JT65-HF as well.

This new program couldn't come soon enough for me as I have worked just about everyone who is on JT9 at the moment and it was getting tiresome doing manual log lookups. Hopefully this new program will attract some new participants to this amazing mode.

Ghostly signals

I have been puzzled and mildly irritated by the 'ghost' traces that appear at plus and minus 100Hz when I receive a very strong signal with WSJT-X.  Torben OZ1TMK wrote to me after we had a JT9-1 QSO to ask if his signal had been OK. He had received requests from a couple of local stations to reduce power because he was 'causing harmonics'. I hadn't noticed anything wrong with Torben's signal but it hadn't been strong enough. It looked to me as if it was the same effect I and a few other JT9-1 users had observed when very strong signals were received, so I decided to investigate.

I had a theory that the +/-100Hz spurious outputs ( +/-120Hz observed in the USA) were caused by ripple modulating the transmitted carrier. I used my general purpose signal generator, otherwise known as the FT-817ND, to transmit a low power carrier (CW key down) into an unscreened dummy load (Elecraft DL-1). I repeated this with the transceiver powered from my bench power supply and then on its internal batteries with the power cable removed. The results in the WSJT-X spectrum display window are shown below.

K3 RX, FT-817 TX on mains supply.

K3 RX, FT-817 on battery power

As can be seen, there are traces at +/-100Hz and at 100Hz intervals on both signals, but the ghosts seem a bit stronger on the signal when the TX is powered from the main supply.

I recalled an issue a few years ago when someone sending CW using their K3 had reports of spurious signals +/- the sidetone frequency. This turned out to be audio modulation of the synthesizer by the sound of the sidetone from the K3 speaker. Elecraft provided a fix in the form of a stiffener for the synthesizer board. My K3 is an old one and does not have this modification. You can see that the synthesizer is affected by physical vibration looking at the trace produced when I rapped on the K3 case.

K3 RX showing the effect of vibration (knock on the case)

My K3 sits on a shelf next door to a heavy linear power supply. Could slight vibration of the mains transformer be modulating the receiver's local oscillator so as to create weak sidebands at +/- double the mains frequency?

To answer that question I repeated the tests using my Elecraft K2 as a receiver, feeding the headphone output at low level into the cheap USB audio dongle I use for computer sound. You can see the result below.

K2 on RX, FT-817 on mains power.

K2 RX, FT-817 on battery power

You can see that the sidebands are much reduced when the signal is produced by a transmitter running on battery power. In fact, some weak +/- 50Hz sidebands are present - possibly the effect of 50Hz AC hum on the un-isolated cable used to connect the K2 headphone output to the sound card.

I'm not sure what to make of all this. It does appear that the 'harmonics' - which are really sidebands - that accompany a strong JT9-1 signal are caused mainly by AC ripple modulating the transmitted carrier, but that hum on the receive side can produce a decodable signal as well. The WSJT-X software is extremely sensitive and can detect these components even if they are 30dB or more below the fundamental carrier.

I would appreciate hearing of other theories or tests carried out to explain this phenomenon. It seems to be that this issue is going to be almost unavoidable when mains-powered equipment is used to generate signals that are decoded by very sensitive software.

WSJT-X update

Stay out of the shack for a few days and up pops another new version of WSJT-X.

Version 0.8 revision 3112 sports a number of improvements including CAT control (see the frequency box.)

At first I thought CAT control wasn't working because if I changed my K3 frequency with the VFO or the band up/down buttons the changes were not reflected by the software. Turns out that's how it is supposed to work. You can set the rig frequency by means of a drop-down list above the level control but it doesn't work in the other direction.

Just spotted there is a newer revision already! Download it from the usual location.

Comforting JT65-HF developments

JT65-HF-Comfort, the fork of JT65-HF that I mentioned a few weeks ago, has now been made into a public beta. There is now a project page at http://abcsolutions.de/jt65hf/. There is also a forum at http://jt65hfcomfort.iphpbb3.com/. If you use JT65-HF then you should really join the forum in order to have an input to the changes being discussed.

Classic WSPR vs WSPR-X

Are you a fan of WSPR mode? Have you tried K1JT's new program WSPR-X yet?

Comparing classic WSPR to WSPR-X

I decided to switch to the newer program as the older 'classic' version won't work with VSPE virtual serial ports. But I had a sneaky feeling that WSPR-X was not decoding some of the traces it should. So I decided to run both programs in parallel, using the same sound card, the same radio, the same data source. Sure enough, WSPR-X is missing about 1 decode in 10 compared to WSPR 2.11. There is no apparent common factor between the signals it missed. They are not at the extremes of the frequency range, close to the limit of timing error nor especially faint.

Look at the screenshot above and look at the decodes for 1540. Classic WSPR has decoded two signals for this interval whilst WSPR-X has decoded only one. The signal from W3CSW was missed. Later signals from the same station were decoded. That is just one example. I only needed to wait a few minutes to find another.

I set the older WSPR to save .wav files and when these were processed by WSPR-X using its File Open option the result was the same as when the signals were received off-air. The same transmission was missed in each case.

WSPR-X seems a bit faster to run the decodes than WSPR. It prints them up on the screen before classic WSPR does. There are sometimes slight differences in the dB and DT figures, but not enough to worry about. Has anyone else noticed this?

WSJT-X update

A couple of days ago I had an email from Joe, K1JT, author of the WSPR and WSJT software. He had read my post about my first JT9-1 QSO in which I said that I missed the JT65-HF user interface. Joe pointed out that WSJT-X is in a very early stage of program development, and user input will surely help to define its future evolution. He asked what features of the JT65-HF GUI I found desirable.

I replied with what I thought were the key points that made JT65-HF easier to use. The result is a new version of WSJT-X which I have just tried. One change is that the horizontal 'panadapter' display scale now matches the waterfall when the user has set FFT Bins/Pixel greater than 1.

However, the real big change is that double-clicking on a decode line now generates a set of messages addressed to the second callsign on the line, regardless of where you double-click. It also sets the Tx and Rx frequencies to that of the decoded transmission and selects the first message in the sequence. This is a big time and error-saver in the few seconds you have between receiving a call and having to reply. You still have to set Auto to ON to enable the transmitter and select the next message in the sequence after the first has been received. Perhaps it's a matter of personal preference but I don't think it is a bad thing for the user to take control of this rather than have the program try to work out the appropriate reply. In other words, double-click on a decode when it is a CQ call or a reply to your CQ. Use the Tx n buttons to select the next message in the sequence as you progress through the QSO.

Try this latest version of WSJT-X. I think you'll find it a big improvement. Now all we need is for Laurie VK3AMA to come up with a version of JT-Alert that adds logging and 'worked before' detection and there will be no reason not to switch to this much narrower JT mode.

A JT65-HF update

Due to the health issues of the developer Joe Large W6CQZ it has been some time since there was a new version of the popular JT65-HF application. So I was interested to receive an email from Erwin, DK5EW, telling me about an enhanced version of JT65-HF made by Matthias DL3VCO called JT65-HF-Comfort.

JT65-HF as enhanced by  Matthias, DL3VCO

Matthias has not made an add-on to JT65-HF in the style of programs like JT-Alert. Instead he has made changes to the actual JT65-HF source code. I was particularly pleased to see that the enhanced version retains compatibility with the popular add-on JT-Alert by Laurie, VK5AMA. When I tried recompiling the JT65-HF source code myself the new version did not work with Laurie's program, which I regard as an essential aid to JT65A operating. (In fact I have cheekily asked VK5AMA if he would consider making a version of JT-Alert that works with K1JT's WSJT-X program!)

I have not spent much time with JT65-HF-Comfort as my interest at the moment is directed towards the new JT9 mode, but you can see from the screenshot that one of the improvements DL3VCO has made is to display the callsign above each trace on the waterfall. He has also added a new Statistics menu which displays the number of contacts you have made per DXCC entity per band. I couldn't show you that as I use KComm for logging so my log is not in a format that JT65-HF-Comfort can read. You  can find a Google-translated version of the JT65-HF-Comfort information here.

If you are interested in trying JT65-HF-Comfort then you can download a setup program (a modified version of W6CQZ's installer) to install the updated version. I shall certainly try using it the next time I do some JT65A operation.

My first JT9-1 QSO

PC4T Paul's blog post about working Tasmania with 5 watts gave me the spur to try the new JT9-1 mode, so I installed the WSJT-X software. The user interface is quite a bit different to the older WSJT programs but most of the same controls are there. I never really figured out how to use WSJT, much preferring the simpler interface of Joe W6CQZ's JT65-HF application.

Working SM5CS using JT9-1 mode

My experience with JT65-HF stood me in good stead as I was familiar with the sequence of exchanges, but I missed the JT65-HF user interface, its ability to decode all the signals in a swath of spectrum, and the alerts and built-in logging of it's companion JT-Alert application.

My first QSO, also using 5 watts, was with SM5CS - not as impressive as Tasmania but sufficient to satisfy myself that I knew how to drive the program. I'm puzzled by the panoramic display though: the two peaks of the spectrum analyzer display don't match up with the two traces shown on the waterfall.

I made the changes to KComm to allow me to log this new mode. I seem to have an increasing number of modes that I can log but not upload to eQSL.cc because the ADIF specification doesn't yet include them, though JT9 is already there.

Digital voice on HF

I was going to title this post "D-Star's nemesis" but I thought that would be too provocative and premature! But the much talked-about Codec2 open source voice codec has just surfaced in usable form, in the shape of an easy to use bit of software called FreeDV.

FreeDV running on Windows

FreeDV is available for Linux, Windows and Mac. I installed the Windows version, which is just a matter of extracting the files from a zip archive into a folder.

If you're set up to run digital modes on HF then you're half way there already. FreeDV uses the same sound card as your digimode software and the same audio levels. As with PSK31 you just need to make sure you aren't driving the transmitter into ALC.

You'll need a second sound card for the receive and transmit audio. Assuming that you aren't using one sound card for both digimodes and computer sound, this will be the one you use for Windows noises. On my shack PC that's one of those el cheapo eBay USB sound card dongles. You'll also need a microphone or a computer headset.

There's no VOX (perhaps that will come in a later version of FreeDV) so you have to click a button to toggle PTT. Before you can do that you need to set up PTT using a com port. In my case the same serial port used for CAT control and updating the firmware of my K3 was used. The rig went straight into transmit until I ticked the RTS +V check box.

The main challenge is finding other people who are using FreeDV. At the moment the frequency 14.236MHz on 20m seems to be the only calling frequency. It would be nice to have some centres of activity on other bands, but no doubt that will come in due course. There's a Digital Voice Google Group which will probably become the meeting place for FreeDV users.

A FreeDV transmission is 1.1kHz wide, less than half of the bandwidth of an SSB signal. The audio is best described as telephone quality. It's a bit boxy, but there is an equalizer called "Filter" in the software that can be used to brighten up both the transmit and receive audio. A nice feature of the software is a button that lets you instantly switch between analogue and digital so you can easily make comparisons. I wish I could include a clip of the audio recorded off air but I couldn't figure out how to do it.

Right now I'm sitting on 14.236MHz waiting for someone else to come on the frequency. Hopefully as the word gets out more people will get on the air with FreeDV and contacts will be easier to come by.

Seeing red

I just started up Google Chrome and my eye was caught by the minimize, maximize and close buttons in the title bar, which are bright red.

They stick out like a sore thumb. I can't believe I wouldn't have noticed it before. Is it just me, or my computer? If the buttons have changed colour, why? My eye is constantly drawn to these bright red buttons. It is a real eyesore.

Another Doh! moment

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.

JT-Alert

I know conditions on 10m are going to be good when I turn on the Albrecht 10m handheld and can hear activity on its 6 inch antenna. Sure enough when I turned on the K3 the band was alive with wall-to-wall Russians at S9 plus.

I made some QSOs on SSB including one with Vadim UA1ZFG from the icy wastes of Murmansk. The nice thing about eQSLs is you don't have to wait long to receive them.

I also heard two stations from Thailand HS0ZEO and HS0ZJS, probably the first time I have heard that country on SSB, but I could not work them because of pileups. I curse the person who invented the DX Cluster as it has taken away the chance for weaker stations to work a DX just by luck tuning across them and turned it in to a contest where he who has the biggest power wins.

I switched to PSK31 where I made several more Russian contacts. Then I decided to try some JT65. My first JT65 contact of the day was with UA3TN whom I had worked before. I only found this out after logging the contact because my JT-Alert utility seems to have stopped working.

After lunch I continued with JT65 and found that all I could now hear was US stations. The first contact of the afternoon was with Tom K4AFR, then I made three other Stateside contacts all first time QSOs.

I downloaded and installed a new version of JT-Alert which is supposed to alert you when someone calls CQ or replies to your call. It also flags stations you have worked before, which I find very handy as I have a poor memory. But this feature is not working. It's probably some stupid setting I've got wrong, but I'm darned if I can see it.

A nice new facility in the new version of JT-Alert is the ability to log contacts to a third party database such as MixW. This just happens to be the log format KComm uses. It's very handy, avoiding the need to import contacts from an ADIF file one at a time, so it is worth running JT-Alert for that reason alone. But I really wish I could get those alerts working!

A virtual impossibility

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.

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?