Most probably the AltAzMount identifies your mount as Virtuoso mount (as it does with my 10" Dob), and the driver expect Virtuoso mounts to be turned on pointing to the Polaris instead of horizontal/north. The AltAzSimple expects the mount to be horizontal/north at the time of connecting the driver.
So if you have connected the AltAzMount driver in a horizontal position (as one would do normally), that cause a big initial error in the mount model in the driver, which explains your inability to correct it with sync operations.
I see reason for both starting from pointing to the Polaris, and pointing horizontal. IMHO there should be an option for that somewhere for that, let the user choose. It does not sound too difficult to implement, maybe I will do that soon.
The AltAzMount driver has a built in procedure for unparking, only the original author of the driver knows why. There is an option on a "motion control" or "mount cotnrol" (I cant check now, as my mount is not with me now), where you can choose the unpark position (North, Shouth, etc...). The default is South, I have no idea, why. If you set that to North, the mount will not turn in azimuth after unpark. It will still raise in Alt, as far as I can tell, this is hard coded in the driver. What I do is I hit "abort motion" immediatelly after unpark, to stop this built in thing. Also there is an option, on the same panel for "silent"/"normal" slew mode. You can choose as you wish, silent mode is slow, normal mode is as fast as the mount can do.
The motor microstep per rew values are read from from the mount, it should be correct. It seems to be correct both for my little Virtuoso mount and the big Dobsonian one too. It is on the "Version" tab, i think.
OK, today I tried some of your suggestions with good success using the SkywatcherAltAzMount driver. I started the scope pointed at Polaris instead of horizontal/North and changed the Park Direction to North from the default South. Only two issues in indi:
1. The scope moves up quite a bit on unpark. No big deal, as it does the GOTO and tracking perfectly after that. I didn't measure how far up it goes, as it is merely an annoyance.
2. For some reason, the Site Management tab wants my Longitude to be 275:00:00 degrees (Kstars Geographic infomation is accurate and correct). The actual value for here is -85:00:00. I have tried changing it, and it stays for the session, but 275 occasionally reappears. I even edited the .xml on the indiserver Raspberry Pi4 that is running the scope, but 275 degrees still appears on startup. Oddly enough, it doesn't seem to affect Tracking or GOTO with the wrong value.
Neither of the above problems would stop me from using SkywatcherAltAzMount over SkywatcherAltAzSimple. Also, I experienced better GOTO accuracy.
The only other issue I noticed was with the Kstars Toggle-on Mount Control Panel. The buttons for left-right-up-down and all diagonals work fine. However, the GOTO heads left (display screenwise). I tried the checkbox for reverse on both axes with no change in the GOTO operation. Both the dropdown menu for focused object->SkywatcherAltAz->GOTO and Toolbar GOTO work correctly, so once again, this is merely an annoyance.
Thank you for all your hard work and assistance in this matter.....now....can you fix my weather? Raining like I need to call Noah here!!
The only reason I can imagine for slewing up the mount upon unpark is that after that one can immediately take a plate solve to sync the mount. It can be made a configurable option though. At least to know about that. For now, it is hard coded into the code.
Yep...lat 34.7, lon 275....land of clear skies and no light pollution. .....Drat! Now I have to go look that up and see where that really is.
Oh...wait a moment. My tiny little brain just kicked back into gear. 360 - 85 = 275. Could it be that this section has been coded to convert +/- 180 longitudes to a 360 positive value? Too much of a coincidence. If that is the case, a note on the entry screen explaining things would not hurt, especially since it gleefully allows one to replace the 275 with -85 without a single bark before turning it back into a positive number when you aren't looking.
Which driver are you using? Mount or Simple? Also, what scope/mount?
I seem to have better pointing accuracy with Simple (Wedge), but it seems a bit "jerky" on tracking. I played with some of the timing settings and it may have improved a bit.
The largest problem I still have with either driver is after it slews to an image and begins tracking. If it doesn't have the target centered, I have tried opening up the KStars [T] icon, that displays a hand unit simulation, then hitting the stop button (which apparently is for stopping the tracking), and then using the arrow keys to center the image. This is all well and good, but after centering the target, I can find no way to reactivate tracking. I have tried GOTO and SYNC on the simulated hand unit, SynScan GOTO and SYNC from the Kstars map right-click display and pressing the TRACK button in the indi control panel. No joy.
The only thing I have found that works is doing a quick GOTO to a nearby star, followed by a quick GOTO back to my target. This is tedious...it works, and tracking is re-enabled, but it isn't easy to do before the target becomes off-center once again.
My scope is a 10" dobsonian. The main difference between the two driver is that the simple uses small goto operations for tracking every timing cycle (which causes the mount noticeable shaking), while the other tries to program the motor driver to continuously mowing while tracking.
I don't think that one has better pointing accuracy than the other, since they are basically the same code base, and utilize the same alignment subsytem.
You should not hit the STOP button, sync the only way to re-initiate tracking is an other GOTO. I think this is the case with all drivers. Normally the EKOS hand controller pad should be able to move the mount while tracking, without stopping tracking. There is an issue with these two driver because it was permanently tracking, and taking back the scope to the original target time to time.
I have made a patch for both driver, and it has been merged into the master branch (about a week ago, I think), which tries to solve this, and modifies the tracking target while moving.
So recompile the drivers from github, and give a try to that. You should be able to move the mount while tracking, effectively modifying the tracking target. It is not dead precise, but better than none.
An other way could be if you have a camera on the mount, is plate solving and syncing the mount (driver) via EKOS alignment tab. That is working more or less.
I thought we had similar equipment. Mine is a SkyWacher 250P 10" Dob.
I spent a lot of time last night (we finally got clear skies) working with the scope with a fresh download/compile from Github. I initially tried to use indi_skywatcherAltAzMount, but its tracking seemed to drift quite a bit. I went back to indi_skywatcher_AltAzSimple and had good pointing results and reasonable tracking, but I had to play a bit with the timing and step rate to get it to be less jerky. I was able to shoot some images, but could not rely on an image capture longer than 4 seconds. I did notice that the arrow keys on the Kstars simulated hand controller worked without using the STOP, although I am convinced that -sometimes- hitting an arrow key turns tracking off.
My preference is using indi_skywatcherAltAzMount, so I probably should just stop using indi_skywatcherAltAzSimple. Are you getting good results with your scope with indi_skywatcherAltAzMount? If so, what do you think I may be doing incorrectly?
I setup using indi_skywatcherAltAzMount as follows:
* Point scope directly ad Polaris.
* Change the unpark to point North (it keeps defaulting to South)
* Unpark (scope remains oriented North but slews up about 30-25 degrees.
* Select Center & Track from the right-click menu while mouse set on Polaris.
* Select Synscan->Goto from the same right-click menu
* Use the Kstars hand unit simulation [T] arrow keys to center the image
* Select Synscan->Sync from the right-click menu
-IF- this is stable, I pick another star, and repeat the process I used for Polaris
-IF- I manage to get Polaris and another star reasonably stable and tracking isn't drifting, I try a deep sky object. No good luck past this point with this driver.
I will say that my camera (SV305) has a VERY narrow FOV, so I am very sensitive to tracking drift and missing a slew to target by even a small amount.
That is pretty much the same, as mine. Just mine does not have a built in WiFi on the electronics. Too bad, because mine is pretty much new
Can you tell me what is Mount Code of yours? It is on the 'Detailed Mount Information' tab in the INDI control panel. Mine is 152.
I think what you are doing is correct. I bet you mean by Synscan->Sync (right menu) Skywatcher AltAz -> Sync. Since there is no synscan involved in this process (that was your goal, right?)
As far as I understand the Alignment subsystem, you can repeat the Sync operation with more stars, and this will improve the tracking accuracy. This is not the same as with the Synscan handcontroller, no "two star alignment" or "3 star alignment", this is "many star alignment".
I don't know the limit, but definitelly can be done more than twice.
Also it is a big advantage of using INDI that you don't need to do it "by hand", plate solving is a great thing!. Just put your camera on the scope from the beginning, and use the alignment tab from EKOS! You don't need to find any known star. Just point your scope pretty much anywhere with a Goto operation (I normally start with polaris). It will not point to polaris of course, but now do a 'Solve and Sync' operation and you have a starting sync. Now goto to an other star, and repeat. The great thing is that you never have to 'center a star' by hand. Plate solving works even when there is no bright star in the field of view.
About tracking accuracy: 4 sec exposures is just what I got, most of the time. You will not like what I say, but these drivers are not production ready, IMHO. I try to make it better, but I just understand too little of how it works yet. I get better results with the Synscan handcontroller, and the synscan INDI driver. That works quite smoothly.
Also the tracking accuracy is greatly depends on what part of the sky is the target. It is the worth just on the zenit, since the mount has to turn azimuth quite quickly. There is an effect with AltAz mount that the field of view is rotating during tracking, and it is an uneliminatable effect without eqatorial setup. It is the worst on the zenit, and much better on the lower southern part of the sky (the stars are just moving right, azimuth only). Sometimes I can go up until 16 secs, but pretty much that is the upper limit. No multi minutes exposures possible with an AltAz mount.
A few night ago I tried to image M57 and M27. I got much much better results with M27, I bet because it was at lower altitude. M57 was just above my head. I did it one after the other, with the same alignment.
Also keep in mind, that the backlash of the mount should always be considered. Always end your centering operation with 'Up' and 'Right' motion. Otherwise the mount will not start following immediately, just after the backlash amount has been rotated. Just the same with the Synscan handcontroller. This is the property of the mechanic, cannot be eliminated.
You are correct. My little mind gets confused with too many "S" words. I did mean Skywatcher and not SynScan. It certainly was my intent to never use Synscan again and I think you every time I use these drivers for that. I am also pleased to find that my exposure estimates are within the realm of expectations. The image of Jupiter, by the way, was last night's attempt. 300, 4 second subs stacked with Siril and finished with GIMP using the indi_skywatcherAltAzSimple driver. So, apparently, it can track effectively. The other image is my indi control panel motor detail. Apparently, we have different motors, if the numbers mean anything.
I really need to wrap my head around plate-solving as it applies to Kstars (that means I probably should actually READ the instructions). I understand the principle, but never have tried it. I am clear that it goes somewhere and can give you the coordinates or give them to Kstars, so now everyone knows there they are, but if the next GOTO, (to Vega, for example) doesn't end up at Vega =exactly= and you plate solve again, so everyone knows where they are, how do you get to Vega? I need to try it and see, I suppose.
Thank you once again for all your hard work on these drivers and your patience with my questions and concerns. I wish I could assist. I used to be a fair programmer in Java and even have written a fair number of motor and device controllers in assembly language, but I really am no good at all in C or C++. Never had a good reason to do more than just a few simple compiles in C.