ASIMount@ZWO Maybe we can attach the fourier transform of the Full periodic error data if you guys really want it.

BTW, please keep in mind that the magnitude of a Fourier transform will be putting out the average harmonic distortion number. And with no phase information, we would not know what the worse case first derivative is.

Have you kept the original data for each mount? If so,the first derivative of that curve would be extremely useful for determining the pulse correction rate that is needed to keep the actual tracking error small for that particular mount -- it could be more useful than a Fourier transform.

Or even just a single number can already be very useful -- max second derivative over the entire rotation, in units of arc-seconds/second of time.

Chen

KC_Astro_Mutt Do aggression settings figure into this at all?

Aggressiveness value is basically the classical "loop gain." Apply too little and there is a larger residual error (e.g., the RA corrections not keeping up), apply too much, and the loop starts being unstable (e.g., the RA corrections, once started, can end up making large oscillations).

See https://en.wikipedia.org/wiki/Loop_gain among many other places.

Mine looks pretty tame, comparatively

Unfortunately, yours also start off having (1) a peak-to-peak Periodic curve that is twice that of Kevin's, and (2) your mount has a huge second order harmonic (see the double peaks in the second figure? The second harmonic is so large that it flipped the direction of half of the peaks!). That basically make the 430 second period appear to be perhaps (eyeballing) 2/3 of what it should be.

Just those two factors put together could make your mount's worse case slope twice as large as Kevin's.

Consider this too: in Kevin's case, the large slopes appear four times per 430 seconds (two positive, and two negative slopes). Because of your mount's multiple humps, you are seeing eight places where the slope is large. So you could be seeing large RA guide errors very often, like every 50 or 60 seconds. Depending on how long they last, they may not register in the main camera's image, but it means that you are bound to have at least one large excursion for every subframe that you take that is more than 60 seconds long.

yet I'm having the hardest time guiding

Seeing your mount's PE curves, I am not too surprised that you have problems. Try starting with a 0.5 second exposure rate since I think your mount might need it (don't use anything longer than 1 second), find a camera that can give 2 FPS guiding (that is harder to do in ASIAIR v2.0 and earlier, but should be easy to achieve with a laptop and PHD2; ASIAIR v2.1 Beta has improved the guide FPS).

Start with low aggressiveness and a max pulse of less than half of the exposure (i.e., start with perhaps 200 ms max pulse or so -- only increase that value if you find that the guiding cannot keep up with the mount PE even with increased aggressiveness; try increasing aggressiveness first before increasing the max pulse). Remember that RA and declination have different gears, you will need different parameters with them.

To use short exposures, you will need to turn on multistar guiding, or "seeing" will eat you alive. If all guide stars have about the same SNR, using 2 stars is equivalent to doing 2 second guide exposures instead of 1 second. 4 stars is equivalent to 4 second exposure instead of 1 second (etc). You guys who have taken Probability Theory will recognize this a "Ergordicity" (in simple terms, ensemble averages is the same as time averages). In practice, not all stars have the same SNR, so 2 star guiding many only be 1.5x better than 1 star guiding, etc, and with further diminishing returns as you add even more stars.

As to MinMove, it will not help if the errors are not unidirectional (i.e., for the declination if you are perfectly polar aligned, and no declination drift, and there is a large backlash).

Backlash is not a problem with RA if you you keep (guide rate x guide pulse width) below the sidereal rate. This is because the mount is already tracking at 1x sidereal rate, and a correct pulse that is 0.5x sidereal rate) in the opposite direction (that is not too long) is simply a process of slowing down the motor for the duration of the pulse. For this reason, never ever make the max pulse duration of RA ever, ever close to 2 seconds when the guide rate is 0.5x sidereal. Or 3 seconds if the guide rate is 0.33x sidereal, etc. Once you know this, it should be obvious, but it is seldom explained, and most people figure it out themselves. If you remember, I was very vehement when I saw stuff like 2000ms being recommended as a max pulse rate for the RA direction.

Good luck.

Chen

KC_Astro_Mutt What are your thoughts on my chances on guiding with this mount, with that PE?

Sure, anything can be guided.

The question is what did you expect from it when you'd checked the specs and bought it.

Are you looking for 1" total RMS error from this mount? Very likely it can do it. Are you looking of 0.5" total RMS error? Perhaps it can. Are you looking for 0.25" total RMS error? Perhaps not.

