I’ve written a bit of code to ‘unwind’ the rotator I use on my SatNOGS station after a pass, which will hopefully lower the risk of the rotator hitting a limit during a pass and having to do a 360 degree ‘unwind’ motion in the middle of a pass.
From the repo:
I operate SatNOGS station #232. It uses a RF HamDesign SPX-02 rotator, with a SPID Rot2Prog controller, and my setup is configured to provide 640 degrees of travel (-180 through to +460 degrees, where <0 degrees and >360 degrees is an ‘overwind’ region).
While hamlib’s rot2prog driver will quite happily report the ‘absolute’ position of the rotator (i.e. if it’s in an ‘overwind’ region it will report <0 or >360 degrees), you cannot set an absolute position. Instead, hamlib will direct the rotator to take the shortest path to the provided position.
Unfortunately, this behaviour can lead to the rotator ending up in a ‘wound-up’ state where on the next pass, the movement of the rotator ends up moving into the overwind region and hitting a limit, and the rotator has to do a 360 degree spin to ‘unwind’ continue to track the satellite. On my rotator, it can take almost 2 minutes to perform this action, and results in big signal gaps (see https://network.satnogs.org/observations/316507/). Wouldn’t it be good if we do this long ‘unwind’ movement before the pass?
This problem has been discussed in a satnogs-client issue (see https://gitlab.com/librespacefoundation/satnogs/satnogs-client/issues/275), and I’ve suggested a fix in the LibreSpace forum (see Rotator control - Parking ). As a means of testing out a possible solution, I’ve created the
unwind.py script in this directory. It’s not an ideal solution, but it’s a starting point.
In short, since we can read the absolute rotator position from the Rot2Prog, we can move to a desired absolute position by moving in a sequence of small steps. I’m using steps of 90 degrees. This can be used to move back to a ‘home’ location, or even better - move to the start of the next observation!
SatNOGS provides the handy
SATNOGS_POST_OBSERVATION_SCRIPT option, which can be used to run a shell script after an observation has finished (duh). We run a script there which will move the rotator to the start of the next observation ahead of time, or alternatively move to a home location if there are no observations in the near (1 day) future.
Check out the repo for information in usage. I’m hoping to continue developing on this, and add in the ability to calculate the expected movement of the rotator during the next pass. This will help in determining the appropriate start position, which may be in an overwind region for some passes. I expect the developing of these algorithms may prove useful in adding a similar feature into the satnogs-client codebase in the future.