Skylab1 IR from security cam can cause seeing problem on guide cam

Ha ha, thats funny.

A good IR filter should do better, if that is the case. Plus a loooong metal dew shield.

It does not help that the ZWO mini guide cameras use AR window instead of an IR cut window.

IR goes through cardboard like its not there -- I found out the hard way when IR from the ceiling light was going through a cardboard shield that I built around my mount simulator -- I added a Baader Semi APO filter to the camera, and all the bright areas vanished. I now swear by the Semi APO (or at least the Baader Neodymium filter -- to get rid of any fringes around stars, the Semi-APO cuts more on the UV end than the plain Neodymium, but it ends up cutting down a lot of light, perhaps 3 dB; and my Borg 55FL guide objective may not need such an aggressive UV cut). This will allow me to use a lower camera gain, and better SNR.

I'll bet the ZWO UV/IR filter still leaks a lot of IR and the passband itself may be poor too (the graphs show their windows already leaking around 1200nm). Your LP filter probably blocked IR better than the ZWO and/or pass the visible light with less attenuation (or better coating, so more light passes through). ZWO glass tend in general to have halos too. You can try the black felt tip pen trick on the edge of the glass to see if it improves for you.

In my case, the Baader Semi-APO visibly beats out the cheaper Optolong UV/IR cut filter on star sharpness in the guide window. I will try the Baader Neodymium when I get the chance, to see if that will give me more photons than the Semi-APO.

Chen

Skylab1 The mount will also slew and pointing the scope to the ground if target is not center and plate solve the first time, on the second try it will slew to nowhere this happen quite often.

Behaviors like that are typical when a German mount has lost its correct side of pier, assuming that the Local Sidereal Time of the mount and the Local Sidereal Time of the computer agree.

ASIAIR does not display the Local Sidereal Time (I don't know why, since it one of the fundamental properties of celestial navigation; omitting it is just a delusional over-simplification ("1,2,3") of an astronomical instrument), but you can get it from a number of iOS apps (search for "LST" or Local Sidereal Time in the App Store), and also from planetarium programs like SkySafari. If you really can't find the correct LST, a correct LST is equivalent to a correct UTC and a correct local longitude.

With a German mount, the mount really has two coordinate systems for its motors relative to the sky coordinates (right ascension and sky declination). After a meridian flip (i.e., pier side flips between east pier and west pier), a German mount reverses the direction of the hour angle motor and the direction of the declination motor.

Your mount could have lost its pier side after that 60 degree polar alignment rotation. By convention, a slewshould not change the pier side (e.g., what ASIAIR uses for the 60 degree rotation). Mount should only change the pier side with a GOTO that crosses the Meridian, but who knows what your mount does.

Any declutching of the RA and declination axes will almost certainly lose alignment. Never, ever declutch and move the mount from the time you turn the mount on, and connecting it to ASIAIR.

To make sure the 60 degree polar alignment slew does not confuse the pier side: after polar alignment, disconnect the mount from the ASIAIR Mount Setup, then turn the mount power off.

Place the mount in its home position (after declutching it) and lock the clutches and never touch the clutches again, ever, until the next night.

Then turn the power of the mount back on. This will initialize the mount's internal registers to be the home position of the mount. I.e., the mount's physical motors and the mount computer's registers are now in agreement; the mount's pier side register is also initialized.

Finally, only after this, connect ASIAIR to the mount in the ASIAIR Mount Setup. This synchronizes the ASIAIR's coordinates and pier side to the mount's registers, which in turn is the same as the mount's motors. Finally, your ASIAIR knows where exactly the motors of the mount are pointing.

Remember, do not ever declutch the axes after this point. And, unless you are careful to synchronize the mount to the ASIAIR, do not touch the slew buttons on the mounts hand controller either, just in case sync is not automatically done for you. Always only use the ASIAIR's directional slew key if you need to slew the mount.

Chen

Skylab1 Meridian flip failed more often then goto, so I just avoid imaging across the Meridian if I can.

Nothing wrong with either function in ASIAIR as long as pier side is correct, and the LST is correct. Tested with my mount simulator even for SynScan protocol.

Just do what I outlined above

1) initialize the mount's registers to the mount's motors (toggle power of mount after you set the mount to home position)

then

2) connect the mount to ASIAIR (which syncs the ASIAIR to mount's registers),

Steps 1) and 2) together will sync the ASIAIR coordinates to the mounts's motor coordinates.

Follow your mount's documentation of how to level it. It is not sufficient to just polar align the mount if you also want to use auto Meridian Flip. Each degree of level error in the east-west direction will cause a 4 minutes of time error in the Meridian flip choreography.

Chen

Skylab1 what is dec flip function after merid flip do?

Check your mount documentation.

After a meridian flip, most mounts only reverses the RA axis motors.

Check the Flip switch in Calibration Data in the Guide Window -- today (v1.5.3), when you flip, only Blue vector reverses direction.

Most other software lets you choose RA flip, declination flip or both flip.

You can easily see the motor reversal effect by putting your mount on the east of the pier -- then use the arrow key (you can do this study without ASIAIR, just use the hand controller). Rotate (slew slightly) the RA axis clockwise (use a Gaffer tape with an arrow drawn on it). Note down the direction your guide camera moves relative to the meridian. (Closer or farther from the Meridian.)

Now, repeat the above with the mount positioned west of the pier.

Notice that for a clockwise RA axis rotation, the guide camera would move in different directions with respect to the meridian (with one pier side, a clockwise rotation of the RA motor would move the guide scope closer to Meridian, while the other pier side, it would move away from the Meridian).

Almost all mounts that I know reverses at least the RA motor after a Meridian flip. And you will see the above effect. If you try to design an equatorial mount yourself, you would see that this is the only way to maintain continuous motor operation after a meridian flip.

With some mounts, the Declination motors will also reverse direction after a meridian flip (it just depends on the mapping in the mount's motor driver to implement the flip).

Remember -- the ASIAIR does not know how to do a Meridian Flip. It simply commands the mount to perform a GOTO. The mount then determines if it want to do a Meridian flip (from said goto) depending on whether the new star is east or west of the meridian. (Or if a star has transited the Meridian.)

Do the same experiment that I outlined for the RA motor above, but use the declination slew button. See if rotating the declination motor clockwise will produce different motion towards and away from the pole when the mount is west of the pier vs east of the pier. (Use the poles as reference instead of using meridians as reference.) If one of the pier sides move closer to the pole and the other pier side moves farther from the pole, you will need to also flip the Meridian. (My RainbowAstro mount only requires RA flipping.)

Chen

Kring The CGX worked well, although multi-star was enabled and found 2 stars, 1 always ended up loosing the circle, so I think it kept reverting to single-star. I don't think this is an issue, this scope has 2800mm focal length and guiding via OAG so it's normal to only have 1-3 stars in view and not a lot to choose from.

Even with a guide scope, you need a camera with a lot of dynamic range. ASIAIR will not choose saturated stars, for good reasons. And if some of the stars are too dim to have a usable signal to noise ratio, those will not be selected either.

Try a good camera like an ASI290MM or the ASI174MM. The 174 has similar dynamic range as the 290 (it has deeper wells, but it also has larger read noise), but the 174 has 4 times more potential stars to choose from. There are other superior guide cameras, but you can't use them with ASIAIR.

Because you are looking for optimal dynamic range, move the gain up and down to find the sweet spot to get maximum stars.

I think I have mentioned before that I expect people using OAG (crippled by the dynamic range) will benefit the least from multi-star guiding, and the same is true for people who use tiny guide scopes. They are the two extremes of scopes that produce the worst dynamic ranges, given the cameras that we have available.

For autoguiding, I use a 55mm aperture (Borg 55FL) with 250mm focal length, together with an ASI290MM (pancake USB3, not the mini) and switching between the Baader Semi-APO filter and the Baader Neodymium filter. And even so, I need to carefully pick my gain. And for some areas of the sky, it is just not possible to max out at 12 stars.

You should already easily see an improvement with 4 stars (centroid RMS error improves by a factor of 2 over the single star case). By the time you get to 12 stars, the mount itself will be the limiting factor to the total RMS error, but it could still be useful when seeing is really bad.

Chen

Kring my setup does have an ASI174mm for the OAG on C11 2800mm focal length, even with reducer it comes in around 1960mm

Yep, I saw that later.

Your 174 on the OAG might be limited by the prism size, have you checked for that (vignetting) possibility? There are some OAG out there with larger prism sizes than what ZWO sells. Teleskop-Optiks has one with a whopping 16mm x 16mm, but depending on how it is positioned, it might end up vignetting your main camera :-).

