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.
@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.
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.
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 ?
From Jan Soldan for those that could encounter the problem and to the developers :
Recently I took off from its box my QHY183M camera.
I connected it to my Netbook Dell working under linuxmint 20. I updated before all that follows kstars/ekos/INDI.
I launched Kstars/Ekos and started connection of the devices.
The QHY183M wasn't detected by INDI. I confirmed it using indiserver that didn't found the QH183M.
lsusb shows only that the cam was here without precision of type or brand. But i saw when she was plug or unplugged.
I decided to install the last sdk available on QHY site.
This fixed the identification of camera by the system:
lsusb shows the brand and name of the camera
dmesg shows the camera with idproduct="c184".
When I looked in the /lib/udev/rules.d/85-qhyccd.rules there was no c184 idproduct.
Scratched my head.
Tested INDI again, without success.
Scratched my head.
I edited the 85-qhyccd.rules under /lib/udev/rules.d and /etc/udev/rules.d. I duplicated theline with c183 and modified the copy with idproduct="c184".
Tested INDI again without success.
Scratched my head.
I downloaded the souces of INDI and 3rd_party dirvers
I compiled the libqhy
I modified the 85-qhyccd.rules as said previously
I compiled the indi-qhy driver
I created a link libqhy.so.21 pointing to libqhy.so.21.9.16 (last SDK)
Tested INDI again ... and ... YAY ... SUCCESS.
All of this is not that clear. I am sure there is a bug somewhere in the sdk(s) of QHY on idproduct (why ? don't know).
Happily those hazardous manipulation fixed the problem.
Maybe I will try to describe better the path I follow.
Same issue here on Ubuntu Mate 20.04
Well, nobody answered, so I suppose that nobody has the answer.
For those that could meet the problem I can provide a temporary answer : I used INDIGO_SERVER that recognize the cam and seems to works well.
So there might be some weird issues with last INDI drivers. I don't ever see what it is.
I tested 2 days ago my Risingcam IMX571 on the RPi4. Was working fine with it.
Yesterday I made an update/upgrade of the system.
The result is that the driver hangs and the camera is not even seen by Ekos.
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
The driver answer:
ubuntu@NAFABox:~$ indiserver -vvv indi_toupcam_ccd
2021-08-30T05:36:08: startup: indiserver -vvv indi_toupcam_ccd
2021-08-30T05:36:08: Driver indi_toupcam_ccd: pid=7500 rfd=3 wfd=6 efd=7
2021-08-30T05:36:08: listening to port 7624 on fd 4
2021-08-30T05:36:08: Driver indi_toupcam_ccd: sending msg copy 1 nq 1:
And hangs on getProperties.
For the offset, I guess you can take a look here:
for the HCG/LCG gain ratio I don't know, maybe this could help
What I have understood is that the threshold of 900 is the limit where you switch from LCG to HCG. The only advantage is to get back to a full dynamic when switching from first mode to second one. It seems that for cameras like Zwo or QHY this is transparent for user because they switch automatically between the two modes.
After the choice of LCG or HCG is up to the user. Maybe for lucky imaging or use of filters like L-Extreme from Optolong HCG might be better than LCG.
Do you know what is the wrong info that have been given by Risingcam engineers ?
Do you mind if it could be a good idea to have a button "search object" in the astrometry tab that open a search panel with a goto button ?
I don't understand all in this paper, but it seems that there is all explanations for all parameters that are in the control tabs.
I will try to read, re-read it as long as I can't understand all (if I succeed to).
Maybe HDR combine low and high gain to give a better result. Who knows ?