With 1.5 the average error is better. I'd say experiment with increasing that to 1.6 , 1.8 ..etc and see. I'll test it hopefully later tonight but currently extremely busy.

But isn't the problem that the speed (rate) is always the same?

We would need a state where the speed goes down from an average of 13 times to an average 9 times if we change something because the tracking is too fast. In the logs, the speed changes for one time, but ultimately it ends up back at around 13.

Or am i missing something?

It's not the same. I tested yesterday and the speed is different. You can even set the clock rate directly for each axis and it will use that speed and ignore PID calculations completely. However, it was still drifting yesterday and I didn't have enough time to test it completely. Seems like a value between 1 and 2 for proportional gain is suitable.

Hi Jasem,

is there a field for setting the rate directly?

Regards

Yes just below the PID (the T1 rate)

Ok, you are right - T1 Rate fixes the rate. So i startet at a (real) star - looked in the logs and checked out a good rate - but than i get small jumps and in the logs i see a fixed rate but the direction changes - can it be, that only the rate is fixed, but the direction ist still set by algo?

Jasem & Mat,

I believe I see what the issue is now. We are setting the tracking speed by dividing the input frequency (16Mhz or 16000000 pps) by the number of microsteps which will always produce a very very "rough speed". For instance, there are large gaps between the following discrete speeds:

16000000/ 1 = 16000000
16000000/2 = 800000
16000000/3 = 533333
16000000/4 = 400000
16000000/5 = 320000
.....6 through 12 microsteps
16000000/13 = 123077
16000000/14 = 114286
16000000/15 = 106667
etc., etc.

We did this on the previous tracking factor and aggressiveness factor versions of the driver as well which could have been the problem all along. We may not achieve the resolution we need to get to a non-drift point this way. Side-note: The mount resolution advertised is 2 arc-seconds. by my calculation, we would need to be within the 2-3 microstep range on our error to achieve this resolution (below). I really like the PID concept, I believe we just need to adjust the feedback loop which sets the speed.

Step angle = (360 degrees/2073600 microsteps) = 0.0001736 degrees/microstep
arcsecond/microstep = 0.0001736 degrees/microstep * 3600 arcseconds/degrees = 0.625 arcsec/microstep
(2 arcsecond)/(0.625 arc-second/microstep) = 3.2 microsteps.

Hey Michael,

interesting, but why do you think only these "steps" are set. In my logs are many different rates set ?

To simplify what I'm saying above, when the frequency is being set above (via the program not manually as discussed earlier today), it is doing so by dividing the input frequency by a whole number. For instance, you'll never get a frequency of 10,666,666 pps as the program doesn't have fractional tracking rates (i.e. 16000000/1.5).

Hey Folks,

I tried more than 3 hours this evening and tested under real sky conditions the actual version - without success. I couldn't find any prop setting (between 0.1 and 2.5) that solves the drift (or doesn't jump).

Michael, I looked at the logs and now see what you meant - it's always the same numbers (16,000,000/ whole number)

would be great if your discovery would lead to the solution!

Unfortunately, I have no further ideas.

@jasem -> can we perhaps try michael's suggestion?

I noticed I didn't state a clear question or comment. To help Jasem decipher our thoughts, specifically, our question or comment is:

It appears the new error (line 1194 of skywatcherapimount.cpp) obtained from the m_calculate (PID.cpp) is being truncated as a whole number. Is this a data type definition issue or the result of something else? Either way, this is nullifying the benefit of the PID controller as the set speeds are being limited by the whole numbers of the error.

Thanks Michael. I pushed two changes now:
1. Use double for TrackRates.
2. Direction for manual T1 is not not overridden by PID loop. You can specify direction by sign and the range is -16000000 to +16000000