My meridian flips fail under 3.5.0 but logs report that they have completed.

Running 3.5.0 on R Pi 4 (64-bit ubuntu 20.04.1) from mutlaqja/ppa (not indinightly).

As always, the trick has been to set a slew limit in the mount that is LESS permissive than the Meridian Flip setting in Ekos.

This means the mount tracks *past* the point where a slew to the same coordinates will trigger a flip in the mount itself, for example while taking a scheduled image in a sequence.

A little later (further west) but still exposing the same image, the mount tracks past the "Meridian Flip" limit in Ekos. This should put Ekos in "Meridian Flip Waiting" mode.

Finally, when the current exposure is finished, Ekos should issue a slew to the same coordinates, which are now far enough west of the meridian to trigger the mount to flip.

I have set the "Flip Slew Tolerance: in the mount hand controller to 1 degree. This means that a slew to coordinates at Hour Angle less than +1 degree will still have the scope pointing east, but a slew to coordinates at Hour Angle greater than +1 degree will cause the mount to point west.

Accordingly, I have set the Meridian Flip in Ekos to HA > 1.5 degrees, so when an exposure finishes and the Hour Angle > 1.5 degrees Ekos triggers the slew that will flip the mount. (1st screen shot)

In the attached logs you can see that Ekos correctly detects the HA>1.5 degrees condition and initiates the slew that is supposed to flip the mount.

But the mount does not move.

The first log snippet at 1 AM this morning shows the message "[
2020-12-06T00:59:10.898 MST CRIT ][ org.kde.kstars.ekos.capture] - Accepting meridian flip request while being in stage 1

It then shows that identical message every second until morning. The mount just sits there at the meridian for hours and accumulates this log message.

The Analyze Panel in Ekos shows the "Flip Waiting" for many hours (second screen shot)

The second log snippet shows the results of a sequence this morning without the Scheduler. Again, we reach the meridian, pass the mount slew limit, then pass the HA>1.5 degree Meridian Flip position in Ekos.

This time the log shows that the Meridian Flip slew starts, then fails, that the pier side has not changed.

But then the log reports that the flip was successful and that the flip has completed.

But this is not true. The mount never flipped. In fact it reaches a safety stop soon afterward and the mount stops to protect the scope from hitting the pier (third screen shot)

I realize that there are subtleties relating to the interaction of mount and driver and Ekos here which are likely specific to 10micron.

I have often been able to get successful flips with these settings and it seems the Mount Slew Tolerance MUST be less than the Meridian Flip HA in Ekos to make it work.

Can anybody help with this?

Thanks,
Scott

I'm having the same issue. Different scope, same issue. Let me know if you find a fix for it, I'll do the same. I just put my rig in full debug for tonight (weather permitting) to gather additional info.

Well I spent the afternoon experimenting with this when I can watch the scope carefully in daylight.

Sometimes I get a flip, and sometimes I don't. It seems to depend on sky position in addition to settings in the mount and in Ekos.

I think what's happening (for my mount anyway) is that in some parts of the sky there's NOT MUCH ROOM between the meridian, the "slew tolerance", the Ekos "Meridian Flip When HA > ??" setting, and the HA slew limits for the safety of the mount.

For my mount, there will never be a flip if Ekos is set to flip at a smaller HA than the "slew tolerance" set in the mount handset.

In all cases I think Ekos sends a slew command to the mount to the same RA/DEC where it's tracking. Since the mount has by then crossed the meridian, it's supposed to flip around and find the same coordinates from the west side. If the coordinates are within the "slew tolerance" in the handset, this doesn't happen. This is a feature in the mount that allows the user to slew to the "wrong side" of the meridian to *avoid* a flip, and there's basically nothing Ekos can do about it. The slew command from Ekos may or may not move the mount, but if so it's a little micro-slew.

So I *must* set the mount's "slew tolerance" to a small number, and I *must* set the Ekos meridian flip HA to a larger number. In my case, I was using 1 degree for "slew tolerance" in the handset and 1.5 degrees in Ekos. But sometimes it still fails.

