My Risingcam IMX571 returns to duty. I had issues with the driver on RPi 4 with previous versions of INDI. The last version has fixed the problem.
I agree with Dmitrii 0 or 100 is quite equivalent, 200 seems to be a reasonable value.
Those gain curves are really a bit confusing.
I still have a problem with the offset. I really don't know what value to use. So by default I set it to 10.
About the drivers, I don't see the plus value to update it.
In May 16 there will be a moon's eclipse. A friend of mine will use Kstars/Ekos/INDI to make a time lapse of the event.
He warned me saying that the follow-up type is not mentioned in any tab of Ekos. And in other way never save in options.
Would be nice to have a recall of the follow-type in Synthesis tab and the mount tab. And be able to save it in the options.
This last point is to avoid forgetting to set to lunar follow-up the D-day of the event. Because for sure you don't forget it when you are preparing it.
Alex don't yoy have a spam problem ? Your answer is repeated 4x times.
Would it be interesting to have a node-red integration in Ekos ?
Looks like it could help to define graphically the behavior and responses of all sensors connected to INDI.
That is just a remark as I just discovered this tool that seems to be interesting.
Thank you Ron.
Damn I didn't saw the option in site management. I must admit that people having done the translation in french have been too far in this exercise. I use Ekos with UI translated in french. Park options is translated as "option de sécurité" which can be reverse translated as security options, which doesn't evoke to me the idea of parking the mount.
Hello all I just finished to build my "observatory". I have to set a parking position. Unfortunately the driver in INDI and the Ekos don't offer this possibility rather than the handpad which offers the 2 positions. Is that an oversight or didn't I missed something ?
I won't be able to do anything until next week. But I will check it maybe in Tuesday next week.
Here is the log of a short session composed by 2 slews the driver failed on the second one.
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.
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 ?
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.