What tools are you using to snoop that?

The tool is named wire shark.

Greetings, again. I hope everyone is doing well.

Not to sidetrack us from the wireshark data, but I wanted to see if this question got answered.

<strong>A general question at line 1684 and below (resetTracking) in skywatcherAPIMount.cpp: why is AXIS_AZ and AXIS_ALT used inside the bracket instead of AXIS1 and AXIS2 in this instance (i.e. m_Controllers[AXIS_AZ].reset......... versus m_Controllers[AXIS1].reset).

Everywhere else in the code, AXIS1 and AXIS2 is used.</strong>

P.S. Mat, I had sent you a PM on Sept. 6th (was related to polling time testing, but beside the point now).

It makes no difference. Both have values 0 and 1 respectively.

I don't think that will lead to a solution because we simply don't know what the numbers mean. As Jasem said, we need a commented version.

Mat, per your question the other day in regard to if a faster polling time makes a difference. I ran three tests (10 ms, 250 ms, and 1000 ms polling times) at 10 minutes using the default settings of the PID in addition to setting the deadband to 7 for both axes. I tested this in the living room by turning tracking on and seeing how well the PID loop responded. The summary of results are below with data attached.

If you go back and look at the data provided a while back (file #5) when testing the PID loops, you'll see the average error for 1000 ms polling time were quite a bit better than the below. I believe this is due to the deadband, however another test without the deadband might be performed to see if I could replicate the results. What we see data-wise is way different than what we see visually. I'm going to try tonight with hopefully clear skies at 250 ms.

The results for 10 ms polling time:
Axis 1 average error: 1.17 microsteps
Axis 1 std deviation: 19.17 microsteps
Axis 2 average error: 0.28 microsteps
Axis 2 std deviation: 19.62 microsteps

The results for 250 ms polling time:
Axis 1 average error: 0.16 microsteps
Axis 1 std deviation: 2.26 microsteps
Axis 2 average error: -0.051 microsteps
Axis 2 std deviation: 3.99 microsteps

The results for 1000 ms time:
Axis 1 average error: -6.87 microsteps
Axis 1 std deviation: 11.35 microsteps
Axis 2 average error: -0.11 microsteps
Axis 2 std deviation: 11.11 microsteps

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