@knro,

By documentation you mean updating the somewhat outdated existing documentation indilib.org/telescopes/skywatcher-virtuoso-alt-az.html ?
I am a big supporter of that. As a new user it caused me a big headache of having so many drivers seamingly for the same purpose, and the lack of documentation of which one to use.

My problem is that I still have so many questions of what is for what?
First of all the naming convection is terrible. We have:
- indi_skywatcherAltAzMount which goes by the name "Skywatcher Alt-Az" in EKOS and the source code is skywatcherAPIMount.cpp
- indi_skywatcherAltAzSimple which goes by the name "Skywatcher Alt-Az Wedge" in EKOS and the source code is skywatcherAltAzSimple.cpp
3 names for each, whith very little connection between them, and the purpose of these two. It is hard to even talk about them without constantly causing confusion (which was clearly going on in this topic all the way).

Also what is Wedge stands for in the driver name? I see in the source code that there is a switch on the UI, but I can hardly find any reference to it in the source code. In fact I have found only one, in SkywatcherAltAzSimple::TimerHit():What about a true wedge (not a full EQ mount)?

Also we have driver for the Celestron mounts, whit a totally different source tree. But the API is the same for Celestron, so these too type of mounts can (and imho should) be handled together.
Having too many drivers causes constant confusion in the users, just like in the case of the AzGTI driver, which is not an "Az" driver despite it's name.

By the way, any of you have access to an AzGTI mount? I think this two driver should work correctly with the AzGTI mount (in AltAz configuration, without a wedge), can anyone test and confirm?

If an AZ mount is on a wedge, how is it differential from a "true" equatorial mount? I have AZGTi but I haven't tested it yes with this driver, maybe I should soon.

I agree we should perhaps clean up the driver. I think "simple" should go, we should just have EQ and ALT-AZ versions. So EQMod + SkyWatcher Alt-Az. We can drop the AZGti (if it works with this driver) and the "simple" driver. Regarding Celestron, I know there is API similarity but we shouldn't touch that driver or merge it with Skywatcher's IMO, we will end up putting special cases all over the code.

I'll start the documentation. Let me look at some of the other models and start putting things together.

I don't know of you do multi-language and can only do American English reliably. I could do German in a pinch. All the Spanish I know is from a warehouse and I'd probably insult the world Hispanic population with my best attempts.

Thank you Jon, that's greatly appreciated! All the documentation is already in American English in fact (including code) so sure go ahead! That would immensely help end-users!

Then what was the original motivation behind the "Simple" driver? Why is there that Wedge UI switch? Someone sometime ago did it for some purpose, I bet.
My imagination may be limited, but I don't really see the rational behind puting an AltAz mount on a tracking EQ mount, just for guiding with the AltAz mount.
But let's forget the wedge thing. You have said to me, that the Simple driver is forked from the AltAz driver. And really, the clean up you have just made in the AltAz driver has already been removed from the simple driver. So I'm thinking about back porting the changes made in the simple driver into the original AltAz driver. Except for the tracking code. The method of hos the simple tries to work (jumps every timer cycle, not moving the mount in between) is a bad idea. I can hardly think of a use case it would work. But there are other changes around the usage of conversion from Ra/Dec to Alt/Az which should be considered bakc porting to the original driver.

The current AZGti driver is really just an eqmod driver with different defaults for the UDP connection. If it is kept that way, I think it should be renamed something like eqmod_azgti or simmilar. But I don't really see any reason why the original eqmod driver should not have that same defaults. If you have say an EQ6 mount, and put a SkyWatcher WiFi dongle on it, it will have the same default IP and UDP as the azgti mount. So it is reasonable to have eqmod that same default.
Jon has almost the same dobson mount as I have, just his has built in wifi, while mine only has a serial port. But when I plug my wifi dongle (I have originally purchased for my Virtuoso mount) it works the same. The same default IP and UDP would work as the one you put in the AZGTi driver.
I understand that earlier noone considered any of the two AltAz driver to use with AZGti mount, since that does not have a serial port, and the drivers was only working with serial connection. But since we have fixed the UDP connection in these drivers, it should be (tested, then) advertised as a usable driver with vanila AZGTi mounts (without wedge).

Jon,

You see my english, that is the best I can do. By the way, feel free to correct me any tiem when I make mistakes. I have to take any opportunity to improve my english.

Gubi,

Your English is not so bad, but if I can ever help you with it or proofread anything, I am at your service. You have been a great help to me and I would be happy to assist.

I agree with your assessment of the AltAzSimple over AltAzMount with respect to the clarity and maturity of the code. That was why my initial attempts were with the AltAzSimple driver. In the end, it was only the GOTO code that sent me back to the AltAzMount, as it looked like the only fix for the GOTO issues was going to be a direct rewrite or replacement of that section of code.

Yesterday there were a few hours of cloud free time, so I've given a test to the actual state of the indi_SkywatcherAltAzMount code.
Overall the setup, sync and tracking worked, just as before the code cleanup. That is good.

As I get more and more used to how the driver is behaving, I can get closer and closer to the issues.
One I've found.

