Remote CW Keyer
by DL4YHF, 2024-03-07
- Introduction, download link, user's group
- Keyer Application (for a windows PC)
- I/O Config tab
- Keyer Settings tab
- Audio Settings
- Network Settings and Client/Server operation
- Network Functionality
- Operation as Server
- Operation as Client
- Network Status
- Accepted Users and Permissions
- Built-in HTTP Server and the 'Admin Password'
- Client/Server test in the local network (step-by-step run-through)
- Debug tab
- Test tab
- The 'Timing Scope'
- Scope Trigger
- Interactive Readout / Timing Measurements
- The 'TRX' Tab (Transceiver Control with spectrum display)
- Morse Decoder Output
- Installation / Deinstallation
- Technical Details, Functional Descriptions, Circuit Diagrams
- Methods for remotely keying modern radios
- Keying via Ci-V
- Keying via USB / Virtual Serial Port
- 'Audio' keying
- Keying the 'old fashioned way' via the rig's Morse key input
- Connecting the Morse key contact(s) on the 'client' side
- Polling the Morse key via serial port
- Generating the Morse 'sidetone'
- Sidetone generated by the keyer's microcontroller
- Sidetone from the serial port's data output (TXD)
- Low latency audio output from Windows 10 / 11 ?
- Network functionality details
- Network Error Messages (on the 'Debug' tab)
- Audio sample format for 'streaming' over the network
- Low-bandwidth 'CW keying' format for the network
- Circuit Diagrams
- Simple Paddle Adapter with sidetone output for the serial port ('client' side)
- RF Sniffer (for a radio / PA keying test with the Timing Scope)
- Simple Keying Adapter for the serial port ('remote radio' side)
1. Introduction
This document describes the author's experiments to key certain Icom
transceivers 'remotely' to send Morse code ("CW"), not by entering
text (that modern Icom rigs can translate into Morse code), but by
connecting a Morse key (straight key, elbug, paddle) on the client side
(using a Windows PC).
To the author's surprise, with the simple 'passive' adapter shown
later in this document,
the timing was accurate even at speeds way above 25 WPM, with a very low sidetone
latency from the serial port's TXD output (abused as an
'audio tone generator' via software).
Current state of development:
- 2024-01-19 :
- Rudimentary Network capabilities (TCP client/server), including low-bandwidth
audio streaming from server (with the "remote radio") and client ("operator").
- Note for German users / Hinweis für deutschsprachige Anwender:
- Am Anfang der Entwicklung sollte dieses Programm eigentlich nur
eine 'Machbarkeitsstudie' (proof of concept) für die spätere
Integration eines echten CW-Keyers (keine Texteingabe) in wfview sein.
Eine deutschsprachige Beschreibung existiert daher z.Z. noch nicht.
Da sich die Integration in wfview als zu
aufwändig herausstellte, wird der 'Remote CW Keyer' als
eigenständige Windows-Applikation weiterentwickelt.
Als Ersatz für ein Anwender-Handbuch in deutscher Sprache
kann bis zur Vollendung des Projektes die
deutsche Übersetzung per 'Google Translate' helfen:
Remote_CW_Keyer.htm per Google übersetzen.
Die Übersetzung funktioniert nur online im Browser. Das Resultat
ist teilweise noch etwas drollig, z.B.:
- Mit "Betrieb als Kunde" ist der Betrieb als Client ("Auftraggeber")
gemeint. Dieser Modus wird auf der Seite des Operators, mit
per USB/RS232-Adapter angeschlossener Morsetaste verwendet.
- Der "Server" (Diener?) ist ein PC (o.Ä.) in der fernbedienten
Station. Der Server steuert per USB oder mit dem später vorgestellten
Keying Adapter
den CW-Tasteingang des Senders, und eventuell auch die PTT an.
- Der "Kodierungsadapter für die serielle Schnittstelle"
besteht nur aus ein paar Pull-Up-Widerständen auf der Client-Seite,
und einem NPN-Transistor für die CW-Tastung auf der Server-Seite,
falls der Transceiver nicht per USB getastet wird.
(Alle modernen Icom-Transceiver mit internem USB/UART-
Wandler-Chip können per USB getastet werden. Sie emulieren dazu
das 'DTR'-Signal (ehemals ein Modem-Steuer-Signal),
die PTT-Tastung erfolgt per 'RTS' (Request To Send)
oder mit der Transceiver-internen VOX).
- Das "Audiobeispielformat" ist das Format von Audio-Samples
(Abtastwerten, nicht "Beispiel") für das Streaming per
Netzwerk. Als Anwender werden sie damit wenig zu tun haben :o)
- Mit "Rückhörtonlatenz" (sidetone latency) ist die unerwünschte
Verzögerung zwischen Betätigen der Morsetaste (paddle oder straight key)
und dem Einsetzen des Mithörtons gemeint. Diese zu minimieren
war ein der wichtigste Punkt der ursprünglichen Implementierung.
- "Schlüssel" = key ist in diesem Zusammenhang eine Morsetaste.
- Das "Zielfernrohr" (scope) ist ein digitales Oszilloskop,
gelegentlich auch als "Timing-Bereich" (timing scope) übersetzt.
Damit der 'Google Übersetzer' funktioniert, muss Javascript aktiviert sein.
Download (link)
The compiled binary (Windows 32-bit executable) and the sourcecode
(written in "C" and a bit of C++ for the GUI) are available
as a zipped archive on the author's website:
www.qsl.net/dl4yhf/Remote_CW_Keyer/Remote_CW_Keyer.zip.
User's Group
For a limited time (using the 'free' features at groups.io for a maximum number of 100 users),
there is a User's group at https://groups.io/g/RemoteCWKeyer-Users.
Only members can post to the group, but messages can be read by anyone, so you don't need
to become a member to look for info (hoping that the 100-member-limit for the 'free' group
at groups.io will be sufficient, until the program reaches a mature state).
2. Keyer Application (for a windows PC)
At the moment (2023-12), the 'Remote CW Keyer' application is a proof-of-concept
in an early development state, but good for fun (and improving CW skills, maybe).
It requires a Morse key (straight key or 'paddles') connected to
a 'Windows'-PC, with an off-the-shelf USB <-> RS-232 adapter,
and a few passive components in between. No need for a special
hardware / electronics / ASIC / microcontroller (at least not for a start).
2.1 I/O Config tab
On the "I/O Config" tab, select the local serial ports (or USB 'virtual COM ports')
where the key (paddle contacts) and the remotely controlled radio is connected.
If you use the 'Simple Paddle Adapter'
described later in this document, the assignment of signals to keyer functions don't
need to be modified, because the default settings (as shown in the
screenshot below) are ok for that adapter. For the local client
side, only the 'COM port for the Morse key' needs to be selected, unless you
torture your PC keyboard's SHIFT and CONTROL key as replacement for a real key/paddle.
The 'COM port to key the radio' is only used if the program shall key a 'locally connected'
radio, or shall act as remote server (more on that later).
Screenshot of the 'I/O Config' tab with settings for the 'Simple Paddle Adapter'
Notes:
- Finding the right 'COM port' can be a nuisance, because Windows
may assign a new 'COM port number' depending on the USB port
the device is connected to. And even a device's 'friendly name'
doesn't always give a clue - see screenshot above.
- Icom radios, like the IC-7300 used here, often present themselves
as 'Silicon Labs CP210x USB to UART Bridge'.
Your mileage may vary - not only for the 'COM port numbers' !
- The keying via serial port / Modem control output like DTR or RTS
is not Icom-specific. With a ridiculously simple
radio-keying adapter
(not a microcontroller-based XYZ-Keyer), any radio
with a straight key input can be operated this way.
- If nothing else helps to find the right 'COM port', open the
windows control panel / "Device Manager", expand "Ports (COM & LPT)"
in the tree view, and disconnect / reconnect the USB device
while watching what happens. For example, if the
"Silicon Labs CP210x USB to UART Bridge" disappears and
reappears when unplugging the cable to your IC-7300,
you've discovered the radio's "friendly" but misleading
COM port name.
- Unfortunately, radios with remote control via USB often
only emulate one serial port (the IC-705 is a glorious
exception: It's "USB (B)" port, per default used for the
built-in GPS receiver, can be configured as a CW keying input).
Thus, in many cases, if another application (like wfview)
already uses the radio's USB 'virtual COM port' for remote control
via Ci-V, the port is occupied, and even if the Remote CW Keyer
only needs to drive the modem control lines shown below, it cannot,
because unlike Linux, Window only allows a single application
to use a particular COM port.
- Planned, not implemented yet:
If the program acts as a client, and the radio is controlled remotely
via LAN / WLAN / Internet, the field titled
COM port to 'key' the radio can be set to NONE.
Network-related settings will (in future) need to be filled out
on the 'Network' tab.
In the lower part of the "I/O Config" tab, inputs and outputs of the serial ports
are assigned to inputs from the Morse key (paddle), and outputs to the key
(voltage tapped from one of the serial port's "digital outputs") and/or
the radio (to drive the CW keying signal, and optionally control the transceiver's "PTT").
The "pin-to-function" assignment is flexible; signals can even be inverted via software
to eliminate the need for e.g. a transistor to invert the 'Dot'- or 'Dash' signal.
Available selections for input signals (from the computer's point of view):
- "NONE" : This signal is not assigned to any pin on any port
- "DCD (DE-9 pin 1)" : The serial port's "Data Carrier Detect" input
- "DCD (DE-9 pin 1), INVERTED" : Same signal and pin, but polarity inverted via software
- "DSR (DE-9 pin 6)" : The serial port's "Data Set Ready" input
- "DSR (DE-9 pin 6), INVERTED" : Same signal and pin, but polarity inverted via software
- "CTS (DE-9 pin 8)" : The serial port's "Clear To Send" input
- "CTS (DE-9 pin 8), INVERTED" : Same signal and pin, but polarity inverted via software
Hints in parentheses refer to the pin number of the "DE-9" connector commonly used
on serial ports (aka "D-sub 9-pin connector"). Btw, GROUND is on pin 5 of that connector.
Available selections for output signals (from the computer's point of view):
- "NONE" : This signal is not assigned to any pin on any of the two ports
- "DTR (DE-9 pin 4)" : The serial port's "Data Carrier Detect" output
- "DTR (DE-9 pin 4), INVERTED" : Same signal and pin, but polarity inverted via software
- "RTS (DE-9 pin 8)" : The serial port's "Clear To Send" output
- "RTS (DE-9 pin 8), INVERTED" : Same signal and pin, but polarity inverted via software
If there is no hardware available (to connect a 'real' Morse key to the PC),
the SHIFT- and CONTROL keys on the PC's keyboard can optionally
be used as a poor replacement for a paddle or straight key.
On the I/O Config tab, check
☑ use SHIFT and CONTROL key as paddle replacement
to turn your PC keyboard's SHIFT key into a paddle's "DASH" lever,
and the CONTROL key into a paddle's "DOT" lever.
For German users: Die 'Umschalt'- und 'Strg'-Tasten können notfalls
als Ersatz für eine 'echte' Morsetaste verwenden.
- Spoiler alert:
- Windows ("GetAsyncKeyState") only seems to poll the PC's keyboard
every 64 milliseconds or so.
Thus you won't have much fun sending CW this way, even at moderate speeds.
But for a quick demonstration about 'squeezing', below say 20 WPM, it's ok.
In the current implementation, when enabled, SHIFT and CONTROL
can be used 'in parallel' to a real Morse key / paddle connected
via serial port as described further above.
2.2 Keyer Settings tab
At the moment ('early beta'), the controls on the 'Keyer Settings' tab are:
- Key Type: At the moment, only ..
'None' (no key connected, intended for operation as the 'remote server'),
'Straight' (straight key connected to the 'dot' input),
'Paddle, IAMBIC MODE B' (the only mode supported by many modern transceivers)
'Paddle, IAMBIC MODE A' (used by operators who learned CW with an old 'ETM' key)
- Speed (WPM): The speed in 'Words per Minute per PARIS test'
can either be entered numerically (edit field),
or by moving the horizontal slider via mouse or cursor keys.
The slider's upper endstop is around 48 WPM, similar as Icom's built-in keyer.
The numeric input field accepts higher speeds for HSCW-enthusiasts and testing.
- Sidetone on TXD: At the moment, a low-latency sidetone
can only be tapped from the serial port's TXD output (serial data),
with either 480 or 960 Hz for reasons explained here.
If that's too unpleasant, add a sinewave oscillator controlled by the
'CW keying' output, or an audio bandpass filter to convert the
rectangular wave into a sinusoidal one.
In the lower part of the "Keyer Settings" tab, the same Timing Scope
is displayed as on the 'Test' tab.
The speed can be modified on the fly (via slider), while operating the paddle.
Each tick on the scope's timestale represents one 'dot' interval.
Screenshot from the 'Keyer Settings' tab from an early version of the 'Remote CW Keyer',
with the Timing Scope indicating bouncing contacts from a Kent key.
At 25 WPM, a 'dot' interval (and thus tick on the timescale) is theoretically
1200 Milliseconds / 25 = 48 Milliseconds
long, where 1200 ms is the length of a 'dot' at one "Word" ("PARIS ") per Minute.
2.3 Audio Settings
This tab allows selecting audio devices for input and output.
Screenshot from the 'Audio Settings' tab.
- Audio input device (optional)
- The audio input device is mainly used on the Server side
- it is either a modern Icom's built-in audio device for reception,
or a soundcard's "line-input" connected via audio cable to the receiver's headphone output,
or (better, but not always available) the transceiver's "ACC" connector which often
has an audio output with a constant level (e.g. 200 mV RMS regardless of the rig's
"Volume" pot setting). Please consult your radio's manual for details.
Under Windows, an IC-7300's built-in audio device (from where the RX audio signal
could be tapped via a single USB cable), the device name was a misleading and
ambiguous "Mikrofon (2- USB Audio CODEC)".
- Audio output device (optional)
- The audio output device can be used to generate a 'local sidetone'
through e.g. the PC's integrated audio playback device, headphones or speakers.
When operating as a Client, the same decive will also output the remote
receiver's audio signal.
When operating as a Server, the audio output device may be routed to the
transmitter's modulation input (if you really insist on using the Remote CW Keyer
to send voice).
- CW Sidetone on audio output device
- Frequency of the sidetone when emitted through the 'Audio output device'
- Note about sidetone output via 'audio device':
- Compared with the sidetone
on the COM port's TXD output, the latency is a bit higher,
but -last not least due to the carefully shaped rising and falling
edges of the synthesized audio tone- it's more pleasant for listening.
- CW Sidetone rise time (ramp time)
- Rise- and fall time (thus "ramp time") in milliseconds.
The lower, the "harder" the keying (more sidebands, in the extreme case
a horrible "click spectrum" as sometimes heard and seen on shortwave,
when ignorant operators run their Killerwatt-amplifiers in class C,
destroying the carefully shaped RF envelope produced by the rig itself).
Hint: You can check the audio input without hearing it (e.g. on the Server side)
by plotting it along with other signals in the timing scope:
Right-click into the scope (curve area), and check 'Show Audio input' in the scope's
context menu. Also check 'Free Run (don't wait for trigger)' to let the scope run
even if there is no trigger event from the Morse key.
The 'Volume adjustment' sliders on the right side of the 'Audio' tab adjust the following:
- A-in : Audio input level
- Additional gain control for the audio input (if you don't want to modify
the gain in the Windows 'volume mixer', or whatever they call it now).
Note: This "gain" (or attenuation) is applied in the internal digital signal
processing chain. It does not adjust the volume in the "soundcard" / microphone gain
or the audio processing in a CI-V controlled Icom radio.
- A-out : Audio output level
- Additional gain control for the audio output. Also applied internally, by multiplying
the digital samples in the internal DSP chain, before sending them to the output.
- SideT : Sidetone level
- Amplitude of the internally generated sinewave that will be added to the Audio output
(digital samples from the program's internal DSP).
- Net-in : Volume of audio signals received from the network, including "signalling tones".
- If the audio signal received from a remote server (web-SDR-like) is too weak or too loud,
this slider provides an amplification or attenuation ranging from 0 to 20 dB.
The center position of these "Volume adjustment" sliders, 0 dB (marked by a horizontal line)
means "neither amplify nor attenuate".
Other controls on the keyer's "Audio" tab:
- allow 'Network audio'
- Used on the Server side, this option allows sending audio via network (to clients that also use
the Remote CW Keyer application, but also to clients using a web-browser to just
"listen" to the remote radio). So remember to check this option when running the
Remote CW Keyer as a kind of "web sdr" (serving multiple receivers, but all doomed
to listen to the same frequency, because an IC-7300 isn't a Kiwi SDR ..)
Later versions of the Remote CW Keyer may have more control elements than listed here.
2.4 Network Settings and Client/Server operation
Two instances of the Remote CW Keyer can 'communicate' with
each other via local network (Ethernet- or Writeless LAN).
A remote connection 'via Internet' may be possible, but more
difficult to set up, because the remote server
needs to have a fixed IP address to be easily connectable
by the client.
Screenshot of the 'Network' tab from an early version
At the time of this writing, the 'Network' tab was only
used to configure the program as client or server
for the (CW-)keying signal, and maybe -in future-
for a simple, non-compressed low-bandwidth audio stream,
multiplexed into the same TCP stream (i.e. same TCP connection
used for the keying signal in one direction, and the
received audio in the other direction).
Blue-coloured labels on this (and other) tabs can be clicked.
Clicking those 'link-like' labels opens the manual, and
(if the web browser permits) scrolls to the relevant position.
2.4.1 Network Functionality
The 'network functionality' is controlled via the radio buttons
in the upper part of the 'Network' tab:
◉ Off (neither client nor server but local operation)
○ Client ("operator's desk")
○ Server ("remote radio site")
When switching from e.g. "Network functionality : OFF"
to "Server" for the first time, DON'T PANIC - you may see
a 'Windows Security Alert' like this:
'Windows Defender Firewall has blocked some features of this app'
- expect to see this, or a similar 'Security Alert' when trying to
start the Remote CW Keyer's 'network' functionality for the first time.
Fortunately, Windows remembers if you 'Allow access' for later settions.
Without 'Allowing access', the program can neither operate as a server
(on the "remote radio" site), nor as a client (on the "operator's desk").
For details about the CW keyer's TCP-based network protocol and troubleshooting,
see chapter 3 in this document.
2.4.1.1 Operation as Server
With the radio button
◉ Server ("remote radio site")
checked on the 'Network' tab, the program will act as a simple
TCP (not HTTP) server.
This functionality is intended to be used on the "remote radio site"
(or "side" if you prefer to see it from the network's point of view).
The server can accept a limited number of remote clients over the
internet, or through your local network.
As a minimalistic access control, if you decide to let the program run
as server through 'the internet' (which possibly requires port forwarding
in your DSL router or similar network equipment), enter the name of all
'Accepted User Names' in the right part of the 'Network' tab.
A remote client (CW operator) can only connect successfully if
his user name matches one of the names in the comma-separated
list of the server's "Accepted User Names".
Before diving in deep with a real server accessable "via Internet",
the client/server functionality should be tested in a local network.
For that purpose, the Local IP Address
is displayed on the 'Network' tab. For the server itself, it's not
important to know its own IP address (neither the "local" nor the public
"world-wide" IP address). Only the server's listening port
is user-configurable - the rest (IP address or hostname) is dictated by
the machine's network settings, or (for the public IP address) the
port forwarding settings in your network gear, and the IP address
assigned to your DSL router (or similar) by your internet provider.
More about running a server accessable 'from the internet' will follow
in a future chapter. An example to test client / server communication
in the same local network follows here.
If, on the program instance that runs as a server, an audio input device
is active (selected for input from the radio to the server), the server will
distribute that audio signal to all clients. In other words, all clients
connected to the server will be able to 'hear' the received signal if they wish.
- Note for German users (radio amateurs) about Remote Operation:
- Before making your transmitter available for other
"Class A" licensed radio amateurs, please read
§ 13a, "Remote-Betrieb", published in "Bundesgesetzblatt Nr. 160"
in June 23, 2023, which will be applicable ("Inkrafttreten")
one year after being published - in other words, June 23, 2024.
Quoted from the above (German Bundesgesetzblatt Nr. 160, § 13a):
- (1) Der Remote-Betrieb einer Amateurfunkstelle ist nur durch Inhaber
einer Zulassung zur Teilnahme am Amateurfunkdienst mit dem
Berechtigungsumfang der Klasse A gestattet.
Im Fall einer Klubstation ist der Zugriff auf Mitglieder
einer Gruppe von zugelassenen Funkamateuren im Sinne von
§ 2 Nummer 3 zu beschränken.
(....)
- (4) Der Inhaber des Rufzeichens nach § 14 Absatz 1 Satz 1
hat auf Verlangen der Bundesnetzagentur Auskunft über den Kreis
der zum Remote-Betrieb berechtigten Funkamateure zu geben.
- (5) Der Inhaber des Rufzeichens hat einen unberechtigten oder
missbräuchlichen Zugriff auf die Amateurfunkstelle durch Maßnahmen
auszuschließen, die dem Stand der Technik entsprechen.
Im Fall einer Störung muss der Inhaber des Rufzeichens
die Amateurfunkstelle jederzeit auf Anforderung der Bundesnetzagentur
abschalten können. Der Inhaber des Rufzeichens muss sicherstellen,
dass er während des Betriebs der Amateurfunkstelle unter den nach
Absatz 3 Satz 2 und 3 angegebenen Kontaktdaten unverzüglich
telefonisch erreichbar ist (...)
Mit anderen Worten: Remote-Betrieb wird zwar in DL ab dem 23. Juni 2024
für Klasse A ermöglicht, der Betreiber der fernbedienten Station muss aber
jederzeit in der Lage sein (auch nach Telefonanruf durch die BNetzA),
bei der fernbedienten Station "den Stöpsel" ziehen zu können !
Der hier beschriebene "Remote CW Keyer" ist dazu im Zweifelsfall
(z.B. bei einem Programmabsturz) nicht in der Lage.
Bei 'echtem Remote-Betrieb' ohne Anwesenheit des Betreibers 'im Shack'
empfiehlt sich der Einsatz eines 'GSM-Fernschalters' / 'GSM-Steckdose'
mit eigener SIM-Karte / Mobilfunk-Zugang, um im Fehlerfall der gesamten Station,
inklusive Transceiver, jederzeit 'den Saft abdrehen zu können'.
2.4.1.2 Operation as Client
With the radio button
◉ Client ("operator's desk")
checked on the 'Network' tab, the program will try to connect
a remote (TCP-) client described in the previous subchapter.
To use the program as a client (that connects to a
remote server), you need to have a User name (assigned to you
by the Sysop). The User name will not be visible
by other users. But your Callsign will be visible to others
(at least when you transmit, you are obligated to send it
periodically anyway, so the callsign isn't a secret anyway).
If after the server positively identified the client
(by his User name, which must have been configured by the server's operator),
Morse code sent by the client's operator will be converted into a low-bandwidth
bytestream, which will be sent via TCP/IP to the server.
Note that in this direction, the signal is not as an audio signal
but as a precisely timestamped
sequence of 'key down / key up' commands. Details and the format of this
bytestream are specified in chapter 3.
The received signal (picked up by the radio at the remote site)
is sent from server to client over the same TCP/IP connection, not as an
'on / off keying' signal, but as a real audio signal at a low sampling rate,
using moderate audio compression to reduce the TCP/IP stream bandwidth
even further.
2.4.2 Network Status
The text field 'Current Network Status' shows a summary of ..
- The program currently running as Server, Client, or without any
network functionality ("off")
- When running as server: The number of remote clients currently logged in
- When running as client: The log-in status, remote server address,
and permissions granted by the server's sysop
- Number of bytes transmitted ("tx") and received ("rx") over the network socket
More 'network diagnostics' can be invoked through the application's main menu
("Settings".."Network Diagnostics" and "Report Test Results on the Debug Tab").
2.4.3 Accepted Users and Permissions
As quoted above, for 'real' remote operation, some authorities require
the operator of a remotely controlled transmitter to restrict
the access to authorized users. The text field 'Accepted Users and Permissions'
must be filled out by the 'sysop' of the server. The format is a simple list
of comma-delimited user names. For each user, the sysop may define permissions,
i.e. specify if a certain user is allowed to talk to other users (via internet,
not radio), transmit (via radio, e.g. depending on his license class),
or even 'control the rig' (e.g. change the frequency). These 'permissions'
are encoded as a decimal number (actually a bit combination, listed below),
separated from the user name via colon. A user name may consist
of letters, digits, and the underscore character.
Example:
Accepted Users and Permissions:
Max:0,Moritz:7
Decimal bitmasks for 'permissions' :
- 0 (default when not specified at all) : No extra permissions
This user (like 'Max' shown in the example) may connect the server
and will receive the radio receiver's audio signal, but he can
neither 'talk' to other users, nor transmit, nor control the remote rig.
- 1 : "permission to talk via internet"
If this user has an audio input device
selected in his client software, the audio signal picked up by that
device may be sent to the remote server. The server will distribute
this audio stream to other users currently logged, if they also have
"talk" permission. This feature was intended for CW training, to allow
the teacher / instructor (who usually will run the server) to speak
with the students (clients) if they are still at the begin of their
'CW career'.
- 2 : "permission to transmit on the radio"
If this user currently 'has the key', his Morse code transmission
directed to the server will be passed on to the remotely controlled
radio's CW keying input (as configured on the
I/O Config tab).
If there is no remotely controlled radio connected to the server at all,
the Morse code keying signal will be 'relayed back' (as a byte stream
with an exceptionally low network bandwidth) to all
currently connected clients (users). This "on/off keying" stream
may be converted into an audio tone on the client side.
This way, OMs plagued by QRM or bad propagation can rag-chew
in CW 'via Internet', without the need for a dedicated voice-over-IP
server or whatever.
- Note:
- Even if the server's sysop has granted transmit permission
for a certain user (by user name) this way, the user will only
be able to transmit if the remote client not only sent a correct
user name, but also a callsign. Without a callsign,
no user can transmit. The user may modify the callsign (for example,
using his private call when operating from home, or with a /p or /m
suffix when operating portable or mobile, or with the club station's
callsign when operating, or even with a /r for "remote" appended
if that is required by the local authorities. The 'Remote CW Keyer'
(server side) doesn't care about the callsign ..yet.. as long as
the callsign sent by the client isn't empty.
- 4 : "permission to control the rig" (change frequency, etc)
This option (bitmask) may allow the user to 'control' the remote radio.
In most cases, a sysop will only allow this for himself, because he
is responsible for the transmit frequency, output power, bandplan-compatible
mode, etc.
- Note:
- Even SWL's (Shortwave Listeners without an amateur radio callsign)
may control the rig, if the sysop permits (for their 'secrect user name').
"Controlling the rig" doesn't necessarily mean "permission to transmit".
The above numbers can be added (or "bitwise combined") to assign more than one
"permission" per user. For example, "Moritz:7" has the three permissions listed
above (thus he may talk (1), transmit (2), and control the rig (4)).
But, as already noticed, if user "Moritz" doesn't fill out the 'Call' field (callsign)
on the 'Network'-tab / Client side (left), he will not be able to transmit.
2.4.4 Built-in HTTP Server and the 'Admin Password'
.. is in a very experimental stage; too early to be completely documented here ..
At the moment, the built-in HTTP server was only used to check the connection
from the office PC to the remotely controlled radio at home,
after experiencing problems to establish a 'raw TCP/IP' connection
to the server's listening port (7355 at that time).
It later turned out that the 'secure' infrastructure blocked any TCP/IP
port except port 80 (the well-known port for HTTP), which by the way
was the reason that none of the nice web SDRs (Kiwis, Twente, ..)
could be listened to during the lunchbreak.
By allowing HTTP besides the 'raw' TCP/IP (used for remote CW keying),
the program's build-in Server for the "remote radio site" can also be
accessed from any web browser (if you remember the IP address, and can
convince your mobile browser to treat the input as an address instead of
'googling' for what you entered). The HTTP server only supports HTTP,
not HTTPS, so to prevent accidental visitors from receiving any info,
the URL (entered in the browser) must have at least a valid user name
in the query string, e.g.:
http://servername.dynv6.net:7355?user=Moritz&pwd=Admin
where servername.dynv6.net was the server's public URL (yours will be different),
7355 was the ham-radio-friendly port number (in the author's case, blocked by paranoid infrastructure),
Moritz was one of the 'Accepted User Names' (see Network Settings tab - yours should be different),
and Admin is a really stupid password to log in 'as administrator' (yours must be different).
Being the 'server administrator' hasn't got anything to do with elevated privileges
for a windows application. Only the 'server administrator' can log into
his own server (e.g. using a mobile phone when being on vacation) to read out
e.g. the server log, disable access to the radio, stop it from being 'keyed',
or even shutdown the entire server (not only the HTTP part, but also
the 'remote CW keying' part), etc.
Note: If a visitor tries a wrong password ("pwd=" in the query string),
he will be immediately kicked out of the system without even getting a response,
and his IP address will be automatially blacklisted for some time.
If the visitor tries another user name (or password) before the blacklist-time expired,
the blacklisting timer will restart. Thus, after accidentally entering
a wrong user name or password in the URL (as part of the query string),
don't immediately try again but wait for a minute.
2.4.5 Client/Server test in the local network
Trying to keep this as simple as possible.. but step-by-step:
- Install and start the Remote CW Keyer on machine 'A',
in your local network (Wireless LAN or Ethernet doesn't matter;
what matters is that Windows and its built-in firewall allows
machine 'A' and 'B' to communicate with each other over TCP/IP).
- On 'machine A', switch to the application's "Network" tab and check
◉ Server ("remote radio site")
Machine 'A' will be acting as server.
If Windows bugs you with something like "Windows protected your PC",
because from its point-of-view the Remote CW Keyer is an
"unrecognized app", proceed as described here.
- Write down the 'Local IP Address' displayed on the 'Network' tab
(this is the SERVER'S IP address for the test in the local network)
- Write down the 'Listening port' (the default was 7355, this is the port on which the server listens for clients)
- Check the Network Status - it should show something like
Server: running no client connected, tx=0, rx=0 bytes
- Install and start the Remote CW Keyer also on 'machine B',
connected to the same local network as 'machine A'.
- On machine 'B', switch to the application's "Network" tab, and check
◉ Client ("operator's desk")
- On machine 'B', Under 'Client' (i.e. in the left half of the "Network" tab),
in the 'URL' field,
enter the Server's IP address (you wrote that down from machine 'A', five steps above),
followed by a colon (':' to separate the IP address from the port number),
followed by the server's 'Listening port' (you wrote that down from machine 'A', four steps above).
- Under 'Client' / 'User': Enter one of the user names accepted by the server.
(With the default settings after a fresh installation, try Moritz because
that's the user with the permission to do everything, including transmit.
Later, if you dare to make the server accessable "via Internet", don't forget
to delete "Moritz" from the list of users on the server side, because anyone
who read this manual will try to access your server with that name.)
- Under 'Client' / 'Call': Enter a callsign here, because
without a callsign, the server will not allow the user to transmit,
for reasons explained here.
- Still on machine 'B', check the Network Status - here, it should show something like
Client: logged into NNN.NNN.NNN.NNN:PPPP, tx=789, rx=1234567, may talk, transmit, control the rig.
(where NNN.NNN.NNN.NNN is the numeric IP address, just in case you entered the server's hostname instead of a numeric IP address;
PPPP is the port number, followed by the number of bytes transmitted and received,
and finally a summary of the permissions granted to the client by the server,
depending on the user name and callsign that the client has sent to the server).
For the next step (sending Morse code from client to server, and letting the server "key" the radio),
select the COM port where the Morse key is connected (on the client side),
and the COM port that 'keys' or even 'controls' the radio (on the server side),
on the keyer application's I/O Config tab.
To hear the received audio on the client side, check the Audio Settings
in the Remote CW Keyer application, and (for 'modern' Windows versions) in the
Windows audio control panel, "privacy settings", or whatever they call it now.
Don't forget to check
☑ allow 'Network audio'
because otherwise, the instance running as server will not pass the audio signal from the radio to the network.
2.5 Debug tab
The 'Debug' tab is a text edit control, primarily intended to emit
error messages and 'test results' from the program. Besides that,
if the keyer is in 'Elbug' mode, characters sent in Morse code
are decoded (by the 'Elbug' itself), and emitted as text in this window.
Different text colour backgrounds indicate if a line of text is an error (red),
warning (yellow), or just an info (white background). Morse code decoded
while sending via built-in keyer has a light blue background.
- Note:
- The built-in keyer also emits decoded Morse code
into the Timing Scope, where,
for the operator, it's more fun to watch during a QSO,
or even for personal CW training.
The display format of a few 'special characters' and
Morse code specific prosigns is similar like
the one used by Icom's built-in "Memory Keyer".
For example, "...-.-" (Silent Key) appears as ^SK .
More on that later.
System info and Morse decoder output on the 'Debug' tab
On the 'Debug' tab, you may find error messages (again, red coloured)
as in the following example (copied from the 'Rich Text' editor):
CW Keyer Test compiled Jan 1 2024
Keyer thread running, 25 WPM.
Client: launched
Client: Trying to connect 127.0.0.1:7355 ...
.. failed: Connection refused
2.6 Test tab
The 'Test' tab can be used for hardware tests. The upper part shows
the current states of all digital inputs (currently, only from
the RS-232 "Modem Status" lines).
The middle part may shows some test results from the 'keyer task' (which
ideally polls all digital inputs every two milliseconds, runs the 'electronic keyer',
and sends the CW modulation to the selectable digital output):
- Thread: shows a history of Microseconds per thread loop.
This should ideally be 2000 us (= 2 ms); if the values are much larger,
there's a problem with the "Windows Multimedia Timer" which synchronizes
the 'keyer task', or with the USB / serial port driver (consuming
"too much time" to poll the Modem status lines, or drive the Modem
control lines on the serial port).
- 'Manually control digital outputs' : Just a left-over from the
development phase. Allows manually control of 'digital outputs'
(DTR, RTS) on the serial port(s) when not assigned to any function
on the I/O Config tab.
The lower part of this tabsheet also shows the Timing Scope.
Early version of the 'Remote CW Keyer' application,
with the Timing Scope in action at 35 WPWM.
2.7 The 'Timing Scope'
The Timing Scope is a simple digital oscilloscope,
showing the following channels (from top to bottom):
- Channel 1, yellow:
- Logic state of the 'dash' input : low = paddle contact open, high = closed.
- Channel 2, green:
- Logic state of the 'dot' input
- Channel 3, red:
- Logic state of the 'CW keying' output : low = 'RF carrier off', high = 'RF carrier on'.
- Channel 4, blue:
- Originally the state of the 'PTT keying' output: low=receive, high=transmit.
In later versions, the source for this channel can be selected
in the program's main menu under 'Settings' .. 'Connect Scope Channel 4 to ...'.
Channels displayed on the scope can be configured in its context menu.
Right-click into the scope to open it. That menu also allows
to display a certain audio signals.
White ticks at the upper and lower edges are the timescale.
Each tick represents a single 'dot interval', depending on the
current setting of the keyer speed in WPM.
Waveforms displayed on the Timing Scope from a 'single lever' key (w/o squzeezing) at 25 WPM.
Note the contact bounce on rising edges (yellow and green trace) from a (t)rusty old key ;o)
If the Morse code signal is generated by the program's built-in
"Elbug" (electronic keyer), and the keyer recognizes a valid
character, it will 'print' the decoded character into the timing scope,
along with an indicator of the character's begin and end.
The built-in decoder recognizes the end of a character by a gap
with a duration of at least two dots (ideal: three dot inter-character space).
A 'word space' is detected when the gap exceeds five dot times (ideal: seven dot inter-word space).
2.7.1 Scope Trigger
The scope display doesn't scroll but sweep ("radar like",
or like an digital oscilloscope in 'slow mode').
The currently updated position is marked by a white vertical 'windscreen wiper'.
It the sweep position reaches the end (on the right), the scope display automatically
pauses until the next trigger event. At the present time, a trigger event
is any transition (low to high or high to low) on any of
the scope's input channels.
Upon detection of a trigger event, e.g. operator starting to key again,
the scope shows a few samples before the trigger event. Thus,
when starting to key the next character, the leftmost few milliseconds
visible on the scope show the waveform shortly before the trigger event,
including the rising edge -or the contact bounce- on the dash- or dot input.
It's good fun to see the timing of one's own 'dashes and dots'
on the scope, along with the resulting 'Morse code' (with inter-word spacing),
and to find the personal "speed limit" (when the built-in
decoder sees more garbage than properly spaced characters).
Also, despite the low sampling rate for the digital inputs
(1 / 2 ms = 500 Hz), bouncing electric contacts can often be seen
in the scope waveforms as in the example shown above.
If you spot a wrong character (displayed in the scope or in the
'decoder output' as plain text), simply stop keying. The scope's trigger
will pause at the end of a sweep, and you can see 'what went wrong'
(either with the software, the key/contacts, or the operator's keying, hi).
- Note:
- The timing scope shows the keying signal before travelling
through the Windows 'serial port' API, the USB driver,
and through whatever happens inside the USB<->RS-232
adapter. There's a trick to measure the total delay between
the key (paddle contacts) and the actual 'RF output' (envelope)
of the keyed transmitter, described in the Circuits chapter.
2.7.2 Interactive Readout / Timing Measurements
The scope allows precise time measurements, using the mouse (or touchscreen) as follows:
- Move to the begin of the to-be-measured interval in a Timing Scope trace
- Press the left mouse button (or touch pen), and hold it pressed
- With the left button / pen held down, move towards the end
of the to-be-measured interval.
The program will draw a thin white line between the start- and endpoint.
- At the end of the to-be-measured interval, release the mouse button / pen.
The program will convert the distance along the abscissa (x axis)
into the time difference ("dt" = "delta t") in milliseconds,
and also into the equivalent number of "dot" intervals.
The result will be drawn into the scope screen, near the line
drawn via mouse / touchscreen, as shown in the screenshot:
(Click on image to magnify. Note the operator's "poor spacing" between characters:
2.6 "dot intervals" between "T" and "E", but 3.7 dots between "E" and "S".)
- Painting more lines into the scope produces more 'overlays' for readout (up to three,
before the oldest overlay is overwritten).
- To clear all overlays again, select 'Settings' ..
'Clear scope overlays (markers)' in the Remote CW Keyer menu.
2.8 The 'TRX' Tab (Transceiver Control with spectrum display)
If remote control is possible (at the moment, for 'modern' Icom rigs with
Ci-V via USB), this tabsheet shows the most important rig settings (at least the
current VFO frequency and mode), and -maybe- a spectrum / spectrogram.
'TRX' tab with a remote display of an IC-7300's spectrum,
from a very early 'beta' with only the VFO frequency and mode indicated.
Note: For a much more versatile 'remote waterfall display' for Icom radios,
use wfview. The 'Remote CW Keyer' only has this
simplistic spectrum/waterfall display built inside because when it occupies
the radio's CiV-port (via USB), the USB port is occupied, and WFView cannot
access the radio.
The 'VFO' field in the upper left corner is a plain text edit field.
The frequency (in MHz) can be typed in directly, but more convienient
is to place the input cursor (aka "caret") at the digit you want to
control, and use the up / down key ("cursor key"), or the mousewheel
to increment/decrement the frequency. If an Icom radio is connected
via Ci-V (USB, serial port, etc), the new frequency is immediately sent to the radio.
The program also recognized if the frequency is modified on the radio itself,
e.g. via VFO knob, or from another network user with the permission
to control the remote radio.
The next field (right next to the 'VFO') is a combo box indicating
the radio's "mode", like CW (normal bandwidth), CWN (CW "narrow"),
or CWNN (CW "very narrow", which for modern Icom radios is filter 3).
Other elements to control the radio from this tabsheet may possibly
follow.
2.9 Morse Decoder Output (-format)
Digits, letters, and other 'normal' characters are printed as plain text.
Prosigns are displayed
in a simular format as in Icom's built-in memory keyer,
described for an IC-7300 as follows in the 'full' manual,
"Operating CW", "Keyer memory edit menu":
> About the symbols
> * Enter "^" to send a string of characters with no intercharacter space.
> * Put "^" before a text string such as ^AR,
> and the string "ar" is sent with no space.
2.10 Installation / Deinstallation
Since the application doesn't depend on any 3rd party tools, no "dot-net"-something
etc, it doesn't need to be installed. Just unpack it from the zipped archive
(see link at the begin of this chapter) into a directory of your choice,
and start the executable (Remote_CW_Keyer.exe). This should even work
under Unix/Wine (not tested at the time of this writing yet).
Newer Windows versions behave a bit paranoid when launching an application
(here: *.exe file) that was not downloaded from the
'Microsoft Store'. Depending on the Windows version, something
may pop up with warnings as shown below.
"Windows protected your PC", because the Remote CW Keyer is an "unrecognized app".
Click "More info" to let the hidden button appear, then click "Run anyway".
2.10.1 Installation
After unzipping the program (including files and subdirectories)
into a directory of your choice (not neccessarily "Programme",
"Program File (x86)", "Program Files" or wherever your OS wants you
to 'install' everything), that directory should contain at least this:
Remote_CW_Keyer
|--- manual
| |-- Remote_CW_Keyer.htm : The manual in HTML format
| '-- *.png, *.jpg : Images loaded by your browser
| when opening the manual
|--- sources : The 'most interesing sourcecodes' (written in C).
| Since these are only interesting for developers,
| the list of sourcecode modules has been moved
| into a separate document
| - see Remote_CW_Keyer_Implementation_Details.htm#Sourcecode .
| You can safely delete the entire 'sources' folder.
| It is not required to run the executable.
|
'--- Remote_CW_Keyer.exe : This is the executable file .
Lauch it via double-click, command shell, or create
a link on the desktop to it.
When launching Remote_CW_Keyer.exe for the first time, the program
starts with what the author thought are meaningful defaults.
However, the program has no idea about your hardware configuration,
e.g. on which serial port your Paddle / Straight key is connected,
if you plan to control a locally connected radio for testing first,
etc. Thus on the first launch, the program switches to the
I/O Configuration tab where you should select
the 'COM port' numbers, or confirm that you have 'None'.
If you do have a real Morse key, uncheck
☐ use SHIFT and CONTROL key as paddle replacement
because the default (after a 'fresh install') has that option set,
for a quick test (only with a sidetone via default audio device).
2.10.2 Deinstallation
Since there is no installer (just a zipped archive with all in one place),
there is also no uninstaller. To clean up, simply delete the unpacked files.
If you don't want to leave any trace on your office PC ;o), the only file
that the program will save on your PC is its own configuration, in a
plain, simple, and wonderfully old-fashioned Windows "INI" file
(INI files are simple text files; they can be edited with a plain
text editor if necessary).
The Remote CW Keyer utility will not touch anything in the Windows 'registry' !
Unfortunately, the place where Windows stores application's "INI" files
depends on the windows version, the way the program was launched
(which kind of user privileges), the name of the current user,
and possibly the language of the windows installation.
For example, when launched under debugger control from the Borland C++ Builder IDE,
the configuration was saved in
C:\Windows\RemoteCwKeyer.ini .
When launched with a normal user account (here: user name 'Wolf'),
and without 'admin' privileges, the configuration file was stored at
C:\Users\Wolf\AppData\Local\VirtualStore\Windows\RemoteCwKeyer.ini .
3. Technical Details, Functional Descriptions, Circuit Diagrams
Note: As this project slowly evolves from a 'proof of concept' into a
real application, some of the contents were moved from this document
into a separate file. Software developers (especially those more
familiar with wfview and Linux..)
may be interested in the protocol details, and in the
'CW keying bytestream format' described in
Remote_CW_Keyer_Implementation_Details.htm#Network_Morse_Routing.
3.1 Methods for remotely keying modern radios
3.1.1 Keying via Ci-V (Icom)
Icom radios like IC-7300, IC-9700, IC-705, and possibly a few others have a built-in keyer
that can translate TEXT (ASCII characters) received via Ci-V (USB/VCP or even LAN or Wireless LAN)
into Morse code. For the author (who prefers rag-chewing in Morse code rather than '599 TU'-style or
Contest QSOs), unacceptable. To send text from a keyboard, we already have WFView
(currently only with a "text input box" to send Morse code remotely).
Theoretically, on the 'client' side, the input from a real Morse key
could be translated into text quite easily before being sent to the radio,
but that's not "the real thing", so this method wasn't evaluated at all.
3.1.2 Keying via USB / Virtual Serial Port
Radios like the IC-7300, IC-9700, IC-705, etc, don't have traditional serial ports but USB
/ "Virtual COM Ports". Besides transporting Icom's Ci-V protocol for
remote control, these interfaces also emulate Modem control signals
(inputs from the radio's point of view), configurable via setup menu
as CW keying signal (IC-7300: "USB SEND / Keying" .. "USB Keying (CW) : DTR"),
and maybe as PTT signal ("USB SEND : RTS") if you don't want to rely on the
radio's internal "semi-break in" feature.
The 'Remote CW Keyer' application (or a similar, yet to be developed add-on for wfview)
can drive at least the CW keying signal as described in a later chapter.
3.1.3 'Audio' keying
Audio keying means e.g. running the remote transmitter in single-sideband (e.g. USB = Upper Side Band),
and feeding in the modulating signal either through the rig's integrated 'USB' (Universal Serial Bus) audio device,
or (for radios with LAN- or WLAN/"WiFi" interface) via Icom's terribly complicated UDP 'audio' port.
Downside: The modulating signal would have to be an 'extremely clean' sinewave, with carefully
shaped ramps. With a typical SSB audio bandwidth of 2.7 kHz, any garbage or artefacts from compression
will cause an excessive transmitted bandwidth, or click spectrum as often heard during CW contests
from totally overdriven power amplifiers. Also, having to switch between 'CW' and 'USB' during each
change-over adds to the software complexity (and makes even Semi-BK operation tricky).
Thus, for a start, this method also wasn't evaluated.
The most common (and universal) method to key a remote transmitter is with
a suitable interface. Such an 'interface' is often just an NPN transistor,
driven by a Modem Control output (e.g. DTR or RTS) on the PC's
serial port / USB<->RS232 - adapter, as shown in the
Circuits chapter.
9-pole sub-D connector for a simple remote keying interface:
| Pin Nr on DE-9, PC side |
Abbreviation |
Normal Function |
Usage (here) |
|---|
| 1 | DCD | Data Carrier Detect | |
| 2 | RXD | Receive Data | Optional Ci-V control (in) |
| 3 | TXD | Transmit Data | Optional Ci-V control (out) |
| 4 | DTR | Data Terminal Ready | Morse keying output
(positive = "key down") |
| 5 | GND | Ground | |
| 6 | DSR | Data Set Ready | |
| 7 | RTS | Request To Send | PTT output
(positive = "transmit") |
| 8 | CTS | Clear To Send | |
| 9 | RI | Ring Indicator | |
Notes:
- The 'PTT' connection is rarely necessary. Let the remotely controlled rig run in 'Semi-BK'
mode, or (if necessary for proper sequencing with e.g. an external PA or RX preamplifier)
use Icom's Ci-V protocol to switch between receive and transmit.
- As long as no application has opened a serial port (and actively controls the "Modem Control" lines
/like DTR and RTS), voltages measured on DTR and RTS ranged from -5 Volts to -12 Volts.
- Due to the network latencies, it's impossible to use the rig's built-in 'electronic' CW keyer.
The Morse code signal, and the indispensable sidetone, must
be generated on the 'client' (operator) side.
Also, having separate 'dash' and 'dot' signals on the server side (radio)
would make things unnecessarly complicated.
3.2 Connecting the Morse key contact(s) on the 'client' side
3.2.1 Polling the Morse key via serial port
9-pole sub-D connector for the 'Simple Paddle Adapter'
(as described later in the Circuits chapter):
| Pin Nr on DE-9, PC side |
Abbreviation |
Normal Function |
Usage (here) |
|---|
| 1 | DCD | Data Carrier Detect | |
| 2 | RXD | Receive Data | |
| 3 | TXD | Transmit Data | Optional sidetone output |
| 4 | DTR | Data Terminal Ready | weak 'positive' supply voltage |
| 5 | GND | Ground | |
| 6 | DSR | Data Set Ready | Input from Dash Contact |
| 7 | RTS | Request To Send | weak 'negative' supply voltage |
| 8 | CTS | Clear To Send | Input from Dot Contact |
| 9 | RI | Ring Indicator | |
3.2.2 Polling the Morse key via microcontroller
A microcontroller would allow more precise timing (e.g. by timestamping
the digital inputs in bytes sent over the serial port), but for a start,
this method was not tried yet - last not least because the timing
even from the Windows-PC-based 'Remote CW Keyer' software was surprisingly accurate.
3.3 Generation of a low-latency 'sidetone'
If you're into rag-chewing in CW (Morse code) with an electronic keyer (and "bug" keys,
paddles, single-lever or 'Iambic' paddles), you know the importance of a good,
low-latency "sidetone", i.e. a locally generated audio tone that gives an
immediate feedback of the "dash", "dot" or "gap" currently being sent.
Even with a straight key, a clean, fast sidetone is beneficial.
Any decent radio of today can generate a nice-sounding sidetone,
which is perfect when operated 'locally', but this is usually not
suited when operated remotely (via USB, LAN, or even "the Internet"),
because:
- There's a delay between the paddle contacts and the arrival of
the "dash"- and "dot" inputs in the PC running the client software;
typically a few milliseconds, depending on the USB hardware,
USB driver, and the way the client software 'polls' the signals
from the USB port.
Optimistically (after own experiments documented later),
assume the 'client software' receives the states of the
Morse key contacts via USB (virtual serial port)
with a 5 millisecond delay (t1).
- If the remotely operated radio isn't directly connected to the
'shack PC' but with a network connection in between, the
network latency (in the order of "ping" test times)
must be added twice, because the 'Morse key' state
travels through the network in one direction (from client to
server), and the audio signal (sidetone during transmit)
travels back from server to client.
Assume a "ping" (as in "ICMP" = Internet Control Message Protocol)
travels from client to server and back within 50 milliseconds (t2).
- If, as sound in modern radios, the remotely controlled radio
uses an integrated 'soundcard' (e.g. what appeared as "USB Audio Codec"
from an IC-7300). Thus the sidetone generated 'inside the radio'
travel through several layers of buffering, USB audio drivers, etc.
the latency was as low as for a keyer-generated sidetone.
Assume the audio drivers (including the firmware that drives
the "USB Audio Codec" inside the radio) isn't up to the latest
hype from Microsoft (more on that possibly later), assume
the 'audio delay' on the server side is 20 milliseconds (t3).
- After the 'sidetone' arrives back in the client software,
it needs to travel through some layers of audio buffering again
(application software, driver software, audio hardware),
so expect an audio output latency on the client side of 20 ms,
too (t4).
Summing up the latencies: t1+t2+t3+t4 = ( 5 + 50 + 20 + 20 ) ms = 95 ms.
That's too much, so the sidetone must be generated locally.
3.3.1 Sidetone generated by the keyer's microcontroller
Generating the sidetone directly by the keyer is still the best method, because it gives the lowest
possible latency between closing e.g. the paddle's 'dot'- and/or 'dash' contacts. Since the days
of the earliest 'CMOS Keyers' by ETM and others, a sidetone for operating an electronic keyer
("Elbug") could be generated this way, even though they didn't always sound nice (but squeaky, harsh,
unfiltered rectangular waveforms, rich in harmonics).
Adding a sinewave-shaped (low-pass filtered) sidetone from the keyer to the operator's headphones
isn't rocket science, but adds to the cabling mess. Thus, a few alternatives were tried.
3.3.2 Sidetone from the serial port's data output (TXD)
Optionally, a crude (rectangular, 'hard-keyed') sidetone can be taken
from the serial port's TXD signal (serial data output). For this purpose,
the keyer application (described later) configures the "Paddle Interface"
port for 4800 baud, with one start- and one stopbit, and sends an 8-bit data
pattern as long as the keyer shall produce a sideone (during dashes and dots).
With 4800 baud, and 10 bit times per serial frame, this method can generate
a clean 480 Hz tone (abusing the UART's hardware shift register with pattern
0xF0), or (with two 'pulses' in the data pattern 0xCE) a clean 960 Hz tone.
An attempt to generate audio tones around 600 Hz by configuring the serial port
for a non-standard 6000 'baud' speed produced an unpleasant wobbling tone,
so at the time of this writing, only 480 Hz or 960 Hz can be tapped
as sidetone from the serial port.
The Simple Paddle Adapter
circuit shows a simple example for driving a 'piezo speaker' without
active components, directly from the serial port.
3.3.3 Low latency audio output from Windows 10 / 11 ?
An article on 'TheWindowsClub' mentioned:
According to Microsoft Low Latency delay is a routine in Windows 11/10,
but it should not be noticeable. Before Windows 11/10, the latency
of the Audio Engine was equal to ~12ms-~6ms, which is now reduced
to 1.3ms for all applications.
Before Windows 11/10, this buffer was always set to ~10ms. Starting with Windows 11/10,
the buffer size is defined by the audio driver. Bingo!
So it's not just Windows responsible, but it is also the driver.
The good news is that Microsoft also says that If an application needs
to use small buffers, then it needs to use the new AudioGraph settings
or the WASAPI IAudioClient3 interface, to do so.
Maybe something to try in future.. at the moment, the program sticks
to the 'mature' audio API (DirectSound), which used to work perfectly
in old Windows versions. If the DirectSound latency is unacceptable,
use one of the other alternatives for the sidetone.
3.4 Network functionality details
Unlike Icom's complex remote control via LAN/WLAN
(e.g. in the IC-9700 and IC-705) using three UDP ports,
this Remote CW Keyer only uses a simple (single) TCP connection
to avoid having to implement a USB-based protocol (like Icom)
that has to care for automatic retransmission, 'packet counters'
to protect against datagrams arriving out-of-sequence,
and all the stuff you get 'almost for free' when using
TCP/IP instead of UDP.
The price to pay for using TCP is a higher latency,
but even with UDP (used "over the internet"), the latency
was too high for using the radio's own sidetone (remotely)
for electronic keying even at moderate speeds.
Since details are only interesting for developers, but not required
to just use this application, the description of the
Remote CW Keyer's TCP/IP-based client / server protocol
has been moved into a separate document - see:
Remote_CW_Keyer_Implementation_Details.htm .
3.4.1 Network Error Messages (on the 'Debug' tab)
Sometimes, if there is trouble with the network (TCP/IP connection),
socket errors like the following may appear on the keyer window's
'Debug' tab. Here is an incomplete list.
You may find help by asking your friendly search engine, or find details
in the description of the Berkeley Socket API (or the 'Winsock' API by
Microsoft, which is sufficiently similar). The strings were actually
copied from sourcecode module CwNet.c :
- Connection refused
(this often happens if the remote IP address exists, but not the PORT)
- Connection timed out
- Interrupted function call
- Invalid socket descriptor
- Permission denied
- Bad address
- Invalid argument
- Too many open files or sockets
- Call of a WINSOCK function would block
- Operation now in progress
- Operation already in progress
- Socket operation on non-socket
- Destination address required
- Message too long
- Protocol wrong type for socket
- Bad protocol option
- Socket type not supported
- Socket not supported
- Operation not supported
- Protocol family not supported
- Address family not supported by protocol family
- Address already in use
- Cannot assign requested address
- Network is down
- Network is unreachable
- Network dropped connection on reset
- Software caused connection abort
- Connection reset by peer
- No buffer space available
- socket already connected
- Socket is not connected
- Cannot send after socket shutdown
- too many refs
- loop detected
- name too long
- Host is down
- No route to host
- not empty
- Too many processes
- Ran out of user quota
- Ran out of disk quota (funny error for a NETWORK SOCKET...)
- Stale handle reference
- Item is remote
- Graceful shutdown in progress
- Network subsystem is unavailable
- WINSOCK.DLL version out of range
- WSAStartup not yet performed
- Host not found
- Non-authoritative host not found
- non-recoverable error
- valid name but no data
- Other WINSOCK error, code NNNNN (no string entry for code NNNNN)
To keep the network bandwidth low (especially for the server, which may
be the bottleneck then streaming audio to multiple clients over a
domestic ADSL line or even via 'mobile internet'),
the audio stream received from the radio (or "soundcard")
is first decimated to 8 kSamples / second. After that,
the low-bandwidth audio stream is passed through an A-Law
encoder. This reduces the sample width from 16 to 8 bits,
resulting in 64000 bits/second (plus some overhead for
the bytestream multiplexing) per logged-in client.
Basically, every 'Morse key up' or 'Morse key down' event is encoded
into a single byte (with the 'key up/down' state in one bit, and a
timestamp in the lower seven bits of the byte). Thus, the network
bandwidth occupied by the CW keying stream is almost neglectable.
The original timing (even when sent with a straight key and
a 'personal signature') is preserved.
Like the optional audio signal, the 'CW keying' byte stream is also
multiplexed into the single TCP/IP connection between server and client.
Details about the 'CW keying' stream format are
in the sources - see
Remote_CW_Keyer_Implementation_Details.htm#Sourcecode,
CwStreamEnc.c ("CW Stream Encoder and Decoder").
3.5 Circuit Diagrams
To operate the 'Remote CW Keyer', only minimalistic hardware is required.
There's no need to invest in any of the well-known microcontroller-based
adapters - neither for the client-, nor for the server side.
The only 'hardware' you need is either a PC with a serial port (unfortunately
out of fashion these days), or an off-the-shelf USB-to-RS232 adapter;
preferrably with an FTDI chip. Stay away from 'Prolific'-based adapters
(with PL2302 chips) due to their habit to 'phase out' drivers.
3.5.1 'Simple Paddle Adapter' with sidetone output for the serial port ('client' side)
To build an adapter between the serial port (or serial port-to-USB-adapter)
and the usual "stereo" 3.5- or 6.3-mm jack compatible with the de-facto
standard ("tip" of the plug = DOT, center ring = DASH), without the need for external power,
and with the Morse key's ground properly connected to the PC's ground:
--------_ ,-----------*------*---< DTR (DE-9 pin 4)
,-------' |__ ___ _ _ _|_ _|_ | (provides a weak
| Morse key | | | | '-' \ | | | | __|__ positive supply
| plug (male) __| |___| |_,-,_/ |4.7| |4.7| _____ voltage, ca. +5
'-------, _|^ ^ ^ | k | | k | |1 nF to +12 Volts,
-------- | | | |___| |___| _|_ software-controlled)
Ground Dash Dot | |
| | |(yellow wire) | |
| | '--------------*---------- | --------> CTS (DE-9 pin 8)
| |(green wire) | |
| '--------------------------------*---------> DSR (DE-9 pin 6)
| __|__ __|__
| _____ _____
|(black wire) | 1 nF | 1 nF
*--------------------------*-----------*---------> GND (DE-9 pin 5)
_|_ (PC ground, mains ground, 'RF ground')
"Ground" / baseplate of most keys and paddles, should never be 'floating'.
__
| |/|
Optional | ,--|-|--*-----< TXD (DE-9 pin 3)
"sidetone"| 470 nF | |\| |
output, | || | | "denoiser" against
tapped | ____ ,----||-* | up to 500 mV pk-pk
from the | |\ ,-----------|____|---, _|_ || | | voltage ripple on TXD
paddle | | \_|_ 1 kOhm | | |_\ | |\| | (see notes below)
adapter | | | | | | _-| / '--|-|--'
| | |___| "Piezo speaker", '---|- | |/| 2 * 1N4148 or similar
(side by | | / | headphone adapter, |___| silicon diodes
side with| |/ | or similar | 4.7 ... 10 kOhm
the key) | _|_ (see text below) _|_ potentiometer
'-- for "sidetone volume"
adjustment (optional)
- Note:
- Compared to other (not recommendable) circuits, where the CW key's
'ground' isn't connected to the serial port's ground (DE-9 pin 5)
but e.g. DTR or RTS, with this adapter, the voltage
on DSR (="dash"-input) and CTS (="dot"- or straight key input)
goes LOW when closing a contact.
When using the recommended circuit shown above, the "polarity"
of the digital inputs (CTS and DSR) can be inverted via software.
So 'invest' in the two pull-up resistors, and maybe three ceramic
capacitors (1 nF each, between the signal lines and gound) for
trouble-free operation, even with "stray RF" in the shack, and
for the bonus of a properly "grounded" base plate on the Morse key.
The author's 'Simple Paddle Adapter' prototype, hooked to a Kent key.
Note the "ever-changing COM port numbers" written on the DE-9 plug :o)
Here, the entire 'circuit' are two resistors soldered directly to the DE-9F (female).
Later, an RF Sniffer was added to check the radio frequency keying.
- About the optional sidetone output / "Piezoelectric speaker":
-
The piezo speaker was a PKM34EW (low-frequency type by Murata),
rescued from the junk. These are high-impedance transducers
without internal electronics (important, because the audio
frequency is generated via software, not inside the 'buzzer' / 'ringer' itself).
Such piezo speakers can be found in smoke detectors,
electronic 'greetings cards' and similar gadgets.
Low-impedance dynamic speakers cannot be used in this ultra-simple circuit
(at least not without a matching transformer) because the serial port
outputs only provide a few milliamps.
An RC low-pass filter, or just a capacitor across the speaker
may be added if the squarewave sound is unpleasant.
"Denoiser" diodes
Due to poor filtering of the +/-12 Volt charge pump driving
RS232 output signals like TXD, some USB <-> serial port adapters
produced a hissing noise on the piezoelectric speaker. This was
caused by 'digital noise' with an amplitude of a few hundred millivolts
(peak to peak). The two anti-parallel diodes in the AC coupled path
cured this, by letting only AC signals above 500 mVpp
pass to the speaker. The AC coupling (470 nF capacitor) also causes
'zero current' from, or into the TXD output when not driven
with a rectangular wave by the software.
One of the adapters with a 'hissing' noise (when used without
the two denoiser diodes) was a
"DIGITUS DA-70156 USB-serial adapter for USB2.0", EAN: 4016032271611.
Besides this minor issue, this FTDI-chip-based adapters was one
of the best in the test, with a low latency also for
the sidetone (when tapped on TXD).
3.5.2 RF Sniffer (for a radio / PA keying test with the Timing Scope)
To measure the real total delay between the key (paddle contacts)
and the transmitter "keying up", this primitive RF detector was connected
to one of the unused 'digital inputs' (Modem status lines) on the 'KEYER' port,
in addition to the Simple Paddle Adapter (SPA):
RF Sniffer (to check TX keying)
,--------*---------*---< DTR (DE-9 pin 4)
/|\ Short wire as _|_ | | (also provides a weak
/ | \ "RF sniffer" | | \|/ __|__ positive supply
| antenna, |4.7| to paddle _____ voltage, ca. +5
| see text . | k | adapter |1 nF to +12 Volts, for
| |___| (SPA) _|_ the 'paddle adapter')
__|__ |
_____ 27 pF *----------------------> DCD (DE-9 pin 1)
| / C
| |\| B |/
*--|-|--*------*----------| "Dot" from SPA --> CTS (DE-9 pin 8)
| |/| | _|_ BC548 |\ E
----- __|__ | | or _\|
/|\ _____ |1 M| similar | "Dash" from SPA --> DSR (DE-9 pin 6)
/_|_\ | |___| NPN type |
| |1 nF | |
'-------*------*-------------*----------------------> GND (DE-9 pin 5)
Diodes: 1N5711 or similar | (PC ground, mains ground, 'RF ground')
RF Schotty types, BAT41, ... _|_
The sniffer is a broadband RF rectifier driving an NPN transistor. The NPN
transistor pulls the 'DCD' (Data Carrier Detect) signal low when it detects...
well, a "carrier" (RF) in the vincinity.
With a 30 cm long "antenna" on the sniffer, a 1 Watt RF signal feeding a shortwave
dipole antenna in a distance of 10 meters was sufficient for detection.
'RF sniffer', temporarily connected to the Simple Paddle Adapter on a serial port
When sending dots at 50 WPM, with the RF Sniffer (DCD signal) selected
as source for the timing scope's 4th channel (blue trace) showed an few shorter pulses
at the begin of the transmission, but besides that, they keying seems to be ok
even for high-speed keying via the IC-7300's USB port:
RF "Keying Test" result at 50 WPM, i.e. 24 milliseconds per dot interval.
- Hint for hard- and software testing:
- When entering the speed (in WPM) manually, in the edit field
(without touching the horizontal value slider), the GUI accepts values
way above 50 WPM.
3.5.3 Simple Keying Adapter for the serial port ('remote radio' side)
Unless the transceiver has a built-in USB-to-serial-port adapter suitable for remote CW keying
(like modern Icom radios, e.g. IC-7300, IC-9700, IC-705), or that port is already occupied
by a remote control software like wfview, a simple circuit
like the one shown below can be used to "key" any transceiver:
--------_
,-------' |__ ___ _ _ To transceiver's
| Morse key | | | | '-' \ "Morse key" input,
| plug (male) __| |___| |_,-,_/ configured as
'-------, _|^ ^ ^ Straight Key !
-------- | | |
Ground Dash Dot / Straight Key
_|_ (n.c.) |
_|_
| |
| | | 100 Ohm resistor
| | | or ferrite bead
|___|
| | | 1 nF for RF blocking
*----| |----,
| | | |
22 kOhm / C _|_
____ B |/
DTR (DE-9 pin 4) >-----|____|--*----| BC548, BC337, 2N2222,
| |\ or similar NPN type
| _\| E
1N4148 ----- |
or /|\ |
similar /_|_\ |
| |
GND (DE-9 pin 5) O-------------*-------*
_|_ Ground