torque
61c10df63d
This should have been multiple commits, but it isn't. Sue me. This change has two main goals: 1. Sample feedback at the beginning of the control loop iteration so that it is always up-to-date when we are computing the actual drive outputs. This means we're doing twice the amount of communication with the labjack (previously, setting the output and reading the feedback was done with a singe command). However, this makes the loop structure much more standard, and it means that we aren't constantly operating on feedback that is stale by one loop interval. 2. Sample feedback into a (configurable size) buffer. This lets us operate on aggregated feedback rather than on a single instantaneous data point. Right now, feedback is computed as a moving average, which acts as a rudimentary low-pass filter, reducing spurious single-loop actions due to feedback spikes or other noise. However, the other reason to aggregate some backwards data is that it will let us do automatic stall detection in a simple way, although that is not currently done.
Yaesu Rotator Driver Shim
The Yaesu G-5500DC rotator is a nice piece of hardware, but it has an analog (0-5 V) control interface and requires a separate GS-232B box for computer serial control (which will run you a nice $600 for a new unit). Someone used to sell an adapter board for the Labjack U12 (which basically consists of a DIN-8 jack, a darlington transistor array, and a few resistors + LEDs), which provides precise computer control of the G-5500DC at a much lower cost.
However, the Labjack U12 is just basic 12-bit data acquisition device that is not specifically made for controlling a rotator, so common satellite tracking software (e.g. hamlib) does not support it as a Yaesu rotator interface.
Fortunately, labjack provides an open-source libusb-based driver for the Labjack U12, which makes it eminently possible to expose this hardware stack as controllable through the hamlib protocol (or, more precisely, a simulacrum thereof).
Implementation
I mostly just want this to run on Linux, as a static executable. The zig build system is good.
Dependencies are fully vendored.
Build
Requires zig version 0.13.x to compile.
zig build
Unfortunately, all platforms have additional steps that must be taken (some easier than others) in order to run the program successfully.
Windows
This compiles for, and runs on, Windows. However, in order for it to work out of the box, it has to link against the (proprietary) Windows LabJack U12 driver instead of the open source libUSB driver. This has two main limitations: the Windows driver is only available for the x86 and x86-64 architectures, and it is exclusively distributed as a dynamic library, meaning that yaes.exe must be distributed alongside ljackuw.dll. When building for Windows targets, the appropriate library file will be copied to the binary installation directory (zig-out/bin by default).
macOS
This works on macOS, though it has to be run with sudo, as access to the USB hardware at user privilege level is gated by entitlements. Using entitlements is in turn gated by signature with an Apple Developer Certificate and Notarization, which may only be acquired with a paid Apple Developer Program subscription. If you have those, great. The provided yaes.entitlements is almost certainly not the correct set of entitlements, since I can't test it. Just run it with sudo whilst praising Tim Apple for the Most Advanced Operating System on the Planet.
Linux
You probably need to install the included udev rules file in order for the USB device to be accessible as a user. This is buried in the source tree as deps/labjack/exodriver/90-labjack.rules. These should probably go in /etc/udev/rules.d if you are installing them manually and I have properly understood the various Linux folder conventions.