@Alfred,
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.

 

Read More...

@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.
 

Read More...

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.

Read More...

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 ?

 

Read More...

Patrick replied to the topic 'QHY183M not detected .. my solutions' in the forum. 4 weeks ago

From Jan Soldan for those that could encounter the problem and to the developers :

Read More...

Patrick created a new topic ' Y' in the forum. 4 weeks ago

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.


 

Read More...

Patrick replied to the topic 'Indi 1.9.2 Ubuntu 21.10 Armf' in the forum. 4 weeks ago

Same issue here on Ubuntu Mate 20.04

Read More...

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.
 

Read More...

Patrick created a new topic ' Risingcam IMX571' in the forum. 2 months ago

Hello all,
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.

The system:
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:    20.04
Codename:    focal

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:
<getProperties version='1.7'/>

And hangs on getProperties.
 

Read More...

Patrick replied to the topic 'Re:risingcam imx571' in the forum. 4 months ago

For the offset, I guess you can take a look here:
www.qhyccd.com/index.php?m=content&c=ind...show&catid=23&id=226

for the HCG/LCG gain ratio I don't know, maybe this could help

Read More...

Patrick replied to the topic 'risingcam imx571' in the forum. 4 months ago

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.

Read More...

Patrick replied to the topic 'risingcam imx571' in the forum. 4 months ago

Do you know what is the wrong info that have been given by Risingcam engineers ?

Read More...

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 ?

Read More...

Patrick replied to the topic 'risingcam imx571' in the forum. 5 months ago

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.
www.imagesensors.org/Past%20Workshops/20...019%20Papers/R06.pdf
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 ?

Read More...