Request : Add other celestial bodies

[stuartdweston]

From the FS we can call "Sun", "Moon".

Can we add the other celestial bodies like Venus, Jupiter etc. They are nice and radio bright as well.

Thanks

[wehimwich]

That would be good. It is a long requested feature. But it hasn't been a high priority item. It would of course have the same limitations as Sun and Moon "tracking," but for farther away objects they should not be as severe. Still the best thing would be to have tracking these objects built into the antenna control system, but that is an antenna-by-antenna approach.

This could be a good starter project for someone. It might use open source software that can be distributed with the FS or another project that could be installed on the FS machines that the FS could interact with.

I am happy to discuss this with anyone who is interested in taking it on.

[stuartdweston]

You might be able to tempt me as a retirement project ;-)

[stuartdweston]

Ed, how about using SPICE ?
https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/info/intrdctn.html

[stuartdweston]

Second Thoughts - perhaps use NOVAS
"The U.S. parts of The Astronomical Almanac are prepared using NOVAS" (https://aa.usno.navy.mil/software/novasc_intro).

[liamdiprose]

Nice to hear from you Stuart.

We also have Anise as an option: https://github.com/nyx-space/anise/tree/master

ANISE was used throughout the operations of the Firefly Blue Ghost lunar lander, from launch until successful landing. As such, the library is now considered NASA Technology Readiness Level (TRL) 9.

Responding to @wehimwich

Still the best thing would be to have tracking these objects built into the antenna control system, but that is an antenna-by-antenna approach.

I agree that object-tracking logic should conducted as close as possible to the motor drivers to maximise accuracy. However, because these libraries fetch data from the internet, I think most antenna control systems will include a Linux interface. I can see an opportunity for the field-system to become a Linux hardware-abstraction-layer (HAL) for antennas if we find a good way to support object-tracking.

[wehimwich]

Second Thoughts - perhaps use NOVAS "The U.S. parts of The Astronomical Almanac are prepared using NOVAS" (https://aa.usno.navy.mil/software/novasc_intro).

That seems like a possibility. An early version of the NOVAS routines, in both FORTRAN and C, is included in the FS. They should be updated to the latest version. That will require testing. Additionally, what is in FS is matched to what drudg uses to provide consistency for the apparent coordinates independent of what mean coordinates are used in the schedule and/or the SNAP file. That should be preserved. One way to handle using a later NOVAS package for other celestial bodies in the short-term would be to have a separate program for other bodies, à la moon, that could have its own version of NOVAS.

[wehimwich]

I agree that object-tracking logic should conducted as close as possible to the motor drivers to maximise accuracy. However, because these libraries fetch data from the internet, I think most antenna control systems will include a Linux interface. I can see an opportunity for the field-system to become a Linux hardware-abstraction-layer (HAL) for antennas if we find a good way to support object-tracking.

I am not sure the FS would be a good abstraction layer for the antenna. It has a lot of other non-antenna specific things in it. The FS has its own antenna abstraction layer, the station specific program antcn. That is used to provide some basic functionality independent of the details of the antenna. This is fairly limited, just commanding sources and offsets, and some simple antenna status (including onsource checks). Each station's antcn is free to implement there features as it sees fit. For example tracking control can pass source coordinates or drive the antenna in its local coordinates. There is a mode in antcn to utilize TLEs or a 1 Hz ephemeris for an object. This is starting to be used for satellite tracking. Other modes could be added, maybe positions and first and second derivatives for nearly sidereal objects. However, which of these are useful at a given antenna depends on what the antenna supports.

I am not sure we want the FS to be reaching out to the Internet itself, but maybe there is an argument for it. In contrast, for example, if you need the JPL ephemeris, maybe there could be a cron job that downloads it periodically. There would have to error handling in the FS for issues like the ephemeris not being available, being out-of-date, or other problem that might come up.

[wehimwich]

One other issue to consider is that the FS currently does not include any packages that require code from remote repositories, like PyPI. This is for security reasons. However, those packages could be installed separately from the FS. Hooks could be included in the FS to interact with them. That would allow stations to decide what functionality they want and what security risks they are willing to take. I don't think this would be a significant limitation for stations that are willng to accept the risk, but maybe I am missing something. Perhaps in the future, this might be relaxed.