That's two minutes - 0.5 degree past the meridian? Had you just done a slew to this position? It could be in the zone where the mount may think it hasn't passed the meridian.

If you can't track two minutes past the meridian then you will have problems with long exposure imaging. Imagine if you are taking 5 minute images. An image starts one minute before you reach the meridian but it won't finish until 4 minutes past and that's the first time that a check can be done to see if a flip is needed.

What i think is needed are hour angle limits. They are:
A tracking hour ange limit. This is the hour angle beyond which the mount must not track. When it reaches this limit tracking is stopped and the acquisition process is paused. Normally this would be well past the meridian, 30 minutes or so, but it could be less, even in some cases before the meridian is reached.
A flip hour angle limit. This is the hour angle which is the earliest that a slew command will do a flip. Normally this is a few minutes after the meridian but some mounts - the Celestron ones for example - can be set to do the flip up to 20 degrees before the meridian.

The flip process should also be managed using the Pier Side property when this is available. At present this isn't used, it uses hour angle. As a result there's a lot of scope for confusion where a mount does a flip earlier than expected and the flip process does another one or, worse, the flip process does one too early. The system now thinks that a flip has happened but it hasn't and it tracks into a hard stop.

Given these things the acquisition process could be made more flexible and reliable. With reliable pier side (NOT simulated, that just moves the problem into the driver) the flip process can be managed correctly and witth hour angle limits things such as mounts with restricted movement can be handled.

I'd have liked to have sorted this out but the complexities and lack of documentation in the Ekos sources make it impractical for a newcomer. I've tried and the majority of my time is spent fighting my way through multiple layers of undocumented code trying to deduce what it's doing. That's not my idea of fun.

Good news, folks, we are starting to work on it. It will make the meridian flip more robust - hopefully - but the code complexity will grow again. Since there are mounts that now their pier side, others not, some can be forced into a meridian flip, others not etc.

- Wolfgang

That's really strange, but maybe it's simply an edge case. Your mount does not take 2 minutes to slew? Or maybe you were not fast enough checking the hour angle?

The question that I always ask in such situations: are you really sure that date, time and location match 100% between the mount and KStars? Is KStars setup in such a way that it propagates its settings to the mount?

If not, that is a typical source for unexpected behaviour.

Wolfgang

I don't know if the mount has any information not from KStars. I have confirmed that the OS time and KStars observation location times are on the same time zone and consistent with the location. I have also verified the location is correct. Where do I check that KStars propogates to the mount?

I did have to effectively reset the mount model after the initial test. The mount pointed so far from the first target that plate solving was going through several astrometry files trying to find where it was actually pointed. I stopped the plate solving and slewed to a point nearer the NCP which plate solved well. The following slew was also good with the target in the frame (2 deg x 1.5 deg).

I'll do a similar check later today.

You can the values in the handset of your mount.


In the INDI settings of KStars:

I had my mount model very screwed up. I think I have it working correctly after going to the defaults, going to park and releasing the RA clutch to get the counterweight bar vertical. Now when the scope slews, it appears to be pointing in the right place plus the hour angle on the Ekos mount tab is consistent with the KStars hour angle.

Here is a follow-up from a more-or-less successful evening.

I was working on M42 and did a solve and slew at HA ~+1minute. The mount was on the west pointing east at the start of the solve and moved to the east side. However, it would only slew to Alnitak or Alnilam at this point in time (consistent with the display in KStars). After playing around on the Horsehead Nebula (not sure how long), I could successfully move to M42.

Any suggestions?

Last night while... ahhh making my normal, non-sleeping walk down the hall , I checked my phone to see how close I was to a flip. I noticed a nice timer message counting down on the , which I hadn't noticed before.

Later after another trip (yeah, I'm getting old)... I saw in my yard cam that the rig did do the flip. Plus that message said Status: Inactive

My thoughts are, as long as that count-down message is running, it will flip.

Here's the simulator showing the same thing:

I think you missed my point. I didn't call for a switch in direction. I only commanded a solve and slew. I didn't look at the hour angle until after the slew took the mount to the east side.

Any slew that is done when the mount prefers to be on the other side of the pier will do a flip.

All that the pier flip process does is wait until the flip condition is reached, then does a slew to the current coordinates.

It's OK that the flip occurred. The issue is it wouldn't then go to the target (M42). The actual (not the desired) behavior was replicated in KStars. I would think that if the logic says we need to flip that it would then go to the target, not just somewhere close.

The capture and slew and, if I recall correctly, a load and slew did not go to M42 at that point in time. Several minutes later (didn't make note of the actual hour angle), it finally would go to the target.

It goes to the same coordinates. Where that is 'on the sky' depends on the quality of your pointing model. So usually it does a solve-and-slew round after flip, if the flip was initiated by EKOS. If it does the flip because it hit the mounts setting limit, this of course doesn't happen, and you are left with the accuracy of your pointing/alignment.