# Re: planscan: Computing optimal directions for performing a plane scan

From: C. Bassa via Seesat-l <seesat-l_at_satobs.org>
Date: Sun, 14 Feb 2016 23:12:09 +0100
```Hi Greg,

Thanks for your extensive reply. You touch upon a few points which I

On Sun, Feb 14, 2016 at 9:44 PM, Greg Roberts via Seesat-l
<seesat-l_at_satobs.org> wrote:
> Now when I do plane scans for the KH-11 satellites I often only have a partial pass due to shadow entry - how is this avoided in your program?

Presently the code finds, for each time iteration the point along the
ring of positions that make up the orbit where the satellite would be
brightest. I use the relation I mentioned earlier:
mag=stdmag-15+5log10(r)-2.5log10(sin(phi)+(pi-phi)*cos(phi))
for when the object is sunlet, and mag=15 otherwise.

As such, that point will be at eclipse egress, eclipse ingress or at
the optimum phase angle/range with the maximum brightness. For each
time instant in the code it explains what the azimuth/elevation of the
point relates to; ingress, egress or maximum.

> The second point is the altitude is required. Now if I do a plane scan on a Molniya type orbit I have an altitude range of something like (say) 800 km to 12000 km - how is this problem overcome and what altitude should one use?

Right now the code is not aimed at plane scans for eccentric orbits.
In fact it will not work for orbits with a mean motion less than 10.
There are two types of eccentric orbits. The first is the Molniya type
where the orbit is very eccentric but the argument of perigee is
stable. The second type is that of a KH or an eccentric NOSS where
orbit boosts or drag and long periods of invisibility lead to the
argument of perigee varying. For the latter I would use planscan and
perform multiple plane scans at different altitudes that bracket the
expected perigee and apogee. For the Molniya type orbits I would have
to adjust the code to to deal with an eccentric orbit, and allow the
user to search at a particular elevation. This is something I'll have

> I do not go too close to the shadow entry point in case the satellite has done a change and perhaps
> dropped its altitude above my location. I also try and avoid a position
> that is too high - say above 60 degrees elevation, as this can cause
> problems with the movement of the scope.

These are very valid points which my code does not yet deal with. The
azimuth/elevation at eclipse ingress and egress are precisely at
ingress and egress, so this runs the risk you mention. I can probably
add a feature to allow a limit on how close to the shadow you want to
scan. I can also put in a limit on the maximum elevation to limit slew
speeds in azimuth.

Regards,
Cees
_______________________________________________
Seesat-l mailing list
http://mailman.satobs.org/mailman/listinfo/seesat-l
```
Received on Sun Feb 14 2016 - 16:12:57 UTC

This archive was generated by hypermail 2.3.0 : Sun Feb 14 2016 - 22:12:57 UTC