Hi Ken,
feel free to submit a pull request. Any help is warmly welcome!
Wolfgang

I've been doing some testing recently while the skies are cloudy. With USB connection it seems quite stable but I then tried the Wifi connection. The driver got itself in a twist when it received a :Z1030 from the mount instead of its expected response. I think this is some sort of notification of LST. Possibly mixed with tracking rate as it also received one :Z1033 as well. I'm guessing the final digit signifies the tracking rate:0=Sidereal, 3=Terrestrial(no tracking)
I'll have a go at handling these if no one else has done that already.

Hi Ken,
hm, that's a strange state. The first "0" represents the motors state showing that both RA and DEC motor are off. The "3" indicates sidereal tracking and the last digit is the motion speed, where "0" stands for "guide speed" and "3" for "slew speed".

In detail: the three last digits represent the motion status of the mount as :Z1<motorsState><trackingSpeedState><motionSpeed> with the following semantics:
motorsState:
// m = 0 both motors are OFF (no power)
// m = 1 RA motor OFF DEC motor ON
// m = 2 RA motor ON DEC motor OFF
// m = 3 both motors are ON

trackingSpeedState:
// t = 0 no tracking at all
// t = 1 tracking at moon speed
// t = 2 tracking at solar speed
// t = 3 tracking at sidereal speed (stars)

motionSpeed:
// s = 0 GUIDE speed
// s = 1 CENTERING speed
// s = 2 FINDING speed
// s = 3 SLEWING speed

- Wolfgang

Do you think this is a notification to the mount or a response to a command? I guessed it was a notification because it appeared in the log between other command/response pairs. Looking at it a bit closer it could be an additional response to a :X3C#
I'll analyse a bit more to see what the pattern is...

I think I see what’s happening. The X3C gets the Z1nnn response but also the LST as a separate response. On USB this arrives before the next command and gets flushed but on wifi it arrives after the flush. So there should be a flush after the first response is read.

Right, Z1nnn is the response to the :X3C# command.

I’ll start by putting in a trace to see what is initiating the LST response then put in an appropriate handler. When done I’ll raise a pull request.

Have you already turned on logging to file? With debugging turned on for the Avalon driver, you could find the entire LX200 communication in the log file under ~/.local/share/kstars/logs

- Wolfgang

I had to enable logging from LX200driver as well so now I'm seeing what is happening. All is going ok until :X362# command which receives an additional :Z1nnn response (unless there is an unlogged command sent) and that throws out the rest of the stream. When I was snooping on the USB stream a while back I did see that some of the X36n commands get two responses. I'll see if I can flush the second response

Made a great deal of progress but it took quite a bit of refactoring. As far as I could tell the issues were related to the commands/responses that went through the LX200driver code. Each time I migrated a function from there to the Stargo driver that command stopped being a problem. Its possibly a problem n the object code and maybe resolvable by rebuilding everything together but the code needed a bit of a cleanup anyway.
Attached are a before and after log. Due to some other problem the lat/lon coords fortuitously do not point to my home.
I haven't yet tested all the functions.

Sounds good. It would be great if you create a pull request - or simply send me your modifications directly.

Pull request sent. Its now very stable although it still has a couple of small things to fix around that timing problem. I thought I read in the code that the ttyread timeout was in seconds but I'm not seeing that. Elsewhere I've seen the timeout for ttyread being in tenths of a second which corresponds to what I'm observing. Currently the StarGo driver is using a timeout of 5 - if that's 0.5s then I might need to up it to 10 (1s) as I'm seeing the occasional read timeout which sometimes triggers the same issue I've been sorting out.