I still have a couple of OAGs lying around here, but have avoided using them for years now. With a separate guide scope, you just need to watch out for differential flexure; everything else is so much easier.

A lot of the old wives tales (like using longer exposures) no longer applies when the centroid can now be cleanly estimated with multiple stars. The shorter exposures allow for better control of the feedback loop. But with an OAG, you probably still need to expose for longer to gather enough photons -- and that longer exposure length can limit how much improvement you can get from using multiple stars.

As of Build 9 of the 1.6 beta, the disappearing star bug has not yet been fixed. When a star is lost, it never comes back even after seeing has improved back for that particular star. So, even if you start with 4 or 5 stars, you might find that the extra stars would disappear (when the atmosphereic turbulence takes that star out) over time.

Up until Build 9 of the Beta, the only star that comes back is the principal guide star. But there is also a bug where no centroid is computed when that guide star is lost -- all centroid computation ceases until that principal star comes back.

The multi-star works really well when you don't hit one of these conditions.

However, a couple of other bugs were fixed in Build 9 -- I had found that if the Guide Window is opened for a lengthy time (sometimes for over an hour), ASIAIR would disconnect the Guide Camera and the Mount. They finally found the source of the bug after I gave them the precise particulars on how to make that bug appear, and Build 9 apparently fixed that.

I have in the past 2 days found another multi-star centroid bug that occurs when a star crosses a pixel boundary. This could cause the guide pulse to issue a wrong sign to the mount (i.e., exacerbates the error!! :-).

Where (arc seconds wise) it occurs depends on your guide plate scale (since the bug is directly related to the pixel size). With my guide scope, that pixel boundary occurs if the instantaneous guide error is at 2.3 arc seconds. With a longer focal length, that pixel boundary could be less than 0.5 arc second, and would throw self-inflicted guide errors quite often. You may be safe with an ASI174 (big fat pixels) and a reducer with your long focal length telescope. ASIAIR could just be confusing the truncation operation from the rounding function in the arithmetic. I gave them detailed descriptions to how to reproduce it indoors without clear skies.

The pixel boundary problem can cause a sudden momentary spike in error on the guide graph, and then it eventually calms down again after 2 or three guide pulses (and may be oscillatory as the centroid moves back and forth across the pixel boundary). Since you have an OAG, you might see it more often than I see it (I had to use my mount simulator to discover why it actually happened). In my case, since the error seldom ever gets that large with my mount, it was initially hard to find. But an unbalanced mount (that does not use harmonic drive gears like my mount) could easily drift that 1 pixel even if the fluctuations is much less than 1 pixel.

By the way, this pixel boundary bug does not happen to the single star centroid computation.

There are now two, what could be show stoppers with multiple stars autoguiding (you need a stable artificial condition to measure the harm they cause) -- the disappearing-and-not-recovering stars case, and now the pixel boundary centroid error.

Anyway, these things are reasons why there are Betas.

Chen