Add support/example for tracking an orbital target using TLEs

[dkozel]

No description provided.

[daniestevez]

Commenting here mainly to be notified of any updates to this issue, but also to share some ideas so that I don't forget them.

A possibility we've talked about is a rigctld-like interface so that Gpredict can be used. Another possibility is to include an SGP4 propagator to compute azimuth and elevation periodically. I think this second possibility is somewhat better. It simplifies usage and also keeps with the spirit of gr-ata of doing all the telescope control from within GNU Radio.

The following block might serve as an example. It uses an SGP4 propagator to compute and correct Doppler. Speaking of this, if we are to include an SGP4 propagator to compute azimuth and elevation, I think it's worth to re-use it to compute Doppler as well. The Doppler output could be tags generated periodically, so these can be used to drive a VCO for real-time Doppler correction or stored into recording metadata for correction at post-processing.

Note that there are many SGP4 implementations out there and the one I linked above might not be the best one.

[daniestevez]

Another comment relevant to TLE tracking and other kinds of tracking that might need a high update rate is how does the control work under the hood. I've seen that in some circumstances each update will run a command by SSH on a remote host.

My main point is that apparently tracking a fixed RADEC (which needs to slew the AZEL constantly) works by preparing some kind of ephemeris file and then sending a single command. After this, tracking works autonomously with no need for updates from gr-ata. Depending on the architecture of the telescope control and how easy is to modify other software running at the telescope, it might be best to implement TLE tracking elsewhere and then just call that from gr-ata.

[wfarah]

Hi @daniestevez. The low-level functionality to track TLEs already exists, and the end-user/observer should not have to worry about updating ephemeris nor the inner workings of how antennas track celestial/orbital objects. The high-level interface is not yet built into GR-ATA, but it's a very straightforward functionality to add.

[daniestevez]

Thank you Wael! Then that's definitely the way to go.

Is there somewhere where we can read about what functionality is supported by the tracking system? I'm also interested in tracking deep space satellites. For most of these, using RA and DEC (with infrequent updates) is enough, but some are near enough from Earth for the diurnal parallax to be noticeable, and so need a tracking method that takes into account the observer's position on the Earth's surface.

[siemion]

I poked around a bit, ATA uses a java interface (https://svn.hcro.org/ata/branches/Rev020108/src/ata/PredictServer/) to PREDICT (https://www.qsl.net/kd2bd/predict.html). It looks like the PREDICT code hasn't been updated in some time, but we'll need to check what branch is actually in production use currently to be sure.

[dmkunsman]

This still open. Is there anything I could do to help with this?

[wfarah]

Hi @dmkunsman. The support to this has been added to an earlier version of ATA-Utils. This issue should be closed.

[daniestevez]

ATA-Utils supports TLE tracking by doing something like

from ATATools import ata_control as ac
ac.make_and_track_tle('/home/destevez/noaa19.tle', ['2h'])

However, gr-ata doesn't currently use this functionality. While most of us are using ATATools directly in Python scripts or through wrappers, it would be nice to support TLE tracking in gr-ata to provide a very simple way to set up an observation completely within a GNU Radio flowgraph.

[wfarah]

Ahh, thanks @daniestevez, I thought this change has already been incorporated in gr-ata. I wouldn't think it's a terribly hard thing to incorporate in the "control block" of gr-ata, as the infrastructure exists in the ATA control software stack.

I'm re-opening this issue.

[dmkunsman]

Is there anything I could do to help with this?