I tried to goto to Mars when it was just beyond 180° azimuth (just past south). First the mount finished the goto nicley (I started from Capella on the east). Then I've just plate solved and synced. It revealed that the mount did turned enough (few degree difference, enough to be on the easter part of the sky). When the mount tried to goto to the actual positon of Mars, it has slowed not at full speed, but somewhat slower, but did not stop at Mars but went on turning for no apparent reason. So I've hit the stop button. Now the mount stopped at a position west to Mars.
Then I instructed (in Kstars) to goto Mars. It has started to turn at full speed eastward (toward Mars), but did not stop the, kept turning. This time I did not hit stop, let it turn, and it whent a full circle around the stopped at mars. Or at least quite close to it. Some more plate solve and sync put it right on spot. These later plate solves went without problem.
So again, the mount (and the driver) knew quite well where the mount is pointing, no confusion here, yet it has turned more than 360° around instead of just stopping when it reached the target.

From here I've just visually observed Mars for quite a time, and the tracking was so good that I've not even noticed any movement. I used a 6mm eyepeace with a 2x barlow, and the focal length of the scope is 1200mm so in theory this gives 400x magnification. Any bad tracking would be noticabel at that magnification level.
Except that at some point the driver decided to slew the mount just enogh to put Mars from the middle of the field of view to the bottom edge. How much can it be? Maybe 10 arcmute? It just slewed there then stabilized and kept on tracking. I had to move Mars back to the middle using the joystick.
Later on I've removed the barlow and kept on viewing Mars, and it happened again, it has slewed, now about halfway to the field of view (which is consistent with the previous one, since the magnification was half of the previous), again the same direction (downwards in the field of view).
I have no idea what could happen in the alignmient subsystem that can cause such a behavior.

Gubi,

That is similar to the odd behavior I have seen in the past, though not recently, around the 180 degree point. Also, it seems to me this happens if you have approached the target from an Easterly start point. When I worked my around from the West (counterclockwise), I didn't get the problem. Clearly there is some math error...overflow or something...that is causing this issue.

I ran guiding tests all weekend with the indi_simulator_guide driver (clouded sky). It worked very well with the Internal guider, and actually guided slightly better with the PHD2 guider through KStars, however getting PHD2 to calibrate took a lot longer and frequently failed. The internal guider calibrated and started guiding reliably and reasonably quickly.

The only bug I noticed was on startup. Sometimes the first slew goes down instead of up. I typically do my first slew to Polaris from the park position. It stays confused, even if you are quick enough to abort before the mount gets in trouble. The solution is a complete restart of INDI and KStars, power off the scope, reorient to park position, then power the scope back on and reconnect. I also had a problem doing a first slew to Mars from Park. It worked and tracked, but the mouse froze. I found that if I used small slews and got there in several hops, it didn't cause the problem. I think that may be a problem with my KStars version. kstars-bleeding for RPi4 Ubuntu 20.04 crashes on mount connect and the compiled version does the same, so I am using the distro "kstars" stable version. I do not have this problem when I use my laptop (Ubuntu 20.04 desktop amd64), but the up/down confusion occurs occasionally with either OS.

Working on DOCS today.

Good night of testing with my scope last night. I had a problem with KStars (even the stable version) crashing when it tried to connect to the mount, but solved it by turning the mount off until Ekos settled for a few moments, then turned the scope on and connected. The test went as follows:
Unpark -- Success (nothing happened)
Slew to Polaris -- Success
Slew to random Westerly target -- Success
Slew to Southern target (M15) -- Success
Precision Alignment -- Success (3 iterations)
Tracking -- very good
AutoFocus -- Success
Guiding -- Success*
Slew to NCG-253 -- Success
Precision Alignment -- Success (5 iterations)
Tracking -- very good
Guiding -- Success*
Slew to NCG-7293 -- Success
Precision Alignment -- Success (2 iterations)
Guiding --- Success*

* Guiding calibrated quickly and operated normally with default settings. The default settings are a bit agressive for the mount. RMS averaged 2.6, so exposures over 1 second were not possible. Hopefully, some tweaking with the settings might calm things down.

I am working on the user documentation using the Synscan document as a model. It should be ready for review in a day or two.

Thank you for the extremely valuable feedback and testing Jon! Please let us know how guiding can be improved so that the drivers provides the best out-of-the-box experience for prospective users.

Another reasonably good night of testing. I found another bug. The mount control in Ekos Mount is not working right. It may do a minor nudge without issue, but a slew more than 1 second or two or three nudges and it goes crazy. I think it gets into a battle with tracking (and loses). After such an occurance, it is necessary to shut everything down and begin again from scratch.

There was a minor problem with sync failure with one area of the sky where Alignment would not center a target and eventually quit on retry limit. Just in one area of the sky, so I am guessing it has to do with solving and will look into that another time. This is, by the way, what lead to me finding the issue with the mount control. I had an image in the corner of the FOV that would not center, so I tried the mount control...big mistake.

Guiding was working with both the Internal Guider and PHD2. I tried PHD2 in hopes the Guiding Assistant would help me to find settings that would calm down the guiding over-control. It did not. Guiding works well enough for visual observing, but is not good for long exposure astrophotography. Guiding (both the Internal Guider and PHD2) sets up a sine wave pattern of over-control that keeps the image centered, but moving around in a not-so-tight circle as the guider over-corrects for each scope motion, then has to over-correct for each over-correction. I feel certain there are parameters that can be entered to calm this down, but haven't found them yet.

I did get one image, but it was bright and I could use a pile of one second exposures. Even at one second, I had to dump a great many images in the stacking process.