Looking for feedback

[gosnold]

Hi! This is not an issue, I was looking for a way to image satellites with remote telescopes and I found your repo. What has your experience with them been? You got the images you wanted?

[pmonta]

Yes, I did get some nice images; see this NavList posting for some examples:

https://navlist.net/Navigating-with-GPS-optically-PeterMonta-jan-2018-g41217

Another example of imaging satellites for timing purposes:

https://birtwhistle.org.uk/MethodsCheckTiming.htm

At present, using iTelescope for this kind of thing seems limited to slow-moving satellites, MEO or slower (such as the various GNSS satellites). Spacecraft in LEO move a great deal more quickly, and iTelescope is not set up to acquire images using a desired timestamped track on the sky. The various uncertainties and biases, as described in the code, just become too much: if the model of the telescope's operations is off by even a few seconds, your LEO bird is entirely out of the field of view.

Still, I'd like to revisit this if iTelescope starts supporting it. The telescope hardware can slew very quickly and is very accurate---it's just a telescope-controller software limitation.

By the way, the specific telescope timings in the code probably need to be revised. Current iTelescope operations with the camera and mount, such as saving a newly-acquired image, are faster than they were a few years ago.

[gosnold]

Thanks! That will be helpful. FYI for GEO sats I found a trick to do it easily, using the NEO format of the ACP planner. You have to provide RA/Dec for points every two hours and then ACP interpolates it. But for a given observatory, the Dec is constant for all GEO sats, and the RA just varies by two hours every two hours, so it's quite easy for make the command manually. For instance for SSO observatory: trackon.txt

Images are good and there is no need for a telescope timing model since the interpolation is valid across many hours (you could do it for days on end if needed):

[pmonta]

I tried the NEO format many times, and each time it did not work---the Lagrange interpolation the ACP software claims to be doing just gives garbage results, with bad positions and tracking rates off by a factor of 100 or more. I opened a trouble ticket with iTelescope some time back about this, and they acknowledged that it was misimplemented, but they haven't had a chance to fix it yet.

I think your example of GEO might be a fortunate special case (nice image, by the way). I believe the ACP software correctly interpolates if the specified trajectory is exactly linear in both RA and Dec. But any quadratic or cubic component will throw it off completely (if the bug is still there).

A non-equatorial satellite will have nonlinear RA and Dec, and while it can be approximated with a linear track in the NEO format, the trajectory would be good only for a few minutes around some optimal time, at least in the cases I checked. Typically it results in a small trailing of the object of interest.

By the way, another iTelescope/ACP bug is that if RA crosses the 24h-0h boundary, things will not go smoothly. It will try to go "backwards" at high speed. Best to avoid any crossings. I think iTelescope uses an old version of ACP, so these things might well have been already fixed upstream.

[gosnold]

Yeah I had issues with mount crossing the boundary too. Now their system waits for enough time so that the boundary will not be crossed during the acquisition, but still when it did the acquisition it crashed the software (don't know why, I opened a ticket). For close-to-GEO the NEO format is good enough I think, even the sats that are non-0 inclination should have a good linear approximation anyway, but indeed for MEO the Comet elements might be the only option.

One thing that could work even in GEO is to turn off the mount tracking, I think it's possible for some telescopes in the live telescope control, I'll have a try, it might be simpler.

Thanks for sharing your experience!