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

I checked my logs:

In the Log-Files we have a date stamp: [2023-09-13T08:08:10.086 CEST DEBG ]

And the .086 are hundreds of a second, right? So at 100ms polling the second goes from 08:08.10.000 to 08:08:10.999 and roughly 10 queries should take place within this period.

For example:
From [2023-09-13T08:08:08.085 CEST DEBG ] to [2023-09-13T08:08:08.117 CEST DEBG ] i have four (EDIT: pair of) "setpoints" in this period and than the next second starts.
Goes from [2023-09-13T08:08:09.087 CEST DEBG ] to [2023-09-13T08:08:09.123 CEST WARN ] with six (EDIT: pair of) "setpoints".

Is that because of delay and network stuff and normal or why are all corrections within the first 150ms and than nothing happens? Or is here perhaps a "delay" from 0.800 ms where nothing happens?

Regards,
Mat

Mat - in regard to your first post, yes, that's exactly what appears to be happening. As far as your second post, you'd expect one setpoint per poll per axis. In my data, I did not see that particular issue. The reason may be that I only tested settings by turning tracking on/off once with the my settings (i.e. I didn't change settings during the 10 minute sessions). This could be a separate issue which we may need to explore.If you have 10 minutes, could you try the following indoors and send me the log file? I want to compare the data in the spreadsheet and see what exactly is happening. Just looking at the log file with many data points is difficult.1. Set the settings to default with 100 ms poll time. make sure tracking is off.2. Delete the log file for the session (it will re-appear).3. start tracking.4. track for ~ 10 minutes with no interruptions.5. stop tracking.6. end the session.7. provide the log file as an attachment.Two things we can conclude from this testing:- If we see the same issue in your log file as I have (spikes), then it is a common cause which we'll need to investigate further. - If we do not see multiple setpoints per poll period, we know there is probably an issue with settings being applied during the same session (i.e. changing of the poll time or other setting).Of course, anyone else may send data as well following the above procedure. This thread has nearly 19k views, so I know there are more people out there :)Thanks!

Hey Michael,

i edited my post. With "setpoints" i meant "pair of setpoints" so one for every axe (which is still too little).

Regards,
Mat