CHriss But "best" is most relative here, a RMS of 0.8 to 0.9 certainly is nothing to be happy about, especially taking the price of the AM5 into consideration.

As I have mentioned many times, a typical worm geared mount will outperform (w.r.t. autoguiding) a strain wave geared mount that is at least 3 times more expensive. The price of the strain wave gear mount has nothing to do with guide performance (and ZWO may be worse than folks who know how to machine precision mechanical parts); you are paying for other conveniences (such as portability) and not precision.

No one should ever buy a strain wave gear mount if they don't understand that price performance aspect of stain wave gears. Don't listen to the YouTube shills, it is not their money; and you never see a YouTube shill tout a 10Micron mount, have you? That should tell you something.

That being said, if you are getting 0.9" typically and ZWO advertises on paper (or web page) that you can get 0.7", that should be enough to return it and get your money back. Even if 0.9" is good enough for you -- you did not get the mount that you had paid for. If they use weasel words such as "typically 0.7", then keep that in mind the next time you need to buy something ("fool me once, shame on you, fool me twice, shame on me").

Just one note about the pixel size of the guide cam.

From the first guide graph that you showed, the large errors are not caused by bad correction pulses. It looks like a mechanical problem. So, not need to look at pixel scales etc. Look for lose bearings, bad belts, etc.

A telling point (which you did not mention earlier) is that the large error spikes are periodic. They occur every 110 seconds or so (you probably can do more work to get a better average using more cycles than is shown in the above graph).

Now, the problem with the above is that it happens on both the RA and the declination axes at the same time. They are independent and orthogonal motors. So, that appears to preclude the strain wave gears themselves as the source of the problem, but some mechanical defect in the rest of the ZWO mount.

Did you send the graph to your dealer? They should immediately refund the cost of the drive since there is something so obviously wrong from the large periodic spikes. If not, just dispute it through your bank/PayPal and do a stop payment.

The problem with the ZWO mounts so far is that everyone seems to have a different problem with it. The design does not appear to have been vetted by an engineer, with proper limits in place for QC to take defective products off the assembly line before shipping to customers.

Chen

Jan75 I use a 80 mm and 328 mm guide-scope from TS, for example, and a ASI ZWO 220 mini camera (4 µm pixels) this yields a resolution of 2.52"/pixel.

It is not just the focal length of the guide scope but the spot diagram (sort of the magnitude of the point spread function) all the way to the edge of the guide frame of the scope, since we need multi-star guiding when using short guide exposures.

I'd recommend taking an image from the guide system and look at the HFD of an average star in that image. If you use ASIAIR, just use the Detect Star utility, even though the numbers you get from ASIAIR are actually sky background dependent (another poor implementation by ZWO; everything in ASIAIR seems to be a copycat of real programs, without any understanding of the basic principles).

In my case, I use a guide scope with 55mm aperture and 250mm focal length (Borg 55FL objective), together with a TS flattener that is really meant for their 60mm- f/6 scope -- but appears to work well enough to get good stars across an ASI178MM frame. With that, I typically get an HFD or around 2.3 pixels. So quite close to critical sampling, by luck -- which could explain why I could get so many guide stars even with low camera gain, that some other folks could not.

Centroids are computed based on this star diameter (which is typically way larger than the Dawes limit, and gets worse with poorer optics). So I have been depending on actually measuring the HFD to determine whether it is under- or over-sampled, rather than the theoretical star size (usually based on the Dawes limit).

Being oversampled is not bad, but you do loose star brightness (and need more camera gain). But you do not ever want it to be under-sampled, since centroid estimation becomes increasingly inaccurate. Imagine a star that is so small that 90% of it completely inside a pixel (with very little energy outside that pixel). That star can move and the centroid estimate will not change (i.e., centroid remains at the centroid of the pixel). That may be the case with the ASI220 camera with its giant pixels. If the measured HFD of a star is smaller than 1.8, I suspect that it will be problematical since the true HFD is probably even smaller.

