Very large backlash in new AM5: Page 3

Very large backlash in new AM5

KC_Astro_Mutt

w7ay erhaps you can return it, if they really claim definitively that the mount can guide better than 0.8" total RMS, and your mount cannot even get close.

From the product description:
"Another huge benefit of harmonic drive mounts is that they have zero backlash, which traditional worm drive equatorial mount owners know can be an issue even in the best mounts. Though harmonic drive mounts do suffer from some periodic error, ZWO has made sure that the AM5 has less than ±20 arcseconds, and each mount comes with an inspection certificate to prove it. When autoguiding, the accuracy is an impressive 0.5 to 0.8 arcseconds."

w7ay

KC_Astro_Mutt ZWO has made sure that the AM5 has less than ±20 arcseconds

That (40" peak-to-peak PE) has nothing to do with whether the mount is easy to guide. You need the first derivative of the PE.

Notice that Kevin's mount is around +8" to -15", and he apparently is already not having an easy time. Yours is +15" to -8" and you are having problems.

I can claim that my mount's color is matched to Pantone silver to within 0.5 ∆E, but that has equally nothing to do with how easy or hard it is to guide, either.

Caveat Emptor.

Chen

KC_Astro_Mutt

Kevin_A

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

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

ASIMount@ZWO

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.

w7ay

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

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

tempus

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

w7ay

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

tempus

w7ay
"As importantly, most people do not align the camera angle of their guide scope (I do) "

Would this alignment be of significance when guiding the AM5?

KC_Astro_Mutt

So I was able to get the AM5 out Friday night. I started with 0.5 second exposures, 200ms Max DEC/RA pulses, 35% aggression on both DEC and RA.

Things started pretty great after I began dialing in the numbers, one axis at a time. At one point, I was getting 0.49"rms, but then that would slowly (over a couple of minutes) ramp up to 1.4"+rms, then back down to 0.5" or so. This was constant, regardless of adjustment to aggression and/or pulse duration settings. Good guiding, then bad guiding.

You can see from the log, I'd get sub-arc second guiding followed by very shaky guiding. It looks almost like a seismograph. I had the mount attached to my Skywatcher EQ6 tripod this time, as I thought perhaps the carbon fiber tripod may have been an issue.

In short, I would get about 2 or 3 minutes of great guiding, followed by 1 - 2 minutes of bad guiding. Thoughts?

I used the ASIAir Plus this time, along with a smaller refractor (Sharpstar 61). ASI533MC Pro, ASI120MM (bin 2) w/ 130mm qhy mini guide scope.

I would assume a mechanical issue with the regularity of the "disturbance" guiding. Polar alignment was at 19 arc seconds error, and was run 3 times to ensure accuracy. I fiddled with the aggression quite a bit, and also the max durations, but the aggression settings near 50% for both axes seemed to be the best. I think I had set the max DEC duration to 1500 and RA duration to around 500. These settings just gave me the best performance to date.

phd2-guidelog-2023-02-17-185348.txt

2MB

w7ay

KC_Astro_Mutt Good guiding, then bad guiding.

That's because there are spots in your periodic error curve that has low first order derivatives (slope of curve) while at other spots, the slope becomes larger.

If the large errors are momentary (a glitch that lasts ony a second or two in time) and don't occur often (say, only two or three times in a long exposure), you can ignore the problem (if you are not OCD), since there are not enough photons in those jumps.

However, if you are consistenly lagging, the slope of the PE curve is too high for your parameters. Try increasing the "aggressiveness" first. But remember, back off when the feedback loop oscillates.

I think I had set the max DEC duration to 1500 and RA duration to around 500.

If the declination gears have the same quality as the RA gears, the declination pulse duration should not need to be anywhere close to the RA pulse duration (since you typically don't need to correct the declination axis at a rate anywhere close to the RA's siderral rate).

It is definitely possible that ZWO had sorted the gears and used the less good gears for declination. But unless they document the Declination curves, we would not know, and you will just need to measure it yourself -- you can try to simulate the drift alignment (for different decination angles) to see if there are bumps in the drift curve.

Chen

w7ay

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

tempus

[unknown]
"As importantly, most people do not align the camera angle of their guide scope (I do) "

Would this alignment be of significance when guiding the AM5?

w7ay

tempus Would this alignment be of significance when guiding the AM5?

No, unless you are debugging. The coordinate tranformation matrix (CTM, for you graphics/Postscript nerds) in PHD2 is is pretty reliable.

But, when you are debugging guiding errors, it is useful to have the guide camera angle set so that the RA aligned closely to either the x or the y axis of the guide camera. You can actually get this from the camera angle when you do a plate solve from your guide camera.

For me, it is just a small, one time adjustment. So it is worth it for me.

Chen

KC_Astro_Mutt

w7ay However, if you are consistenly lagging, the slope of the PE curve is too high for your parameters. Try increasing the "aggressiveness" first. But remember, back off when the feedback loop oscillates.

Increasing the aggressiveness beyond 50% in either axis made things much worse, that's why I began working on the Max Duration settings.

w7ay you can try to simulate the drift alignment (for different decination angles) to see if there are bumps in the drift curve.

To be honest Chen, I'm getting weary of troubleshooting. I'm going to be reaching out to ZWO Customer Support to get this sorted out. It either needs to be repaired or replaced. I've applied the recommended settings, made adjustments, and I still have to throw away 40% of my subs. I suppose someone that enjoys tinkering would be happy to figure this out, but I'm a hobbyist, not an engineer. I just want a mount that works as advertised like I said earlier.

Thanks for you help! You add great value to this forum!

Cheers,
Jeff

KC_Astro_Mutt

w7ay Yes, when my guiding was say, 0.5"rms for a couple of minutes, the FWHM on my images were consistently around 1.5. Then the rms error would rise, and FWHM on those images rose to 1.9 to 2.0.

w7ay

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

KC_Astro_Mutt

w7ay 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.

I use the subframe selector in Pixinsight. I use 2 categories to choose the best images. Number of stars, and FWHM. I've gotten my best image processing using just those 2 parameters.

« Previous Page Next Page »