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.
This image of Jupiter is much better than I have ever got!
But I don't understand, do you really expo Jupiter for 4 secs? I use 15 ms expoes for Jupiter.
Plate solving is not difficult, Jasem has great tutorials about that:
Just be sure to set your telescope focal length of your scope.
The basic principle is that it tells the driver where the scope is pointing at, updating it's coordinates in the driver. Of course that mean that the crosshair also updated in Kstars. But it actuially updates the driver. Essentially the same operation you yuse for SYNC. After that what happens in the AltAzMount driver is that as it is tracking and now knows it is not pointing to the target, it will slew to the target (center Vega). As the AltAzSimple driver stores the Alt/Az coordinates of the target, it will not slew automatically after solving, but you will see in Kstars that it is not exactly targeted, and you can issue an other GOTO to your target, which will now be much more accurate.
I tried using indi_skywatcherAltAz mount last evening, but "crashed and burned" (pilot-speak for failure). It drove the scope smoothly, but I couldn't hit a target on GOTO...close, but not close enough. Also, it wouldn't hold a target. Drift made it impossible to use. Sync seemed to have no effect. I get a feeling that using it with a guide scope, constantly correcting and holding position, is the ticket.
This may sound odd, but highly appropriate: We got frustrated and decided to use the Tablet with Synscan. In a navigation error (heading for the wrong fuzzy gray area after a near miss GOTO) trying for the Angelfish Cluster, we ended up at the "Dumbbell Nebula." Perhaps that is the default. If one fails to operate the scope properly, one ends up at the dumbbell.
I did get some good shots of the dumbbell, however. A bit noisey, but I didn't take time to process properly.
What you need is plate solving, I think!
That makes the difference to using just Synscan.
One more good news: one more improvement have been made to the drivers: joystick support has been fixed. So now you can use a joystick (or rather an USB gamepad) instead of the "hand controller simulator" on screen.
I even use it for eyepeace observing, it is nice just panning around the sky. In order to know what I see, i put the camera on the finder scope, and use plate solving with that!
Then connect SkySafary on my phone to INDI and pan with gamepad and I can see on SkySafary what I am looking at.
I'm still having problems. I did install a guide scope, but last evening, when I was try to align it, the indi_skywatcherAltAzMount driver would just stop working. It always went like this:
1. Goto target (close but no cigar).
2. Use either "hand controller simulator" or Indi Control Panel->Motion Control North/SouthEastWest to try and center the target.
3. Two or three adjustments and it just stops moving the scope. The only cure was a complete powerdown and restart. I had to go back to the indi_skywatcherAltAzSimple to complete my guider alignment.
Note that this was a fresh compile from a git yesterday morning running on the new 64 bit Raspberry Pi OS on a Pi4 aarch64. Last time, I was using Ubuntu Server aarch64 20.04, and didn't have this particular problem. But there were no errors in the compile. I also tried to get PHD2 to connect and the only INDI driver it liked was the indi_synscan_telescope driver. It "couldn't see" the other two drivers during the connect routine. Ekos, can, though.
I plan to try either Ekos or PHD2 plate solving as soon as I can get things stable again. While indi_skywatcherAltAzSimple has never given me any operational issues, its tracking is too wobbly for photos.
In the indi_skywatcherAltAzMount driver the guiding code is disabled, the comment says: " TODO: Hide the auto-guide support now because it is not production-ready" which I don't understand since the whole driver is "not production-ready".
Yopu can enable it for yourself, by removing the comment sign from this two lines:
// Guiding support
// TODO: Hide the auto-guide support now because it is not production-ready
// initGuiderProperties(getDeviceName(), GUIDE_TAB);
// setDriverInterface(getDriverInterface() | GUIDER_INTERFACE);
It is at the end of SkywatcherAPIMount::initProperties() function, around line 460.
I have only tried EKOS internal guiding, not PHD2 yet.
In my experience there are some parts of the sky that this driver somehow does not like, and the scope mark is just jumps away. Other parts of the sky works. I do not understand.
The indi_skywatcherAltAzSimple driver is a fork from the indi_skywatcherAltAzMount driver, removing most of the complicated parts of the code, completely replacing the tracking code. I don't know why and when it happened. I'm new to INDI.
Unfortunately the way it does tracking is completely unsuitable for photos, since as you say, too wobbly. It is maybe working for wide field photos with DSLR only, but not with big scope.
Maybe sometime I will try to take the best part of both driver and make a 3rd one from them. But it is not the good direction, since we have too many drivers, not too few. So now I concentrate on fixing the existing one.
I agree, best to repair one that nearly works than to "Frankenstein" a new one from bits and pieces of others. I wish I could be of some help. I can, and will of course, make the changes you suggest and recompile and test, but my abilities with C or C++ are very limited. I could probably emulate the driver in Java or even assembler, but that would be worse than useless.
Is there some way to do more logging to perhaps find what indi_skywatcherAltAzMount is locking up? And yes, I have see that business where it starts a severe drift at certain targets.."parts of the sky." I think the two things that I find most annoying are having to restart when it gives up moving the scope and when you Sync and it goes into that "drift into oblivion" mode that only another Goto can cure.
Trying again tonight....no PHD2, and maybe Ekos plate solving.