Using the eightolives' RadioRemote Server
Download RadioRemote Server (Linux)
Eightolives RadioRemote Server supports the remote control of an Elecraft KX3 radio. It requires the radio's ACC1 serial port connector to be properly connected to a computer's USB port using a serial link adapter cable such as the Elecraft KXUSB cable. This allows control of the radio from any modern, logged-in, web browser using the eightolives RadioRemote User Interface (UI) web app. The UI web app also handles the audio signals connected from the radio to the computer.
If the computer is connected to a local network, another computer, pad or smart phone can log-in and remote control the radio. You can optionally configure the local network to allow platforms on the internet to connect.
PrerequisitesThe program requires installation of NodeJS, an open source, Javascript runtime environment that is available for Linux and Windows computers. You can download NodeJS from https://nodejs.org.
The software can be executed from the command line, however, a simple GUI that displays only a STOP button can be optionally run if your computer supports Python3 or Tcl/Tk.
In Linux, the serial port is part of the "dialout" group. You, the user, need to be part of that group (sudo adduser $USER dialout).
InstallationThe RadioRemote Server is provided as a zip file that you download and unzip in a directory. Configuration data is "hard coded" so you must edit certain files if you do not run the default settings.
The permissions.js file specifies who can log-in to the server so you should edit this file first. Three roles are defined - CONTROLOP, GUEST and OPERATOR. The CONTROLOP has transmitting priviliges and must specify the callsign of the station, the applicable license class, and passphrase for a valid log-in. A GUEST has receive-only privilege and is intended for SWLs. An OPERATOR has transmit capability and must specify his call and license.
Three files can be used to start the server: runRadioRemote, server.py or server.tcl. Each contains default configuration data. You may need to edit these items if your setup is different. These files specify the IP port for the server (default = 3001), certificate file names (default = server.key and server.cert), the expiration date text file (default = keydates.txt), USB serial port pathname (Linux default = /dev/ttyUSB0) and KX3 serial baud rate (default = 38400).
The server uses an SSL certificate to communicate on the network in a secure context. A time-limited, self-signed certificate is provided as the default. The certificate consists of files server.cert and server.key. An associated "helper" file lists the expiration date which is displayed each time you start the server. You can create your own self-signed certificate using openssl available at https://www.openssl.org/ along with the makeCredentials script included in the directory.
One drawback of using a self-signed certificate is that web browsers will flag dire warnings that it cannot verify its pedigree. You can "tell" your browser it's OK to accept the certificate by clicking a few buttons as described in more detail below.
You can also obtain a "real" certificate from a third party on your own. We do not provide support for that endevour.
Starting, Running and Stopping the ServerThere are four ways to start the server:
- On the command line enter "./runRemoteServer". All status is written to the command window. You exit by entering CTRL-C on the command line.
- On the command line enter "./server.py" or "python3 server.py". (If python3 is not defined or if "python" is python3 change the first line of server.py to reflect "python") A window with one STOP button appears. All status is written to the command window. You exit by clicking the STOP button.
- On the command line enter "./server.tcl". A window with one STOP button appears. All status is written to the command window. You exit by clicking the STOP button.
- On the command line enter "./autostart.sh". Both the server and the "primary" browser will start. You can also add that link to your operating system's autostart feature.
The web browser needs to accept the self-signed certificate before the RadioRemote User Interface can connect to the radio. The RadioRemote Server supports a simple https server that uses the self-signed certificate. Trying to connect to the server to get file index.htm will invoke the browser dialog to accept the certificate. For the server shown in Figure 1, using the url https://192.168.1.159:3001/index.htm will either start the dialog for acceptance or display a confirmation that the certificate was accepted. The actual Local Network Certificate Test Link is displayed when you start the server.
When you start the RadioRemote User Interface in a browser, if no server is found, enter the appropriate server IP address and port in the Setup Menu popup. Click "Select" then click "Test". The "Test" button will try to open the Certificate Test Link for the entered data and either invoke a dialog to accept or report acceptance of the certificate.
What does the server do? The server provides a few services supporting the remote control functionality.- Interface to the radio's USB serial link cable using the WebSerial API.
- Secure Websocket Server permits communication between connected browsers and the radio's serial link using WebSocket API
- Signalling server using WebSocket to support WebRTC API audio transfers by connected browsers.
- HTTPS server to support self-signed certificate acceptance.
- Log-in services.
To interface to the internet, the local network router must be configured to permit Port Forwarding. This allows access to the specific local IP address and port number from the internet. Exact procedures for setting Port Forwarding vary by local network server models.
The RadioRemote User Interface displays the external IP address to be used to access the server.
Network routers sometimes assign IP addresses dynamically meaning that a computer's IP address can possibly change under certain conditions. The network server must also be set to permit a static IP address to be assigned to the RadioRemote server's computer.
Allowing GUEST permission to be accessible by anyone on the internet is probably not a good idea. Even though a GUEST only has receive access, permitting anyone to fiddle controls on your radio is not prudent.
Operating ConsiderationsThe server and associated browser on the connected computer must be powered and operating during any times when the features may be used. If no interface is available to power on the radio, the radio would also need to be powered. RadioRemote Issues