Thank you for the testing. The "tracking goes crazy" issue is confirmed by all of us. @gubi, can you send a PR for the fix? I'll fix the inverted speed issue now.

@krno,

My fix for the "move while tracking" issue has already been merged into the trunk a while ago, it was PR #1184.

It has introduced a new priate class variable "moving", set by MoveNS() ans MoveWE(), and checked in every TimerHit() call, setting the CurrentTrackingTarget to the actual position of the scope, effectively disabling tracking while turning.

You can most easily check it's effect indoors, just connect the mount to indi, start tracking and with the mount control tab you can turn the mount. You will see the crosshair moving in Kstars at every TimerHit() period (every seconds by default). When you release the mount control button, the mount will carry on slewing for a short while, and the tracking code will move bask the mount to the position it was at the time (according to the driver, shown in Kstars) at the time you released the button, causing a small backslash.

For realy small adjustments (shorter than a second duration) it seems as ineffective since the tracking reverses some or all of the slew. But for larger slews it is not so confusing.

It definitelly needs improvements. What I can think of now is introducing one more state, at release of the "move" button it could go to a "post move" state, and go back tracking after one more timer period, reading the scope actual position one more time. I will experiment with that soon.
But I'm pretty sure, that Jon's problem (the mount going crazy) was not caused by "tracking and moving fight", but some other (at the moment unknown) issue. I have also found that sometimes the mount just goes crazy, without any consistent (repeatable) reason. That is a big issue.

I'm thinking about creating a documentation discussing the several methods of connecting the scope to INDI.
I mean, synscan app, hand controller, direct cable, directly to the motor controller via UDP, via Synscan app and TCP.
That seems to cause endless confusion in newcomers (and caused one for me!). This is some kind of "meta" documentation page, linking into the actual driver documentation pages.

Gubi,

Thank you for the work on the mount control. I pretty much move by plate solve and goto now, so I have no other way to tweak the positioning.

I agree that the mount control is not the only cause for "unscheduled movement" in the scope. However, I have not seen the issue since I have taken care to begin my session from Park and slew counterclockwise (West), even when my intended target is East and clockwise would be the shortest slew. I do recall clearly the last problem I had was slewing clockwise and then experiencing issues around the 180 degree mark when crossing back and forth over 180 degrees.

I have already written a connectivity section into my documentation, but would appreciate your input. I hope to have a version ready for critique after this weekend.

Latest testing with the skywatcherAltAzMount driver has gone mostly very well. (I tore my cornea Tuesday, so have been a bit out of service...better now.) The latest version works very well in general. However there are still a few oddities:
-- Guiding can work very well at times. I shot an hour of images with a total RMS of .72, but then I tried another target in the same area of sky and due to occasional instability, an RMS of 5.6 over 10 minutes. No visible root cause.
-- On occasion, the second (and subsequent) plate solve will yield a "Sync failure." This results in multiple iterations of Capture/Solve/Slew, each ending in "Sync failure" and eventually too many retries. This behavior does not occur on the initial slew to a new target, but is nearly guaranteed if you attempt to GOTO a target you have been tracking. For instance, a target that has slipped from center during the guiding calibrations and requires a re-center. I suspect it has something to do with code checking a "tracking" flag.

Knro: I will be back on documentation shortly.

Gubi,

The documentation (first draft) for the Alt/Az Mount driver is now posted on the site. When you have time, please look at it and let me know about any changes you think may be needed. I especially would like to know about changes to the "Connectiivity" section, as you expressed an interest in that. I would be pleased to make any changes you suggest.

I have a question on the mount software on another matter. Since you plate-solve, have you noticed that sometimes the alignment module will slew to a target and seem to get stuck in a mode where it cannot sync (Syncing Failed), so it continues to retry and fails to sync over and over as the target drifts slowly away? It seems only to do this on occasion, and it seems clear that the error is generated in the alignment module, rather than the mount driver. There is no code in the mount driver relating to throwing a sync failure that I have found.

