The alignment info comes from the syncs you made with astrometry (and to be accurate in RA this should **not** be done near the celestial pole, see @jabian comment).
This info is eventually saved into an alignment file (for fixed observatory) and reused between sessions. Your log file starts after the mount driver inititalization, thus I don't know if this is your case.
Look into your <code>.indi</code> directory for a <code>AlignData.xml</code> file (this is the default name), and rename or remove that file.
When you restart your session (and before any sync), the delta RA should now be zero.

I wonder if loading this AlignData file is actually used by fixed observatory users, I believe they make the best polar alignment they can do once, and sync their mounts on every sessions without saving these AlignData.
Maybe this feature could be simply suppressed/disabled, as it seems to create confusion rather than being really useful.

how I can correct the mount misalignment

Hi
Go back to basics?

Turn off the mount and physically set RA and DEC level. Use a bubble level. Horizontal for RA, CW level. Whilst you're there, zero the DEC setting circle then make sure that the park command -from anywhere- also zeros the circle. Finish every session by parking the mount.

Connect the mount, Clear the mount model for good measure then polar align.

Next, in align, capture and slew to target, anywhere away from the home position. Dubhe is good.

Set the mount to flip at least 0.2 hours after the meridian.

That's it.
HTH.


Cheers and HTH.

Thanks both @geehalel & @alacant.

I couldn't find AlignData.xml anywhere (searched for it on Terminal so it looked at the whole machine). Anyway, I just purged all the configurations, and tried again (dummy run indoors). The mount parks fine (pointing to celestial north), slews to a range of targets either side of the meridian & returns to park normally. But it still doesn't do the flipping meridian flip. Am uploading the log file from the dummy session (hopefully it will show whatever the mount driver is doing at initialisation).

The crazy thing is that if I set a target that's just the other side of the meridian (ie positive HA but still less than 0.10HA as a goto, the mount goes to it the "right way" (east pointing west) but if it had been tracking that object it wouldn't do that flip).

@alacant as you can see I came to the conclusion of trying from basics too (great minds ) but it's still no joy. I always bubble level before a session, & always park at the end of a session, & always polar align at the start (unless the mount has been left untouched from the night before).

@geehalel your last msg suggests that good operating practice would be to sync a mount model at the start of each session even if you've also done polar alignment, or am I misunderstanding that? (I had thought mount model tool was only needed if polar alignment was not possible?).

Anyway here is the latest log file from the dummy session - thank you again!

Just to say I double checked that crazy thing. If I set a target east of the meridian, the mount goes west pointing east and starts tracking but does not flip (even after >0.10 HA). But if I set a target at say 1m after the meridian as a go-to, the mount goes east and points west in the correct way. So EKOS & the mount are figuring out correctly the goto, but for some reason if that object was being tracked across the meridian it would not flip. (All models had been cleared & purged before, and a power-cycle done too).

Cheers.

geehalel wrote: I wonder if loading this AlignData file is actually used by fixed observatory users, I believe they make the best polar alignment they can do once, and sync their mounts on every sessions without saving these AlignData.
Maybe this feature could be simply suppressed/disabled, as it seems to create confusion rather than being really useful.

At least I use it just like this, I have around 10 points synced from around the sky saved and load that as basis for per session syncs. It's especially useful when plate solving can't be used due to too bright sky. That and auto homing with EQ8 have saved my remote imaging sessions quite a few times.

This is the normal operation. The mount driver won't never initiate a meridian flip by itself. When the user or a client wants to perform a flip, he initiates a goto (usually the celestial coordinate of the target he is tracking).
The point is that the goto target should be **mechanically** after the meridian for the mount driver do the flip. The mount meridian is not the celestial meridian when the mount is misaligned. And your equipment is attached to the mount.

Ok. I'm puzzled why that happens even after I've now cleared & purged everything. If a target is set just after meridian (say 1m), I guess its the mount driver that's processing that goto and orienting the mount a certain way? So if the mount driver knows this target is after the meridian & figures out which way it should move, why does the same driver not have the same alignment when trying to process a meridian flip?

(Unless its EKOS telling the mount driver to orient a certain way for the 1m object...but if its that and the EKOS driver prevails, why does the mount driver not listen to it in a meridian flip).

Most important Q I guess is how do I fix this?! Clearly purging the model hasn't worked, so do I need to set up a model and then cross my fingers? (In which case I can't dummy that indoors?)

Thank you

@jpaana Thanks for answering, I have not thought to that case. I don't know the precision you get when using a high quality mount in a fixed observatory and how alignment may still be relevant in such a case.

