Integrate rotor control

[tomaszmrugalski]

We now have SPX-02 rotor and a nice X-Quad directional antenna on it. Now we need to start using it.

The general interface is that rotctld needs to run in the background. However, we need to send commands to it to do couple things:

• rotate it to point to the current sat position (this is to be repeated many times, every couple seconds during fly-over)
• (optional) get rotor position (this will be super useful for plotting the tracking accuracy plots, more on that later)
• after the reception is over, we need to park the antenna

The getting rotor position is optional, but would be very useful. We could have a polar and alt-az plot with 3 lines on it:

1. the actual sat position
2. the direction the antenna was told to point
3. the actual direction the antenna was pointing

This way we could make pretty deep analysis of the pointing accuracy and optimize the algorithms (do we have to change position every X seconds? Or maybe this should be angle based? or...)

Once the rotor control is implemented, we need to integrate this into reception automation. I think one nice way would be to define PRE_OBSERVATION_SCRIPT and POST_OBSERVATION_SCRIPT, which would be called before and after observations. This is generic enough, so other actions could be defined in the future. Looking at what Satnogs supports, some more fancy radios have tuning control that is also done in similar way (see rigctld tool). It's too advanced for us for now, but it's good to have the option available in the future.

[fivitti]

Maybe we should write a separate program to control the rotor? The program will accept as arguments AOS, LOS, and some orbital parameters (TLE?). Next from AOS time to LOS time, it will set azimuth and elevation to track the satellite.

At the start recipe, we call the control program in the background and next perform standard reception. Probably we shouldn't run the recipe at AOS time, but a few seconds before, because the rotor needs some time to set the start position.

We need to analyze if rotor control should be part of a recipe or separate code. I think that recipe should work correctly even if the rotor isn't connected to the station (as far as it doesn't increase code complexity).

[fivitti]

Another proposal is the rotor controller as a separate program/script registered in CRONtab simultaneously (with a small margin) with the receive.py script. In this case, the recipe solution isn't related to rotor controlling code. The controller may be tested separately from the rest of the station code.

[tomaszmrugalski]

I agree it should be a stand alone program. I don't think having separate cron jobs for it would be a good idea. You'd get into all sorts of race conditions, misconfigurations (just the receiver job running or just the rotor control running)...

[tomaszmrugalski]

Here's a list of potential tools:

• skytrack - can integrate with gqrx and control rotctld, but it's for celestial objects (Moon EME transmissions, listening to Saturn storms etc). Does not support TLE.

[tomaszmrugalski]

I've wrote a design proposal for the rotor controller. Hey @fivitti, can you take a look?

[fivitti]

I added Option 3 that merges Option 1 and 2. I think that Option 1 should be a core solution. Option 2 may be an additional tool for users (but probably not for the station code).

[tomaszmrugalski]

Cool. I'll get this thing going!

[tomaszmrugalski]

The rotor control now lives on its own as a separate project: https://github.com/gut-space/svarog-ctl