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

It appears the forum submit button is working on my end again (yay!).

Mat - that is great news. From the personal messages and images you sent over, it appears you are getting consistent results by performing an alignment with sync points around the target. As mentioned in our correspondence via PMs, I am currently unable to test this as my plate solve feature is not working correctly. I've posted the instructions to the simpler driver below.

Jasem - Platesolving seems to be broken on my end. It used to work very well, but it doesn't anymore. I have the same symptoms as these folks here . In addition, "slew-to-target" will slew once, sync, pretend to slew again, sync, pretend to slew again, sync... .etc. I have confirmed that manual slewing and goto works, so it's something with this particular platesolve function. Is there a directory of previous indi versions which I can revert to?


P.S. for others:
I've reverted to a previous version of the az-gti driver with partial changes from a comment I made above in regard to tracking. If you remember, this is the version where pretty much only the PID terms could be set. What I've done:
-reverted back to prior version.
-added harcoded deadband of -4 microstep to 4 microsteps for the error. That is, the frequency and track rate will stay the same if the error falls with the deadzone.
-Changed PID track rate constraints of -50 to 50 to 1 to 100. This will allow a frequency range of 16,000,000 hz to 16,000 hz.

Here is the Branch .Essentially, copy and paste (replace) the skywatcherAPIMount.cpp to your local indi/drivers/telescope directory and re-build without grabbing the indi official repository source files. make sure you replace the files and don't hit "skip".

For those interested in helping, test this with the alignment procedure Mat has discussed above.

First many thanks to Michael for all his input via PM, while posting in the forum didn t work.

Since I had free sky for a short time yesterday, I put the "circle procedure" to the test and it worked again!
First the telescope drift was there on the target and i minimized it with many randomly placed sync points (17) around the target so that the drift almost completely disappeared again.

The target was NGC7479 and i made 220 frames with 14 seconds exposure. You couldn't see the galaxy on the individual 14 sec frames (i m located in a city and only use the pi-cam), but after stacking it became slowly visible - amazing.



195 frames (46 min) used
Raspberry PI HQ cam
Scope 420/76
(I used kstars 3.6.0 and the actual INDI from GITHUB.)

But I think you have to mention that the azgti in "alt az unguided" also has its hardware limits. I couldn't use every frame and sometimes it's inaccurate or a frame is not good. But that was it with the original synscan app from Skywatcher too - I would say that the level of the original app has been nearly reached, what is amazing, because ekos is so much easier and more convenient to use than the app (and has platesolver ).

i will keep you updated!

Regards,
Mat

Attachements:
a standard singleframe
a "lucky" test frame 45 sek (that realy works not everytime with the az-gti )

Good news. I was able to perform the alignment procedure Mat outlined above with excellent results on the first time. My target was Polaris, and I achieved multiple 45 second exposures similar to the one attached.

I normally use the Ubuntu version of Kstars on the interface end ( i.e. non-stellarmate end) however due to the recent upgrade to Kstars 3.6.6, platesolving is pretty much useless. I switched over to windows and ran Kstars 3.6.3 (which had a few performance issues, i.e. super slow and froze repeatedly) but it was able to sync multiple times unlike with 3.6.6 allowing me to perform the alignment procedure.

Clouds set in, and I could image only one target. I'm pretty confident in the process. I'll attempt again on a clear sky.