Avalon gave me the following hint which is working fine for me:

Wolfgang, How do you feel about grabbing the focuser code I wrote and adding it to your driver? I have decided to halt development of the Telescope/Focuser driver combo I was working on so we can focus on a single Avalon driver. If that sounds good to you I'll start trying to break your driver

Warmly welcome, go ahead!

And maybe we should spend some effort in a proper modularization. Because one huge class implementing all StarGO features might not be the best idea. Currently we need to modifiy LXGeneric in order to be able to subclass it and need to stay within the core framework. Maybe we can convince Jasem to change this so that we are able to move our implementation to a proper 3rdparty driver.

Hello Wolfgang, hello CanisUrsa,
You join your work to write one driver : VERY GOOD NEWS.
Can you add a function in your driver : PushCloud () Because it is very difficult to test and use your driver with cloud.
I am waiting the information for the new one, to know if it will be int the git space of Wolfgang or CanisUrsa.

Hi Jean-Jacques,
the PushCloud() is not the problem, I will take it into the product backlog. The invest in the physical device might be challenging - better you start saving money now

Wolfgang

Hi folks,
the first imaging session with the new driver went almost fine. The driver worked perfectly fine for hours and I could take ~25 subs. The downside: my kstars client crashed after the meridian flip, so half of the night the scope was running, but no images were taken

Stay tuned...
Wolfgang

Sorry about that, that's terrible. Please always run KStars in GDB so that if there is a crash, we'll get useful backtrace back. You can run it like this:
If it crashes, just go back to the console and type in bt to get the backtrace and share that. Also the logs would be useful, but the backtrace is more useful in cases of crash.

Thanks for the hint. I opened another thread here .

Wolfgang

Great to see this work taking place. I am keen to help out if I can. I've had to revert to Windows since getting my M-UnoI don't think that is quite right. I've been chasing down an issue in the ASCOM driver where it fails to notify PHD2 when a guiding pulse is complete till very late. So in response to a guiding command Mg (followed by n/e/s/w for direction and nnnnn for duration in ms) e.g. Mge00678 a follow up X34 command returns m40 meaning the mount is guiding in RA. Once guiding is complete the X34 command returns m10. At least thats how it looks.

Aha. Just saw Wolfgangs code where 4 means Moving at low speed to refine. That makes sense. In any case no problem for PHD2 as it only polls for IsGuiding on ASCOM mountsand even then it is apparently not reliable.

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?