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:
https://www.qsl.net/dl4yhf/Remote_CW_Keyer/Remote_CW_Keyer.zip
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 ?
73,
Wolf DL4YHF .
