I am using an AZ-GTI in AZ mode and am experiencing the same tracking problems which are described here.
I have not found a solution to the problem, but I have found a workaround that helps to get stable tracking and which may help to visualise the effects of the problem.

I use the AZ-GTI with the "SkyWatcher Alt-Az WiFi" driver in "AZ-GTI station mode to home WiFi". So the AZ-GTI mount, the Raspberry PI with Stellar Mate, the SynScan Pro app on an Android smartphone and a PC are all connected to my home WiFi.
It is possible to connect to the AZ-GTI mount from Stellar Mate and the SynScan Pro app in parallel. This means you can control the mount from the app or from Stellar Mate without having to switch between the two. Of course you should not use both at the same time.

So my workaround for successful tracking is
1. Position the mount with the telescope facing north and parallel to the ground
2. Start Ekos
3. Open the SynScan app and connect to the AZ-GTI mount
4. "Goto" the desired object via Ekos
5. Alignment "Capture & Solve" via Ekos
6. Stop the tracking in Ekos
7. Start the tracking in the SynScan App

Now you can use Stellar Mate as usual but with deactivated tracking because the SynScan app takes care of it. Just be sure not to use both tracking methods at the same time.

Beside this workaround I have found a good method to visualise the problems with the Stellar Mate tracking algorithm. You can connect the SynScan app to the Stellarium software. This allows you to see the movement of the mount when using either method of tracking. In Stellarium you can see the position of the mount as it is projected onto virtual sky. There may be a difference in the absolute position of the mount, because the SynScan app doesn't know about any previous plate-solving corrections. But the interesting part is the relative movement of the telescope position when using one of the two different tracking methods.
The Stellar Mate tracking method shows much more fluctuating movement than the SynScan App tracking method.

Perhaps this will help to visualise some of the effects of the different tracking methods.
The good thing is that you can simulate this behaviour without the need of a night sky.

Thank you Michael & Martin for your feedback and analysis. I think one idea to try to get to the bottom of this issue is to run this experiment:

1. Pick a specific target + specific time of day.
2. Track it with INDI for 60 seconds and record all logs.
3. Track it with synscan app for 60 seconds and record all logs from Wireshark.
4. Decode wireshark logs to the Skywatcher command packets.
5. Compare the two to find any clues. Perhaps try to model what the App is doing, is it PID or something simpler?

#3 and #4 are the challenging parts.

Hey guys,

hello Martin, thank you very much for your suggestion. I'll test the procedure like this.
Michael, its interresting that the numbers speak others than my experience on the target. Just for protocol in one second i had 10 packets to the scope und 10 back -> so i think 100ms would be the synscan polling frequence.
One thing i do not realy unterstand is: we are always hunting for the zero-error. So if i unterstand you right, if we pending near around zero = no drift?
But on that magic moments, when ekos simply tracks fine, it is the exact same PID with same settings - and i see also errors in the logs. i have the feeling everything (tracking, correction etc) is just happening in the right speed.

Yesterday i operated the mount with just Synscan to take a few pictures on M16.

I had to admit that the glorified tracking of the Synscan app also had a drift. It's a lot lower, but I couldn't expose images for more than 12 seconds. i did a few point-on-alignments (edit: without initial alignment reset, my bad) and the drift was always direction down left.
Than i restarted all devices and switched to ekos and the much faster drift was back - up-right. Right the opposite direction, you could draw a line.

In the advanced settings in Synscan is a point called "speed compensation" in ppm

the manual says:

"Speed Compensation (in Settings > Advanced) is useful for correcting tracking speed error caused by inaccurate rate of mount’s internal clock. Typically, such error would be in the order of a few ppm (parts per million)."

So just as a suggestion -> is the PID tracking just fine or as good as the synscan and perhaps we just should make the clock go a little faster or slower depending on the target?

Or is one of the many settings Jasem implemented already this kind of correction?

Regards,
Mat

Thank you, Mat, Martin, and Jasem.

Mat - you are probably correct that the synscan protocol may be polling at 100ms.

One thing i do not realy unterstand is: we are always hunting for the zero-error. So if i unterstand you right, if we pending near around zero = no drift?- to get the advertised resolution (2 arcseconds), I'd say reducing the error to 4 microsteps minimum would be preferred. To add to this, it's not just the average error but also how much it deviates which I tried to convey in the data via the standard deviation.

But on that magic moments, when ekos simply tracks fine, it is the exact same PID with same settings - and i see also errors in the logs. i have the feeling everything (tracking, correction etc) is just happening in the right speed. -yes, this is what we need to understand. I think we need to readback the T1 interrupt which Jasem is setting in the code. Currently, we set it, but we do not read it back to ensure the value is being set......see below.

