Interesting challenges have cropped up in the backyard testing.

I'm seeing frequent serial communication errors with the GM8 mount.  I think that this can be directed to:

1. USB communication failures due to dirty contacts in USB
2. Dirty contacts in RS 232 socket.
3. Failure of the mount to attempt a meridian flip command.

In these cases, CCDAP doesn't seem to be aware of the mount not flipping.  Guiding vectors are updated and that means that all the autoguiding fails after this error.  I wake in the morning with the mount pointing east but well past the meridian.

With any luck it will be a serial port connection issue where exercising the port will solve the problem.  The first step was to use a dry cotton swab to polish the contacts in the RS-232 port, then exercise all the USB plugs in their respective jacks.  This seemed to eliminate the serial errors, so it may have been a physical issue all along.

In the days following this fix, I found that the problem cropped up again.  The communications issue seems to be very problematic during flip, slew, and park commands.  Guiding commands are fine.  My next step will be to swap out the USB to serial port adapter.  If this hardware is acting up, then it's likely the source of these problems.

In the meantime, I've noticed that the RA worm gear is too tight.  I loosened it up a bit, adding slop in the gearing, making east bias harder to maintain.

I will also need to confirm middle-bias and try retightening the RA.
Going back to the neutral position has helped with guiding.  Stars were nice and round and there was minimal trailing in RA, at least on the eastern side of the sky.

The real question will be, if I can get the flip to happen on demand using the control panel software, then why would the skyx or ccdap fail?
I was able to get the software to trigger the flip repeatedly with the control panel after cleaning the contacts.  However, just triggering the flip with the control panel isn't enough to do a proper test. After observing a couple of controlled flips on Vega and Sadr, I can see that the problem is not with mount limits and CCDAP's setting for how long past the meridian it's supposed to track before flipping.

The symptom of the problem is that CCDAP sends the flip command, the control panel appears to send it, but there is no dialog that comes back saying that the flip was received.  Eventually the CCDAP log will report meridian flip completed with a duration of 200-600 seconds.  During this time, there will likely be a focus run and plate solve.  The mount continues tracking and does not perform the slew to the western part of the sky.  On watching the Gemini control panel, I can see that the length of time to the limit doesn't update during the flip sequence - or in one case I observed it performing the flip to point west, then flipping back to point east!

On inspection of TSX's mount setup page, I have seen a note stating poor communications with the mount.  I think that this must be a major part of the problem.  There's a drop in connection that is happening frequently.  This is likely being caused by a driver or the USB-Serial device being bad.  I have new spares, so I'll put them in service and mark this one as suspect.

As another fun, annoying, thing, the handy motor has stopped reporting temps.  I'll try swapping it with the one on the mak and see if that makes a difference.  As it turned out, the motor was not plugged into the controller and all is now working properly.

With the clouds expected in the coming days, I'll be able to try it out and see what I can reproduce.

Update:  I swapped the USB-Serial port device and all is good now.  Hope that this lesson can be passed forward to someone else in the future.