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.

Hi Michael,

thank you for taking time to explain.

So its not a tracking rate, but it defines if the steps the motor does for way it has to move -> why dont we simply change that value with a multiplier. So if the motor thinks i have to move x steps per degree (hardcoded and sometimes wrong) to keep up with the star with an offset zero -> why dont we say "motor you only need x * 0.99 steps per arcsecond" and the 0.99 is set by a value in the settings for both axes? Couldnt we then test the theory?

But isn't that the purpose of the tracking factor?

No, in my understanding with a faster tracking factor or rate the offset increases. We need something with speeds up (or slows down) without changing offset or am i wrong?

When Jasem's new tracking offsets are used, you will be inherently changing the offset difference between the setpoint and the measurement which will in turn slow down or speed up the tracking speed for that axis as compared to what it would have been if no offsets were used. With that being said, I believe Jasem mentioned that the offsets are being applied in the background, so the log files for the offset error wouldn't increase, but I'll verify tonight when I test.

Note: I sent a long-winded e-mail off to SkyWatcher to see if they could provide some input on their methodology (Synscan's one/two-point star alignments) for comparison.

I downloaded and tested the latest git from indi.

What I tested in the tracking tab:
AZ offset: values ranging from -1000 to 1000
ALT offset: values ranging from -1000 to 1000
Julian day offset (JD): all values allowed from -5 to 5
Clock % for both axes: various values from 0 to 200%.

These values were all tested independently (i.e. no two parameters were tested in parallel. For instance, only ALT/AZ offsets were tested and the other parameters above were set to zero. Likewise for the other Julian day offset and clock%).

With tracking on and ONLY the default PID settings in place, stars drifted to the north west. I used the loop feature on the camera to take a photo every second to observe the star movement.

What I found after adjusting the values stated above:
The values would affect the drift of the stars for one or two iterations and then the drift would resume at the same rate and the same direction to the north west. it's as if the changes are only being applied for the first poll and then are not applied again.

Let me know if anyone else observes the same.