Patrick replied to the topic 'Onstep crash' in the forum. 2 weeks ago

I won't be able to do anything until next week. But I will check it maybe in Tuesday next week.

Read More...

Patrick replied to the topic 'Onstep crash' in the forum. 2 weeks ago

Here is the log of a short session composed by 2 slews the driver failed on the second one. 

File Attachment:

File Name: log_19-40-11.txt
File Size: 206 KB


Read More...

Patrick replied to the topic 'Onstep crash' in the forum. 2 weeks ago

In my case I tested it with serial (usb) connection. Is it really the same problem. If it is, there is something buggy in the driver.

Read More...

Patrick created a new topic ' Onstep crash' in the forum. 2 weeks ago

Hello all,
I am building an onStep system to motorize  my old GP mount.
I have chosen to use a Wemos D1 R32 + CNC3 to make it simple.
The first tests after having uploaded the firmware are done with LX200_onstep INDI driver.
To do it I use the Wemos D1 R32 alone. All connect fine but the INDI driver crashed after the first goto simulation.
Before going further in exploration of the problem I have a question for the one that use onstep: have you find similar problems  ?
Thanks

Read More...

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

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. 2 months 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. 3 months 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. 3 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...