For the safety of cameras and scopes, my mount only allows movement five minutes past the slew tolerance. This doesn't leave much wiggle room for the mount to track beyond there, detect HA > ??, finish exposing the current frame, and then slew.

I think what happens is that the slew command tries to move the mount and it "gets stuck" in an impossible geometry where the slew path for a meridian flip requires it to move into what the internal mount software "thinks" is an unsafe zone that's forbidden to protect cameras from crashing into the pier. So it just sits there.

I was able to get more reliable flips by increasing my Ekos "Meridian Flip when HA > ??" angle to 2 degrees from 1.5 degrees. My mount won't flip within 1 degree of the meridian, which takes 4 minutes on the clock. 2 degrees is 4 clock minutes after that. One more minute and my mount calls it quits (5 minutes past the slew tolerance). So I'm cutting it awfully close.

It would be nice if Ekos could detect this conundrum and just slew east to get away from the tight safety limits. Then it could slew way west to force the flip. Finally it could slew to the imaging coordinates and plate solve ("align") to set up the rest of the images for the night.

But in almost all cases when the flip fails, the Ekos logs report that it "Completed" as I showed in the log snippets above and which you also see. So I don't think Ekos can even detect that it's stuck, let alone get itself unstuck.

It looks like the internal mount software and Ekos are talking past one another. Ekos thinks it's done because it requested a slew. The mount software thinks it's done because it's reached a safety limit and has to stop tracking. So the whole rig just sits there for hours and hours not collecting images.

Hope this helps!
Scott

I started seeing this on mine when I have the mount update KStars with the time and location. For whatever reason, even if I only use GMT time without DST. The time for the meridian flip is off. Clocks don't match. I honestly don't know what the deal is, why I can't get it to sync. I've not tried again now that DST is over. It might work again. But when I was having this issue, I let KStars update the mount time and location, and everything works perfectly. The only issue I experience is that pointing accuracy isn't perfect after the first night, and I have to rebuild the pointing model.

I wrote about my time issues in another thread here somewhere, but can't find it right this second. Incidentally I have not tried 3.5.0 Mac, but this was happening for me on 3.5.0 beta on Stellarmate, and earlier versions on the Mac (like the last stable release).

Forgot to mention I had guide limit set to 5 degrees past, slew limit 2 degrees past, and meridian flip set in EKOS to 3 degrees past. This works very reliably for me when the time sync is correct.

hi Scott,
maybe it's not the issue but I didn't see mentioned explicitly in your post: in my experience the only way to control meridian flip from a client software is to enable unattended flip on the mount first.
That's a setting I didn't find on the handpad but software like MW4 allows to enable / disable unattended meridian flip (see attachment).
Once this is set I never had an issue with meridian flips (tested also on kstars 3.5.0)

ferrante

Ferrante,

Thank you very much! I had no idea this setting was buried in there. I wonders why this option doesn't show up on the keypad?

For that natter it would be wonderful if (1) the setting were exposed in the INDI driver; and (2) it was toggled by Ekos when the Meridian Flip box was checked!

Anyway, it's checked now. Thanks again.
Scott

Glad to hear that it worked.
Bear in mind that the mount doesn't store that setting. You have to set it every time the mount powers on.

I reported to Hans, the developer of the 10micron driver, and the good news he's now working on that.

This is great -- thanks!

I tried this last night and my mount flipped just fine (twice, unattended).

Andrew,

You are over-riding the time and location from the mount; do you have a GPS (MGPBox) in your setup?

I have another problem that I suspect is related to the mismatch between Kstars and the mount (MGPBox). A few times each night my DEC jumps, then slowly recovers over many minutes. Maybe this is mismatch in latitude that gets smoothed out over 15 minutes.

I've been pulling what's left of my meager hair out over this for weeks. I will try just ignoring the GPS time/location and see if I get round stars again.

If you happen to find your other thread about this, would you please post a link or PM me?

Many thanks!
Scott

Andrew,

Never mind -- I found your old thread about time sync between Kstars and 10micron.

I'm going to try unguided imaging without the GPS sync.

Weird. I wonder if this is an INDI driver issue?

Scott