This was while I was doing some testing inside. What might have happened was that I picked an object to track on and saw how long it would be until the MF happened. I didn't want to wait that long so I picked an object that would cause the MF to occur sooner. (I'm very impatient :) ).

--
iOptron GEM28, Redcat 51, Nikon D7500, WO Uniguide 32/120MM, ZWO ASI120MM Mini

Read More...

Wolfgang,

Thanks for looking at the log. I thought that I had the flip set to occur after the meridian had occurred, but I was playing with settings in that run. Is the value you're talking about 'meridian diff' ? Is that value in hours?

I'm attaching another log that has a MF failure, this one has:

[2023-05-03T11:12:11.530 CDT DEBG ][     org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "00h 29m 54s"  scope RA= "12h 17m 54s"  ha= 0.199836 , meridian diff= 0.1 , hrstoFlip= -0.0998358 , flipDelayHrs= 0 ,  "Pier Side: East (pointing West)"
...
[2023-05-03T11:12:16.461 CDT WARN ][     org.kde.kstars.ekos.mount] - Meridian flip failed, pier side not changed

I have a GPS dongle connected to the RPi, it appears that Ekos sends the time & location to the mount since I've configured KStars to use GPS for location and time. I see this in the log:
[2023-05-03T10:52:02.173 CDT INFO ][     org.kde.kstars.ekos.mount] - "GPS driver detected. KStars and mount time and location settings are now synced to the GPS driver."
But I'll double check that when I start KStars.

Thanks again for your help. We have clouds for the next few days, so I"ll be doing indoor testing to see if I can reproduce this again.

Pete

File Attachment:

File Name: log_10-51-48.zip
File Size: 60 KB


Read More...

Fred,

The log I attached was with 3.5.5 (Astroberry Server 2.0.4). So yes, an old build. I built a SD card yesterday with Ubuntu 22.04.2 and KStars 3.6.4 and I noticed that it started out with the pier side being incorrect, but I don't have logs of that build failing the MF. I'll see if I can reproduce with the newer build.

I should have stated initially that I think its 90% likely the issue is either an incorrect setting or something I'm doing wrong.

Thanks,
Pete
--
iOptron GEM28, Redcat 51, Nikon D7500, WO Uniguide 32/120MM, ZWO ASI120MM Mini

Read More...

Here's a log file with MF failures. I'm not sure what verbosity was set when this happened, hopefully there's enough info in it. I'll bump up the level and see if I can get it to happen again.

I've had this mount for a couple of months, so I'm still learning about it. At first I wasn't aware of the Meridian Treatment settings in the HC. It was defaulted to 'stop at position limit' and the position limit was 0 in the HC; of course that caused MF (and autotracking) to fail. Now I have the HC position limit set to 10 deg and in the mount tab of Ekos it is set to flip at +5 deg.

Thanks,
Pete

File Attachment:

File Name: log_14-39-11.zip
File Size: 53 KB


Read More...

Fred,

If you don't mind, I've got a question about my iOptron GEM28 mount with Ekos.
I started with my RPi4/8G with the Astroberry 2.0.4 image and had some issues with the meridian flip. I now am trying with Stars 2.6.4 stable on Ubuntu 22.04.2 LTS. It looks like both have this issue that sometimes Ekos will initiate the MF, but it immediately says that the MF completed and failed.

My issue seems to be that sometimes the pier side is wrong in the Ekos mount tab. Do you know where Ekos gets that info? Is there a way to force it to sync up with which side the mount actually is?

As long as the pier side is correct in Ekos, it looks like the MF will work.

Thanks,
Pete

Read More...