Thanks for the log, it now has all the mount commands so we can see what is happening. The detailed analysis also helps.

The ra and dec from the mount before your disastrous slew look OK:
[2020-05-26T23:49:03.775 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GR#> "
[2020-05-26T23:49:03.777 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <18:29:40> "
[2020-05-26T23:49:03.777 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [18.4944] "
[2020-05-26T23:49:03.777 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GD#> "
[2020-05-26T23:49:03.778 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <+32:15:40> "
[2020-05-26T23:49:03.779 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [32.2611] "
[2020-05-26T23:49:03.779 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gm#> "
[2020-05-26T23:49:03.780 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <W>, lst 15.036521, ha -3.457923, pierSide 0 "

Then the slew is commanded:
[2020-05-26T23:49:04.017 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] <setObjectRA> "
[2020-05-26T23:49:04.017 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:Sr 18:29:30#> "
[2020-05-26T23:49:04.018 CEST INFO ][ org.kde.kstars.indi] - Atik 383L : "[INFO] CCD FOV rotation updated to -98.5115 degrees. "
[2020-05-26T23:49:04.025 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:Sr 18:29:30#> successful. "
[2020-05-26T23:49:04.025 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] <setObjectDEC> "
[2020-05-26T23:49:04.025 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:Sd +32:11:48#> "
[2020-05-26T23:49:04.025 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:Sd +32:11:48#> successful. "
[2020-05-26T23:49:04.025 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] <Slew> "
[2020-05-26T23:49:04.026 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:MS#> "
[2020-05-26T23:49:04.027 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <0> "
[2020-05-26T23:49:04.029 CEST INFO ][ org.kde.kstars.indi] - Losmandy Gemini : "[INFO] Slewing to RA: 18:29:30 - DEC: 32:11:48 "
[2020-05-26T23:49:04.781 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gv#> "
[2020-05-26T23:49:04.783 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <S> "

That all seems fine, the correct position is set, the slew started and the mount reports that it is slewing.

The slew completes, all the solver successful message means is that the solve and slew process has completed, it says nothing about the quality of the process.
[2020-05-26T23:49:47.211 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gv#> "
[2020-05-26T23:49:47.212 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <N> "
[2020-05-26T23:49:47.214 CEST INFO ][ org.kde.kstars.indi] - Losmandy Gemini : "[INFO] Slew is complete. Tracking... "
[2020-05-26T23:49:47.215 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GR#> "
[2020-05-26T23:49:47.215 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <13:56:57> "
[2020-05-26T23:49:47.215 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [13.9492] "
[2020-05-26T23:49:47.215 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] CMD <:GD#> "
[2020-05-26T23:49:47.218 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] RES <+32:11:48> "
[2020-05-26T23:49:47.218 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[SCOPE] VAL [32.1967] "
[2020-05-26T23:49:47.222 CEST INFO ][ org.kde.kstars.ekos.align] - "Differential slewing complete. Astrometric solver is successful."

And the position reached is incorrect in Ra, it's reached 13h 56m 57s when it was commanded to go to 18h 29m 30s. That's nearly 5 hours different.

Somebody more familiar with these mounts needs to look at this but it looks as if the mount controller is faulty in some way. It's gone to a position different to the one it was commanded to go to. It doesn't seem to be anthing that we can resolve.

After the bad slew tracking seems to be off. the Ra is changing by about 1 second a second.

There's nothing obvious that could start slewing but the mount seems to be reporting that it is slewing:
[2020-05-26T23:50:03.342 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gv#> "
[2020-05-26T23:50:03.344 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <S> "
[2020-05-26T23:50:03.344 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] CMD: <:Gv#> "
[2020-05-26T23:50:03.345 CEST DEBG ][ org.kde.kstars.indi] - Losmandy Gemini : "[DEBUG] RES: <S> "

The only possibility is the guiding commands.

Somebody more knowledgable than me needs to look at this.

I may be completely off with this, so please have patience, but do tell me whether this is a completely dumb idea, please.

Could it be that the time-keeping in Kstars is off somehow?

The reason why I am saying this is that I know that Magnus is using a self-built focuser based on the MoonLite protocol and I started putting one together myself over the weekend. When I tested that, I noticed something strange. Look at the 3rd, i.e. last image in my post from the weekend:

indilib.org/forum/focusers-filter-wheels....html?start=48#54478

Look at the time stamp in the log window at the bottom and look at the (correct) time the system shows in the upper right corner of the window.

The times are way off. I am wondering whether the same thing is happening for Magnus and whether that messes up the mount positioning in his case.

Is that possible or is there another innocuous explanation why the time the focus module sees and the system time would be so radically different?

Jo

PS: Actually, Kstars shows the correct time (upper left corner of the KStars window, same as system time), but the MoonLite focus driver in the Control Panel has the time completely messed up. If that is a more general problem, I could imagine that that could translate into these strange mount slews Magnus is seeing. As his log shows, the RA position his mount ends up is >5 hrs different from the one it is supposed to be at. In my case, the MoonLite focus module thinks it is >3 hrs ahead of the system. Could there be a common cause for these two discrepancies?

Hi all!

Latest news on this: after a long stretch of testing, that is, Jasem doing the testing and me mostly watching, we found out that this is indeed a mount issue. It is reproducible in windows. We found out how to systematically reproduce it and could do in win to.
And: it is actually a known issue (seemingly not well communicated though). THere is a beta firmware, and it seems to solve the issue!! (this far)

So thanks all for helping me out with this, and again, particularly to Chris for fixing that irritating side-of-pier issue that had nothing to do with this!!

One happy amateur over here!

Magnus

That's great news! What is the problem exactly and could this also explain the weird behaviour I am seeing with my iOptron mount?

Because I think it is unlikely that Chris' fix has anything to do with my iOptron issues either.

Hi!

I'm not really sure what causes the problem, but it manifests as small adjustments in RA, about 10", at times casuses real runaway slews. What causes this is beyond me, but clearly a firmware issue.

As this is Gemini-firmware, I don't hink it can be realted to your iOptron issue.

Magnus

I was wondering too if the telescope location could have been an issue here, but while two *different* locations are set in sequence, that information does not seem wrong (near the Malmö airport for both).

Jo, it seems the indiserver in your screenshot did not succeed in updating its local time. This will certainly break stuff related to LST for the mount.

As an example, for an unknown reason, my setup recently lost its geographical location setting. While it simply shifted longitude to Greenwich, which is quite close to my location (1 degree), the latitude went down to the equator. Because of this, altitude of NCP went to 3 small degrees from the point of view of the mount. The unexpected side-effect was that the safety zone configured for the horizon triggered at surprising places to stop mount tracking. And Ekos/Scheduler is not that good at restoring tracking...

In any case, congratulations to Jasem for this live debugging!

-Eric

Hi!

Two different locations? How do you mean, in my log files?

Yeah, a huge thanks to Jasem and to Chris!!!

Magnus

Yes, once we could extract a log showing the relevant information i.e. what commands were sent to the mount and what it did it was obvious. Absolutely nothng to do with Ekos. Everything to do with the mount.

The thing to remember is that correlation does not imply causation. Two things happening together need not be related.

None the less I think the Meridian flip enhancements should go. I am sick and tired of having to waste time defending them from random posts blaming them for everything except possibly bad weather.

Perhaps you should all start thinking before posting fake news.

I am a future G11 user (as soon as I save a few more pennies ) Anyway I have read a few other posts on the Losmandy user group after following this post. Thank you all for the heads up Chris, Jasem and Magnus !

groups.io/g/Losmandy_users/topic/29574555#62167

groups.io/g/Losmandy_users/topic/32858271#63456

For a future G11 user, this thread has enlightened me, I know it has been a pain for you and Jasem but it has been helpful to me and who knows who else going forward !

Are you really still a 'future G11 user'?

Yeah I can see where I might be seen as masochistic... Maybe I need to really think this one over?