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

Here's the thread. I never came to a successful conclusion. Even if I could get the times to match in both EKOS and the mount, the meridian flip would happen one hour early. I believe Somehow EKOS was compensating for DST even using only UTC time without an offset.

The only way I can successfully get flips to work on time, is if I let EKOS update the mount. I do have an MBox (regular) but GPS module on the 10Micron, which I use to create and build models. Basically I polar align the mount after GPS has updated it. Then load MountWizard4, and EKOS, which syncs time and location to the mount. Meridian flips work perfect this way.

If I set the mount to update EKOS, I have time mismatches between the hand control and EKOS, and I believe DST in EKOS still counts whether or not it's on or off on the mount. Then the flip doesn't occur correctly. Anyhow, feel free to look through the thread at what I tested.

indilib.org/forum/general/7928-why-is-th...y-mount.html?start=0

Another issue that crops up for me if I have EKOS update the mount with time and location. The second night out GOTO starts to get off by a few arc seconds. EKOS can barley nudge it back into position after plate solving. It saves, moves it a tiny fraction, then solves again, and continues to do this while it slowly nudges it over about 30 tiny moves until the object is centered again. The only way I've found to fix this, is to build a new model each night I use the mount. Annoying, but it only take about 20 minutes since it's automated. I never SYNC any plate solves. I only have EKOS update the time and location to the mount.