For those where the mount parking works, can you please share your firmware version?

We updated both the hand controller and the RA board to the latest firmware and parking still doesn't work. The RA axis goes to the zero position but the DEC axis again gets stuck under a seemingly random angle. We'll stick to using the hand controller.

Worse: now the DEC axis (which we didn't update the firmware for) started slipping. We here a rattling noise when it is moving and the axis doesn't rotate further. We recently added extra washers in the locking shaft (the one that pushes the DEC motor axis to the DEC axis) to give a higher pressure to the spring pushing the ball bearing and it seemed to be working well. No clue why it suddenly started misbehaving. Note that the parking test described above did NOT involve this rattling noise. It only started doing that after we tried several times.

Additional note: we also have an iOptron GEM45 with the latest firmware installed (this is necessary for Ekos to be able to control it) and with that mount parking doesn't work either. We always use the hand controller with that mount as well. It seems to be something in the iOptron firmware. I thought I read somewhere that iOptron said that their firmware doesn't have park positions but only zero positions but I don't remember where I read that.

Yes, I can confirm that the latest Firmware does not solves the park issue (what I´m not bothering really about anyway) but also not fixes the meridian flip issue either.

I just updated the HC and the RA firmware. And tested it again. I tried all suggested values and settings - evenn those that work with others bit sill nothing.
Before that I updated the RasPi with update, upgrade and dist-upgrade - there was not much to upgrade though. Need to get the logging working...

I haven't updated the firmware in my CEM25P (which matches yours), mainly because I would need a blood PC to do it and don't want to dust the clunker off for that purpose. Correct me if I'm wrong, but I do need a PC for this, don't I? - Or will it work with wine?).

So this is not firmware related.

Rattling noise: Either your Stepper motor is missing steps, that makes a noise similar to rattling, or your tension screw is not tight enough. The latter you can test easily by trying to move the mount plate in DEC. I always do that now to find the minimum tension where there is no more perceptible motion in DEC (or RA for that matter). Those steppers are powered with minimal current, so any mechanical resistance will stall them. In fact, I had to take out my stethoscope to find the optimal sweet spot where the motors are happy and the mount plate sits tight.
When I bought the CEM25P I had not anticipated that I would have to perform cardiology on it before an imaging session, but by now I think fondly of the mount as my patient in dire need of TLC.

At any rate, it flips nicely and it parks nicely, so a good kick in the butt might make yours behave and solve the problem.

You need a blood PC. Luckily we have one here which helped us do this. It is strange that parking works for you and not for others...

I don't think it is the stepper because the sound comes from within the DEC axis. I think the worm is slipping on the DEC shaft. I'll open up the mount now to have a look.

OK it seems that the DEC axis gets stuck occasionally which causes the stepper motor to skip steps which causes the rattling noise. Sorry for having hijacked this thread. I’ll take continue offline now.

The solution is to not tighten the DEC screw too much. When we tighten it and jntighten it by ine turn, the DEC axis doesn’t slip anymore.

naugustin, if Ekos wants to flip, but mount do a mini slew without flipping, reason is that mount and Ekos doesn't agree about where meridian is. To command a meridian flip is nothing but saying to the mount to slew to the very same coordinates it is pointing to; then the mount, that has tracked the same coordinates past the meridian until now, thinks "ok, someone told me to slew to an object ovest of the meridian, so I should point it from east" and slew to it the only way it knows, moving east of the pier. Problem arise when Ekos (or any other software) sends slew command, but the mount thinks the requested coordinates are STILL EAST of the meridian, so it feels itself on the right side.
You can verify this also inside your house, asking KStars to slew your mount to a star near the meridian; then to slew to a star near the meridian, but on the other side: if the mount doesn't move on the other side on the pier, it's because the mount thinks the two stars are on the same side of the meridian, while KStars doens't agree (actually they don't agree where the meridian is).
My GEM45 behaved exactly the same as yours, until I found that time was not in sync between the to: my problem was the DST settings I think you already disabled. But maybe there's something else you're not seeing
Hope this helps-.

Yes, that´s the hole issue the mount disagrees with Ekos I will check later today once more all the time settings in the hand conroller and in KStars and Ekos.

Fist of all, many thanks to all of you for taking the time to write suggestions and trying to help!
It´s very much appreciated and I´m happy to be here

I checked and tested once more. Still, I don´t get any Log-file even though verbose logging is activated for INDI and the Mount. No files appear in the log-files directory

I checked again for any discrepancy of the time between mount and KStars but there is none. It also makes no difference if DST is on or off, neither in KStars nor in the Handcontroller. At the moment I have set in both UTC+2h (120min in the hand controller). The time is exactly the same in both - there is one second delay in the HC but I assume that is because KStars is set to update the mount what takes a second (see image).

Still, no automated meridian flip. Another thing that I tested is to approach to a target near both sides of the meridian (as suggested by picciux). Both times I started from the Zero Position. I would expect that the mount would approach the two sides of the meridian via the opposite sides of the pier (we do know already that this is not working but just wanted to test it once more).
So, when I command to slew to a (random) star that is approaching the meridian from the East, the scope slews to it via the West side of the pier, pointing East - all fine. When I go back to the Zero Position and command now to slew to a target that already passed the meridian towards the West I would assume the scope slews via the East side of the pier, pointing West… but it does exactly the same as before. So yes, agreed that Mount and Ekos disagree in something here but why?, time and location match exactly.

I even simulated a plate solving after slewing to the star that was close to cross the meridian and set the solver action to Sync. It succeeded with the info that the mount is synced to the solution coordinates. So, the mount should actually know perfectly, where it´s pointing at. Still, no auto-meridian flip.

Then I did read in the StellarMate FAQs that „All mounts must be first aligned using the handset using 2 or 3 star alignment before you can use them with StellarMate. The only exception to this rule is…“ EQMod mounts where it is assumed that they point to the celestial pole at startup anyway. There a plate solve and sync shall be necessary. Well, my routine usually is to start up, polar align (via Ekos Polar alignment), then slew to a bright star using plate solving and „slew to target“ for focusing (I don´t have a motor-focus yet) and then slwe to my target, plate solve with „slew to target“ again, start guiding, start imaging… With all this plate solving the system should know quite well where it´s pointing at, right?
Are you other CEM25P users do a 2-3 star align after setup? I never did that since I plate solve.

Running out of ideas and since I can´t save a log-file I can´t provide any new info at the moment.
Will read on a bit

Cheers, Nico