Getting the best performance from my AM5
- Edited
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
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!
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
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
- Edited
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
- Edited
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.
- Edited
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
btw, what's the opinion on PHD2's DEC backlash compensation with the AM5?
On or off?
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.
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?
- Edited
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
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.
- Edited
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.
w7ay I guess I could go back to using phd2 but I think I prefer imaging wirelessly from my couch. Haha. But when I build another house with a real observatory then I will go back to where I can decide and use my own settings. Winter is coming soon and I just can’t do cold anymore!
I hope they fix their errors in the next update. I moved both asiair pro units to my widefield scopes so higher guiding numbers are less critical . I did try an OAG on my Askar FRA300 and since the scope delivers crisp stars at F5 and with my 533mc pro having a tiny sensor, i could get it deep towards the centre… it worked quite well when I pumped up the gain. I imaged all night at 0.5rms and under.
Star quality definitely matters with this ecosystem.
- Edited
Kevin_A I guess I could go back to using phd2 but I think I prefer imaging wirelessly from my couch.
You can do the same using this with a Raspberry Pi 4 (guess how I know :-):
https://www.indigo-astronomy.org/indigo-sky.html
From indoors, you can do rudimentary stuff (planetarium, mount control, camera control/scheduling, PHD2 guiding) just from any web browser (including on tablets), or use a full blown laptop on your couch with full blown components:
https://www.indigo-astronomy.org/software.html
The components are all packaged as a turn-key INDIGO "All-in-one" A1 if you are lucky enough to own a Mac:
https://apps.apple.com/us/app/indigo-a1/id1617125771?mt=12
https://www.cloudmakers.eu/a1/
The second link has videos to how to do things like polar alignment, etc.
(Notice that it collects no user data. Even if it does, it would go to a NATO and EU country, instead of to China.)
If you prefer YouTube (comic book) documentation, Rumen Bogdanovski (one of the two principals) even has a YouTube video:
https://www.youtube.com/watch?v=ko1Qjs9Zdes
Rumen [https://bg.linkedin.com/in/rumenbogdanovski] owns one of the earliest AM5, by the way. Peter Polakovic, the other principal, is a MacOS nut -- he ordered his M1 Mac even before I did :-) For day work, one of them is an astrophysicist, and the other is a computer IT professional.
Best of all, you can use better cameras, filter wheels, and image rotators than you can on an ASIAIR.
Even better for a geek, since the INDIGO bus is completely open sourced, and documented (in fact, the only place I even found the documentation of communication protocol for the ZWO mounts was in INDIGO's documentation), you can add any of your own software (that is how I run my All-Sky camera nowadays, though a Raspberry Pi 4, and my own macOS program, using a no-longer used ASI294MC).
https://github.com/indigo-astronomy/indigo
Everything looks like devices on a networked bus. Add as many servers as you want to the bus, and access them from multiple clients.
I have already 12-volt-modified a M1 Mac Mini (retired it as a desktop computer when I replaced it by the Mac Studio) to use as my outdoor server. Even if you buy an M1 Mini new from Apple, you can get it for $600, and it is orders of magnitude faster than an ASIAIR.
So, you can go from just a single Raspberry Pi 4 and a tablet running a web browser, to a serious system where the sky is the limit. The upgrade path is already there today. Just add more processing power (more microcomputers, or simply a faster microcomputer) when you feel the need. (Oh, INDIGO can run any device that is supported by INDI -- you can even find humidity sensors. :-) All of your current ZWO devices will still work: I have tested ZWO EFW, EAF, cameras, etc. Just get a Raspberry Pi 4, download and burn an microSD IndigoSky Image, and start playing from just a web browser.
Chen