Guide Algorithms

Guiding Theory
Guide Algorithm Parameters

Guiding Theory

The default guiding algorithms in PHD2 are well-established and should work well for most users.  Unless you already have some experience with guiding and understand the basics, you should probably be cautious about changing algorithms.  However, you may have some special circumstances that require changes or you may simply want to experiment with the different algorithm choices.  The Advanced Dialog settings in PHD2 make it easy to do that.  Each algorithm has a set of parameters that controls how observed changes in guide star position (star deflections) are translated into guiding commands that are "most likely" to restore the star to its initial position.

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:
So what isn't included in the above and isn't correctable by conventional guiding?  Unfortunately, it's a very long list, of which a few are:
The common denominator shared by the guide algorithms is the need to somehow react to the slow and steady deflections while ignoring the rest.  This is a difficult problem at best because any given guide star deflection is likely to have contributions from many of these sources.  And if that isn't hard enough, remember that real-world  mounts are never perfect - so the move you ask for will not be exactly the move you get.  Usually, the most important requirement for any algorithm is to avoid over-correcting, wherein the mount is being pushed back and forth and the guiding never stabilizes.  A typical approach in these algorithms is to apply "inertia" or "impedance" to the guiding corrections.  That means making corrections that follow a pattern and are generally consistent with corrections that have been made before, while being "reluctant" to make corrections that require a big change in direction or amplitude.  Resistance to changes in direction is particularly important in declination, where gear backlash is a common problem.  Hopefully, this background will give you enough insight into the basics of guiding so that the various guiding parameters used in PHD2 will make sense.

Guide Algorithm Parameters

In PHD2, the various guide algorithms can be applied to either the right ascension or declination axes.  Most of these algorithms include a minimum move parameter.  This is used to avoid making guide corrections that are overly small, are unlikely to have any effect on star shape, and are mostly due to transient seeing effects.  These values are entered in units of pixels, so you need to think about them in the context of how large your star images are.  The default values work well for short-to-medium focal length systems, but you may need to increase them if you are working at long focal lengths and expect stars to have larger diameters.

The hysteresis algorithms keep a "memory" 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.

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 moving in a consistent direction or "getting worse."  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.  Because the low-pass algorithm is so resistant to quick changes, it is probably most applicable to declination guiding.

The declination guide mode gives you additional control for declination guiding.  Declination guiding is not like RA guiding because the errors are not caused by imperfections in your mount's gears.  Instead, deflections in declination are primarily the result of imperfect polar alignment.  The result is an error that should be smooth and should be in only one direction, assuming there is no "over-shoot" from an earlier correction.  The default value of 'auto' tells PHD2 that some reversals in direction are acceptable, subject to the behavior of the various guiding algorithms.  However, if your mount has severe declination backlash, you may want to prevent direction reversal altogether.  If so, you can select either 'north' or 'south' to restrict corrections to one direction only.  Keep in mind, however, that an "over-shoot" in correction with one of these modes will leave the star positoned off-target for an extended period of time. So you'll probably want to use conservative parameters for aggressiveness if you are disallowing direction reversals.  Finally, a choice of 'none' here disables declination guiding altogether.