I have recently started new station SP2ZIE. SatNogs proved to be fantastic tool for testing our station and we have found more than one problem with it thanks to Satnogs. Some of the problems we are currently working on, some will require more investigations.
One of the issues we are having with controlling station is managing rotator. We are using SPID RAS with Rot2Prog controller under rotctld. It is obvious, that rotator has to have some short of limits of their travel not to damage cables. Although having range of 720deg travel, when used to track satellites in uncontrolled way, you will quickly find rotator at the limit. I was trying to find a way to park rotator in the central position after each observation, but it is trickier than I thought. Even if I will tell rotctld to go to 180deg after each observation, it will try to go whichever way is shorter (if rotator is in position -10deg (350), it will travel to left (170 deg to travel), rather than to right (190deg to travel), thus reaching limit, rather than centre position).
Here is a question:
Is there a way in SatNOGS / rotctl to park rotator in center position and monitor its position in not only 0-360 deg, but also in -180deg - 540deg, so to have better control on the actual position (number of turns it made) of the rotator?
Sorry to make it that complex question
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[0]) 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.
There has been some changes since my last post. I have found out, that my rotator model was most likely early design and in fact had limit switches allowing only 20deg overlap (380deg turning). Because of that, electronic limits (in Rot2Prog) were not even activated. After removing physical limit switches I found out, that rotator controller actually allows for the electronic limits in such a way, that if it is ordered to rotate beyond programmed limits, it will rotate in other direction. For example: if your limits are +90deg and –90deg and your rotator is set to 000deg and you will give command to go to 260deg it will not go shorter way left to –100, but it will chose longer way and turn right whole 260deg. This led me to think of some sort of the solution. If I will set limits on +175 deg and –175deg, then if I will command my rotator to go to 180deg it will always set in the middle and till be able to turn 355deg each way. This should be sufficient for any sort of satellite observation, however it will require to park rotator at 180deg after each observation. This will requite up to 2-4minutes and ideally you would need to allow some 2 minutes before each observation (for the rotator to be set to correct azimuth at the begin of each observation). This would require 4-6 minutes between each observation.
Obviously, it would be best to be able to do “smart” management of the rotator as Mark has pointed out. There is no point in “parking” rotator if next observation is not getting to limits of our rotator and thus resulting in less wear on rotator and cables. But this would require some clever programming and knowledge of the future passes and exact position (absolute) and limits of the rotator. I’m sure it can be done, but for now I would be happy with “quick and dirty” solution with parking rotator in the center.
It looks like I’m a bit late to the party, but I’m having a similar issue with my rot2prog controller and was wondering if there were any updates or solutions here.
