SatNOGS Rotator Unwinder

SatNOGS Software
1

Hi all,

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.

See here: https://github.com/darksidelemm/satnogs-unwinder

From the repo:

Motivation

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?

Solution

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.

73
Mark VK5QI

4 Likes
2

Great work Mark. Very cool.

3

I’ve been coming across the same problem.

I’ve addressed the actual flip by modifying the firmware so it can implicitly deal with the overwind situation in both directions. I will make those modifications available. It works the same way that rot2prog does - it simply looks for the shortest path. For unwinding it remembers the state and a simple RESET of the rotor will move it to the real 0/0 position. This information is also preserved in EEPROM for power outages and reboots.

Now what is still missing is a pre position so the pass can make the best use of the available angle. I could put this into a post observation script as suggested - what I dislike here is that this would not work for observations that are scheduled in the more distant future or on very short notice (i.e. no more observation occurs before them). It would make much more sense to do this in a pre observation script - but given the reset and pre positioning can take a minute or two, this would lead to potential data loss during the pass.

My current thinking is, that it would be best to allow the pre observation script to be run with a T- offset instead of running it right at the start of the observation. This offset could be configured along with the script on the ground station.

I am happy to create a pull request for this, but wanted to make sure that I am on the right track, or if there are better ways to do this? One potential downside of configuring this straight on the ground station could be that the network does not know that the ground station is not available for the observation but also for whatever time has been configured as offset before the observation. So it might need to be configurable on the network (similar to the minimum horizon?) and should translate down into the client?

Would be great to get input from the client/network developers here. @Acinonyx

4

I guess the danger here would be in back-to-back observations. You’d have to check if an observation is currently in progress, though I guess that isn’t too hard to do. At the moment the post-observation script I wrote will not move if the next observation is within about 3 minutes, it won’t move (this time can probably be shortened).

With my rotator system (-180 through +540 degrees of movement) at least, I’ve found that moving back to a ‘home’ location (in my case 0 degrees) works fairly well if you don’t have any upcoming pass information. I suspect moving to 180 degrees is probably a better option though. The important bit is that the rotator has enough overwind capability to not hit an endstop during a pass.

5

see also Solved the meridian flip problem

6

I’ve read that one before posting. It just addresses the same firmware changes required that I described here. I am happy to create a pull request for those to fix this issue.

However the required changes to have this supported all the way through are then still missing in the satnogs-client and potentially in the satnogs-network. I am not asking for somebody to do the coding on these - I am looking for guidance as to the best solution. Given that I do not know the codebase in-and-out, I don’t want to go down a wrong path. Once we agree I am happy to work on the code required for this.

1 Like