Using multiple stars should also reduce "star lost" cases, since seeing will not affect all the stars within the same exposure; the probability of losing all 12 stars at the same time is like winning a lottery.

Well, I'll be a monkey's uncle. I won the Star Lost lottery last night!

Seeing was not very good. The star picture in the top left corner of the auto guide window was mutating to all kinds of shapes, very rapidly.

When that happens, one usually packs up for the night. But I wanted to see how much multi-star autoguiding helps.

Seeing was so bad, even the calibration stage produced a slightly non-orthogonal red and blue vectors. The two vectors in the Calibration Data popup shows up to 15 degrees of non-orthogonality. I recalibrated a few times to get better orthogonality and settled for some 5º off. So, there will be a few percent of RA correction applied by mistake to the Declination motor, and vice versa.

Multi-star picked a good number of stars (sometimes up to 12, but sometimes as low as only 7 stars).

Then the terrible thing happened.

Slowly, over the course of a few minutes, one by one of the green circles disappeared!

You expect one or two star loss when seeing is poor at the stars' location, but they should come back again when the turbulence leaves the star after a guide plate or two. In the case of ASIAIR, those dropped guide stars never came back.

Eventually, all stars dropped out and I lost guiding completely :-). They never came back even when the condition for each star improves. I have already written ZWO about this, so by the time there is public Beta, it might be fixed.

When I restart guiding after the stars are lost, all the guide stars magically reappeared. This should be a simple algorithmic bug to fix.

I had also suggested in my Beta feedback that they initially identify more candidate stars, even if the Raspberry Pi can only handle say 12 of them (seems to be the number they chose at the moment) while it is in the middle of autoguiding. So, when a star is temporarily lost you can pick the alternate stars and still be guiding with the maximum number of stars.

While the guide stars were slowly disappearing, I could see the Total RMS error climb -- so multi-star is indeed working; fewer stars, bigger error. And even with 4 or 5 stars available, multi-star seemed to be doing better than single-star.

The other thing is why should stars drop out to start with -- I got an answer from them that they are using HFD to determine hot pixels. When the star shape ever jitters so that the HFD is below a threshold, it is marked as a hot pixel and it is no longer identified as a star and hence the star is lost! (I have submitted a suggestion of a more robust way to find bad pixels during the calibration phase that won't cause a real star to be misidentified as a hot pixel while guiding is ongoing; this might fix the single star "Star Lost" problem too, we shall see).

By the way, the smaller MinMo seems to help with my mount (harmonic drive gearing). Even with poorer seeing, I seem to get better guide numbers than I get from ASIAIR v1.5.3 (1" last night vs 1.3" typically with v1.5.3). Still not as good as v1.3 days, but seeing was also horrid last night.

With hindsight, it is good for ZWO not to push the Beta yet to everybody. Beta is suppose to be for people to test and feedback problems, it is not for the casual user to get a new feature -- for most companies, that comes in the GR, general release.

By the way, ZWO does not appear to follow the Golden Master (GM) paradigm -- a final beta before the full release. I have seen the build number skip a few updates between the last available beta and the general release. This means that there were some changes that never went through external beta. That's like playing Russian Roulette.

The problems that I have encountered so far in Multistar guiding require simple fixes (seems to be algorithmic and mathematical in nature, so far), but they will probably mislead the casual user into thinking multi-star autoguiding does not work on ASIAIR (remember my earlier comment about scaring horses and children). Beta feedback is also merely feedback -- there is no guarantee that ZWO will fix the problems that you submit, or accept a single recommendation.

You probably need to be a shareholder like Warren Buffet to get them to listen more seriously to every bug report :-) :-).

Chen

billx Chen, why do you think guiding changed so drastically since v1.3.

That is the $64,000 question. I have no idea (otherwise I would be richer, ha ha).

Believe me, I have personally emailed them multiple times and asked what they changed in the code. The answer that came back had always been "Nothing was changed."

My error used to average around 0.6" to 0.7"total RMS error (I have kept v1.3 logs). With V1.5.3, I averaged closer to 1.3".

Yep, I agree it is something ASIAIR changed, not something in the original PHD2, nor even how PHD2 was used in v1.3. And since PHD2 guides fine, it is not the camera hardware, either.

Chen

