I’ve had some discussions with Fredy on the IRC channel about this, and I figure I should get my thoughts written down somewhere more permanent. Parking the rotator after a pass is definitely one way to get closer to solving the problem, but I’m pretty sure it’s going to work in all cases.
As a bit of background, I have a RF HamDesign SPX-02, which also uses the Rot2Prog controller. The SPID protocol allows reporting of positions from -180 degrees through to 540 degrees (360+180 degrees), and in fact this is what hamlib will return when polled for a position. When the rotator is outside of the 0-360 degree range, it is considered to be in an ‘overwind’ region. As observed by SQ2DK above, it appears that you cannot command an ‘absolute’ position to the rotator (i.e. tell it to move to -50 degrees). Instead, the rotator will take the ‘shortest path’ to the commanded position.
(As an aside, this behaviour results in the rotator movement thresholding being ignored if the current rotator azimuth is outside the 0-360 range - the solution is simply to modulo the reported azimuth with 360 before the threshold comparison is made - I’ve got this running on my station, and all I had to do was insert a % 360.0 after the float(position) type conversion on this line: https://gitlab.com/librespacefoundation/satnogs/satnogs-client/blob/0/satnogsclient/observer/worker.py#L183 )
Anyway, to be able to avoid the rotator hitting the limits during a pass, we need:
- To know where the limits are. These would need to be set as configuration parameters (i.e. a ‘start’ - in my case -180, and ‘stop’ - in my case 480 - limit)
- To have the rotator report the rotator position accurately, including whether it is in an overwind region. The SPID protocol does this nicely, and hamlib passes the information along. The Yaesu GS232 protocol will report positions 0-450 degrees (a limit of the G-5500 rotator). I don’t know what other rotators do.
So, my idea is that at the start of each observation, a check is done to determine:
- What the current rotator position is, and where it will end up when we command it to move to the start position for the pass.
- If the pass requires the rotator to spin in a clockwise or counter-clockwise direction.
- What the final azimuth will be, and based on the spin direction, if this will cause it to hit a limit.
I believe the pass information should be fairly easily calculated - the ‘Worker’ class already has the TLE information, a few quick calculations can be done to determine the azimuth movement over the pass.
From this we have two outcomes:
- A limit will not be hit during the upcoming pass. In this case we just move to the start position and continue as normal.
- A limit will be hit during the pass. In this case we need to ‘unwind’ the rotator, and move to the start position via the ‘long path’. Since it doesn’t seem that we can directly command the rotator to do this, it would have to be performed as a sequence of shorter movements, perhaps in 90 degree steps. Once this is done, tracking throughout the pass should be able to be performed as normal.
This way, the ‘unwinding’ action can be performed at the start of the pass, when it has the least impact on reception.
Hopefully this has meant something to someone.