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

KC_Astro_Mutt These settings just gave me the best performance to date.

Still not super great, but quite usable.

The errors consistently make excursions past 1 arc second. So these will definitely register in your images.

The saving grace is that they are random, with no perceptable RA-declination correlation. So the error should distribute over all radial angles, and instead of creating a non-round star, the errors simply create stars that are perhaps 1" to 2" larger (but still mostly round).

If your "seeing" is worse than 2" seconds to start with, the star diameter will not bloat that much. If your "seeing" is 3", for example, the bloat is perhaps just 10% to 20%.

Chen

KC_Astro_Mutt Then the rms error would rise, and FWHM on those images rose to 1.9 to 2.0.

Yep, from the randomness of the error, I would bet the stars remained "round," though

I LOL every time I read, "my guiding must be good since I get round stars." The fact is that stars will remain round as long as the error is distributed over all radial angles.

Roundness also improves after stacking (since you are further randomizing). If you are interested, it has to do with Jointly Gaussian distribution which has a perfect circular symmetry, if the x and y are independent, and have equal variances:

https://en.wikipedia.org/wiki/Joint_probability_distribution

Note that this means that star at celestial equator will remain round, but the ones closer to the poles may not :-)

Here are some round stars from a strain wave geared mount (not too far from Equator :-) :-) (ASI2600 mono camera, with a Chroma Luminence filter, FSQ85+flattener):

http://www.w7ay.net/site/Images/Lagoon.png

Chen

tempus You should definitely start a conversation with the coders looking after Phd2.

Currently, I am still modeling the behavior by using a simulator (which can run thousands of time faster than real time, so simulation runs takes less than half a second instead of an hour). I plan to take a while more to fully understand the problem; but already, the guide rate is yielding results exactly as predicted. My plan is not to create software for others, but trying to understand better the behavior of mounts with large harmonic distortion.

I will be eventually be implementing with real stars using Indigo (I have been programming computers since 1966 on an RPC-4000 and Flexowriter as I/O, and have control theory knowledge (up to Kalman filtering) from my EE background.

None of it should be very foreign to me, but I do have to start with first principles along the way, such as detecting stars in a guide frame estimating centroids -- even that topic needs work since multi-centroid algorithms like the one in ASIAIR does not take care of long term field rotation; I need to stop and restart ASIAIR guiding once every hour or two, for example, or the guiding will eventually become worse.

Chen