Indeed, switching to my NUC resolved the problem, it’s running fine with both ASI cameras attached. I used it mainly for planetary imaging, but for the bold 6200 chip it seems the appropriate solution.
Read More...
No, the scheduler doesn't reset the counter, this is a focuser attribute. And btw, there is also an option to re-align before each job start. This is helpful for those situations where you have a job with the repeat n times or repeat until options set. In this case, for each job repetition, an alignment is triggered first.
Read More...
Definitely, that's exactly the intention behind this feature. I have it set to 2 minutes.There are two types of restarts. If guiding fails, the scheduler tries to restart a couple of times. Only if this fails, it aborts the job. Now the restart feature steps in. If an aborted schedule job is restarted, the starting procedure with focus, align, etc is executed.
I personally do not use initial focusing but use the "refocus after ..." feature of the capture module. When there are problems with clouds etc., it could happen that a job is restarted and focusing fails. Then it could happen that the focus is so off limits that the next focus attempt will fail. For me it seems a robuster strategy focusing after a certain period of time and not at the beginning. At the beginning of a night, I start focusing manually.
HTH
Wolfgang
Read More...
OK, RGB is another story, I have the mono version. I switched to the 64bit version of Raspian which resolved the memory allocation issue.
I think it is a good compromise if we keep the pixmap during the focussing process in the memory. But as soon as focusing is done, we can free the allocated memory if memory is scarce.
And regarding Java vs. C++ - well, it's definitely not my favorite language. After ten years using Java I was convinced I never need to do memory management manually - haha... But - it's cool working on EKOS.
Read More...
Good to know, I have an oder NUC hanging around. So if it doesn't get better, I at least have a fallback option. But currently its too early to surrender 
Regarding the memory consumption - turning off the FITS viewer at least makes it better. The problem is not the FITS viewer itself but the fact that each module - Focus, Align, Manager stores its own pixmaps. This was not a problem with smaller chips, but with these big chips we need a better strategy.
As a first step in this direction I am currently working on improvements of the Manager (the tab where you start EKOS from). I think if we improve it, we do not really need the FITS viewer all the time. As soon as this is done, I think it makes sense to implement a memory management strategy so that we do not need to store all the pixmaps. As an example: do we really need to keep the pixmap of the last focusing session? I would question that, it should be sufficient to keep the HFR data.
Cheers
Wolfgang
Read More...
I'm struggling with a similar problem:
[2021-06-15T23:43:50.416 CEST INFO ][ org.kde.kstars.indi] - ZWO CCD ASI6200MM Pro : "[ERROR] Exposure failed after 3 attempts. "The strange thing is that it behaves differently on my two Raspberrys although they are on an identical INDI version.
Read More...
I'm afraid you need to build it from the sources, if you want to switch to a previous version. Checkout commit 66f45a2f58026aa13b8a8debff585a8e34fccf50 from indi-3rdparty and build it. You can get it from here: github.com/indilib/indi-3rdparty
Read More...