Getting the best performance from my AM5: Page 25

Getting the best performance from my AM5

Kevin_A

So far from my testing the biggest thing that affects my guiding seems to be guide star quality. When my guide stars are tight, small and clear I get 0.25 to 0.4 all the time, but when my stars experience atmospheric disturbance or if I use a small crappy guide scope my guiding stays between 0.6 to 0.8.
It did not matter what settings or exposure or pointing direction… star quality ruled!

MrAstro

Kevin_A
Recently, I faced same situation as you described..
I was using a normal 50mm FL180 SW finder scope witch came with the SW 100mm Esprit telescope.. and it was installed by fixed rings without that thumbnail screws and not using the thumbnails finder shoe rather I used 2 Hex screws to fix it firmly .. no way to wobble,, what ever I did in PHD2, cables, no winds, or changing exp. time I am getting 0.7"-0.9" RMS..
As soon as I switched to WO 50mm FL200 scope and with defaults PHD2 values ( except Agg. ) I am getting 0.6"-0.45" RMS with same rigs exactly.
I can't explain this improvement except its better star shape and better optics guide scope.

CHriss

MrAstro
I will be able to report on this, soon.
I've ordered a QHY5III 178 Mono as guide cam and since I already use a high quality 60mm f/4 scope for guiding, with the new cam image quality should be close to the maximum possible. Let's see if it makes a difference.

w7ay

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

CHriss

w7ay I'm not using ASIAIR and never have or will, it's "real" PHD2 using a Windows 11 PC.

Kevin_A

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.

w7ay

CHriss I'm not using ASIAIR

OK, the remaining possibility is there is a bug in the mount firmware, then. Thanks for the additional info to fill the gap.

As to ASIAIR, I expect more people to abandon it once they discover the limitations, and the never fixed bugs of the ASIAIR.

Chen

w7ay

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

w7ay

Kevin_A Or just bad centroid estimation

That would not account for why the large error spikes are periodic, though.

