'Remote CW Keying' / proof of concept on Windows PC

Excuses for opening a new thread on thus, but as a new user I am only allowed to post a single reply per thread. This should have been a follow-up on ‘Remote CW’. Short form: I have played with connecting my old paddle directly to the Modem control lines of a serial port, and with a bit of trickery with the “Windows Multimedia Timer” (to synchronize a worker thread for the emulated ‘Elbug’ running in the PC), an IC-7300 can be keyed via USB / internal virtual COM port, with a suprisingly precise timing.

Sources and executable win32 binary for the “proof of concept” uploaded to my website.
Again, this is in a very early stage of development, and it does not have an interface to wfview yet (if that’s feasible at all, because the worker thread loop needs to be executed once every two milliseconds, at least for higher CW speeds).
‘Remote CW Keyer’ (proof of concept without any ‘network capapility’ yet)

Direct link to the zipped archive:


The most interesting module is the (windows-) thread that polls the modem status lines for the keyer. In the archive, that’s in sources/SerialPortKeyerThread.c . The rest are a stoneage ‘Elbug’ emulation (converted from a PIC assembler source written decades ago), and a simple GUI written in stonage Borland C++ Builder (old, but I still love it for its simplicity). The interesting stuff doesn’t have any Borland / VCL dependencies - it’s just plain C with a few bare-bone Win32 API function call (for multithreading and to access the serial port).

Food for thought:

If we (or, more precisely, the wfview core developers) decide this is worth a try, let me suggest a simple format to send the actual ‘keying signal’ between client and server application via UDP:

  • encode each transition on the Morse keying signal for the radio in a single byte. Pack a few of these bytes as payload into e.g. UDP

  • let the MSBit of each byte encode “key down” : 1=RF on, 0=RF off.

  • use the lower seven bits as time in milliseconds, until consuming the next byte on the receiver side.

  • if 127 milliseconds are insufficient (e.g. for “slow CW”), simply send another byte with the same value in the most significant bit.

This way, we have a low-bandwidth stream for the Morse keying signal.
From the 7-bit timestamps (“milliseconds since the last key up / key down transition”) in each byte, the receiver (server application controlling and keyig the radio) can reconstruct the timing, regardless if the client side / operator uses a straight key, elbug, ancient ‘Vibroplex’, or whatever. The original timing (wheter good or poor) can be exactly reproduced at the remote site.
If necessary (e.g. due to “suprising network latency” detected by running out of bytes from the received byte stream), the ‘remote keyer’ could leave a gap between characters or even words, instead of leaving a gap between dashes and dots within a character.

So much for today… maybe we should move the rest somewhere else, since this isn’t really a “feature request” yet ?

Wolf DL4YHF .


Winkey remote integration would be a simple low risk and pretty widely accepted method…

Drew K3PA

Hi Drew,

Yes indeed - if you have a winkey hardware, that’s fine, because most of the “tricky timing” / low-latency sidetone is in the keyer firmware. But still, I like the idea of complete homebrew, and am quite happy with the super-simple hardware which (in the most simple case) consists of nothing more than an off-the-shelf USB/RS-232 adapter and two 4.7 kOhm resistors (as “pull-up” resistors for the dash- and dot contacts). Plus, with the two-millisecond sampling interval, even a sidetone output via soundcard is possible (the latency isn’t as low as when sending the sidetone through the serial port, abusing the TXD output as audio tone generator as described on my website).

I understand the wfview developers have a different main focus, so I will keep developing my standalone ‘remote CW keyer’ further (even though only for windows, since I’m not familar with Qt, and have no idea how to synchronize threads with the PC’s “multimedia timer” under Linux). True network capability (with client and server functionality) is on the to-do list this evening.

Seasons greetings from Germany,
Wolf DL4HF .

I was working on similar concept and have its PoC implementation here:


Also opened issue to implement this in wfview…:wink:


1 Like

I have tested Wolf’s software using my COM1 port to key my IC7300 (transistor switch). I use it with either wfview or Icom Remote (both use the USB COM port for radio control, hence I’m using COM1 on my PC to do the keying).
The radio needs to be set to straight key of course. I use ‘CI-V Scout’ to do that, all over the network using Chrome Remote.
Latency is very low, hardly noticeable.
The hardware aspect is so simple too, as Wolf said a few £$€ at the most, no Arduino or Winkey boxes here!

Well worth looking into if you want real CW (not keyboard).

Richard G0MIE

1 Like

A real remote CW feature would be awesome as (at least to my knowledge) there is no serious solution for this on the market. Especially since Wolf has now presented a solution for the timing/latency problem.

@DL4YHF Your app is looking great, please continue to develop it! Unfortunately, I cannot tribute anything to it but to request features (like a linux/MacOS port; audio stream…) but I’m pretty sure that your app will be highly appreciates by many hams.

Indeed development of the standalone ‘Remote CW Keyer’ goes on, still hoping that something similar will be available in wfview one fine day.

News will be announced in the user’s group that is linked in the documentation.

73, Wolf DL4YHF .

1 Like