wookash
I have stopped commenting on ZWO mounts, but since this post is directly addressed to me, and I particularly liked your idea of showing the full derivative graph (last image, which shows the 90º phase relationship between sine and cosine [its derivative]), I will make some quick comments on points that are still being ignored on the forums. Not directly related to ZWO mount glitches, but autoguing in general.
(I have no dog in this hunt. I am current getting 0.25" total RMS type guiding with an RST-135E (RainbowAstro and Hobym were the first to use strain wave gears, from Harmonic Drive, LLC), with an FMA180-pro as the guide scope, ASI678MM as the guide camera at 2 FPS update rate and camera gain of 27 dB, with a Baader Neodymium filter. I use RA and declination steps sizes that are barely sufficient to handle my mount's PE derivative, to keep any centroid computing error from making more error than neccessary, and I keep the loop gain really low. )
That 0.6 arc sec per second (and probably a little worse at places that ZWO won't show the numbers) is going to determine the minimum guide pulse that you will need to handle the worse time.
Remember (most people miss this part about guiding, even people who do implementations!) that when you take a guide exposure, you do not get the position of the star. What you get is a streak on your guide frame, corresponding to a guide star as it moves during the exposure. If you use a 0.5 second exposure, and the derivative is 0.6 arc sec per second, the guide star has moved 0.3 arc second during the exposure. I.e., if you look carefully, in the worst case, a guide star is a streak of 0.3 arc second long, not a single point of light. And (this is the expecially bad part), PHD2 has no idea which endpoint of the streak was from 0.5 second ago, and which is the most current endpoint (!!!) -- this can be improved by better algorithms that are based on the sawtooth, which is a dynamic estimate of a star position. The best it can do is to estimate the centroid of the streak . I.e., we are not estimating the centroid of a nicely formed star, but of a short line that in your worst case, is a line that is 0.3 arc second long. This is going to affect how well you can guide. In your case, I would expect guide glitches, even when there is no wind, of the order of 0.3 arc seconds when using 0.5 second (2FPS) guide update rate, and 0.6" when using 1 second guide update rate (1FPS). (This is why you need to use high guide frame rates with mounts that have high first derivative of the PE curve.)
Another thing to remember is that the places where you are going to get spikey errors will move 15 minutes from one night to another. So when you are taking notes to find out more about your mount, you need to take this into consideration. The relationship of periodic errors of the mount motor and gears is relative to your mount's hour angle, not to the sky's right ascension angle. I.e., when you take maeasurements, it is relative to where the mount is pointed to relative to the meridian. Each night, the meridian moved 15 minutes in right ascension.
To be objective, you also need to measure at the celestial equator. When you are near the pole, each arc second of the gear error will move the guide star by a smaller number of pixels compared to the star at the equator.
A final comment on the relationship between the worst case slope (your 0.6"/sec and the longest guide pulse duration. The reason you want to keep the pulse duration as short as possible is because of all the centroid estimation errors. With a nice Renishaw encoder, the feedback is very well controlled. With autoguiding (basically using the stars as your encoder) you need to estimate the star location (centroid) when there is atmospheric turbulence, stars not a single point, etc, and in the ASIAIR, case, poor centroid algorithms. You cannot keep these errors from moving the mount when they should not be, but you can limit how much it moves by using the max pulse duration settings. The centroid estimation errors will be different from one frame to another. This causes the guide algorithm to "overcorrect" in the opposite direction after the original centroid error. And you end up with an oscillatory motion if the loop gain is set too high. By setting the max pulse durations, you are telling the autoguider -- do not ever move the mount by this amount, no matter what centroid estimation tells you, because it is not an error that is produced by my mount. Basically, you are limiting the harm from centroid estimation error.
I.e., you choose 2 FPS vs 1 FPS to counter the worse case first derivative of the PE curve, and you set the max pulse durations to limit the error from centroid errors. Each setting solves a different problem (please let this sink in), even though both problems are ultimately tracable to the first derivative of the PE curve.
Chen
