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.
remoteRotator supports the following protocols:
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.
- NATS (preferred)
- HTTP + Websockets + MDNS (will be deprecated)
remoteRotator is published under the permissive MIT license.
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.
remoteRotator does not have any runtime dependencies.
remoteRotator provides a series of nested commands and flags.
$ ./remoteRotatorNetwork 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 --helpThe 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 yaesuno 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
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-enabledno 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
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.
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.
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,
toml, or
json.
The first line after starting remoteRotator will indicate if / which config file has been found.
If you have several rotators, you have to create a configuration file for each of them and specify them with the --config flag.
Priority:
- Pflags (e.g. -p 4040 -t dummy)
- Values from config file
- Default values
If an error occurs from which remoteRotator can not recover, the application exits. This typically happens when the connection with the rotator has been lost or if the rotator is not responding anymore. It is recommended to execute remoteRotator as a service under the supervision of a scheduler, like systemd.
Please use the Github Issue tracker to report bugs and ask questions! If you would like to contribute to remoteRotator, pull requests are welcome! However please consider providing unit tests with the PR to verify the proper behavior.
If you file a bug report, please include always the version of remoteRotator you are running:
$ ./remoteRotator versioncopyright Tobias Wellnitz, DH1TW, 2020
remoteRotator Version: v0.6.0, darwin/arm64, BuildDate: 2021-04-18T03:35:42+02:00, Commit: 00fe466
The auto-generated documentation can be found at pkg.go.dev.
To compile remoteRotator from the sources, you need to have Go >= 1.16 installed and configured.
Install the dependencies if you haven't already
$ sudo apt-get install git build-essential upxDownload, prepare and compile remoteRotator under Linux/MacOS:
$ mkdir -p $GOPATH/src/github.com/dh1tw && cd "$_"
$ git clone https://github.com/dh1tw/remoteRotator.git
$ cd remoteRotator
$ go get ./...
$ make install-deps
$ make generate
$ makeAll critical packages have their own set of unit tests. The tests can be executed with the following commands:
$ cd $GOPATH/src/github.com/dh1tw/remoteRotator
$ go test -v -race ./...The data race detector might not be available on all platforms / operating systems.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent