I spent a few hours on the SkyWatcher Alt-Az driver today. Had to partially setup my 16" Orion SkyQuest Dob to test this. Many fixes were made to make me finally use the Dob the way it's suppose to be. Two things are important:

1. Start in home position. That means telescope pointing NORTH. For some my dob, the OTA would be HORIZONTAL and LEVEL with ground. In essence, the scope should be at Az = 0 and Alt = 0
2. Make sure it gets the correct location and position. This is done automatically by KStars, but I noted I had to set to GPS for testing before and I was trying to understand why it's not working since there was no GPS.

The new driver is now 1.2 and should be available in the nightly repo tomorrow. Please also git pull and this. The changes are listed in commit aeba92ac67f0f8afec53b96cd00d41f17c2f1359

Things I didn't test:
1. Alignment Subsytem. I'm going to need to set a camera on it and see if it works with astrometry like EQMod.
2. Guiding. The guiding & tracking code in the driver is quite complex and I decided to leave it for now.

Knro,

I stripped out a lot of stuff and have a very good working version of indi_skywatcherAltAzMount. I did some serious testing last evening (no clouds) and it performed flawlessly for GOTO, SYNC, TRACK and with Astrometry for Plate Solving. The Guiding is broken, and I am about halfway down the chain in tracking down why. By broken, I mean that now it does not move the scope at all, nor does it error or cause any issue. Parts of the guiding code are running, but the scope remains unaware.

I found a lot of issues with the Park/Unpark functionality. Several chunks of exception handling code and work-arounds. I ripped it all out by the roots and along with it went the unreliability in GOTO. I see no reason to put it back in for a Dobsonian. My startup workflow goes like this now:

- Point the scope somewhere (anywhere)
- Turn the scope on and connect the drivers/computers/cameras
- Take an image
- Plate Solve the image
- SYNC the mount to the solved image
- Go happily on with life...no additional setup needed...GOTO any target

When finished, I just turn stuff off. No need or value in parking portable scope.

Thank you for all your efforts in this matter. I look forward to viewing your code to see your changes. Did you find the root cause of the GOTO instability?

I am going to continue on with Guiding. It's really important for an Alt/Az mount as even very good tracking is not...well...not very good from a photography standpoint.

I understand the value of starting pointing at a "HOME" position of North and Horizon Level. This is the only reasonable option if you do not plate solve, and is a good starting point in the beginning. The SYNC and GOTO work reasonably well, however and it pains me to think how much time I wasted before I got around to plate solving. The only issue I found (testing with KStars and Carte du Ciel) was that care must be taken in the Astrometry setup to keep the resolution time low. Tracking is not enabled during the solving and if it takes a long time, one ends up with more near miss solving iterations than convenient. This due to the drift over the time waiting for each solving solution.

It seems many programs that are "indi compatible." PHD2 as a perfect example, do not properly initialize indi drivers. In the case of PHD2 when not used in conjunction with Kstars, neither the camera nor mount load the configuration. Also, time is not set. This can cause some of the instability in operations and is not the fault of indi code.

@knro:

Looking at the code now. Interesting!

The Virtuoso code was my next target for root canal.

The TTY error is tedious, but harmless. It basically just clogs the log files. I am using the WiFi UDP connection, so I just try to ignore the error. Probably, that check and warning should be disabled by the ETHERNET switch.

I missed that SetEncoder issue. Interesting that it didn't bite me.

The startup thing was not an issue after I deleted the Park code. I am going to try your version tomorrow evening (weather permitting) and add Park/Unpark to my startup (if I must) as long as it doesn't require me to do an initialization with the star align. I much prefer to just point the scope and start with a semi-blind solve. My two cents: Park/Unpark is vital for some and just an added step for others (such as myself). Perhaps that functionality deserves an Enable/Disable switch.

The alignment code worked very well with my version, excepting that with tracking off and a long solve (1 minute or more), the fine adjustments couldn't keep make much headway against the drift. Once it got a localized solve (8-10 seconds) it did better but frequently took too small a bite in the adjustment, taking many more iterations than necessary. I assume, based upon what I see, your changes should not have changed that performance. My guess is that "sneaking up on the target via multiple iterations" is more of a parameter issue than a code issue.

I am looking at the guiding today and will post my results later.

Thank for the feedback Jon. I wanted the driver to be similar in EQMod. i.e. on startup, it assumes to be in HOME POSITION. For equatorial mounts, that looking at celestial pole with counterweights down. For Alt-Az, that's looking north/south with telescope at horizon level (zero altitude and azimuth). From there you can slew anywhere and then capture & solve and it should be the same as EQMod. But I never tried it yet in this manner as it's been raining here for a week, and setting up a 16" Dob is a chore.

It makes sense to do it that way (Park/Home). That does, after all, follow the standard operating procedure set forth by Skywatcher for their SynScan product. They want a North-facing, horizontal scope to start. This way, the expectation is that your first attempt at alignment is at least in the general area of the known star they allow you to seek. So, you have a procedural match with both the other INDI drivers as well as the SynScan product.

And yes, the 10" is enough of an effort to setup and tear down for each session. I can only imagine a 16". And here's me thinking of something smaller as a "next scope."

By the way, the indi_synscan_telescope driver has a few holes in it as well, but that is an issue for another time. It isn't terrible, and it works at least as well as the SynScan Android App, though that isn't saying much.

Jasem,

