Over the Jan-Aug 2016 period many additions were added to the K3 configurations.
The following was configured over the term:
- Remote Rig remote control system implementation
- Interlocking mini-whip
- Local telnet skimming
- N1MM and CWSkimmer Remote Rig serial passthrough
- Coax replacement on panadapter
- Problems with v2.9.0 firmware and Remote Rig platform
Remote Rig Remote Control System Implementation
The remote rig was implemented by following Section __ of the following PDF:
The serial configuration was done as follows: K3->P3 Panadapter->Remote Rig->Computer
On the P3/0 control unit, the following settings were changed from default: _____
Without these settings, the dual receiver, serial passthrough and CW keyer did not function.
The files below contains a snapshot of all the setting configurations made on the Remote Rig units: ___
Problems with v2.9.0 Firmware and Remote Rig platform
The following main problems exist with the v2.9.0 iteration of the Remote Rig system:
- Serial passthrough
- Device instability causing audio dropouts
- UDP protocol
The documentation provided with the Remote Rig lacks in explaining what various dropdown configurations do, does not provide example configurations and the online form does not properly explain if solutions were for previous firmware revisions.
Inside the Remote Rig web interface, the software has various critical dropdown menus to select various operation parameters. For example, the two figures below show the serial settings for the Remote Rig attached to the lab’s K3:
Nowhere in the PDF documentation provided with the Remote Rig is it explained what these drop down options do or are examples provided.
In order for software on the computer to control the K3, serial commands must pass through the Remote Rig. In theory, the Remote Rig is supposed to act as a transparent man in the middle, sending its own serial commands to the K3, while allowing K3 to communicate to the computer. This does not actually happen in reality. Through trial and error, it was discovered that the K3 must be attached to the P3 panadapter, the Remote Rig connected to the P3 panadapter and the computer connected to the Remote Rig. In theory, this order should not matter, but with the P3 and Remote Rig positions reversed, the computer nor the panadapter would be unable to retrieve the current frequencies off of the K3, rendering software like N1MM and CW Skimmer inoperable.
It has been observed that the Remote Rig needs to be rebooted periodically to resolve audio dropouts. Although the Remote Rig can be configured to periodically reboot, this has not been enough to fix the audio dropout issue. The audio dropout is periodically spaced instances where no audio comes out of the K3/0 remote. To resolve this issue, rebooting the Remote Rig connected to the K3 resolves.
The UDP protocol used by the Remote Rig caused two main issues:
- Packet filtering / traffic shaping by UVic and public internet
- Control over mesh
Packet filtering / traffic shaping by UVic and public internet
It was found via WireShark and Sophos UTM’s monitoring software that UVic’s traffic shaping appliances were filtering out UDP packets originating from the Remote Rig. Since the Remote Rig uses SIP packets, an industry standard protocol for VOIP, the traffic shaping should have detected the SIP traffic and not filtered it. I hypothesize (but never confirmed due to the VPN solution I ended up using) that this is because they are custom implementing SIP, modifying the standard SIP packets into something custom.
Control over mesh
The issue with UDP over TCP is that the devices never confirm if the packets they send are received or not. This is an issue over a mesh or long range network as packets occasionally drop, and are not re-sent by the mesh devices if the link drops enough. This is because it would not be economical to include enough of a buffer on the device to cache 20MBps+ data rates during periods where the link is broken.