@vineyard The mount driver does not have a 'meridian flip' command. It only offers track, slew and goto (and sync, guide). When tracking or slewing, it runs as long as it is told to run, even if it crosses the meridian (it may stop if you have set/enable limits).
You may make three turns in RA if you like. Concerning gotos, it always performs a goto with counterweight down at the given target (unless it is told to do counterweight up, there is a property switch you may set before issuing your goto).
That way, client/user may image passing the meridian without performing a flip if its setup allows it. Or it may start a session east of meridian without performing a flip if it starts counterweight up.
You have nothing to fix in your case. If you repeat your last test (start tracking east of meridian counterweight down, no alignment), just wait the target pass the meridian, then manually issue a goto in kstars to the same target, the mount should flip.
As I previously said, the problem seems to be that the client (Ekos) is using celestial coordinate to issue the goto performing the flip. It should use the true telescope coordinate, or wait for the side of pier property to toggle (the driver uses true telescope coordinate to compute this value, unless someone changed that).

Thanks @geehalel - yes I tried what you suggested (manually issuing a goto for the same coordinates after the meridian had been passed) and the mount flipped. You're right that definitely seems a glitch on the mismatch between EKOS coordinates and mount driver coordinates (even when purged).

Do you think it is possible to fix this within EKOS? (For example through a routine that automatically issues a goto command - rather than a flip command - once the user-selected HA has passed beyond the celestial meridian. Sorry if that's naive, I'm not a programmer!). B/c otherwise this means that the user has to be physically around to manually issue a go-to command (which for example could be at 0200, 0300, 0400!) which would defeat the purpose of an automated imaging session software?

Thank you again for taking the time to help & explain.

To be honest you are not the first to report this problem and I already tried to explain why meridian flip may not occur (regarding indi-eqmod at least, I don't know for other drivers which are using alignment).
Eventually there may be some misunderstandings between developers. Here is my understanding:
Meridian flip is used in order to keep down the counterweights of the mount, avoiding your equipment to hurt the pier. If your mount is perfectly aligned, the mount meridian coincides with the celestial meridian, and a meridian flip should occur when the mount crosses this unique meridian. Now suppose you turn the pier of your mount 45 degrees to the west. The mount is misaligned with deltaRA = 3.00 hours and the alignment system will correct that for you and track your target as desired. At that point, if the driver performs a flip when the target crosses the celestial meridian, this will result in a counterweight up position, as the target is still 3.00 hours before the mount meridian. And that's not what you want in order to preserve your equipment. That's why indi-eqmod may not perform a meridian flip if the corresponding goto is still before the mount meridian.
To sum up a meridian flip is related to the mount coordinate system and should occur at the mount meridian, never at the celestial meridian. And that may be before the celestial meridian when the pier is shifted to the east.

Thanks @geehalel. Ok I see now the logic for the reliance on the mount meridian. I'm still a bit puzzled as to how the mount meridian could be so far off (20m) if I'm doing polar alignment through the polar scope in the mount axis, b/c if the mount was that far turned, presumably Polaris wouldn't even be visible for the polar alignment (I align visually first, and then use the EKOS PA tool for the fine adjustments). So if Polaris is at all visible in the polarscope then there must be an upper limit on how far the misalignment could be?

But nevertheless it is what it is - now that the models are purged, I will try to be even more careful in the polar alignment to try and get the mount meridian close to the celestial meridian. Fingers crossed that then the flip will happen before it would otherwise damage the scope.

Thanks again for your patience!

Don't forget that when you polar align, you're pointing near the celestial pole by definition, and there, RA visually corresponds to a rotation of your scope around its optical axis. You could be 12h00 shifted in RA at the pole, Polaris will still be in your FOV, simply it will be on the wrong side of the celestial pole. Polaris being only 45 arc minutes from the pole, you should be very precise when you make your alignment (depends on the magnification of your polar scope). Your 20 minutes error is only a 5 degrees error **in rotation** of Polaris around the pole. Maybe half the diameter of Polaris itself as you see it through the polar scope (just an estimate). And if you simply spent 5 minutes between the time you set the RA angle of Polaris in your polarscope and the time you finish your alignment, you're 5 minutes away.
Not sure where your 20 minutes error comes from, as you did not find the AlignData file, that may be a plate solve/sync near the pole. Here too depending on the resolution of your imager and the quad star the astrometry solver finds in your image, you may get high error in RA when you sync near the celestial pole.
Anyway the problem with the meridian flip not occurring is a software issue, it seems that INDI/Ekos/client devs have to discuss this point and decide the correct way to go for mount drivers which can sync.
In your situation you may simply set a flip HA 1.00 hour past the meridian, just check your setup allows for that (it depends on the declination of your target though, your latitude, your pier...). That way you may live with a 20 minutes alignment error, the meridian flip will occur 1h00 past the celestial meridian.

Forgot to mention the accuracy of the home position: the home position is what determines the mount coordinate system for the driver. You may have a perfect polar alignment, if the home position is not accurate, you will lose accuracy as long as you point away from the pole, and then gets misalignment when you sync on your target star. The mount pier should be leveled so the RA and DEC axis are leveled too, then you may level horizontally each axis and turn them 90 degrees to get the home position.