Guiding works quite a bit better since the last round of changes. The target stays within the green circle in Ekos Guiding, though it still hops around a lot within the circle. In PHD2, there remains a sine wave pattern, indicating over-corrections and corrections to the over-corrections. I have tried making changes to the values exposed by Ekos and PHD2 without significant result. Still, it is now possible to take a 30 minute session of 10 second exposures, though you will have to dispose of about 1/3 of them for motion due to the aggressive corrections. The good news is that the target stays very much locked for a very long time. The only exception is expected image rotation, for which there is no software cure on an Alt/Az mount.

I maybe missing something, but where can I find this draft?

I don't fully understand the intended working of the sync TAB in EKOS, but there are three choises: "sync to target", "slew to target" and "do nothing".
I think "sync to target" should tell the driver where the scope is actually pointing, and the driver should update it's position so that the crosshair points to the newly learnt position and keep tracking that position.
In my understanding the "slew to target" should do the same, but affter that it should issue a goto to the original target.

The "AltAzSimple" driver behaves something like that. But the APIMount driver does not. After a "sync to target", it updates it's internal knowledge about the scope actual position but leaves the tracking target at the original position so the tracking code feels a tracking error and corrects. Effectively getting the same result as the "slew to target".
I have come to the conlusion that the difference lies in that the APIMount driver keeps the tracking target in Ra/Dec coordinates but the Simple driver keeps it in AltAz coordinates. At sync operation the Ra/Dec coordinates of the scope gets updated, but the AltAz coordinates remains the same (the sync operation updates the Alt/Az -> Ra/Dec mapping), so the driver keeps tracking the same point.

To answer to your question: sometimes plate solving fails for me without any real good reason (there seems to be enough stars on the taken image, the actual target is close enough, no good reason), sometimes later (maybe after moving the scope a bit) the plate solve just succeds.Also sometimes I got the error (after succesfull solve) "sync failed". I have no idea about the reason. Seems random to me, but maybe I just dont see something.

I have no real success with guiding. I have succeeded the calibration a few times (most often than not, just calibration fails). But after start tracking it tracks very rudely, much worse than without tracking. I have given a try to PHD but no success. After calibration it has strated tracking but it just diverged instead of tracking.
So I do multi-hundreds of short (10 sec or so) expos by splitting it apart, say 50 picture at a time, the re-center the target and shoot an other 50. When it drifts so much that the target drifts away in 50 shots, the individual pictures will be bad qualtiy (due to poor tracking) anyway. And as you said, image rotation is inevitable for AltAz mount so one must have enough headroom on picture framing anyways.

Gubi,

The documentation has been published, so changes will go live pretty much immediately: indilib.org/telescopes/skywatcher/skywat...lt-az-dobsonian.html

My understanding of SYNC and SLEW TO TARGET matches yours. My concern comes from a search of the code to find where the "Sync Failed" message is thrown. It comes from align.cpp and not the driver. Further, there is a notation in the alignment code that indicates handling of Sync has previously been an issue.

In the case with which I am concerned, the plate solve succeeds and outputs to the log the correct coordinates. This is followed by the Syncing Failed message and generates a retry. By now, tracking being off (or perhaps on, I am not certain about this), the target has drifted a few more arcseconds. So, the new image is a bit further away from the target. The retry solves, but "Syncing Failed" repeats and the cycle continues until the retry limit is reached.

I have also seen the issue where something does not solve for no good reason. That is a different issue and may be due to photo quality. When that happens to me, I typically bump the bin up a notch and retry. Then it typically solves.

If you have not tried guiding lately, you should retry. The latest changes made to the driver made a great difference. I did a great deal of testing using the Guiding Simulator driver as a CCD to get my head wrapped around the process during daytime. Guiding really does make a difference. I would try the internal guider first, as it calibrates faster, which for me is less frustrating upon failure. I believe the guiding is very close now to being of great value, if one can just find the right spot to tweak. I have taken as many as 500 shots at 10 seconds with the image remaining centered. Granted, there is a high number of throw-away images due to overly-aggressive adjustments.

A question comes to mind: Do you know if the slew rate impacts guiding at all?

There may be another evil at work in the mix with our scopes as well. I am not convinced that some of the "Freedom Find" or Dual Encoder Technology or SoftPEC isn't getting involved at some level. Too many cooks in the soup! I may try turning some of that stuff off.

Oh, I see there are 6 different driver documentation for skywathcer mounts. I think here is due some consolidation.
At least your "SkyWatcher Alt/Az (Dobsonian) " and "Skywatcher Virtuoso (Alt/Az)" documentatin should be merged, as these are about exactly the same driver. I think only the softPEC portion of the Virtuoso documentation should be kept, as these is the only extra information there.

The "Connection" section needs some improvements. It is too complicated, and sometimes technically not so precise. For ex: the cable is not FTDI-to-USB, it is TTL serial-to-USB. FTDI is a maker of one type of such chipset, but there are others too. The device file /dev/ttyUSB0 does not identify the USB port, it identifies the device (cable with converter chip in it in this case). It is not change if you plug the cable into a different USB port. It changes if you pull and plug other Serial-to-USB cables, as these are (by default) numbered in the order enumerated by the kernel. But if you have only one such device (one cable connected) it will always /dev/ttyUSB0, unles some error occure and some yet.-non-existent device stuck in the mind of the kernel. Also there are methods to lock the device name to a particular cable (by serial number), but these is clearly out of the scope of this documentation.
Actually the connection needed for our driver is exactly the same as the eqmod driver, so we can take merit from the eqmod documentation. For example there the cable needed is named "EQDirect cable", we should stick whit that.
Also you menion that one can connect through the handcontroller, but you does not mention that is must be done in "PC direct" mode. It is important, otherwise it will not work.

I will try to come up some replacement text suggestion, just need a bit of time for that.

I think trackin should be ON during plate solving. Otherwise how can you utilize the result? The solve tells you where the mount was pointing at the time of the picture taken. But not any more...

I have tried guiding recently (on 26 dec, I think). I don't think anything has changed in the code that involves guiding. Jasem explicitly said: "the guiding code is a mess, leaving for an other time". Has that other time arrived yet?
I don't think slew rate impacts guiding. In my understanding these are totally different things.

I have just realized what SoftPEC is, it is disabled in my setup, I will try to experiment with that.

Also the network connectivity is vrey well documented on the AzGTi driver's page. Everything written there also applyes here. So mybe we should just link to there.

There are a lots of things (like site management or motion control) that is documented on many driver page, which are the same, as these are the services of the indi_telescope base class. Maybe these should be collected to a central document, and every driver should just link to that.

Gubi,

Thank you for your feedback. I'll begin making revisions and incorporate your changes when you have them ready.

The USB port numbering issue was and is a mess. I have machines that will not clear an assigned port number without a reboot. I also have machines that behave as you describe. Perhaps a "less is more" approach is in order. Explain that they need to match the port and leave the how to the specific support group for particular hardware/OS...in other words, beyond our scope.

My guiding results improved after Jasem's last update. I am speaking stricktly of RMS numbers. I went from 1.5-2.9 RMS to 0.4-0.85 after the latest change. Now most of the tracking dots stay within the green circle However, I cannot say how old the driver was that gave me the high RMS results. It may have been a month or two old, and a lot has been done to the driver of late.

I don't think Jasem directly addressed guiding, but any adjustment to pointing also impacts guiding. I seem to recall formulae in the code that added or subtracted guide values from the motion control values. It would seem that improving the tracking or motion control might also improve the guiding.

And yes, softPEC probably has a role as well, but the Skywatcher 250P scopes have softPEC integrated into the motor controller. I wonder if there would be a conflict if one enabled the version that is commented out in the skywatcherAltAzMount driver. I think there is enough difference between the Virtuoso and other Dob/Alt/Az Skywatcher mounts to keep them separate. Otherwise, the final instruction page will become a monster with "if this mount...do this...if that mount...do that" sections.

Question: Do you know of the Ekos simulated hand control has been fixed? And if not, can you recommend a joystick control. Trying to move the scope with Indi Control Panel is tedious.