Hi,
Regarding the log, your mount is misaligned twenty minutes in RA. This is why the meridian flip does not occur: for the mount driver, the goto issued to perform the flip is still on the same side of the (mechanical) mount meridian.Here the driver uses the alignment info to compute the telescope goto, the delta RA is 0.377650 hour, ~ 20 minutes.This gives only 102 microsteps as the mount is still mechanically before the meridian.
Clients should use the true telescope coordinate to initiate a meridian flip, I believed that the PierSide property was reflecting this (i.e. was using true telescope coordinates to compute the property, not celestial coordinates).
But this may have changed.

Thanks @geehalel. Do you know how I can correct the mount misalignment (does it need to purge the parking or something like that?)? I polar align (using the EKOS tool) at the start of every session, so should that not align the mount driver correctly too?

I've just done some dummy runs tonight, at 0.10 & 0.20 after HA, and the timer correctly shows when the flip should happen, the designated time passes, the status just changes to "Meridian flip planned..." & nothing more happens for a good few minutes after that (I stopped waiting after that). <This is a difference from the other night when it said the flip had actually happened>

The problem is that at 20 minutes of misalignment, the flip will happen too late & my main imaging scope will hit the pier and be useless for anything near the zenith. (I didn't use to have this problem so I'm also a bit confused on how the mount could misalign like this).

Thank you for any more help you can suggest!

PS the only PierSide property I can see in INDI Control Panel just says "West (pointing east)"? Thank you!

Hello, I just tried some more - just left it running on a dummy run indoors while watching the news. It got to +47mins and still no meridian flip. There seems to be something seriously wrong? The LST on the Mount tab is correct. Thank you.

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.

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.

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).