This prevents offsets from being able to point below the elevation
mask. The way this is done should probably be reworked, but this whole
thing is such a messy hack anyway that, like, whatever, man.
Rather than having somewhat confusing flipped logic when the rotator is
operating in the 180-90 degree elevation regime, this internally
performs sign flipping. This means that a 3 degree elevation offset
means "point an additional 3 degrees up from the horizon" regardless
of whether the rotator is operating in the 0-90 or 180-90 elevation
ranges.
The serial interface on the MD-01 seems to be extremely slow (this is
with USB serial, though the RS232 ports probably have the exact same
issue. It seems that sending requests too quickly may negatively
impact the performance of the controller/rotator (i.e. makes it shake
more)? I'm not exactly sure this is the correct conclusion, since our
timings do not compensate for the actual communication time with the
MD-01 (i.e. the 100ms poll rate sends the next request at least 100ms
after it has received a reply). However, based on empirical testing,
running these at a lower pace (perhaps particularly, the command
frequency?) seems to make a big difference in the amount of shake
observed. We will need to keep an eye on this over time.
This is done synchronously, but assumed to be fast enough that it won't
cause problems for the event loop. I may try to use the libxev file
abstraction in the future but this is the real fast way of
implementing it. This codebase is a mess, and that's an endorsement.
These are coupled in a somewhat nonintuitive manner. Previously, we
would send a command every other request. Due to an oversight, we were
only sending a request once per second, which meant we were reading
position once every two seconds and writing position once every two
seconds. However, this seemed to work pretty well (at least the radio
performance was largely improved and qualitatively it seemed like the
controller was doing a better job of keeping up with the pointing
target).
I wanted the UI to update the position more frequently, so we keep the
scheme of sending a command every N requests, but we send
significantly more get position requests. These can be adjusted on the
fly in order to get an idea of how much the communication pattern
actually impacts the pointing performance.
This is very messy. I forgot how much callback-based async programming
sucks, especially without closures. Now I need to slap together the
UI.
This essentially has a "fixed" rate poll loop that alternates between
setting the position and getting the position. We return mangled
positions through the interface for display purposes, so this might be
usable.
I will never get tired of vendoring dependencies. ha ha. It is possible
I am insane. I had to do a lot of pruning to get these not to be
ridiculous (especially the unicode data, which had nearly 1 million
lines of... stuff).
