Guide Algorithm Parameters

Before discussing the details of these parameters, it is worth reviewing a little guiding theory and looking at what these algorithms are trying to accomplish. Setting aside adaptive optics devices, which are entirely different, conventional guiding faces enormous challenges. The problem at hand is how to move machinery that weighs tens or even hundreds of pounds with a level of precision that will not cause streaked or oblong stars. This type of guiding can only hope to deal with tracking errors that are "slow and steady", not "fast and random." Sources of slow and steady (correctable) errors include the following:

- Certain kinds of mechanical imperfections in right ascension gears, including those that cause periodic error.
- Smalll errors in the sidereal tracking rate of the mount
- Atmospheric refraction - stars appear to move more slowly as they near the horizon
- Limited kinds of mechanical deflection and flexure - but not differential flexure
- Mis-alignment of the right ascension axis on the celestial pole

- Atmospheric seeing ("turbulence")
- Gear noise, roughness, and vibration
- Differential flexure - relative movement between the imaging scope and the guide scope
- Wind gusts, cable snags, grit in the drive gears
- And lots more...

The hysteresis algorithms keep a history of the guiding corrections that have been made in the recent past, and these are used to help compute the next guide correction. The hysteresis parameter, expressed as a percentage, specifies the "weight" that should be given to this history as opposed to looking only at the star deflection in the current guide frame. Consider an example where the hysteresis parameter is 10%. In that case, the next guiding correction will be 90% influenced by the star movement seen in the current guide frame and 10% by the corrections that have been made in the recent past. Increasing the hysteresis value will smooth out the corrections at the risk of being too slow to react to a legitimate change in direction. The hysteresis algorithms also include an aggressiveness parameter, again expressed as a percentage, that is used to reduce over-correcting. On each frame, PHD2 computes how far it thinks the mount should move and in what direction(s) it should move. The aggressivness parameter scales this. For example, take a case where the star deflection has been evaluated and a corrective move of 0.5 pixels is warranted. If the aggressiveness is set to 100%, a guider command will be issued to move the mount the full 0.5 pixels. But if the aggressiveness is set to 60%, the mount will be asked to move only 60% of that amount, or 0.3 pixels. If you find your mount is always overshooting the star, decrease this value slightly (say, by 10% steps). If you find PHD2 always seems to be lagging behind the star's motion, increase this by a little bit. A little can go a long way here.

The ResistSwitch algorithm behaves much as its name implies. Like the hysteresis algorithms, it also maintains a history of past guide corrections, and any change of direction must be "compelling" in order to issue a reversing guide command. This is appropriate for declination guiding, where reversals in direction are both suspect and likely to trigger backlash in the gears. For that reason, ResistSwitch is the default algorithm for declination but not for right ascension, where valid direction reversals are expected. Starting with Release 2.4.1, two additional parameters are available for fine-tuning the ResistSwitch algorithm. The first is "aggression", a percentage amount that controls how much of the computed guide correction will be issued. Reducing this parameter can help to avoid over-shooting with mounts that have little or no backlash. The second parameter is a checkbox labeled "Fast switch for large deflections." If this is checked, PHD2 will react immediately to a large change of direction rather than waiting for three consecutive deflections in the new direction, which is the normal behavior. This can help to more quickly recover from large excursions in Dec, perhaps caused by wind, cable snags, or other mechanical shifts The definition of a "large deflection" is 3x the minimum-move value. So if PHD2 is over-reacting to direction changes, you can tune the behavior with the min-move parameter or disable the "fast switch" option altogether. It is worth remembering that "less is usually better" when it comes to Dec guiding, so don't try to over-tune these parameters.

The LowPass algorithms also employ a history of recent guiding corrections in order to compute the next correction. The starting point for the computed move is the median value of the guide star deflections that have occurred in recent history. This means that the star deflection seen in the current guide frame has relatively little impact on calculating the next move and the algorithm is very resistant to quick changes. But the history accumulation also includes a calculation to determine if deflections are trending in a consistent direction. The slope weight parameter, expressed as a percentage, determines how much influence this should have in calculating the actual guider movement - it is there to keep the algorithm from being overly sluggish. If you set a slope weight of zero, the guide pulse will always be just the median value of the recent history. If you set a non-zero slope weight, that median value will be adjusted either upward or downward based on the recent trend of guide star movements. Because the low-pass algorithm is so resistant to quick changes, it is probably most applicable to declination guiding.

The LowPass2 algorithm is a variation of the original LowPass algorithm with somewhat different behavior. It also maintains a history of guiding corrections, but the next correction is simply a linear extension of the commands that have come before it (i.e. a slope calculation). This continues until a significant change in direction is seen, at which point the history is cleared. The algorithm has two adjustable properties: minimum-move and aggressiveness. Minimum-move has the same effect as it does in the other guide algorithms, and aggressiveness (percentage) is a way of further dampening the size of the guide corrections. LowPass2 is a very conservative, high-impedance algorithm that may be a good choice for users with good seeing conditions and well-behaved mounts with little or no declination backlash.

PHD2 Predictive PEC Guide Algorithm (PPEC)

**Overview**

· Medium-term: for residual periodic errors, typically occurring
at intervals less than or equal to the worm period

· Longer-term: for steady drift and for lower
frequency (longer time interval) harmonics that can be caused by the
interaction of multiple gears in the drive train

**Algorithm Details**

**predictive** **gain’** and ‘**reactive** **gain’**
parameters are exposed in the Advanced Dialog, and their default values for
these parameters should work well for most mounts. You should be conservative about changing
them because bad choices for these parameters can definitely make your guiding
worse.

**period** **length’**. This gives the
algorithm a good starting point, but you should also leave the ‘auto-adjust
period’ option checked. This
tells the
algorithm to adjust the period as needed to better control whatever
periodic
errors it finds. Once you have run the altorithm multiple times
and are happy with the results, you can leave this field set to
whatever value was computed in the previous sessions.

**min-move’**
parameter affects only the reactive component of the algorithm. If the measured star displacement is less
than this amount, the reactive component will be set to zero. However, the predictive component of the
algorithm will still be computed and applied.