I have a serious autoguiding problem.
I use a CEM60 mount and a ASI120 connected to a 60x300 guiding telescope.
With previous versions of EKOS/INDI I had a global RMS around 0.30 arcsec max and a RMS on each axes around 0,2 arcsec and sometimes around 0,10 arcsec.
The curves where very soft.
Now with the new autoguiding process I have a very, very bad result. Global RMS around 0,5 and huge shots of more than 3 arcsec. Axes RMS is around 0,4 arcsec.
To find good parameters has become drastically difficult.
Is that a different calculation of the deviation that might cause the problem or the parameters ?
Have you met same problems ?
Sorry about the difficulties. The scheme itself hasn't changed much, so you should get similar or slightly better performance. However there are a few things to think about. I hope these are helpful:
The main thing I'd look at is calibration. The calibration is now fully used. Previously only the direction was used, now both direction and "strength" (how many milliseconds of push is required to move an arc-second). So, make sure you have a good calibration, if you are re-using calibrations, which is what I'd recommend.
Make sure your parameters related to camera pixel size and focal length are correct.
The parameter values for aggressiveness and min-pulse were reset to defaults, since their scales changed. If you have tuned them, look again there.
Similarly the GPG aggressiveness parameter was removed and it now uses the standard RA aggressiveness parameter. If you tuned that, please look at it again.
Honestly, as far as I can recall, those were the main things that changed.
Well I have also big troubles with the new guiding settings. The RMS error was around two times bigger than before. I have done new calibration and tried to tune the parameters. I am thinking that I will return to PHD2
Just a question , why the old algorithm wasn't keep alive and offers the opportunity to switch from the old to the new one ?
A transition period would have been a good choice. Just to give time to mount users to share the best practices on new algorithm.
For me, the new guiding works the same or even a bit better than the old one.
That is for two mounts - HEQ5 and RST-135.
Had to tweak parameters to make the guiding work right.
RPI 4 B (4Gb) with SMate
Askar FRA400, TPO RC6, Nikon D5500 full spectrum (with IDAS D1 clip-in filter).
ZWO ASI120MM Mini on ZWO 30F4
ZWO ASI224MC-S on Orion 50 mm f/3.2
ZWO EAF x 2
Do you use 2x2 (or higher) binning? If I recall correctly in the old code the RMS could have been calculated wrongly if you had used binning. This could possibly explain a 2x higher RMS (in each axis) now. If so, the previously reported RMS was too low.
Of course this does not explain huge shots in your graphs which should not occur in the first place.
@Alfred I used the 2x2 binning. And the deviation was soft with a very good RMS around 0,25 arcsec plus or minus 0,05 arcsec on each axes.
I still use the 2x2 binning but the result is so worst. In fact the amplification of the deviations values are not really very important if they are equally distributed around 0.
The value of deviation is mostly contained in plus or minus 1.5 arcsec. The main problem before reducing the deviation are those huge shots of more than 3 arcsec that didn't exists on previous autoguiding processes.
For calibration I had to increase the pulse duration to 5000 to have a decent move of the mount overall in AR (2000 with previous version).
Under this value, the calibration curve looks to nothing good.
This didn't changed anything on the guiding process. It remains as bad as with a less calibration pulse of 2000.
For the moment I am fully lost in adjusting the values of the parameters for calibration and guiding.
As I don't have the chance to benefit of good weather conditions very often, I guess that will take a while to find the good values.
Maybe I will get back temporarily to PHD2 to improve the autoguiding process.
Patrick, I see. Obviously binning doesn't play any role in your setup when you did use 2x2 before and after the problem occurred. Tonight should be OK here in Frankfurt so I will test and report back what I find out.
Do you run releases, nightly builds or do you compile from git? In case you compile from git you can revert back to any version before the guiding problem came up.
I usually use the current release. I don't use the nightly builds or compile from git. I compile only libindi and 3rd-party drivers from git when I remark a driver dysfunction (this was the case with QHY183M f or me).
Here for the autoguiding issues I used the current release.
OK, so you have experience with git and it isn't too complicated to compile kstars yourself so you might consider this option as you gain more control over which version you run and also get the latest improvements. I do keep a second (proven) version just in case the latest one surprises with a show-stopper bug.As I had hoped, I was able to do some observing yesterday night. Overall, guiding did perform OK. I did find a few issues but these are unrelated to the ones you experienced. At least I did not see sudden spikes. Seeing was very bad which does not come as a surprise given the fact that (just for testing purposes) my scope sits on top of a heated 6 storey building while outdoor temperature was ca. 5°C.Calibration plots looked like
and guide graphs like this
Nevertheless this testing session was productive for me since I think I found the root cause of an issue that I have been struggling with for quite some time. I'll write more about it in another thread. I'm intested in your further test results. Did you have a chance to run phd2 yet?
Here are some, hopefully I give you what you want, otherwise, please give me specific parameters for which you want defaults:
Aggressiveness for RA/DEC: 0.75 (you can use anything in the range of 0.4-0.8 probably to get started)
Integral gain for RA/DEC: 0.0
Minimum pulse for RA/DEC: 0.2 arc-seconds (again, don't need to be too exact at the start)
Maximum pulse for RA/DEC: 25 arc-seconds (ditto--just trying to make sure the system doesn't do anything too crazy)
GPG parameters--default is off, but I'd use it if I was you.
Estimate period: checked, but see below
Major period (seconds): you need to look this up for your mount, and if you can be confident in the value, then use that and uncheck estimate period. Otherwise, you can let it run for a half hour and see what value it gets, note that, and uncheck the estimate period if you're happy with RA guiding.