Recently I modified the math used in the polar alignment (PA) scheme so that polar alignment can be done using any part of the sky. I also slightly modified the user interface for PA by introducing the correction triangle, replacing the correction vector that was previously used. See indilib.org/forum/general/8602-new-polar...me-and-features.html
As a companion to those changes, and following some excellent suggestions made by Jasem, I'm now introducing a couple optional user-interface elements to help you in the PA process. The user interface is more-or-less the same through the measurement steps (though some of the instructions have been modified, and I moved the "legacy polar alignment" process to a new sub-tab). However, once you reach the correction page, where you would adjust your mount's altitude and azimuth knobs to correct polar alignment error, there's a new checkbox titled "Update PA Error" that enables some new UI elements. If you check that, then:
- The reference star is circled--that is, the star which you selected and are supposed to "move along the yellow and green lines". If the system can't figure out how to track it, it doesn't circle it.
- The system displays the polar alignment error that it measured at the start of the process. (Actually this is displayed whether or not you check the box).
- The system displays its estimate of the remaining polar alignment error, after the corrections you've made so far.
This can be seen in this screenshot:
Clearly these things require the system to track your reference star, in a somewhat analogous way to guiding. This requires star detection for each of the refresh images, but it turns out that doing this only adds a small amount of overhead (though the overhead is measurable--see below, so that's why I made this optional).
I want to point out that these are aids to help you move to the right position, but do not in themselves change anything. So, if you suspect that the tracking is wrong, ignore it. In my experience the tracking is very good, except for very close to the image edge. Again, if the circle does not draw, or draws in the wrong spot, ignore it and the estimate of corrected PA values.
Finally, while experimenting with this, I looked at the latency during the refresh stage. I found that with everything running on my Raspberry Pi 4, and imaging with my ASI 1600 (32Mb image file, ~20 Megapixels monochrome), even though I set the exposure time to 1s, the overall cycle time was 5s--most of that time due to image transfer (~1s for capture, ~3s for transfer and buffering, ~1s was due to star detection). If I changed binning to 2x2, that reduced to 2.8s (0.4s for detection). 3x3 became 2.3s (0.3s), and 4x4 binning resulted in 2.1s cycle time with 0.25s of that a result of star detection. Since the polar alignment estimation error is likely much much larger than a few pixels (i.e. a few arc-seconds), I think that you will have a much better user experience if you bin (e.g. 3x3) while doing you polar alignment, if you have a system similar to mine or with more pixels. Do not change the binning during refresh though. If you want to use a particular binning, use it from the start. Of course, if you just are measuring your polar alignment error, but aren't correcting, the binning won't change the overall time taken very much. Its impact is mostly in the refresh/correction phase.
As usual, these changes are in the 3.5.2-beta code, not in the current 3.5.1 release, so to test you need to compile from source or use a nightly build. See discussion at the end of my first post
my previous PA thread