So just as a suggestion -> is the PID tracking just fine or as good as the synscan and perhaps we just should make the clock go a little faster or slower depending on the target? Or is one of the many settings Jasem implemented already this kind of correction? - We can really only change the motion mode (low speed goto, low speed tracking, high speed tracking, low speed tracking) and the T1 interrupt according to the command set found (here) on page 4. As mentioned above, we currently are only setting the T1 interrupt and not reading it back. We could do this by adding a function to the skywatcherapi.h & .cpp files which would translate the command set header "i" (inquire step period). We can then add the function to the skywatcherapimount.cpp line 1235 to ensure T1 is being set the way we want via the debug log. You can also see on page 2, the equation for the T1 interrupt. We are missing a value for "N", however the PID loop doesn't care as it will eventually come to the solution. We could add the value of N, and it might solve a little quicker/be more steady up front.

I'm not sure if this will help or not with the wireshark tests, but I found a synscan app protocol which was released early in the year. It is here: SynScan App Protocol

One other question in regard to my post above: When we set the MotionMode as "1" in the code it's the low-speed slew mode. What if we set it as "3". Have we ever tried this? (see modes at skywatcherAPI.h line 268).

Thank you, Michael, for your explanations and answers in your first post!!!

So i changed local in skywatcherAPIMount.cpp in line 1246 ( SetAxisMotionMode(AXIS1, '1', Direction); ) and 1303 the one with a three (hope that was right) an made a rebuilt. But no difference in tracking - error around zero and the star had a drift to the right side.

Regards,
Mat

and to make the puzzle even more mysterious: here a nearly perfekt 45 sek exposure from star Al Giedi (3.4 mag) with the pi HQ cam with 76/420 scope made with EKOS tracking.

I slewed to the target and had drift - i was frustrated and mounted a weight on the front of the telescope (150gr) - my 16 second loop became super sharp. At first i thought the weight could be the solution, but when I removed the weight the drift didnt came back. then I took this 45 second exposure (without the weight).

i slewed back to M16 and the drift was there again... i dont know...

Thanks for that information, Mat, and for testing the alternate motion mode.


I've had no luck with clouds....

Thank you for all the effort you put into this topic.

I am sorry if this is already known information: I have found a document called "Manual: Sky-Watcher Motor Controller Command Set" at skywatcher.com with some information about a motion mode they call "Speed(Tracking) Mode" as it is implemented in the controller command set.

You can find the PDF document in the second entry on this page:
www.skywatcher.com/download/manual/application-development/

Is this already known?

Jasem definitely probably knew this before yesterday. I had posted the same document yesterday in the post discussing the T1 interrupt and the motionmode.

The PID loop which Jasem and others have contributed to determines what they are calling "Speed_DegPerSec " in the the equation for the T1.

The TMR_Freq is always 16 Mhz.

CPR is always (1.6 microsteps/arcsecond * 360 degrees/rev * 3600 arcseconds/degree) = 2,073,600 microsteps/rev.

It is called the T1 step period as the dimensions ultimately become 1/microsteps.

Keep exploring. The more eyes we get on this the better chance we have of figuring it out.

I tested at 100 ms with no deadband.

I noticed something in the data. There appears to be a 5 second delay in the log file where the spikes in error are occurring. I went back to the other data files I submitted a few days ago, and it appears to be a similar situation for those as well. I also went back to the data from March and before the spike a 5 second gap exists (when a spike occurred, that is).

I did a conditional formatting of column J on the attached files. Look at the rows approximately where the large spikes occur on the graph and you'll see that instead of 100ms between the time increment you'll see 5 seconds right before the spike.

The question is: What is happening? Is the program freezing up resulting in tracking to turn off?

It appears to be freezing and not an bad encoder. My reasoning is twofold: 1. both axes are affected. 2. You can multiply the time difference before the spike (~5 seconds) by the prior tracking rate, and add this to the measurement before the spike. It will sum to the measurement at the spike which implies that if the tracking would have continued (not stopped or skipped) the error would have stayed low.

Thanks,
Michael

Hey Michael,

thank you for your efforts. So in easy words for me: you say in your logs are sometimes delays where no speed-correction happens. But the delay is not corrected afterwards and so it can happen that the scope runs too fast for a while (during the pause) but after the pause it still thinks it "only" has an error of, for example, 1 or 2, even though it has drifted away further?

i will run an indoor test and check my logs at 100ms. I don't think I've ever checked whether 10 queries per second actually take place at 100ms polling.

Regards
Mat