Getting the best performance from my AM5: Page 25

Getting the best performance from my AM5

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

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.

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

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

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

CHriss

btw, what's the opinion on PHD2's DEC backlash compensation with the AM5?
On or off?

MrAstro

CHriss
I never used backlash compensate with my AM5 and PHD2.
Also, in PHD2 when you tick "fast recenter after calibration or dither" it will ignore the Max duration to recover faster.

Jan75

I have now tried using a guidescope rather than OAG and even 0.2s guiding exposure (instead of 0.5s) and a counterweight. To no avail: the total RMS is still mostly in the 0.9"-1.1" area including on targets such as M57 that have high declination. Frequency analysis shows strong Nth-order peaks with the dominant 2.9s-period one reaching above 1". I just sent my latest PHD2 log to ZWO, now waiting for any response but right now I think I have pretty much exhausted all configurable parameters.

Jan75

Kevin_A

I am noticing that when I look at the guiding graph in asiair, that while guiding is acceptable, there is very little small guide pulses to keep it in check and it only seems to have a few large pulses when my graph gets spikes? Anyone else notice this? Guiding generally is in the 0.4 to 0.8 range but no corrections in either axis are issued unless a 1s spike occurs. Maybe asiair just is not showing smaller pulse corrections?

w7ay

Kevin_A it only seems to have a few large pulses when my graph gets spikes?

OK, we are finally getting down to the gist of it all.

Did you see an especially large guide pulse before the large guide graph deviation?

If you are seeing large number of pulses before the guide graph has gone, up, PHD2 is doing something weird (issuing guide pulses without any stimulus).

However, if you are seeing large number of pulses after the guide graph has gone up, this is "normal." However, you need to investigate it the rise in the guide graph is cause by (1) wind (I see the effect of even 3 mph gusts (measured on NetAtmo 15 feet away from the tri-pier); but the graph would deviate for a couple of seconds, and settle back), or (2) by centroid estimation error (i.e., the guide scope "lying" to PHD2 that the sky has moved even though it has not), or (3) by the mount' mechanism not being able to keep sub-arc-second precision.

(1) and (2) are likely to affect both axis at the same time. (3) tends to happen to just one axis at a time. So that could be a clue.

I was just going through 6 mph wind gusts last night, and autoguiding deteriorated to the 0.5" range from the 0.35" range the night before, when the gusts peaked at no more than 2 mph.

Chen

Kevin_A

w7ay the pulses in log viewer are there and happen right at the middle of the peak so it is working it seems… they are just not being shown on the asiair graph. I did find out why 2 of my older asiair pros are crappy… their minmo is 0.2 vs my asiair plus at 0.1. Same firmware update.
Weird but now I know why 2 rigs are good and 2 are bad.

Kevin_A

Revised: I had noticed that when I look at the guiding graph in asiair, that while guiding is acceptable, there is very little small guide pulses to keep it in check and it only seemed to have a few large pulses when my graph gets spikes? Guiding generally is in the 0.4 to 0.8 range but no corrections in either axis are issued unless a 1s spike occurs but asiair just is not showing smaller pulse corrections it seems. Actually in phd2 log viewer they are there… just not in asiair app. Another thing I just noticed is in the latest firmware 10.74 for asiair plus the minmo is 0.1 but in the same firmware version for the older asiair pro it is 0.2. No wonder my 2 older asiair pro guide much worse on my am5.

Zwo can you fix this as my guiding is 50% worse on my asiair pro setups using a minmo of 0.2.

w7ay

Kevin_A their minmo is 0.2

Yep, that will definitely be one huge step back. Not problem for me, but for people stuck with using ASIAIR (their own choice, so you can't really blame ZWO).

Chen

« Previous Page Next Page »