Skylab1 what board does asi air runs on?

v1 runs uses a Raspberry Pi 3 and v2 uses the Raspberry Pi 4.

The serial number of your ASIAIR is a portion of the processor ID string on the ARM chip that is unique for every chip that is made by ARM for Raspberry. So these are stock Raspberry Pi boards.

I don't know if they are still using that serial number scheme with the current QR code license scheme.

If you are bored one day, connect the HDMI output from the board and to a TV or monitor that takes HDMI input. You see the Raspbian console. You can connect a USB Mouse and USB Keyboard to the USB ports too, but if memory serves, there is no guest account.

Chen

billx Chen, I never used a ST-4 cable before. I don't know if I can find it out of the stuff I have. How would I hook it up? Wish I could help more.

Please don't waste any time, Bill, if it is not a 5 minute exercise for you. This is ZWO's problem after all, not the customer's.

For what its worth, ST-4 is a cable that has an RJ-11 connector at the camera end. So it is identical to the telephone cable from the set to the wall (in other words, a smaller, fewer pins version of the Ethernet RJ-45 connector). (A even smaller version, the RJ-9 is used in corded telephones to connect the handset to the base.)

Most mounts also use RJ-11 on the mount end of the cable. And with many mounts, it is a one-to-one cable. The problem is that not all mount have 1-to-1 wiring. Then there is the Takahashi Temma controllers, which use a mini-DIN at the mount end. That is why, if you haven't already been using ST-4, it may take some head scratching and document searching and cable splicing :-).

ST-4 is not really magical, and the ST-4 connector in a camera is not something very special.

Back in the very old days, you guide by staring into a very long focal length guide scope with an illuminated cross hair (I still have one of those eyepieces :-) and use the RA-Dec buttons of a hand controller at the slowest speed, like 1x sidereal, to visually keep a guide star centered. That is also why guide scopes come with the tube rings, so you can center your main camera on the target and recenter the guide scope's cross hair of a guide star. It is definitely not for the faint hearted. Back then, film weren't cheap either, so you don't want to ruin a frame by improper guiding, and you keep a hat handy when a plane comes by (no pesky Elon Musk satellites to deal with). Most of us had our own darkroom (ah, the smell of D-76 and Dektol :-) so we don't have to wait the one week turn around at the drug store.

During the digital camera era, someone smart came up with the idea of using a camera instead of the human watching a crosshair. And instead of the human pushing buttons, the mounts were modified so that they would make movements through 4 pairs of wires. If one shorts out the wires of the RA+ pair, the mount would make a motion in the positive RA direction. Likewise the RA-, DEC+ and DEC- directions.

At that time SBIG decided to market a cheap camera just for autoguiding (cheap by SBIG's standards. that is). SBIG still some of the best astro cameras, but if you are shopping ZWO, they are probably not in the same ballpark.

I still have my SBIG ST-8300 but haven't used in some half dozen years now, at least. Most of SBIG's cameras had a "ST" catalog number, and they called this "cheap" camera the ST-4!

http://www.company7.com/sbig/products/st4.html

As you can see from the historical picture, the entire ST-4 package includes a large control box.

From that time on, anything that directly controls the mount to auto guide are known as ST-4.

With today's guide cameras, what happens is that there is some circuitry that piggy backs on the USB chip set that usually carries just the image data and control. The circuitry (really firmware in a microcontroller chip) decodes USB commands and convert them into the RA+, RA-, DEC+ and DEC- contact closures.

There are no voltages in the four pairs of control signals. Simply contact closures (switches). Most of the time just using transistors switches, but I have seen some old designs that used reed relays. There were a lot of home brewing back in the old days; playing with technical things was one of the main attractiveness of the astrophotography hobby. The more complex the problem is, the more the nerds are attracted it. Unfortunately that has changed a lot with the selfie generation, where astrophotography is a process that is the equivalent of taking snap shots.

You know the alternate way, of course, which is what is called "pulse guiding." Some enterprising souls decided that they don't want to pay the few dozens of dollars to buy or build a converter that went from an RS-232 serial port (no USB back in them days :-) to the four contact closures. Instead, they use the RA and Dec slew in the Mount protocol itself.

Is it an advancement, yeah -- you no longer need the ST-4 cable if you are already computer controlling your mount, so it is very convenient. Is it better than ST-4? Questionable, especially for mounts that use 9600 baud -- latency needs to be calibrated out, and then you assume the latency is consistent, which is unlikely in today's programs that uses multiple threads -- especially if autoguiding is not given high thread priority.

ST-4 guiding is simply a way to send guide instructions to the mount directly through the piggy backed ST-4 circuitry that is present in many of today's guide cameras. Pulse guiding tries to emulate it by using the slew commands in mount protocols.

Some mounts actually do have specialized guide commands, where the command format is a direction plus a duration in milliseconds, so you don't have to sloppily time it in software with a start-slew-stop-slew sequence of commands. That is superior to using ST-4. But ASIAIR does not use those better guide commands even when they are available.

If the ASIAIR autoguiding bug is caused by their using the synchronous video captures that I described a couple of posts before, but did not properly discard unusable frames for example, then ST-4 guiding will not improve anything.

However, knowing ST-4 guiding performance could help understand where the bug resides.

I know ZWO says they did not change anything, and thus "no bugs." When you are in denial, you obviously will not be looking for the bugs. I know it is not our job to look for the bugs for them, and I know a number of people who have moved on to other platforms instead of fighting the autoguiding bug in ASIAIR, which supposedly does not exist!

As customers, I think we really have only three choices 1) accept and keep using the poorer autoguiding performance, 2) pinpoint the source of the bug for them (as I recently did with the Sync-and-GOTO bug, which also was left unfixed for a long time, perhaps because they were not even looking for the bug), or 3) move on to some other platform.

