Hi CanisUrsa,
I took a first look into your code. It looks great, very clean, easy readable. Great job!!

Duplicating your work does not seem to be reasonable. The only thing we should think about whether the best base class is INDI::Telescope or LX200Generic.

As far as I could see is, that LX200Generic contains a lot of functions that worked out of the box in my implementation:
- Park
- Move mount (N/S/E/W)
- Abort Motion
- Goto RA/DEC
- Sync to RA/DEC

My idea was staying as close as possible to the standard LX200 implementation and implementing only the StarGo specifics.

What do you think?

Wolfgang

I had two main reasons for not utilizing LX200Generic as a base class. The first was to increase my understanding of INDI. The second is that Avalon has certain functionality (mainly AUX1/AUX2 control) that can't be accessed during things like slew and parking. I am pretty certain it could be made to work but I didn't want to cobble something together. I think it ended up making a more cohesive driver. I find utilizing inheritance too much can make code more difficult to understand. There are a couple of things I am not happy about design wise, the main one being the mixing of the telescope and focuser functionality. I may try to pull those two things apart but I haven't spent enough time thinking about how to handle that.

After speaking with Jasem I found out what I was missing for controlling the tracking rates so that should be fixed later tonight.

OK, good point, makes sense. Out of the same reason - getting a better understanding of INDI - I will continue exploring the LX200Generic based approach for a while...

Next features implemented: parking, unparking, tracking rates, slewing speeds.

@CanisUrsa: I think I found a way how to keep the tracking rates and slewing speeds in sync between the INDI driver and StarGO. Setting it from outside - e.g. with the Windows StarGO client - leads to updates in the INDI client.

I have the ability to set the tracking rates and slewing rates. I haven't figured out how to query what the currently selected tracking rate and slewing rate is. One status command you might be interested in is :X34# it will return something like m00# where the first 0 is for RA, second 0 is for DEC. The higher the number, the faster that axis is moving. m10# indicates RA tracking only while m54# would indicate a fast slew on RA, and slightly slower slew on DEC.

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.