It's not a PHD issue, it has it's origin in a weird behavior of the mount I haven't seen before:

1. The meridian flip starts as expects, but it terminates with the wrong pier side result at 23:44:26
2. Alignment starts but surprisingly in between the alignment, a second meridian flip at 23:44:49. This time guiding is not running since the post-flip-calibration wasn't finished yet
3. Flip finishes, but fails again.
4. This time, after alignment finished successfully, guiding is not restarted since before the second flip it wasn't running
5. Unfortunately, the guide deviation before capturing setting is checked, i.e. start of capturing is postponed until guider is running, but the capture module won't do it since it wasn't running  before the second flip.

The core problem we need to investigate deeper: why did the the flip start for a second time and did not wait for at least 4 minutes.

@Ron: The problem started when KStars initiated a flip while the mount hardware had a different opinion. It remained on the same pier side and did not switch to the other one as expected. As a first fix I would recommend increasing the flip delay. Nevertheless I would recommend checking whether EKOS and mount hardware have either different time setup or different location setup which would explain why the pier side did not change. If both match, then the only solution to avoid this increasing the flip delay.

HTH
Wolfgang

Not sure is settling time, if I read logs correctly PHD2 never asked to start again

[2022-02-19T23:44:28.233 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"GuidingStopped\",\"Timestamp\":1645332268.069,\"Host\":\"stellarmate\",\"Inst\":1}\r\n"
[2022-02-19T23:44:28.588 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"LoopingExposuresStopped\",\"Timestamp\":1645332268.524,\"Host\":\"stellarmate\",\"Inst\":1}\r\n"
[2022-02-19T23:44:29.032 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":true,\"id\":4068}\r\n"
[2022-02-19T23:44:29.033 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":4069,\"jsonrpc\":\"2.0\",\"method\":\"get_app_state\"}"
[2022-02-19T23:44:29.034 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":\"Stopped\",\"id\":4069}\r\n"
Then
[2022-02-19T23:44:49.922 EST INFO ][     org.kde.kstars.ekos.mount] - "Meridian flip slew started..."
[2022-02-19T23:44:49.923 EST DEBG ][           org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "

Then
[2022-02-19T23:45:15.868 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: defer call "get_app_state"
[2022-02-19T23:45:15.952 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":true,\"id\":4100}\r\n"
[2022-02-19T23:45:15.952 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":4101,\"jsonrpc\":\"2.0\",\"method\":\"get_app_state\"}"
[2022-02-19T23:45:15.955 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":\"Stopped\",\"id\":4101}\r\n"


[2022-02-19T23:45:18.374 EST DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Complete"
[2022-02-19T23:45:18.375 EST INFO ][   org.kde.kstars.ekos.capture] - "Post flip re-alignment completed successfully."
[2022-02-19T23:45:18.375 EST DEBG ][   org.kde.kstars.ekos.capture] - setMeridianFlipStage:  "MF_NONE"

Then
[2022-02-19T23:45:18.868 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":4102,\"jsonrpc\":\"2.0\",\"method\":\"get_connected\"}"
[2022-02-19T23:45:18.868 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: defer call "get_app_state"
[2022-02-19T23:45:18.871 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":true,\"id\":4102}\r\n"
[2022-02-19T23:45:18.871 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":4103,\"jsonrpc\":\"2.0\",\"method\":\"get_app_state\"}"
[2022-02-19T23:45:18.874 EST DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":\"Stopped\",\"id\":4103}\r\n"


THen
[2022-02-19T23:45:20.557 EST DEBG ][   org.kde.kstars.ekos.capture] - Waiting for the guider to settle.
[2022-02-19T23:45:20.557 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Capturing"
 

Wolfgang,

Hmmm... good analysis! Then this is really the same problem that I had prior to upgrading... which I thought was solved. In prior instances (as I was watching), EKOS would tell the mount to flip... but would fail. It would then say that it would wait for a later time (like reset to a 20 minute countdown), but would then try (and succeed) about 4 minutes later. Then it would not restart guiding or capturing.

I'm not sure how to check the mount (EQ6-R) for the same location/time as EKOS, but I have checked the EKOS settings and verified it sets/updates the location and time on the mount. I think I may be able to plug in the handset and check for proper synchronization.

In the mean time, I will delay the flip for a longer period.

Thanks for looking at the log... really helps!

Ron

Gene,

Thanks! I'm not sure what exactly is happening, but (per the above) it appears that EKOS and the mount are not in sync. I'm going to try some experiments to see if I can figure out what's going on.

Ron

This issue is typical of a wrong mount starting position at power on. I find that mount with Eqmod are very sensitive to that.
If it is not exactly counterweight down at power on this make an offset with the mount physical pseudo-encoder position that is not changed by subsequent Sync.
Because of this offset the mount can think it must still slew with Pier West when it is really past the meridian.

A solution is to set a delay before flip that is larger than this position error.
The solution I implement in CCDciel is to check Pier Side after the slew for the flip, if it is still West the program stop the tracking and wait 5 minutes before to retry up to 5 time.

I was pondering setting a minimum to the meridian flip hour angle threshold in Ekos. Right now you can set it to zero. Would making the minimum 3 or even 5 degrees help with this?

What if you start (from park) with the counter weights horizontally? Do you then need to go 90 degree past the meridian to make it flip?

Patrick,

Interesting point. I have mine set to flip six minutes (0.1 hours) after it crosses the meridian, which may not be enough. I always thought that EKOS would update the mount once it performed an alignment... but maybe not?

Thinking back... I never had this issue with my Meade LX85 mount, but it had a well-marked home position on the mount. The SW EQ6-R does not and I'm not sure how accurate I am in setting it.

I'm going try a higher setting.

Thanks,

Ron

Jasem,

Is it possible to update the mount with the position after alignment?

Also, I'm assuming that "hours" selection is referring to clock time... correct? Maybe I should check "degrees" and set to something like 5?

Ron

Not saying I understand the ekos vs mount in sync issue but the trace shows a MF running, failed, message says wait 4 minutes then 19 second later try it again, showing in State 7, failing, saying will retry in 4 minutes
and then a retry in 15+ minutes or so, failing again.

[2022-02-19T23:44:25.612 EST DEBG ][ org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange "FLIP_ACCEPTED"
[2022-02-19T23:44:25.612 EST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_ACCEPTED"
[2022-02-19T23:44:26.166 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to "FLIP_RUNNING"
[2022-02-19T23:44:26.166 EST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_RUNNING"
[2022-02-19T23:44:26.166 EST DEBG ][ org.kde.kstars.ekos.capture] - meridianFlipStatusChanged: "FLIP_RUNNING"
[2022-02-19T23:44:26.786 EST INFO ][ org.kde.kstars.ekos.mount] - "meridian flip failed, retrying in 4 minutes"

The 19 seconds later

[2022-02-19T23:44:49.011 EST CRIT ][ org.kde.kstars.ekos.capture] - Accepting meridian flip request while being in stage 7
[2022-02-19T23:44:49.012 EST DEBG ][ org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange "FLIP_WAITING"
[2022-02-19T23:44:49.012 EST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_WAITING"
[2022-02-19T23:44:49.552 EST DEBG ][ org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange "FLIP_ACCEPTED"
[2022-02-19T23:44:49.552 EST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_ACCEPTED"
[2022-02-19T23:44:49.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to "FLIP_RUNNING"
[2022-02-19T23:44:49.899 EST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_RUNNING"
[2022-02-19T23:44:49.899 EST DEBG ][ org.kde.kstars.ekos.capture] - meridianFlipStatusChanged: "FLIP_RUNNING"
[2022-02-19T23:44:50.968 EST INFO ][ org.kde.kstars.ekos.mount] - "meridian flip failed, retrying in 4 minutes"

Then 15 minutes later retry after saying 4 minutes previous

[2022-02-20T04:59:25.528 EST DEBG ][ org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange "FLIP_ACCEPTED"
[2022-02-20T04:59:25.528 EST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_ACCEPTED"
[2022-02-20T04:59:26.255 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to "FLIP_RUNNING"
[

As Wolfgang says the flip failed at 23:44:26, probably because the mount didn't think it was past the Meridian and therefore did not have to flip. EKOS reports that it will retry in 4 minutes. I think there is a bug in the code here as whenever I get this retry message it retries almost immediately (not in 4 mins). This is repeatable every time. This is also the case with this log.

The mount has another go at the flip, 33 seconds later at 23:44:49 but it fails to flip the mount again.

For the first failed flip, EKOS reports the HA:
Hour Angle  "00h 00m 27s"

For the second failed flip,
Hour Angle  "00h 00m 28s"

So the HA is very close to the Meridian so if there is a small discrepancy between EKOS and the mount in terms of time or location setting it could well be that the mount doesn't think it has crossed the Meridian and so doesn't flip. Because of the "4 min" bug EKOS tries a few seconds later and gets the same result. It seems to get into a funny state after that so thats the end of the session.

If the MF sometimes works and sometimes doesn't then it could be because sometimes the Mount thinks it has crossed the Meridian and flips, and sometimes it thinks it hasn't quite crossed it so doesn't move. Things like how long the MF has to wait for an ongoing capture to complete can make a difference.

What I would suggest is:
1. Check the mount settings for time and location so ensure they are consistent with EKOS.
2. Work out how far past the Meridian you can go with your equipment before the scope crashes into the mount and in the Mount tab in EKOS, set the "Flip if HA >" value above zero but below your maximum limit. For example, if you can go to an HA of 1 hour before problems try setting your "Flip if HA >" to 0.5. So if there are small timing issues these should not cause problems.
3. Have a play with your setup in daylight doing some MFs to make sure you get settings that work for you.

I wrote up a doco on MFs that might help...
As Wolfgang says the flip failed at 23:44:26, probably because the mount didn't think it was past the Meridian and therefore did not have to flip. EKOS reports that it will retry in 4 minutes. I think there is a bug in the code here as whenever I get this retry message it retries almost immediately (not in 4 mins). This is repeatable every time. This is also the case with this log.

The mount has another go at the flip, 33 seconds later at 23:44:49 but it fails to flip the mount again.

For the first failed flip, EKOS reports the HA:
Hour Angle  "00h 00m 27s"

For the second failed flip,
Hour Angle  "00h 00m 28s"

So the HA is very close to the Meridian so if there is a small discrepancy between EKOS and the mount in terms of time or location setting it could well be that the mount doesn't think it has crossed the Meridian and so doesn't flip. Because of the "4 min" bug EKOS tries a few seconds later and gets the same result. It seems to get into a funny state after that so thats the end of the session.

If the MF sometimes works and sometimes doesn't then it could be because sometimes the Mount thinks it has crossed the Meridian and flips, and sometimes it thinks it hasn't quite crossed it so doesn't move. Things like how long the MF has to wait for an ongoing capture to complete can make a difference.

What I would suggest is:
1. Check the mount settings for time and location so ensure they are consistent with EKOS.
2. Work out how far past the Meridian you can go with your equipment before the scope crashes into the mount and in the Mount tab in EKOS, set the "Flip if HA >" value above zero but below your maximum limit. For example, if you can go to an HA of 1 hour before problems try setting your "Flip if HA >" to 0.5. So if there are small timing issues these should not cause problems.
3. Have a play with your setup in daylight doing some MFs to make sure you get settings that work for you.

I wrote up a doco on MFs that might help...
  

Gene/John,

Thanks for the replies!

Gene: Yeah, regardless of how to get MF working correctly... there needs to be some work on how EKOS handles a MF error.  I'm sure it's complicated... but probably doesn't need to be.  It would seem to me that if MF fails then EKOS should reset the countdown to some value (e.g., 4 mins) and continues with all other processes (e.g., guiding, capturing, etc.).  Then try again in 4 mins... wash, rinse, repeat... until successful.

John: Great analysis and excellent article!  Here are my observations:

• My HA greater than 0.1 hours is probably just too low.  I will test my mount for potential crashes, but think I should be able to set it to 0.5 hours (7.5 degrees) without issues.
• I'll check my mount to see if it is in sync with EKOS.  It should be, as I have EKOS setup to update the mount based on EKOS.
• Which gets me wondering if EKOS re-syncs to the mount after alignment?  When I run alignment, I can be 1-2 degrees off... which EKOS corrects.  The question is... what impact (if any) does this have on what the mount thinks is the meridian?  If I go-to another object and perform alignment, I'm off by about the same amount... which tells me that EKOS does not update the alignment model in the mount.  Should it?  I don't know... perhaps others can chime in.
• SO.... my theory is that when my home position is off by 1-2 degrees, EKOS performs alignment and corrects its model (including MF time) and starts the MF countdown.  However, the mount hasn't changed its model.  When the countdown gets to zero, MF will work as long as the HA delay is within the alignment error of the mount.  If it isn't, then I have problems.

Make sense?

Ron