Correct. See my post here www.indilib.org/forum/ekos/7753-meridian....html?start=24#60677

I finally copared your XML file with mine and I dont see any difference apart from one turned entry in the right beginning. Though I could not figure out what that means...

This is mine:

Showing after "DEBUG" the "ENABLE" on OFF and the DISABLE on ON

This is the example

Showing after "DEBUG" the "ENABLE" on ON and the DISABLE on OFF

No further differences in the whole file - they are (appart from the location coordinates) indentical.

It means that in my case debug logging is on and in your case off. I compared my xml file with the one of El Corazon and found one difference. For him the slew speed is set to 9 and for me to 5. I don’t think that’s thenissue though (even if I said so in an email to him) because for me the RA axis does park. And the mreridian flip goes at full speed as well. I am as puzzled as you are...

Agree, this is not an Ekos problem. The difference must be either mechanical (too much resistance and missed steps when parking - makes sense for the DEC motor, which is underpowered) or rooted in the hand controller.

But how can everything work normal if its a mechanical problem? Normal slewing works fine. Plate solving and accurate slew to target works fine. Guiding works fine. Automatic slewing for polar alignment works fine. Even the slewing back to the park position works fine now. So everything where Ekos needs to move the mount for various reasons works super, apart from the flip (and parking but that I don´t care about). Ther are no strange noises from the gears. And I just tested it with different tension on the gear screws - meridian flip does not want, independend of how much tension is on the screws.

In the HC there it seems that only two things could screw it up: the time and location tab or the meridian handle tab. Both we checked several times now and the time and position is syncronized between KStars and the mount. obviously it doesn´t matter who is updating whom as long as both are sychrone and DST is off. Even if I try with settings suggested from users that have no issues it´s not working.

Can it be that the KStars version on my StellarMate causes this issue? I have v.3.5.0 BETA running on it (BULD 2020-08-29T02:41:24Z).
I did not actively choose for it and it was installed automatically (even if I did set the software updates to STABLE in the StellarMate settings). Also the circumstance that I can´t get a Log-file (wich I succesfully did before) is letting me think that something with my version is not right.

I will install KStars on Windows now just to test if it´s a problem with my Raspi´s KStars... Will report as soon as I know.

Cheers, Nico

Hoi Nico,

Interesting. I occasionally notice, epecially after an imaging session, that the scope doesn't go back to the zero position but that both axes are slighlty off. I notice because we marked the zero positions.


Groetjes, Wouter

...okay, starting Ekos locally on Windows is not supported... need to get the USB-Serial adapter working on my mac first the.

Yes, during testing now it always slews back nicely to zero (I also marked the zero position on my mount). But yes, after a longer session it was slightly off too. But I don´t bother too much about "slightly off"

That would have been the next thing I would have suggested: Complete fresh install. I am using a self-compiled Kstars on Ubuntu MATE, no problem there.
I had another successful night on the CEM25 imaging M31. All worked without a hitch (except for the Pi losing network connection, but Kstars finished autonomously and parked the mount exactly where it was supposed to be). Flip executed autonomously. I am as baffled as Wouter is.

Why don't you get a new SD card and install Kstars either under raspios or under Ubuntu MATE and see how it behaves there?

Well, because I´m not that fit in Linux and Co as it might seems
The reason why I bought StellarMate OS last year was simply that I could not get my own installation to work at that time.
In the meantime I did got a little more confident and got my RTC to work (wich took me a full day) and even got my Raspi to boot from SSD (what took me another full day and only works via USB2).
But yes, I may slided too far to the pure user-side during the last years
Will first try to test with my Mac - then I can think about a clean installation.

So, finally I could test with my Mac and... it failed again but I got a log-file! So, it´s most likely not KStars or my StellarMate.
All I see in the log is that the Flip was scheduled, triggered, accepted and failed - but I´m obviously not the most qualified person to translate the log
Is there anything in that can help further?

It looks to be what we have been saying all along. The flip is failing because it is too close to the meridian.

A slew finishes at 00:03:29, the pier side is West so Kstars expects that a slew will be needed soon.
At 00:04:00 the flip slew starts. The hour angle seems to be very close to zero.
Then 4 seconds later the slew finishes and Kstars reports that it failed because the pier side did not change. The system is set to retry in 4 minutes but you stopped it before then.

You need to allow the mount to track further past the meridian At present your limit is 0.02 hours, 1.2 minutes.

One thing though, it looks as if the first slew was to a position that was past the meridian - a positive hour angle - this slew would b expected to have already done the flip. I would experiment by doing a series of manual slews to see at what hour angle the mount will flip.