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.

>>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.

I observed exact the same, but i am not sure if Jasem wanted it do be so to correct only once (to compensate the offset change caused by the time between image and platesolve).

EDIT:

>>Note: I sent a long-winded e-mail off to SkyWatcher

Thats very cool, thank you, but i dont think thy will support us. But who knows...

Yes I noted the same. I think we cannot rely on the encoders once tracking starts. Maybe a different approach is this:
1. Use encoders when performing GOTO/SYNC only.
2. Once tracking starts, adjust speed from the expected AZ/AT position while completely disregarding the encoder values.

The trick is find out the required tracking speeds for different positions in the sky. We can start with standard values and then adjust with zenith angle.

On the stargazerslounge forum is an interesting discussion on: Alt-azimuth tracking speed formula?

I think the problem is in the "alignment subsystem".

For mounts using hand controllers, 1-3 points are explicitly aligned and coordinates are calculated and remapped. but The alignment subsystem has no place to check the alignment points, no place to check the results of the alignment calculations, so it has no idea how the remapping is done. (BlackBOX...And the default is "append" to the coordinates)

When I operate it, I feel that the coordinates are not updated properly in the alignment subsystem at present.(If the coordinates are distorted, the tracking calculated from the coordinates will also be out of order.)

When you get a lot of Sync, the problem will be more noticeable. (GOTO (Slew) stops halfway, suddenly jumps to a different location on the map, etc.)

It would be easier to understand the cause of the trouble if at least the items that display "alignment points in use" and "coordinates updated by alignment" are added.
(I think all drivers that use alignment subsystems have the same problem, but if you're shooting on an equatorial mount, you just don't notice it because it's auto-guiding.)

Judging from the current behavior, it seems that the peripheral position information is calculated when adding the alignment points, but it doesn't seem to do the all-sky remapping based on the calculation.

Originally, the more alignment points, the more accurate the coordinates should be, but the current situation is the opposite.

I need to add items to display the registered alignment points and calculated coordinates, and add the appropriate references to the alignment (I don't know which item in the control panel affects how it works)

The current workaround is to correctly level the mount, orient it exactly "North", and don't use "Sync" on PlateSolving. (It tracks with the default coordinates.)

@Thomas Stibor - thanks for the link. On that particular forum, they had an excellent paper which I downloaded regarding the mathematical model of a telescope control system. I believe the indicom.c and indicom.h files are the indi equivalent to the sidereal tracking calculations as described in the paper. We should (of course) largely disregard the de-rotation equations for the tracking effort mentioned in the paper. Although I do plan on getting a de-rotator when I can center an object and track it without drift!

@T-Studio - The tracking problems do seem to be pointing at an alignment issue somewhere. After studying the paper, as well as doing more research, I believe with a proper alignment point(s), resultant mapping of the sky, and Jasem's tracking rate adjustment loop we should be able to track a star. I now do not believe special tracking rates for different positions in the sky (i.e. map) are necessary as this should be covered by the sidereal tracking equations if a proper alignment model is present with Jasem's tracking rate adjustment loop.

I can attest to the issue you've experienced with half-way GOTOs when using multiple plate solve syncs. I've also ran into issues where the scope won't slew to reduce the solution error on an object after multiple syncs have been performed. I was planning on holding off mentioning the plate solving issues until after the tracking issue had been solved, but it's starting to look like an alignment issue.

It's not an alignment issue. Tracking speed has nothing to do with alignment accuracy, except perhaps for calculating the rate of change at a particular position in the sky. This driver works OK when tested on my 16" Orion Dobsonian, the tracking was actually better than AZ-GTi from what I recall.