I will test tonight with meridian flip using scheduler and see if I detect any issues.

OK. I'll do the same.
The cable must be OK and not disconnected as I restarted the scheduler; after I'd tried to restart align after the flip. The mount was still connected and responded to the align...
Dunno...

Hi
Yes. You can blink through and see the change in the position of the stars at the time of the flip.

Please bear in mind that mount model was not reset due to failed flip. So this could affect the results. At any rate, I will know for sure tonight if there are issues pre and post flip.

Is this what I should be using?
Build: 2018-08-23T08:23:25Z

I was able to replicate the issue today and identified the problem, so I'll be working on a solution with Eric.

Thanks for your patience.
@Jasem: did the eq-mod flip work for you?
TIA and clear skies.

No, I got exactly the same results are you did with the shift. Upon investigation I found the problem and discussing it now with Eric. I don't want to go into the details since it's quite technical but we are working on a solution. For the time being, if you enable "Restart Alignment on Guiding Calibration Failure" option in Ekos-->Scheduler that might help as well.

Question, was capture getting aborted regularly due to PHD2 guiding deviations getting out of bound? then when they're normal again, guiding resumes?

So, the mount flipped and then stopped with the eq-mod 'unknow error'? Or do you mean it flipped correctly but the alignment was wrong after the flip?

PHD2:. No, that is now under control; hardly ever fails since following Andy's advice and the modifications you made to the timeouts etc.
TIA
Steve

Hi
Warning I'd not seen before:

[ 42%] Building CXX object kstars/CMakeFiles/KStarsLib.dir/ekos/scheduler/scheduler.cpp.o
/home/steve/kde/kstars/kstars/ekos/scheduler/scheduler.cpp: In member function ‘void Ekos::Scheduler::unParkMount()’:
/home/steve/kde/kstars/kstars/ekos/scheduler/scheduler.cpp:4917:50: warning: this statement may fall through [-Wimplicit-fallthrough=]
else currentOperationTime.start();
^
/home/steve/kde/kstars/kstars/ekos/scheduler/scheduler.cpp:4922:9: note: here
case Mount::UNPARKING_BUSY:
^~~~

(The first caret is beneath the semicolon)
Probably nothing but thought I'd post just in case.
Cheers,
Steve

This is a fairly minor warning that took us three commits to unsuccessfully solve I need to push a final diff for this one. Cross-platform build taken to the next level!

-Eric

Yes, you were correct. We found the culprit. It's the usb3 data cable. It does not stay put. I'm sure there must be a better way than velcro. The stiff cable doesn't help either. Epoxy resin? Ideas?