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 experience with guiding and understand its principles, you should be somewhat cautious about changing algorithms.  However, the Advanced Settings dialog in PHD2 makes it easy to do that.  Each algorithm has a set of parameters that control how observed changes in guide star position (star deflections) are translated into guiding corrections that will be sent to the mount.

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 considerably different, conventional guiding faces substantial 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.  Even though many guide cameras are sensitive to guide star deflections of only a few microns on the sensor (e.g. 0.0002 inches, 0.005 millimeters),  we still expect the mount and the guiding software to move the camera across the sky for hours with this level of precision. Guiding applications like PHD2 are best able to deal with tracking errors that are "slow and steady", not "fast and random."  Sources of slow, steady, or predictable (correctable) errors include the following:
So what isn't included in the above and isn't correctable by conventional guiding?  Unfortunately, it's a long list, of which a few are:
The common denominator shared by the guide algorithms is the need to react to the slow, steady, or predictable deflections while ignoring the rest.  This is a difficult problem at best because any given guide star deflection is likely to have contributions from multiple sources.  And if that isn't hard enough, remember that real-world  mounts are never perfect - so the correction you ask for will not be exactly the correction 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 ignore deflections that are most likely caused by seeing and to apply "inertia" or "impedance" to the guiding corrections that are sent to the mount.  That usually means making corrections that follow a pattern of movement 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 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 your image scale and the typical size of your guide stars.  If you have used the new-profile-wizard to configure your system, the min-move parameters will be set to values that are likely to work well for the image scale you're using.  The Guiding Assistant can also adjust these values based on its measurement of high-frequency seeing disturbances.  If you are seeing a high rate of declination guider corrections and lots of direction reversals, you may be "chasing the seeing" and adjusting the min-move values upward can be a simple way to reduce that.  Of all the detailed guiding parameters discussed here, the two min-move values are the most likely ones to warrant adjustment on a nightly basis based on seeing conditions.

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 latest 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 and in what direction the mount should be moved. The aggressiveness 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've done a reasonable job of setting Min-Move values, there is generally no need to modify these parameters, and any modifications you attempt should be based on a careful analysis of long guiding sessions using the PHD2 LogViewer tool.

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.  Two parameters are available fur controlling the ResistSwitch algorithm.  The first is "aggressiveness", a percentage amount that behaves like the hysteresis aggressiveness described above. 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 algorithm also employs 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 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 or to mounts with absolute encoders.  Use of this algorithm has been deprecated in favor of the LowPass2 algorithm.

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 is a good choice for users with good seeing conditions and well-behaved mounts with little or no declination backlash.  It is the recommended algorithm for mounts that have high-precision encoders.

The Z-filter algorithm is a variation on the LowPass algorithms but operates in the discrete frequency or "Z" domain. In terms of guiding it applies full correction to the low frequency components caused by mount periodic error. Higher frequencies are corrected with aggression progressively reducing down to zero.

The Z-filter algorithm allows you to use shorter guide camera exposure times (e.g. 1s or 0.5s) without chasing the high frequency seeing. The advantages of shorter guide exposure time are reduced lag time for applying corrections and smaller corrections.

The Z-filter algorithm offers just two adjustments: Exposure Factor (XFac) and Minimum Movement (MinMo). The virtual guide exposure time is given by the actual exposure time multiplied by the Exposure Factor. A given virtual exposure time will perform similarly to an unfiltered algorithm using the same actual guide exposure time. For example, an exposure time of 1s with Exposure Factor of 4 gives a virtual exposure time of 4s (4 x 1s) and performs similarly to Hysteresis with Aggressiveness 100% and Hysteresis 0.0 using an exposure time of 4s. An exposure time of 2s with an Exposure Factor of 2 also has a virtual exxpsoure time of 4s (2 x 2s) and thus performs much the same. The main difference is that the shorter actual exposures allow the corrections to be applied sooner and more frequently so they are smaller.

This feature lets you adjust the guide exposure time to optimise the guide star SNR and guide latency. You can then adjust the Exposure factor to get the desired guiding response. A virtual exposure time of 2s to 4s per the usual recommendation is a good starting point for the RA axis. On the Dec axis, longer virtual exposures can be used and can help minimise reversals that can result in backlash.

Note that when using short exposures the movement from seeing will be more visible on the guiding graph. This does not mean the guiding is worse. Other algorithms rely on guide exposure time to filter out the movement from seeing. The Z-filter Exposure Factor performs the same function.

The Z-filter also has a MinMo setting. The value should be chosen to match the ability of the mount to accurately make small corrections. With other algorithms MinMo is sometimes recommended to provide some filtering e.g. to prevent reversals of the Dec axis. With the Z-filter the recommended approach is to increase the Exposure factor.  The Z-filter algorithm is more complex and harder to understand and is unlikely to produce results better than LowPass2 with most mounts, so it is not generally recommended.



