Looking into things a bit more. I see that the StarGo ASCOM driver sends guiding pulses as %05d format versus the lx200 default of %04d. Not sure if this is a problem for the mount or not.
Also noticed that using the mount control, slewing even at highest speed was slow. I need to look deeper into this as I thought the default behaviour was that the 4 speeds correspond to Guiding, Centering, Finding and Slewing at the speeds set for each of those.
At face value, the INDI driver fixes an issue I'm having on ASCOM whereby there is often a long wait after a guide pulse is sent before PHD2 is informed that guiding has completed. I believe this is a bug in the ASCOM driver.

For setting the 4 speeds please use the ASCOM client. I haven't implemented changing the speeds yet.
Concerning pulse guiding: same thing, maybe it works occasionally, but I did not change the behavior of the underlying lx200telescope implementation. Does pulse guiding work?

I did have them set from ASCOM but the Slew speed was still slow. I'm a developer too so I'll dive into the code. When do you think you'll move the code to a branch of INDI?

Hm, strange. Mine worked that way.
There are no fix plans when I shift it to INDI. Currently I am collaborating with CanisUrsa who takes care of the focuser part. When the focuser and the telescope are working on my repository it might be the right time to announce it for beta-testing and shift it to INDI.

After another look the mount control is working fine. I did have a long delay before the first move and after that it worked well. Some operator error as well as I was holding down the buttons rather than toggling. I did get a timeout error early on but that may be due to holding down the button.
I see that the Telescope Simulator labels the slew speeds as Max/Find/Center/Guide rather than 1x/2x/3x/4x which is more accurate. Maybe that can be incorporated into the driver. Odd that the lx200_telescope driver does not do this by default.
If I make changes can I submit with a pull request? No issue if you prefer to keep it inhouse for now - just offering to help where I can.
Maybe Jasem can also advise on coding conventions. I tend to overload virtual methods to customize whereas the new driver seems to write a parallel method and invoke it. I prefer get/set terminology to the query... naming used.

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.