Also, remember that the RMS (root mean square) values are long term averages. You will likely see occasional (and in your case, twice as often as Kevin's mount) spkes of larger than the RMS values (peak values are always no smaller than the mean value).

If those spikes have short durations (like lasts only 1 or two seconds), they are not likely to show up in your main camera images (although your is twice the problem of Kevin's) if they don't repeat often.

Stain wave geared German mounts would usually be outperformed by a legacy worm-geared German mount that are a quarter their price when it comes to guide precision.

When you buy a strain wave geared mount, you are paying for portability, not for accuracy. I really wish the vendors and dealers would temper the customers' expectations, instead of getting their shills to tout these mounts. They are not for everybody -- they are for people who desire more portability, and don't mind paying more for the portability (and be willing to have guide experiences of a mount a quarter the price). The strain wave gears' good attributes are somewhere other than guiding. An AZGTi for example can probably guide better than your mount, but it cannot sling a heavy paylod around, and it will always need time to balance every eveing.

Touting "small peak-to-peak PE" to astophotographers for example, is just plain misleading; since PE amplitude is not the root problem for guiding, the first derivative of the PE is. A mount can have low peak-to-peak PE, and yet guide terribly because it has large harmonics.

The old maxim for good guiding is to have a (1) long PE period, and (2) a smooth curve (i.e., very low harmonics). That hasn't changed -- I have simply pointed out that one way to get around a non-smooth mount is to produce higher guide pulses per second, and that you can do this even without exposing for shorter times (just cannot do it with PHD2 today, unless you write your own code to replace PHD2 for guiding).

Chen

w7ay actually mine is about +8/-11 and it does guide fairly well averaging between 0.3 and 0.7rms, but I was looking for additional information on how to guide a harmonic drive mount better compared to how I guide my Gem mounts. With my typical worm driven mounts I use 2-3s exposures with 1500-2000ms duratons and mild aggression. I will now use 1s exposures with 500ms durations and low aggressions, testing out each axis at a time until I find the best settings for each axis. My only issue now will be how to deal with chasing the sky with faster 1s exposures. Haha

w7ay

w7ay Also, remember that the RMS (root mean square) values are long term averages. You will likely see occasional (and in your case, twice as often as Kevin's mount) spkes of larger than the RMS values (peak values are always no smaller than the mean value).

Indeed, the RMS is a result of the statistics strategy of your guiding log, which obeys the 68-95-99.7 rule. You can still get around 22 guide pulses that are even larger than 3x RMS value during a period of 1-hour 2-FPS guiding record.

BTW, we are making efforts to reduce the Max&Min PE of the strain wave gears loaded on AM5.

ASIMount@ZWO which obeys the 68-95-99.7 rule

If you are referring to 1, 2 or three Sigma values, that only applies to the Gaussian (Normal) Distribution. I don't believe the strain wave gears errors are Gaussian. For example, there is identically zero chance that a working gear can produce an infinite amount of error, as the tails of a Gaussian curve can.

Now, if you measure a million strain wave gears, their collective probability distribution will approach the Gaussian, due to the Central Limit Theorem.

Notice from the wiki page https://en.wikipedia.org/wiki/Central_limit_theorem that says

"the standardized sample mean tends towards the standard normal distribution even if the original variables themselves are not normally distributed."

However, a single mount that belongs to a customer will not likely obey the Gaussian statistics.

we are making efforts to reduce the Max&Min PE of the strain wave gears loaded on AM5.

No need to, as I have explained earlier. For astrograph mounts, what you do need to do is to reduce the harmonics of the strain wave gears (more precise machining of the spline gears). This is different for the "normal" usage of the gears, where magnitude of the error is important. For easy guiding, it is the first derivative of the error curve that is important.

Chen

w7ay Notice from the wiki page https://en.wikipedia.org/wiki/Central_limit_theorem

An anecdote: as mentioned in the above Wiki, the name of the theorem "Central" was created by George Pólya, even though the theorem was known much earlier. By the time I arrived for graduate school in 1969, Pólya had already retired and no longer taught classes. But I managed to sit in a general talk that he gave. Computer scientists and Topologists among you nerds may have heard of "Pólya counting" -- same Pólya -- at the time I was there, Stanford's IBM 360 computer was located in a building named after him :-).

Central LImit Theorem is not just some academic stuff, I have used the CLT often -- one time was to get Gaussian distributed numbers from the rand() Unix call :-) Described in Section "4.1 The Gaussian Random Process" in the program's manual:

http://www.w7ay.net/site/Applications/cocoaPath/Contents/technical.html

Chen

Kevin_A testing out each axis at a time until I find the best settings for each axis.

That is very good advice.

For everyone else, remember that when you are tracking a target, the RA axis moves constantly at sidereal rate though the different angles of the RA shaft. As time elapses, it would move completely through one period of the error curve in 430.82 seconds.

The declination axis is completely different.

If the mount is perfectly polar aligned (won't happen in practice), the declination axis does not even move. With imperfect polar alignment, the declination of the mount will make an error path relative to the constant declination in the sky. But this is typically a slow drift -- you can observe by turning the max declination pulse duration to 0 (in ASIAIR you cannot use zero ms; just use 1 ms), so that PHD2 is not controlling the declination axis, and you can watch the drift rate for your given polar alignment error. (That how we used to do "drift alignment" -- slowly adjusting the altitude and azimuth bolts until the drift flattens out.)

So, while RA is moving about 15 arcseconds per second of time, the declination will move very little, perhaps one arcsecond per second of time. Moreover, it will be moving back and forth, but centered about a fixed declination motor angle, and only make one cycle in one celestial day (23 hr 56 min) instead of the 430 seconds for the RA axis.

For the declination axis, the optimal max declination pulse is therefore usually much lower than RA axis. That is, if there is no flexure, and the RA axis is within a minute of arc or two of the pole.

How big and how small that error envelope is will depend on the actual declination angle, since the declination angle depends on the angle of the declination shaft. If you are lucky, the target's declination places the declination shaft at where the slope of the PE is lowest. If you are not as lucky, the target 's declination places the declination shaft at angles where the slope of the PE is highest. Again, it is not the amplitude of the PE, but the slope of the PE that matters.

I don't think ZWO gives plots of the periodic error of the declination shaft, otherwise you could pretty much predict where the favorable declination angles of your mount is. However, it is not a huge problem, since the RA is going to move much more.

Anyway, do what Kevin does... threat the RA and the declination guide parameters as independent adjustments. Don't use for example, 150ms max pulse width for declination just because 150 ms works best for the RA axis.

(If I were ZWO, I would have measured each motor/gear set, and reserve the better ones for the RA axis, while using the less good ones for the less critical declination axis :-).

Chen

w7ay "" that 150 to 200 milliseconds should still be ample to handle all the errors from the mount.""

Newbie here with newbie question: Where do you set those values in phd2? On the main guiding screen "Max RA pulse" and "Max DEC pulse"?

thanks for your help and patience

tempus On the main guiding screen "Max RA pulse" and "Max DEC pulse"?

Yes.

If you are not familiar, and puzzled by why max pulse is in milliseconds (time) instead of arcseconds (angle)...

auto-guiding is just a process where the computer program detects that the centroid of a guide star has moved a certain amount of pixels (it usually can detect a fraction of a pixel movement). It would then ask the mount to compensate by move the mount in the opposite direction.

With sub-arcseconds type precision that is needed, GOTO commands are usually not precise enough, so typically you will ask the mount to start a slow speed slew, wait for enough time to pass, and then stop the slew. This is the "pulse" that people talk about, and that is why it is stated as an amount of time, instead of an angle.

The slew speed is typically set to less than the sidereal rate, which is 15 arcseconds per second of time. So, if you had set the guide rate to 0.5x sidereal rate, it will take 1000 ms to apply 7.5 arcseconds of correction -- a 10 ms pulse will therefore move the mount by just 0.075 arcseconds.

You never want to use a faster slews rate than 1x sidereal rate for the RA axis, since that ( slower than 1x) prevents the RA axis from performing a correction that includes a backlash. Without any correction, the mount is tracking the sky at 1x sidereal rate, so any slower slew will not reverse the RA gear direction. For most mounts, 0.5x sidereal rate has a high enough slew rate to keep up with mount errors.

There is one further hiccup... the image of the guide scope in in units of pixels, and the slew is in units of time. So you need to "calibrate" your mount to find this amount. As importantly, most people do not align the camera angle of their guide scope (I do) so that the RA and declination axes are not at the same angle as the x and y axis of the guide camera. So, the calibration phase also has to figure out the angle the camera (x-y) makes with the RA-declination axes of you mount.

When the centroid detection tells the program that it needs to move a guide star by ∆x and ∆y in the camera's coordinate, the guide program would compute to find out how much ∆RA and ∆declination is needed, and then apply a slew for a certain amount of time to achieve those.

For the majority of mounts, these pulses literally involves sending a start-slew to the mount, wait N millisecond in the program, then sending a stop-slew; so you want to make sure the timer process at the computer has high priority, and the baud rate to the mount is moderately high (a typical command could take 10 milliseconds on a slow 9600 baud link). There are some mounts where you can send the N directly and let the mount do the start-wait-stop as a single action -- there is less dependency on the communication link, but you are now depending on the mount to not inject any other delays.

Chen