With my current guide system, I can actually see centroid estimation errors from ASIAIR as I change the camera gain. With 11 to 12 stars, and 0.5 second exposures, ASIAIR is producing an error (i.e., it will steer the mount the wrong way even when the mount has no error in that frame) of the order of 0.3" to 0.4" RMS! By adding 20 dB more gain (200 gain steps for ZWO camera, and correspond to an analog linear gain of 10), the centroid error falls to the 0.2" to 0.25" region. (With that I can actually guide my RST-135e to 0.35" RMS total when there is no wind.)

Now, if your mount has large errors (say 0.9" RMS), then the centroid error is not a problem -- the mount is the problem (i.e., focus on fixing or replacing the mount instead of the guide scope). However, if the mount itself is capable of guiding to better than 0.5" total RMS, then getting a good guide scope/camera match is worth the money (the Borg 55FL objective itself is twice the cost of a ZWO SeeStar :-).

An easy way to watch for the errors is to first do a good polar alignment so that there is very little declination drift (10" to 20" is good enough). First calibrate PHD2 with declination guiding turned on. Wait for it to start guiding, and turn it off. Then turn declination guiding off and start guiding. Since there is no declination drift, a perfect centroid estimation should also show no declination error. But if you watch the declination graph, you will see it moving. The ASIAIR is telling the mount to adjust the declination motors even when it should not be, had declination pulses been turned on. You can then try adjusting the gain of the guide camera and see if the declination guide graph becomes better. Anyway, all these observations should help you understand the guide process (even though with the ASIAIR, it is hidden inside a black box).

For what its worth, I am increasingly (like some of the Cloudy Nights folks) leaning toward the ZWO mounts having some fundamental flaws. I don't think guide scope/camera tweaks will or can solve that.

Only a proper study and redesign -- after understanding what causes the current problems -- can do that. But what do you do with the customers have already paid for the current mounts, and does ZWO even have the necessary mechanical engineering talents to achieve that? Right now, they appear to just be deer caught in headlamps. The recent attempt to increase the MinMo is very telling of how much they understand (or, more accurately, do not understand) the characteristics that are important with mounts with large error slopes.

Superficially copying someone else's product without doing serious engineering work will lead to problems -- I think you will remember episode where the tantalum capacitor leaks that rendered electronics to fail after a few years, and also the exploding lithium batteries more recently. In both cases, the chemicals used were missing some critical stabilizing material which the copycats' spies did not manage to copy.

Chen

All,

The periodic spikes that @CHriss posted (real guide grphs to prove it too) kept bothering me, firstly because similar periodic spikes had been repoerted in the past both at Cloudy Nights and on this forum (perhaps with a different period than the approx 110 seconds; I do not remember -- someone else may remember).

(OK, ZWO should be the one that is bothered and their geniuses should be be looking for a cause, but lacking that, here goes one possibility...)

The graph from @CHriss is very illuminating since it shows that (1) there is no precursor large correction pulse before the spikes, and (2) it happens at the same time on both axes.

Initially, that really puzzled me, since (2) means that the actual strain wave gears are not the culprit (I am trained as an engineer not to believe in coincidences -- independent events should be statistically uncorrelated). At the same time, the graph shows that seemingly nothing is causing the spikes.

Aha! "seemingly" is the key word!!!

The correction pulses shown in the PHD2 guide graphs only shows the pulses that are issued by PHD2! (OK, a couple of you should now have light bulbs over your heads.)

A guide pulse is either sent as a command to issue a slew (at guide rate) for N milliseconds (the pulse width), or as a sequence of two commands, the first to start slew at the quide rate, followed by a software timer, then followed by an end-slew command.

These pulse commands can be sent by some other process (for example,the mount driver) or even autonomously within the mount's firmware.

So, it is important to know if these large periodic pulses only appear when using ASIAIR or also happens when you use some real program. If it is the former, we (royal "we," since I don't own, and don't plan to ever own a ZWO mount) can place a USB Sniffer between the ASIAIR and the mount. WireShark for example can do that, or on a Mac, you can also use a program I had wriiten an eon ago called Serial Tools:

https://www.w7ay.net/site/Applications/Serial%20Tools/

If the problem also occurs on a computer running a real program, then there is no way we can look for the bug, since the bug would be in the mount and not observable over the serial USB interface. Only ZWO has access to the code for the mount's firmware.

So... it does not have to be a mechanical problem. It can also be a very serious bug in ASIAIR or the mount firmware.

Now, if it is a serious bug, you would think ZWO would have tracked it down by now (instead of cluelessly changing MinMo!).

Chen

w7ay you my friend have hit the nail on the head I believe. I think it is a firmware glitch that may affect mounts with certain slope characteristics. Or just bad centroid estimation that make certain mounts with specific slope characteristics go bonkers when the star gets weak.
I have a hard problem fully believing it is a mechanical problem when my guiding runs at 0.4 for an hour or so then it hits the fan all of a sudden then rinse and repeat. One strange thing that occurs which is very weird is… I can look at asiair on my ipad for 15 minutes as it guides really well and as soon as go and bring up the main guiding page to view the graph bigger with all my settings… it all of a sudden then starts acting up and spiking slightly. I thought it was a fluke, but flukes do not happen that much repeatedly.

CHriss I've ordered a QHY5III 178 Mono as guide cam

Do you still have time to exchange it for the QHY5III 678 Mono camera?

The IMX678 is more sensitive than the IMX178 sensor, and at the same time have 2 µm pixels instead of 2.9 µm. Additionally, the QHY camera comes with an IR-pass (685 if memory serves) filter in the box so you can try near-IR guiding too (for me, I get a 25% better guiding with near IR and I get better improvements with other tweaks, so I have myself put near IR guiding on the side -- getting more stars is more important). The pixels are half the size of one from an ASI220.

Getting lots of stars with lots of gain margin available (i.e., being able to push 20 dB past 12 stars) is important because, if I am not wrong, PHD2 uses SNR weighted centroids. The proper thing to do is to use a different weight. But we do not have a choice if we don't write our own software.

Just the the past week, a Forum reader had asked to read the white paper that I was working on. I confessed that I have not touched that (waiting for winter when it is clouded up and rains for 3 mounts non stop to resume) but made a checkpoint of what I currently have (rough notes all over and very rough English -- was my third language):

http://www.w7ay.net/site/Downloads/AutoGuiding/Rough/index.html

Scroll to section "Appendix B. Star Centroids Under Atmospheric Turbulence" and you will find how pushing the gain helps when the guide software mistakenly uses SNR as the centroiding weight.

Again, I apologize for the very rough nature of the whole paper.

I use an ASI178MM with ASIAIR, but have started to experiment with my own autoguiding algorithms using the QHY678M and INDIGO (macOS desktop, with M1 Mac Mini [modified for 12V] or Raspberry Pi 4 at the telescope). No definitive result yet, but I expect the 678 to comfortably outshoot the 178. Definitely searching for a better centroid weight (I suspect for now it is simply uniform weighting since centroid error is not much affected by SNR).

I already use a high quality 60mm f/4 scope for guiding

Take a well focused image from it and look at the FHWM or HFD over the frame. Are the star sizes within 10% from one another? Even the best refractor objective has field curvature, and we do need the star shapes to be moderately uniform to take full advantage of multi-star centroid estimation. The world has changed from the single star case, where you can pick just a single good guide star. And for the sake of the stars away from the optical axis, you need to focus well (I have a belt driven EAF on my guide scope since I am too lazy to spend time outdoors in the dark and cold fiddling with a helical focuser).

Chen

By the way, to be a bit more clear, unless you are already achieving about 0.5" type tracking error, the guide scope is probably not the main limitation.

11 to 12 stars typically causes a 0.35" type centroid estimation error in ASIAIR (donno about raw PHD2; but I think it is the same since ZWO just copies PHD2) with my guide scope/camera combination.

Pushing the gain past that point will reduce this estimation error (i.e., make centroid include more stars when weighted).

However, if your total RMS error is significantly greater than 0.5" to start with, the cause of error of that magnitude is not coming from centroid estimate (unless you have particularly bright star in the guide frame, and it is chosen as one of the guide stars).

If you are guiding around 0.5" but can't seem to push it to get better guiding, that is where more guide stars come in.

I had been hanging around 0.45" total RMS region a year earlier, when I tried to use the least gain possible to get barely 12 stars so that sensor noise is minimized. At least that was my reasoning. I had thought back then that the 0.45" was the limitation of my mount. It was only after I realized what SNR weighting is doing to centroid estimates that I started pushing the guide camera gain beyond the 12 star point, in spite of adding more camera noise.

I had earlier described the way I quantified the centroid estimation (turning off declination pulses and watching the declination guide graph). You can try the methodology on your guide set up to see if the guide scope is the limitation.

That way, you will know if your guide scope/camera is the limiting factor, and needing improvements.

Chen

CHriss no and took the 178 on purpose.

Should not be a problem with a large aperture.

With the ASI178MM, I am getting 11 to 12 stars with about a gain of 6 dB (gain of "60" units for the ZWO camera -- notice that ZWO uses log based 10 for gains, while QHY uses natural log for gain units so there is a factor of log based e of 10 between them; that is why I prefer to just use decibels as a gain factor so there is no ambiguity).

Pushing 20 dB beyond 12 stars therefore only pushes the ASI178MM to a gain of 26 dB (or "260" in ZWO's gain units). Pushing to 40 dB gain does bring up excessive camera noise though.

Getting smaller monochrome pixels is my current vector. If we don't use SNR as the centroid weights, life should be much better, since we can just use about 6 to 9 stars and get better centroid estimates than using 12 stars plus 20 dB extra gain today. With proper centroid weights, we should not even need 6 dB of camera gain at 0.5 second exposure to get us the equivalence of 3 second guide exposures with a single star.

The DONUTS algorithm (professional astronomers) uses uniform weighting (since it is FFT based), and they claim 0.18 pixel centroid accuracy. That is why I think SNR weighting is the limitation of today's hobbyist guiding (about 0.35 pixel RMS accuracy).

FWIW, with my guide scope's plate scale, I am getting an HFD of about 2.3 pixels with the current 2.9 µm camera.

Chen

Kevin_A My spikes are never periodic… very random or whenever I scroll thru asiair app while guiding.

Yep, the ZWO mount does appear to have multiple unrelated (and all unaddressed by ZWO) problems. Yours may indeed be a mechanical problem (way past returnability, I expect).

But there are multiple reports now on large guide spikes that are mostly periodic. I need to find the Cloudy NIghts posting to see if they also had a 110-ish second period as @CHriss .

As to the scrolling problem... it is truly bizzare, since guiding should be done in the ASIAIR itself and any tablet (ASIAIR client) redrawing latency should have no effect, unless the ASIAIR processor is so stressed that you are losing guide frames while it is trying to update the tablet. Any competent programmer would have placed guiding as a higest priority process and GUI as the lowest priority -- but you can never tell what is in the minds of the ZWO programmers.

When you scroll the main camera image, does the guide FPS number stutter? You can use a second tablet to monitor the guide window (to watch the FPS number) while you scroll the preview image with the first tablet.

If the guide FPS stutters when you scroll, then we know where the problem is -- rubbish code.

Now that you mentioned the behavior, I will try to watch for it the next chance I get. Won't even need good sky transparency to see if FPS is stuttering, as long as the guider can see a few stars. And I can try different preview window sizes, from a 12.9" tablet to the macOS iOS emulator, down to an iPod touch.

(As an aside, I know that ASIAIR will only support a max of two ASIAIR clients at a time. Perhaps updating windows in a client is stressing the ASIAIR device.)

Chen