Woot!! This is really exciting news. 60 seconds and your stars still look round. I agree with Simon, excellent image.

A storm from came through yesterday evening so no field testing until Thursday
for me it appears, but I'm very eager to get out and test.

I did determine from testing indoors that the polling time difference between the axes appeared to have been a one time fluke and the logs look normal again, so we can scratch that from the issues list.

**Update**: I am adding another excel sheet with some analysis to this post from indoor testing today using the same parameters used yesterday. Axis 1 appears to be good. Axis 2 may need the derivative term increased slightly to correct the initial overshoots for faster accurate tracking. For those testing, it may be a good idea to test indoors and use a similar procedure to get the gain values determined visually prior to going outdoors. It took around 5 minutes for the tracking to settle, but as I noted in the excel file, I believe this can be corrected by bumping the derivative term a bit.

>>>I see that you are using HQ Camera for imaging? Are you imaging with Ekos? Which INDI driver are you using for HQ Camera?

Unfortunately I have to disappoint you here - i made the picture with my own crappy Java-GUI which only starts/stops libcamera shell-commands in the background. No EKOS used here. But i follow the HQ thread with great interest!

After taking that 60 sec frame i swichted to M42 and took a 60 sec frame and there was a little drift -> but i think this was perhaps because of field rotation ( M42 was AZ 240 ALT 16). But as i went down to 20-30 sec it was very good again. For me lower values are ok, i use more 15-20 sec when imaging.

I think we have to make further tests to proof it was not only luck, but what i can say is, that it was yesterday more consistent than ever.

@MAT: Thank you for sharing that info.
Maybe you can give a try to RONALD SCHREIBER's great indi_pylibcamera driver and try to capture image with Ekos?

More info here:
- github.com/scriptorron/indi_pylibcamera
- indilib.org/forum/ccds-dslrs/12177-indi-libcamera-driver.html
- saimons-astronomy.webador.com/1216039_ra...ndi-libcamera-driver

All -

I'm attaching yesterday and today's data files for indoor testing. Essentially, Axis1, which is the azimuth axis is not carrying much load. I hypothesize that this is why it always produces zero error almost immediately. On all excel sheets I have provided the data for both axes. The data in the excel files is for the following settings:

File 1: both axes @ 0.75 Kp, 0.13 Ki, 0.01 Kd.
File 2: both axes again @ 0.75 Kp, 0.13 Ki, 0.01 Kd.
File 3: Axis 1 @ 0.75 Kp, 0.13 Ki, 0.01 Kd, Axis 2 @ 0.95 Kp, 0.55 Ki, and 0.02 Kd
File 4: Axis 1 @ 0.75 Kp, 0.13 Ki, 0.01 Kd., Axis 2 @ 0.95 Kp, 0.65 Ki, and 0.27 Kd
File 5: Axis 1 @ 0.75 Kp, 0.13 Ki, 0.01 Kd., Axis @ 1.1 Kp, 0.65 Ki, and 0.01 Kd.

Hopefully my notes on the graph document the thought process enough to lead others in the right direction.

Excellent reports Michael! @Mat, can you try the setting for File 5 with load? I will be able to test today as well and will report back.

Hey folks,

@simon: Thank you for the hint with the cam!

@all:

i tested indoor with mount loaded with 3.7 kg:

I set the values (Axis 1 @0.75 Kp, 0.01 Ki, 0.13 Kd, Axis @ 1.1 Kp, 0.65 Ki, and 0.01 Kd) ​​and started the tracking - then I waited 2 minutes for it to settle - here are some logs as attachement. I had some high errors in between. So i think this values would not work well?

Is that what you wanted me to test?

EDIT: i have to add, that it settled around zero but then errors appeared - it settled again an errors came back...

Regards

Thanks, Jasem. I figure continuing to document/share our testing will help propel us forward on this.

Mat - thanks for taking the data. I noticed your settings which you used to capture the awesome photo the other night were:

1.8 - 0.01 - 0.05
0.75 - 0.01 - 0.13

I believe your altitude/azimuth encoders may be flipped in comparison to mine. So could you do a 15 minute test with the following?

Axis1 @ 1.1 Kp, 0.65 Ki, and 0.01 Kd
Axis 2 @0.75 Kp, 0.13 Ki, 0.01 Kd

Note: I messed up and switched the Kd and Ki values above in the post. The data files I provided have the correct terms I used. I have corrected the previous post! I apologize. Kd should always be the smallest value.

If you have bandwidth, also re-perform the test you did in your most recent post ~1 hour ago switching the Ki and Kd terms. If you provide the logs for both of these tests, I'll plug the data into the spreadsheet, and we can trend. The objective of these tests are two-fold: 1. to see if we can produce a faster stabilization time 2. to see if we can provide initial guesses for non-technical users to speed up the PID tuning process.

To summarize the testing discussed above could you perform these two 10-15 minute tests and provide the logs?:
Test 1:
Axis1 @ 1.1 Kp, 0.65 Ki, and 0.01 Kd
Axis 2 @0.75 Kp, 0.13 Ki, 0.01 Kd

Test 2:
Axis1 @0.75 Kp, 0.13 Ki, 0.01 Kd
Axis2 @ 1.1 Kp, 0.65 Ki, and 0.01 Kd

Thank you!!!!

Hi Michael, Jasem,

sry, the next days im a little bit short in time (travelling).

Regards

I will test tonight. I think we need to adopt some default parameters as the next INDI release is due in a week.

Hey Folks,

How did ur tests go? (Im back home and back on track on friday)

Mat

Indoors tests were great, I changed the default values in the driver now to those proposed by Michael. I will test to test tonight if it clears up.

Ok I had a good test run yesterday, and this is what I found out:

1. PID is working OK to keep the errors to a minimum.
2. Very small errors (+/- 5 steps) did not prevent drift.

So this means that we're probably chasing the wrong target. When tracking is toggled off, the tracking was drifting substantially to the North West. After tracking is toggled, it was was *slightly* drifting to the South West. So this probably means:

1. Azimuth Axis: Not compensating enough for drift
2. Altitude Axis: Compensating too much for drift

I thought one issue might be when it calculates the error. The error is calculated between current encoders vs tracked target EQ-to-Horizontal coordinates. Each second, this is calculated for NOW. So I thought what if we track the target position as it would after 1 second? But this didn't work (still trying to figure out why) and it went on a wild swing. Last test yesterday before I literally fell asleep on the keyboard was to introduce an offset in the error itself by certain amount of steps.

This actually worked quite well, but I still couldn't get perfect tracking. I also didn't like the solution since it just became overly complicated and introducing magic offsets shouldn't really be a solution, but it might point us to the right direction. Today I'll start early with the testing and see if the tracking errors can be minimized.