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

Hello, Jasem,

I attached Mat's data to the previous post. We're noticing a strange polling issue in the logs. The issue for Mat is inconsistent polling during 100ms as well as a spike similar to mine (except super big) with a 1 second delay before the spike. For me, my polling is consistent at 100ms except right before the data spikes. To help diagnose the issue, I propose the following.

1. In the skywatcherAPIMount.cpp file, add an if statement to cover us when the PID returns a "0" value for the tracking rate (Line 1227 & Line 1284). For instance, use the last non-zero value from the prior poll for the current poll and log the results. It may be necessary also to constrain the range of values the PID can use (i.e. instead of 50, -50, we use 1 to 50). This can be done anywhere we use the m_controllers function I believe, but whatever you think is best. Both options may have to be performed. Why this change is necessary: If you notice in the logs, almost all negative errors result in a tracking rate of "0".
2. Define a function which allows us to view the step period ("i") in the skywatcherAPI.h and skywatcher API.cpp files. Call the function after setting it as a variable for both axes (we can set it as a variable before as as TrackingRateReadBack or something to this effect.) in skywatcherAPIMount.cpp at line 1233 & 1290, respectively for axis 1 and axis 2.


Thanks,
Michael

Hey Michael,

I'm impressed. Thank you very much for your strong efforts and visualizing my data. It's really incredibly interesting.

I hope Jasem finds time to implement your comments, maybe we're on the right track here!

(As always, I'm available to test. With precise (what to change in code) instructions I can also create a local build an test it.)

Regards,
Mat

Hey Jasem,
you mentioned earlier that alignment is not related to calculating tracking.

If I do a platesolve (successfully) and the tracking starts with the problem drift and I then manually on the map set a new sync point (without slewing, for example not far to the left of the centered star) the drift changes, even the direction (reproducible).

But if I manually sync the telescope to the point to the left of the star (cleared model before, with just this one sync), then the drift behaves differently.

So I have the feeling that if more points are set in the alignment model, the drift behaves differently, but that is a thing that sould not be right? Because you said its only calculated from the actual location, right?

Regards,
Mat

Hey Michael, Hey All,

I wrote a lot with Michael via PM - we tested a lot of things in the last week. (Michael is not able to post in the indi forum anymore.I also have problems to post, e.g. in Firefox I cant press the submit button.)
I discussed the alignment stuff with Michael on basis of the alignment-whitepaper from indi and we decided to test a bit.

Good news:
The first time I was able to reduce the drift while it was there -> and I made three complete restarts to test it (with moving/ turning the full equipment a few centimeter).

the procedure:

1. start up everything
2. slewed the scope with mount-control and platesolves (option "nothing") to star Al Giedi
3. first platesolve at star with "sync"
4. enable tracking -> drift problem is there a 14 Sek frame was not possible

Now the important part:
5. I did about 12 gotos and platesolves in the direct neighborhood (in an irregular circle) around the target. but realy not far away - maximum 3x field of solver distance (120/30 Scope). Between the gotos I sometimes returned to the target and platesolved again on the target.

6. The drift was nearly gone and I was able to take some super sharp shots on:

- Star Algiedi
- IC4756
- NGC6976
(files as attachements - camera was again Raspberry Pi HQ Cam at 14 Sec exposure at a 420/76 scope)

After every target I did a full restart (mount and pi) and everytime after the first solve on target I had again the drift -> after the platesolve-circle the drift was almost not noticeable.

It would be great if someone could test and confirm this.

So all in all I think the syncpoints in the model do somehow influence the tracking. For me, if the circle-procedure works reliable -> I m happy

Regards,
Mat