RemoteRotator

remoteRotator is a command line application that makes your azimuth / elevation antenna rotators available on the network. It is available for Linux/Windows/MacOS and is written in the programming language Go.

To get a first impression, you're welcome to play with our public demo at demo.rotator.shackbus.org.

Supported Rotators

remoteRotator supports the following protocols:

• Yaesu GS-232A
• Yaesu GS-232B

This is a list of rotator controllers that are known to work well with remoteRotator:

• Yaesu Control Interfaces
• K3NG Open Source Rotator Controller (implements Yaesu GS232A)
• RemoteQTH Azimuth Rotator Interface (K3NG firmware)
• EA4TX ARS (implements Yaesu GS232A)
• ERC Easy-Rotator-Control (implements Yaesu GS232A)
• CG Antenna RTC-200 (implements Yaesu GS232B)
• Dummy rotator (great for playing around with remoteRotator)

If your rotator controller is not supported, feel free to open an issue. It is relatively easy to add more rotator controllers / protocols.

Supported Transportation Protocols

• NATS (preferred)
• HTTP + Websockets + MDNS (will be deprecated)

License

remoteRotator is published under the permissive MIT license.

Download

You can download a tarball / zip archive with the compiled binary for

• MacOS (amd64)
• Linux (arm,386,amd64)
• Windows (386,amd64)

from the releases page.

remoteRotator works well on SoC boards like the Raspberry / Orange / Banana Pis. The application is just a single executable.

Dependencies

remoteRotator does not have any runtime dependencies.

Getting started

remoteRotator provides a series of nested commands and flags.

$ ./remoteRotator

Network interface for Rotators

Usage:
  remoteRotator [command]

Available Commands:
  enumerate   discover and list all available rotators on the network
  help        Help about any command
  server      remoteRotator Server
  version     Print the version number of remoteRotator
  web         webserver providing access to all rotators on the network

Flags:
      --config string   config file (default is $HOME/.remoteRotator.yaml)
  -h, --help            help for remoteRotator

Use "remoteRotator [command] --help" for more information about a command.

So let's fire up a remoteRotator server for your rotator:

First, identify the serial port to which your rotator is connected. On Windows, this will be something like COMx (e.g. COM3), on Linux / MacOS it will be a device in the /dev/ folder (e.g. /dev/ttyACM0).

All parameters can be set either in a config file (see below) or through pflags. To get a list of supported flags for the lan server, execute:

$ ./remoteRotator server lan --help

The lan server allows you to expose a rotator on your local area network.
By default, the rotator will only be listening on the loopback adapter. In
order to make it available and discoverable on the local network, a network
connected adapter has to be selected.

remoteRotator supports access via TCP, emulating the Yaesu GS232A protocol
(disabled by default) and through a web interface (HTTP + Websocket).

You can select the following rotator types:
1. Yaesu (GS232 compatible)
2. Dummy (great for testing)

remoteRotator allows to assign a series of meta data to a rotator:
1. Name
2. Azimuth/Elevation minimum value
3. Azimuth/Elevation maximum value
4. Azimuth Mechanical stop

The metadata enriches the rotator representation in the web interface 
for example by colorizing the rotator range or indicating the mechanical stop.

Usage:
  remoteRotator server lan [flags]

Flags:
      --azimuth-max int        metadata: maximum azimuth (in deg) (default 360)
      --azimuth-min int        metadata: minimum azimuth (in deg)
      --azimuth-stop int       metadata: mechanical azimuth stop (in deg)
  -b, --baudrate int           baudrate (default 9600)
      --discovery-enabled      make rotator discoverable on the network (default true)
      --elevation-max int      metadata: maximum elevation (in deg) (default 180)
      --elevation-min int      metadata: minimum elevation (in deg)
      --has-azimuth            rotator supports Azimuth (default true)
      --has-elevation          rotator supports Elevation
  -h, --help                   help for lan
      --http-enabled           enable HTTP Server (default true)
  -w, --http-host string       Host (use '0.0.0.0' to listen on all network adapters) (default "127.0.0.1")
  -k, --http-port int          Port for the HTTP access to the rotator (default 7070)
  -n, --name string            Name tag for the rotator (default "myRotator")
      --pollingrate duration   rotator polling rate (default 1s)
  -P, --portname string        portname / path to the rotator (e.g. COM1) (default "/dev/ttyACM0")
      --tcp-enabled            enable TCP Server
  -u, --tcp-host string        Host (use '0.0.0.0' to listen on all network adapters) (default "127.0.0.1")
  -p, --tcp-port int           TCP Port (default 7373)
  -t, --type string            Rotator type (supported: yaesu, dummy (default "yaesu")

Global Flags:
      --config string   config file (default is $HOME/.remoteRotator.yaml)

So in order to launch remoteRotator on Windows with a Yaesu rotator connected at COM3 an having the web HTTP server listening on your local network, we would call:

$ remoteRotator.exe server lan -w "0.0.0.0" -P "COM3" -t yaesu

no config file found
2017/12/08 16:50:25 added rotator (myRotator)
2017/12/08 16:50:25 Listening on 0.0.0.0:7070 for HTTP connections

Connecting via TCP / Telnet

If you have an application (e.g. arsvcom or pstrotator) that can talk to a Yaesu compatible rotator, you can point that application to remoteRotator's built-in TCP server (although disabled by default).

Let's start a dummy rotator instance on Linux and enable the build-in TCP server:

$ ./remoteRotator server lan -t dummy --tcp-enabled

no config file found
2017/12/08 16:50:25 added rotator (myRotator)
2017/12/08 16:50:25 listening on 127.0.0.1:7070 for HTTP connections
2017/12/08 16:50:25 listening on 127.0.0.1:7373 for TCP connections
2017/12/08 16:50:25 discovery disabled; the HTTP server must listen on an accessible network interface (e.g. 0.0.0.0)

For testing, we connect directly via telnet:

$ telnet localhost 7373
Trying ::1...
Connected to localhost.
Escape character is '^]'.

?>C
+0303
C2
+0303+0000
M310
+0303+0000
+0304+0000
+0305+0000
+0306+0000
+0307+0000
+0307+0000
+0308+0000
+0309+0000
+0310+0000

Web Interface

A more comfortable way of accessing the rotator is through a web Interface. You can specify the host and port in the settings above, or deactivate the built-in webserver if you don't need it.

The red arrow indicates the heading of the rotator and the yellow arrow indicates the preset value to which the rotator will turn. The yellow arrow disappears when the desired direction has been reached.

The dotted red line indicates the mechanical stop of the rotator. A green arc segment indicates a limited turning radius for this rotator. A blue arc segment indicates the mechanical overlap supported by this rotator. These indicators are just visual helpers and are configurable through command line flags or in the config file.

Web Interface (Aggregator)

If you have multiple rotators, you might want to use the dedicated aggregation web server. The following example starts the webserver on port 6005 and listens on all network interfaces.

$ remoteRotator web -w "0.0.0.0" -k 6005

The Webserver automatically discovers the available remoteRotator instances in your local network and adds them from the web interface. Depending on which transport you have chosen, the discovery process is either done through MDNS (lan) or NATS. The discovery functionality doesn't require any configuration.

Config file

The repository contains an example configuration file. By convention, it is called .remoteRotator.[yaml|toml|json] and is located by default either in the home directory or the directory where the remoteRotator executable is located. The format of the file can either be in [yaml](h