I am beginning to suspect that some idiot (I can't find a kinder word for such uneducated action, if that is what happened) added a correction term to periodically move the mount to achieve a perfect sidereal rate (since their internal hardware clock is probably based on some cheap standard clock crystal that are usually keyed to 24 hour days).

If you are experiencing periodic spikes, change the tracking rate to Solar to see if the spikes go away. Solar rate tracking (23h 56m days instead of 24h days) will make the RA guiding work harder (you may need to increase the max pulse duration to keep up), but if the spikes then go away (or changes period)...

However, the reason why I am far from certain about this is that why would such correction term also include declination spikes, since we know ZWO does not have an internal mathematical model of the mount (I kept telling them to read Seki-san's white paper to educate themselves)?

Anyway, not my problem.

Chen

CHriss

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

no and took the 178 on purpose.
Check out the specs and curves, the readout noise of the 178 is way lower and it's a BSI type chip.

Kevin_A

w7ay That would not account for why the large error spikes are periodic, though.

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

w7ay

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

w7ay

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

w7ay

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

Kevin_A

w7ay i do notice that my frame rate goes from 0.9 to 1.3 rapidly and continuously with 1s exposures and 1.9 to 2.1 using 0.5s exposures. My skies may be a big contributor to my star quality too as my guide star is never constantly sharp either. Canada wildfire smoke all gets directed down thru southern ontario! So add turbulent skies with smoke and it is not a great recipe! My biggest scope resolution is 1.2 so getting near 0.6rms consistantly is my goal and my stars are round so the spikes are not affecting it too badly. Last night I got an hour averaging 0.51rms so thats fine for a portable mount. I am just happy that I do not image at 1300mm and up!

w7ay

Kevin_A 1.9 to 2.1 using 0.5s exposures

If you stop acquiring images on the main camera, does the FPS numbers still stutter?

I do get the occasional +/- 0.1 FPS stutter, which could just be rounding errors. Typically, a 1.9 will be immediately followed by a 2.1, which is just a case of poor software timing clock resolution. But you should not see 1.8 (or less) or 2.2 FPS, for example.

The ASIAIR has rounding errors all over the place. If you look at the Mount Setup window, take a look at the mount's Latitude and Longitude (Mount Info box) and compare that to the tablets Latitude and longitude (Location Info box), you will often see an error in the least significant digit even after you have synced the mount to the tablet. That bug has been there since the very first version of ASIAIR.

my stars are round so the spikes are not affecting it too badly

You should not see the effect of spikes (even if they are many arcseconds tall) as long as the duration of all the spikes together is much shorter than the duration of the main camera exposure. The worst is if you have a very bright star in the frame (e.g., Alnitak when imaging the HorseHead) -- those are more visible since the brightness adds to the exposure value.

Chen

w7ay

Kevin_A I am just happy that I do not image at 1300mm and up!

I willl be facing that not long from now.

I have reserved a Mewlon 180 from the next production run. When I ordered it, my original plan was to use it at 2160 mm focal length unguided just as a planetary OTA. And that is the reason too why I bought the absolute encoded RST-135e, to keep planets to within a small ROI (and therefore faster frame rates).

But I have also bought an Astro-Physics reducer/flattener, hoping that it can be adjusted to give me a 0.45x reduction, and thus 970 mm -ish focal length. That would make it an f/5.4 and somewhat usable for DSO. So I will need to be able to guide well enough for 1000 mm -ish focal lengths. This is why I am working hard at achiving 0.35" error; I can do that at the moment with the RST-135e, but I don't know what the addition weight of the 7" Dall-Kirkham would do. Time will tell.

Chen

Kevin_A

w7ay tonight I am imaging at 1s and getting 0.9 fps fairly consistently. Guiding is below 0.5rms and only a few deviations.

w7ay

Kevin_A t

OK, just tested the FPS.

I currently have the 4th generation (Chinese processor, ASIAIR "plus") in my box outdoors. Ethernet connected.

Two ASIAIR clients connected to the ASIAIR. One is a 12.9" iPad opened to the Guiding window., watching the FPS number The second client is either an IPhone 12 Mini or the ASIAIR app running in a Mac Studio that is running the iOS emulator. (I don't really use the iPhone 12 mini as a phone -- I still use a flip phone -- but as a small form factor iOS device, since Apple has discontinued the iPod touch.) The Mac is connected to the same Ethernet switch that the ASIAIR device is connected to (so packets don't even pass through my router), while the iPhone mini is connected through WiFi of the eero mesh network.

With either of the clients, I can switch windows, change the image scale, and so on, and the guiding FPS stays perfectly fixed at 2.0 (with 0.5 second guide exposure).

However, when I capture an image on the main camera (a dummy ASI183MM with a CS lens on it), the guiding FPS stutters down to 1.8 and 1.9 FPS while the ASIAIR device is uploading a new image to one of the clients.

This is a screenshot of the guide window at the time the FPS dropped to 1.8 FPS. Notice there is no glitch in the guide graph, though. Not quite out of astronomical twilight yet, so I had to keep the gain low (13.6 dB) to keep the background from a whiteout. But the "seeing" appears good from the guide RMS error numbers, even though the transparency is terrible, if you believe the satellite picture from WunderGround.com.

So, either guiding is fubar, or the one estimating the FPS is fubar in ASIAIR.

(This is one of the reasons I have converted an old M1 Mac Mini for 12V operation -- this is in preparation for running INDIGO in it, instead of running INDIGO Sky in a Raspberry Pi 4. The simple processors just don't have the horsepower I need -- who knows how much processor I need for my guide algorithm :-) 12x faster on multi-core Geekbench 5, and 100x faster with 32-bit floating point arithmetic:

https://www.cpu-monkey.com/en/compare_cpu-apple_m1-vs-raspberry_pi_4_b_broadcom_bcm2711

Chen

Kevin_A

w7ay i think the asiair just shows +/- 0.1 and it probably is ok at 0.9fps using 1s.
I had asked zwo to add a minmo feature and guide rate adjustability plus address the issue of multistar guiding including oversaturated stars in the 12 even at high gain…. The programmers won’t offer minmo permission right now and have not agreed that guide rate would be even in the next release but did say they would look into the guide star(s) selection criteria.
Last night I guided 0.51-0.54 all night long with blips included every 20 minutes or sobut I did get good images for 3 hours on M31.

w7ay

Kevin_A The programmers won’t offer minmo permission right now

They also need to ignore the max pulse duration during a dither recovery, and also to ignore the north-south only declination pulses during dither recovery. There are crazy amount of things that don't work properly in ASIAIR. Most of them don't even involve more than a few lines of code and a week of testing. But I have given up giving them recommendations for a year now -- the management are obviously not interested in engineering, but in doing the minimum possible to get the novices to buy their products. I switched to doing things I want in INDIGO.

Chen

« Previous Page Next Page »