You can of course take a hybrid path, even if you prefer the convenience of a Raspberry Pi -- use ASIAIR to polar align (instead of using SharpCap to polar align on a real computer) and then switch to INDIGO Sky to do serious astrophotoraphy. The cost of an extra Raspberry Pi 4 is in the noise. And if you don't want to be tied down by a Raspberry Pi, the sky is the limit. But even this solution won't work if ASIAIR is not slewing your mount by 60 degrees during polar alignment!

Just use ASIAIR as an expensive PoleMaster substitute. If you can see the pole, you can even mount a dedicated polar alignment camera permanently to your mount like you do with the PoleMaster's camera.

Chen

billx But I don't understand how the guide camera would connect to the laptop.

In PHD2 I believe you would select "On Camera" as the Mount. See Mount Selection here:

https://openphdguiding.org/man-dev/Basic_use.htm

With ASIAIR, you would go to Telescope Settings or Mount Settings window (the name kept changing with different versions of ASIAIR, ha ha; the Menu icon looks like the silhouette of a refractor, right under the Guide Camera setting menu selection icon); and for Telecope, choose "On-Camera-ST4" which is not alphabetically ordered, but is at the very top of the Telescope menu items (just above the Argo Navis mount). Consistency is not one of the ASIAIR GUI's strong point -- that is why so many people are puzzled by the ASIAIR.

Notice that with the ASIAIR, you cannot control the mount and use ST-4 at the same time (don't know why they cannot simply add the ST-4 option to every mount selection; that would create a consistent GUI and provide useful functionality). So you need to first move/slew the mount to where you want it to go, then switch "mounts", then go to guiding window.

You should be able to keep the ST-4 cable connected even when not using ST-4; but I would remove it when you are selecting a real mount, just in case there is yet another bug that is unbeknownst to us peons.

When you select On Camera ST-4, ASIAIR would select the ST-4 interface in the camera that you have chosen as your Guide camera, so you need to activate (select) the guide camera first. If you don't do that, ASIAIR will complain and tell you to connect the camera. This way, you can have multiple cameras with the ST-4 interface, and only the one selected as the Guide Camera will be used as the controlled ST-4 port. Yeah, Rube Goldberg.

With PHD2, guiding is independent from the mount controls (done with a different program, not PHD2). But ASIAIR conflates the Mount and the Guide. SMH. So, on anything other than ASIAIR, you have full independence on how you want to guide. With ASIAIR, if you want to guide with ST-4, you cannot control the mount (but you can dither the frames). You can actually remove the control cable from the ASIAIR to the mount, but it should not hurt to keep the mount plugged in to the ASIAIR. The ASIAIR just won't talk to it if you have selected On-Camera-ST4..

Chen