PHD2 Predictive PEC Guide Algorithm (PPEC)

 Overview

 The PPEC algorithm is different from the others in PHD2 because of its modeling and predictive capabilities.  The algorithm analyzes the tracking performance of the mount in real-time and once the analysis is complete, it will compute guiding corrections even before a repetitive error is actually seen.  Issuing proactive guiding corrections reduces the time delay inherent in traditional guiding and can significantly improve performance.  With the other algorithms, which are completely reactive, guide corrections are issued only after the error has been seen on the camera sensor.  

 Once guiding has begun, the algorithm analyzes the performance of the mount and looks for tracking errors that are repetitive and thus, predictable.  The algorithm employs a sophisticated Gaussian process model developed by a research team at the Max Planck Institute in Germany.  The mathematical details can be found in a paper referenced here:

 http://ieeexplore.ieee.org/document/7105398/?reload=true

The PPEC algorithm will normally be used for RA, where residual periodic error and other gear-related errors often reduce tracking accuracy.  The algorithm uses separate time-scales for characterizing the behavior of the system:

 The short-term behavior is used to identify the unpredictable noise in the system, which is essentially filtered out in order to identify components that are predictable.  For most mounts, the medium-term component will be the most important.  If you’re following best practices, you will have programmed periodic error correction in your mount (assuming that feature is available to you).  Doing this reduces the amount of work that needs to be done by PHD2, and the PEC correction in the mount is normally saved permanently.  This approach is preferable to having to measure and infer the periodic error behavior every time you set up your equipment.  That said, PEC in the mount is never perfect, and you will often see residual repetitive errors even when PEC is active.  These often arise when the tracking errors occur with a frequency that is not a harmonic (integer fraction) of the mount’s worm period – most PEC implementations can’t deal with those.  You can also get residual periodic errors if they are dependent on the mechanical loading of the mount or if the mount’s behavior has changed since the PEC was programmed.  The PPEC algorithm can be quite effective at identifying and reducing these errors because it doesn’t depend on the worm period and is always doing a fresh analysis of the mount’s current behavior.

 The PPEC algorithm will also detect and proactively correct for drift errors.  Although drift is typically handled well by any of the guide algorithms, the corrections will always lag the error by some amount.  For some use cases – perhaps spectroscopy, photometry or comet-tracking – this might be a problem, in which case PPEC may deliver better results. 

 Since PPEC employs a learning process, it will usually take about 2 worm periods to model the mount and become fully effective.  During this training period, the algorithm will behave more like the ‘hysteresis’ algorithm, so you won’t normally see a performance penalty while the internal model is being built.  Instead, you’re likely to see a steady improvement in tracking as the model is refined and the algorithm shifts seamlessly from hysteresis to predictive-mode.   This improvement can usually be seen even before the medium-term mount behavior is fully modeled.

 Since the PPEC model is implicitly tied to the state of the gear train, it must be re-learned if the mount is slewed by a substantial distance.  For the same reason, it can’t be retained across different guiding sessions, which is why conventional PEC is important.  However, the PPEC model will remain intact during dither operations and while guiding is paused (via automation) for activities like focusing.  For the most common use-case, namely imaging the same target for multiple hours with periodic dithering, the PPEC model will remain valid.  In any case, the learning process and transition from one mode to the other is handled automatically, so you won’t need to pay it any attention.

 Algorithm Details

 Once the training period is completed, the PPEC algorithm computes the guide correction using two factors.  One is reactive, based on the displacement of the guide star in the most recent exposure.  The second is predictive, based on the output from the Gaussian process model constructed during the training period.  Each of these terms includes a separate gain or aggressiveness factor, so the final guide pulse amount is a sum:

     Guide-correction = (predicted amount * predictive gain) + (recent displacement * reactive gain)

 The ‘predictive gain’ and ‘reactive gain’ parameters are exposed in the Advanced Settings 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.  Note that the two components in the calculation of the guide-correction are vector quantities - they may have opposite east/west polarities.  For that reason, there is no restriction that the sum of the two gain values must be less than 100% - but be careful to avoid over-correcting.

 During the training period, the algorithm needs to identify periodic errors in the observed guide star movement.  For initial trials, you can use the worm period of your mount as the starting point for the ‘period length’.  This gives the algorithm a good starting point, but you should initially leave the ‘auto-adjust period’ option checked until you have a clear view of your mount's periodic error curve.  This tells the algorithm to adjust the period as needed to better control whatever periodic errors it finds.  Once you have run the algorithm multiple times and are happy with the results, you can typically un-check the 'auto-adjust period' option to be sure the PPEC algorithm remains focused on the most important frequency. Similarly, if you have a mount with a recurring tracking error that occurs on a non-harmonic frequency,  un-checking the option is probably a good idea as well.  Obviously, knowing this requires an FFT analysis of your native tracking performance, a capability that's part of the PHD LogViewer tool.

The 'Retain model (% period)' parameter specifies how long the mount can track unguided before the PPEC algorithm will be reset.  This is computed as a percentage of the current period length.  This is useful in situations such as auto-focusing where the mount is continuing to track at the sidereal rate but guiding isn't being done.  It also applies to westward changes in the RA pointing position from slewing. Care must be taken if the default setting of 40% is adjusted upward.  Running for extended periods of time unguided causes the PPEC model to lose accuracy, in which case a reset would be the best course of action.  The point where that occurs is specific to the mount and the current seeing conditions, so you may need to experiment if you want to adjust this parameter.

 The ‘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.