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