I have checked out the code from github, and I've given a test to the indi_skywatcherAltAzMount code. Only indoors, since it is cloudy here since weeks. It seems to work OK.
I agree that the driver should assume a home position on startup. In the old code we had a problem that we have two drivers (AltAzMount and AltAzSimple) and they had different behavior. One assumed pointing to polaris the other being horizontal. Either could work, just it should be consistent.
It is true, that a Virtuoso mount by itself (without synscan) assumes to be turned on pointing to the polaris (it learns the Lattitude of the location from that), but when used with the hand controller or synscan app it also assumes to be initially horizontal pointing north. The same as my 250 dobson mount works. So it is OK for the driver to assume horizontal north, as it is consistent the operation of synscan (with which new users is most likely familiar).
The driver starts up unparked, which is welcome by me. Also the old behavioral of on unpark turning to some default location was not so good idea, as new users may get confused by that, seeing the mount turnin somewhere, without any apparent reason.
I have tried the driver with my Virtuoso mount, and it seems to be working consistently. I have tried to instruct it to follow mars (at south), and it seems to point to the right location.
I have never understood the comments in the code like "The altitude degrees in the Virtuoso Alt-Az mount are inverted." because it seems to me, that the big dobson mount works exactly the same way as the Virtuoso mount.

One strange thing I've found is that when I try to control the mount with the "mount control" panel buttons or with joystic, the Az axis turns in the opposite direction. I mean the mount position shown in Kstars is consistent with where the mount is pointing/moving, just the left button turns the mount east->west and the right button turns the mount west->east which is the opposite of what I've expected. The up/down seems "normal": the up button raises the mount, the down button lowers.

I've also noticet that when I disconnect and restart the driver (without turning the mount off/on), after reconnect it reads the coordinates from the mount, and shows the mount in Kstars pointing to the position where it is left, which is a welcome change too.

@Gubi:
I agree with all your points. Although, the left being right and right being left didn't bother me, as I rarely move the scope other than slew to position or plate solve. I especially agree that UnPark is a good starting position. On Park it returns nicely to start (North horizon) instead of loosing its mind and dancing a jig.

You were right about indi_simulator_guide. It works fairly well. As I am clouded out too, it was a better option than setting up Stellarium on the TV monitor and trying to focus the guide scope across the room.

@knro:
No joy on testing today. I have been trying to test guiding, but kstars is fighting back:
* Tried to use indi-dbg and kstars-bleeding-dbg with Pi4, but they are not available as source that I can see nor is there an arm64 version yet.
* Kstars won't compile on the Pi4 presently. It barks on config looking for StellarSolver, that is apparently not included in the git download. There is a problem with the git instructions as well. It looks for a URL as git://, that does not work. It downloads fine by replacing the git:// with https://...excepting for the missing StellarSolver code.
* Setup a new nightly-build kstars on a Ubuntu amd64 desktop, but it crashes the moment Ekos connects to a mount. I tried several mount drivers that will connect to my mount and it crashed with each one. I may try wiping Kstars completely and doing a distro install, then compile the new driver and move it in place. I did find that starting the indiserver and connecting with other software works as expected, which seems to point directly at a Kstars issue with this OS.

What I want to accomplish is to find out why guiding isn't moving the scope. There are debug lines in the code that will output the very variable values I am interested in and verify that sections of code are running, but I have not yet found a way to view them. All I want is: System.out.println("VariableName " + someVariable); // but alas, Toto, we're not in Java anymore. So far, turning on the Ekos logs hasn't been very helpful. I am certain that if I took the time figure out how to run the whole mess inside NetBeans or QtCreator, I might be able to extract what I need or at least set breakpoints and know half the answer. And that may be the endgame if I can't just view debug information in Kstars. Presently, I have NetBeans happily doing gits and compiles of indi and syntax checking, but not running code.

@All:
By the way...what part of the planet are you two camped in? I ask as general interest and for time-zone reference. I am in NW Georgia, about 60 miles NW of Atlanta (Bortel 4).

Hoover!! ..um..no....Dyson!!....uh..no....EUREKA!! (yeah, that's the one). For some completely unknown reason I tried the indi_skywatcherAltAzMount and GUIDING WORKED! The setup was the Skywatcher 250P Synscan GOTO mount with running a minimal config of indi_skywatcherAltAzMount and indi_simulator_guide on a Raspberry Pi4 with Raspberry Pi OS for arm64 (Debian 10 [buster]) with KStars Internal Guider. I am reasonably sure I have tried this configuration before and failed. The only change I made was to enable and additional check or two in the debugging section of the Indi Control Panel for SkywatcherAltAz. I am not sure if or why that would have made a difference.

I am going to try again shortly and capture the logs to a file so I can be sure that WORKS means WORKS PROPERLY.

That's great to know! For rpi4, do this:
Then KStars should compile OK.

Why do you want to compile Kstars? You don't need that to debug indi.
Debugging is somewhat trickey, you should enable debugging in the KStars config panel EKOS tab, and in EKOS on the specific driver. Just chek both "log to client" and "log to file", and open the log file in a terminal widnow with "less" or "tail -f". You will find the file name in the EKOS message window. It is under the ~/.inid/ directory...
For quick dirty debugs instead of System.out.println() you have printf() you know. Quite powerful.You just need to run the indiserver in a terminal window, and set EKOS to "remote host: localhost".
But in the driver source code there is DEBUG(DBG_SCOPE,....). Same power, and goes to the log file. That just works, if you enable "driver debug" checkbox in EKOS.

I'm in Europe, CET time zone. It is almost midnight here now...

Glad to see it's working. The strange thing that I noticed is that when using the W/E directional buttons is that the mount "fight back" and tries to over-compensates by returning to the tracking position. Maybe this is a side-effect of the pseudo-tracking code in the driver, I didn't have the time to investigate further.