Couple things.
1) If you downloaded software and compiled, please let me know the last git commit so I can see what you're running. (I've really got to put some version ID in this).
2) Working great or not, I'd love a log from you, being in the southern hemisphere. Can you make sure that verbose logging is turned on to file for at least alignment, and then upload a log somewhere, e.g. google drive, that I could access?
Thanks,
Hy
AP1100 mount, GSO RC10 mount w/RSF focus, ZWO ASI1600 imager & guider, Astronomik Filters, ONAG.
KStars/Ekos/Indi on NUC10 with Ubuntu 22.04
Projects: Greedy Scheduler, Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
This is not correct. The axes used for the correction matter. If it didn't and any way of moving the scope to put the target star in the calculaed position was OK you could use Ra and Dec movements to do this. This would obviously have no effect on the polar alignment.
It is correct. The PA routine works anywhere on Earth at any given time. In other words, for any given orientation and rotation of the mount wrt the rotation axis of the Earth. Therefore in a local frame it doesn’t matter at all if the mount is rotated (i.e. not level).
The fact that you cannot use RA and Dec to align the mount is because you are using the fine adjustment knobs to align the RA axis with the rotation axis of the Earth as well as possible. By doing so you compensate for the mount not being level by moving both axes. A remaining rotation over the Dec axis once the PA routine has completed results in a difference in local sidereal time which the mount and Ekos will correct for as soon as you do a star alignment or a plate solve with either Sync or Slew To Target enabled.
If this were not true then the previous implemtentation of the PA routine with the pink line between the location in the FOV where the star currently is and where it should be for perfect PA wouldn’t work as well. Both that pink line and the new lines, that are split up over corrections in azimuth and altitude, are merely projections to help you get the PA done as well as possible. It could have been a swirling line all over the FOV or even outside of it and it still would have worked.
The only thing that matters is to get the star from where it was in the FOV to where it needs to be as well as possible. How you do that is irrelevant. I often move the entire mount left or right if the PA error is large because the fine adjustment knobs cannot move the mount far enough left or right. And still I end up with an as perfect polar alignment as I can get. I know because I check afterwards and the PA error then is close to 1 arc minute or less.
Wouter van Reeven
ASI6200MM and 7 slot 2" filter wheel with a SkyWatcher Esprit 80 ED on a SkyWatcher HEQ5-Pro
ASI1600MM-Pro Cooled and 5 slot 1.25" filter wheel with an 8" TS Ritchey-Chrétien on a SkyWatcher EQ6-R
That makes no sense Chris. In effect you are saying that if the mount is out of polar alignment, e.g. because a previously polar aligned mount has been set up with a tripod leg not extended properly, then the calculated correction is going to be wrong simply because the mount alt and az do not correspond to terrestrial alt and az. If that were the case the tool would never work at all. Of course it is essential that only the alt and az controls are used and the scope is not moved from its position when the star is selected
But once the polar misalignment is known in alt/az it is fairly trivial to calculate to calculate what movement is needed for a given star in HA/Dec and display where the guide star should be moved. As long as it is moved using the alt and az controls only then polar alignment should be achieved.
It sounds like the same erroneous argument as to why a mount should be level to polar align it.
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
I'll try yet again.
Yes, you can rotate the mount about any set of coordinates to correct for a polar align error. But the correction indication determined by using a reference star will depend on the position of the star determined in the coordinate system of the correction axes.
There are a number of positions which need to be avoided, for example for the normal Alt Az corrections a star at the zenith will be a poor choice for the azimuth correction because adjusting this axis will not move a star at the zenith. Similarly looking East or West won't work for the elevation correction. The optimum positions are fairly close to the meridian and away from the zenith. Avoid a band running overhead from East to West.
Your tripod leg length error will have the effect of rotating the mount about an axis defined by the other legs and in theory the required corrections could be determined in that coordinate system. You could then get a correction that could be corrected by adjusting tripod legs. That's going to be tricky to determine. Simpler to determine the error in the AltAz system and correct in that system.
Not having the mount level will make a difference but as I said previously the effect will be small for small errors, about one arc minute per degree of error or level.
I agree it is bad practice to choose a reference star in that band. But lets say you choose a star near the zenith. And the algorithm determines that a large azimuth adjustment is needed. When the corrected position is converted to HA/Dec it is more or less the same position as the reference star already. So the correction line will be very short or non-existent. And as you say, any error in the calculated position is small. So were you just being contrary for the heck of it ????
I'm actually more concerned about the calculated position being a moving target when far from the pole. Some folks need time to adjust alt/az and by the time they get there they could have moved to the wrong spot. So the position needs to continuously recalculated, if it isn't already.
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
I’ve been using it on Astroberry for the last couple of nights. It worked fine (north vision isn’t a problem, so I’m using the “classic” way of pointing towards Polaris).
The only glitch that I’ve found is that it doesn’t likes zoom changes. For example, after the correction triangle is draw over my image if I zoom in before clicking to move the triangle, then as I click it will reverse from left to right, invalidating the procedure.
If I zoom in before the triangle is drawn (before the three measurements finished) it works as expected.
It’s a minor delight to be carried on to a more consistent alignment. Thanks for this improvement!
Didn't mean to start a "frank exchange of views" here!
So as I understand the geometry and mechanics, the routine calculates correction vectors in the vertical and horizontal axes, and displays those as the base and height of a right triangle, the hypotenuse of which is the direct vector from "wrong" to "right". Right?
If the mount isn't level, adjusting, say, the azimuth will also introduce some movement up or down. Which will cause the star to not track along the outline of the triangle. When you adjust the altitude a bit, you can fix that.
Which is to say, my sloppiness in leveling might obviate to a small extent Hy's fine work in making things easier for me, unless by some burst of mathematical brilliance which I don't even think is possible, the routine could *also* deduce how far off from local vertical the azimuth axis is. But he's amazed me before so I wanted to check.
It is true that being unlevel will introduce some amount of error between Alt-Az adjustments, but it should be fairly small. Overall level is a non-issue as long as you get from one end of the hypotenuse to the other, which is defined by the original correction vector. Doing so should be all it takes to align the mount's axis of rotation with the celestial pole.
Level does matter when doing a drift alignment, but that is not the case here.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
It will be a deviation between the Alt Az distance computed and the Alt' Az' steps needed to do the correction, yes. The endpoint is the same. And the needed correction vector doesn't depend on what you use to correct it. The AltAz is some helper coordinate system. The relevant ones are the two spherical coordinate systems of the mount axes and the celestial coordinates, and there is only exactly one correction vector to get them to match. You can compute it directly, without needing to go via AltAz, Alt'Az', or any other third coordinate system.
The only moment when a non-level mount would cause problems is if you compute (absolute) corrections for the AltAz system, and then blindly apply them in the Alt'Az' system and assume you have now corrected the error and have perfect PA. This is indeed not the case. But you would see that after those corrections the star is not at the position that the (unique) shift vector gave. But the whole process works in checking the progress live and in celestial coordinates. With a non-level mount you notice that the movement is not along the given directions and with different amounts. Without drawing those help lines one wouldn't even notice. The AltAz decomposition of the correction vector is a convenience for the user, but not needed/relevant for the correction process. For that, only the end position matters. And if you end up there, the PA will be done properly...
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
An injection of a bit of a Cloudy Nights vibe
But Chris raised a very good point which is that if your reference star is at the zenith then no amount of adjustment in azimuth will move it. You could spin the mount 360 and see no change. Similarly at the E/W horizon the altitude adjustment does not move the reference star. So a modicum of care is needed with reference star selection.
And I'd be interested to know how long one has to make the adjustment before the correction point becomes invalid - say more than 1 arcminute off.
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
Yes, it might be a good idea to think about some sanity tests for the star used to correct the PA and pop up a warning if it is too close to the critical points. But you wouldn't want to pick one on the horizon anyhow I guess
As for the duration of validity: The PAE is a constant, it doesn't change as the mount/sky rotates. Therefore the correction vector (in sky dRA and dDEC) is also constant. It only depends on the sky coordinates of the reference star. So the only thing that will change in time is the AltAz decomposition of that vector. So the effect would be similar to the one of a non-level mount: Movements done by turning the Alt/Az knobs of the mount would no longer move along the plotted lines, but the endpoint still is the same. So as long as you end up on the proper endpoint you can take as much time as you want...
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF