And would a field to fine tune the 1.6 perhaps be a simple solution?

There exists a new GPL-3 project called ASCOM Synta protocol driver for SkyWatcher and Orion telescope mountsASCOM Synta protocol driver for SkyWatcher and Orion telescope mounts
written in C# for Windows. However, as the code is under GPL-3 license one could try to study the code to explore how the author solved the AZ tracking for AZ-GTI.
So far I can see, the server supports

Probably the following code line could help solving the problem:
ConvertRateToAltAz

Thank you Thomas. How would this solve the encoder issue? You can set a custom tracking rate, but then the encoder values would reflect different Alt/Az (and therefore different RA/DE) and it would look like it's moving to a different target. You understand what I mean?

>>>Another quite complicated solution is to solve at two different positions in the sky and then calculate the actual microsteps/arcsecs range. Currently, it's hard-coded to 1.6 microsteps/arcsec, but I think this is actually variable across different positions in the sky for the AZ-GTI. Theoretically, you can build a map of different encoder <---> arcsecs conversion rates at different locations in the sky

But would it be complicated to make a manual tuning for the value? I think it is not too much to ask the user to fine-tune a value after the slew to a new target. I would love to do that every time, if it compensates the drift a bit. So in my understanding this would (figuratively) slow down or speed up the sky what perhaps is exactly what we need? Would love to test!

Jasem I think you are right, somehow this would result in different RA/DE. I will study the C# code in more detail and see what I understand.

Are all the problems described here only az mode related or is eq mode also problematic with this mount?

Peter,

I've tried mine in both modes and it's always West of where it should be. So the RA motor in EQ mode is too fast and in AZ mode the AZ motor (Same motor) is also too fast. In EQ mode this results in a fight between the Guide Camera and the mount. As a result the guide images need to be kept on a short interval, around 1 to 1.5 seconds to keep the mount in check.

I still think it's a mechanical problem as I said in my first post. The mount is not designed for astrophotography as stated by Skywatcher themselves. Varying tolerances on the mount's components may result in some mounts being better than others at tracking.

Thanks

Alan

I'm not entirely sure if the mechanics are the only problem. Enormous progress has already been made with the software adjustments in this thread.
I think we agree that we are not dealing with a highly precise device here. However, sometimes it runs very precisely and sometimes it is too fast or too slow, but then it is also stable at the wrong speed.
I believe that a basic slow down and speed up, as jasem mentioned, could possibly be the solution. Not as an automated solution, of course, but when the drift occurs, as a solution to compensate for it.
I did quite well with the manual selection last night, but unfortunately it is very hard work to find out the values ​​manually and takes many attempts. Therefore a general speedup/slow down might be a solution.

Regards

Add to latest post: In my manual test i corected with PID to zero, than took that values as basis for my manual setting and catched the star quite well with the manual value setting and the error value in the logs kept steadily increasing on and on. So the "model" (dont know how to call it) was to slow and i had to speed it up a bit.

Just an update from me:

I tested the "old" version last night in the field (that is, without the latest offsets and only the PID configuration settings). I felt like I should verify Jasem's observations for testing purposes. The PID, as Jasem mentioned, worked excellent and quickly resolved the error to ~0. Despite the error, I still obtained star trails with tracking on. The stars were moving in the north west corner of the screen. With tracking off, the star trails were longer in the same direction (1.1 cm in length versus 1.7 cm in length).

I should have clear skies tonight and will download the new version today for testing. One major potential issue I see with manual offsets is longer shooting sessions (over night with short exposures) will require adjustment as the scope tracks the object throughout the night. There's no way to overcome this without defining a discrete point (or points) in the sky and mapping the offsets relative the AL/AZ telescope coordinates as Jasem mentioned. This is probably why skywatcher requires a north star alignment or two star alignment for the Alt-Az scopes when using synscan; not only for the GOTO functionality but for tracking. I'm going to e-mail skywatcher and see if I can get any feedback. Perhaps if we could get their offsets/tracking rates/equation for their "map", we could combine this with a short exposure platesolve (to determine the initial AL/AZ telescope direction for the mappings) and the process be automated.

Hi Michael,

>> Perhaps if we could get their offsets/tracking rates/equation for their "map",

tank you for the update. But am i right, that at the moment we dont have a manual value for that? That would be the tuning of the 1.6?

Regards

The 1.6 microsteps/arc second is calculated from the total number of microsteps per revolution. That is, 2073600 microsteps / 360 (deg/rev) = 5760 microsteps/degree. Converting from degrees to microsteps in the denominator you get..... 5760 [microsteps/degree] / 3600 arc-seconds/degree = 1.6 microsteps/arc-second.

This value is used to convert the alt/az coordinates from the TDV to an encoder value. This conversion is defined in the skywatcherAPI.cpp files (line 221) and is used in the skywatcherMountAPI.cpp (lines 527 & 529). It is not a tracking rate, rather the definition needed to define the encoder value when converting from a "coordinate". Currently, these coordinates are defined "locally" and are not "true" global coordinates. This is currently why a platesolve is unnecessary for tracking. However, if we wanted to do things right, we'd need to define at least one coordinate with a platesolve and develop a map with offsets for different AZ/ALT in the sky.