G'Day,

I have recently fielded several emails assisting members with using LOGic. For the benefit of all, restated here is much of the detail of those emails. I always answer all emails, but much prefer my assistance with LOGic be provided on this LOGic forum for the benefit of all members, minimising my effort.

The summary that follows is "risky business". Read it in the context of someone for whom sending reliable CW generated by LOGic during a contest proved impossible, but could not figure out why.

Clearly, many get a good result from their implementation of CW keying and computers. But, many are puzzled why they often do not get a perfect result.

I have no detailed knowledge of the internal workings of LOGic for sending CW. I do have a lot of experience getting PCs to do things for Amateur Radio. LOGic has both a "serial port DTR/RTS based" Keyer, and a Winkey driver for a Winkey based external device.

Please discuss the topic, but type gently, and be considerate to others.

I recommend using the LOGic Winkey driver and an external Winkey based CW device.

In 2014, using any version of Windows, sending CW using the DTR/RTS lines of an RS232 port, unassisted by additional software, or keying devices, is problematic at best.

RS232 on a PC used to follow "standards". Not in 2014. Not since the early 1990s. The wonderful thing about standards is that there are so many to choose from.

Plain RS232 ports, implemented as a USB device, are not usually successfully used for sending CW. I understand some have got them to work, but only particular USB chipsets and drivers, under particular circumstances, using particular items of software. Plain RS232 ports, based on hardware installed within the PC, may work, but may not in a general sense, under modern versions of Windows.

First let me explain the techniques being used, and a bit of history. Hopefully, by then, you will start to see the issues we need to deal with.

RS232 serial devices have a long history dating back many years before PCs were ever invented. When PCs came along, the RS232 device was implemented using dedicated electronic chips within the hardware of the PC, with “software” reading and writing to/from specific memory addresses within the PC. More specifically, any program running on the PC could read/write DIRECTLY to those memory addresses. When the software wrote to the memory address, they were actually writing to a “port” within the serial hardware chip implementing the serial device – that’s how they become known as SERIAL PORTS.

One of the PORTS within those chips was defined so software could read the status of the serial line simply by reading a memory address (port), or set a “status” for the device, by writing to the memory address (port). The standards for the serial device defined various bits – for example, DATA TERMINAL READY (DTR), or REQUEST TO SEND (RTS) – there are many others.

The system worked well for sending and receiving serial data. When radios started including serial devices, one could control a radio like a Kenwood TS440. No one sent CW using the serial ports. All uses, mostly, were according to the RS232 standards.

But, sometime around the early 1990s, some bright spark came up with the idea that by using software to “toggle” up and down bits in the status port of the PC serial device chip (DTR or RTS), one could send CW directly from the PC.

CW was sent one character at a time, with the software having to pay particular attention to the timing of each and every DIT, DAH and space of the CW.

Software running on DOS based PCs began to be used for contesting – the best example being K1EA’s CT. The ability to send CW automatically meant that one could spend more time "listening" and "searching" the bands rather than "sending CW". I personally set up many “networks” of PCs running multi-multi contests using PC serial devices for controlling the radios, sending CW with the function keys via serial port DTR/RTS, and networking the PCs together. It was great fun at the time – cutting edge stuff for radio contesting.

As PCs became faster, and microprocessors appeared some saw that many of the status bits were not being used, and someone had the bright idea of using a status bit set “high” to actually power the devices connected in the RS232 cable.

The problems started when DOS began to die off, and Windows started to take over.

When everything ran using the DOS operating system, all software had direct access to the hardware. DOS lived long enough that Windows 95 was rarely used for contesting, and even with Windows 98, software still had direct access to the hardware – specifically, the serial device chip “ports”. Many amateur radio “things” were cobbled together using non-standard techniques with the serial ports.

But – there is always a BUT in this topic! – Microsoft began to discover that most of the problems report with Windows 98 et al were caused by miss-behaving user software, not Windows itself. No mater how much money Microsoft spent testing and proving their software, errors would occur, and Microsoft wore the blame, no mater what caused the error in the first place. Some user software clobbered itself, clobbered the memory of other programs running alongside it, and even the memory areas of Windows itself.

To protect the Windows software from corruption from “other software”, Microsoft developed Windows NT, and subsequently the version you might be running, Windows XP. I will not discuss the security issues of such abilities before Windows XP, nor the relative reliability of XP compared to earlier versions.

Why is that significant? Windows XP places all user programs in a closed restricted memory area – totally separate from the hardware, from other programs running on the PC, and especially Windows itself. Software no longer has direct access to the hardware. Software could no longer read/write directly to a memory addresses to “fiddle” the status port of serial devices to send CW directly. Many layers of software were placed between the “contesting software” and the serial device status port used to send CW. One could do it, but the CW became rough and the code timing unreliable – due to the timing issues and the many layers of software. Timing the DITs, DAHs, and spaces became rather more difficult.

At the same time, USB serial ports came along, and PC manufacturers no longer put serial device chips on the mother boards of the PCs. To read/write anything related to the serial ports one needed a USB driver, adding even more layers of software between the software wanting to “toggle” the serial device status port to send CW and the actual status port. Most importantly with USB, adding a lot more “unpredictable delays” to the “blocked” data moving up and down the USB cable bus, potentially mixed together with other USB devices. Timing the DITs, DAHs and spaces became even harder.

Clean, consistent, high speed CW became close to impossible under Windows.

To solve the problem, the amateur radio community headed in two directions. Some wrote new Windows drivers to run as part of the “kernel” of the Windows operating system and then modified their contesting software to use the ports directly under Windows – N1MM initially took this route, but also uses method two. This technique did not really solve the problem, but did get back the “performance” needed to drive the serial device “status port”. I wont discuss the security aspects of this solution.

The second group saw the “writing on the wall” and gave up using “status port bit toggling” under Windows completely and implemented CW in dedicated “external microprocessors” connected to the PC via an industry standard RS232 serial device – arguably, the best known is K1EL and WINKEY. CW was sent by having the PC software send complete text messages to the microprocessor over a standard serial port, the microprocessor then keyed the radio directly, completely independent of the PC and the problems with timing the DITs, DAHs and spaces.

N1MM can use either of these systems. Logic can use WinKey, and the older “status port bit toggling”, but does not include any special kernel mode drivers for CW via the serial port (that I know of), suffering the problems of the multiple layers of software between it and the “real status port”, possibly at the end of a USB cable.

With every new version of Windows software, the “kernel driver” method is at risk of no longer functioning. Security, the inevitable strengthening of it, will be the issue.

WinKey style CW is the only long term viable solution – for reliable CW using a PC during a contest.

I gave up on “serial port CW” years ago for the above reasons. I use Winkey chips in MicroHam contesting equipment for CW.

I recommend implementing WinKey for sending CW with any Windows based PC.