Hi All!

I am encountering an issue and I haven't been able to solve it or pinpoint the root cause.

The issue is my flats sequence keeps failing.
It randomly manages 34 frames for a few filters and at some point it just stops.
It can stop anywhere after filter change, sometimes it manages to do the 7 filters.
The general tab shows "Idle" status, scheduler tab shows sequence is "Running" and capture tab shows "Idle" for the offending line also next to caputre status time  (on the bottom) I can see the spinnner turning, but no status text (such as capture, downloading...).

Most of the times I see log messages "capture module timed out. Restarting request...", but sometimes (seldom) nothing capture or scheduler modules don't even log.

When this occurs, I have tried stopping the scheduler, disconnecting and reconnecting the camera, and restart the scheduler.
Doing does nothing, capture is still idle.
The only way to recover, is to completly disconnect the indi profil, stopping it and restarting it (ekos is kept open).


Also having an ASI6200, I tried increasing indiwebmanager memory further, but it didn't help (increased from 300 to 600mb).


Perhaps someone has an idea what troubleshooting steps I should try next, or if I am very lucky someone encountered this issue?
 

I would like to add that I went through standard troubleshooting steps:
- The computer is nearly new (not 4 months old) and OS install is fresh, I am running kubuntu for increased compatibility as ekos is part of KDE
- I am using high quality 1m USB3 cables and they are plugged-in directly on the computer.
- My power supply is a 14.1V/30A Powerwerx.
- Power is distributed using high quality cables (appropriately dimensioned) with PowerPole connectors.

I forgot to mention that when this occurs there is no log in any module console (including in INDI control panel).

Also this never happens while shooting lights, only flats (about 80% of the time, the sequence gets stuck). I have not done darks in a while so I cannot tell if they cause this issue too.

Any help or ideas would be very much appreciated.

I'm struggling with a similar problem:
The strange thing is that it behaves differently on my two Raspberrys although they are on an identical INDI version.

Oh I have experienced that one when using a 6200 with a pi.
First things first, the pi really struggles with the 6200 no matter what.

However I more or less got it to work :

• One big issue seems to be related to impedance causing unstable USB connection.
  I tried so many configurations, the only one that worked was using 50cm high quality USB3 cables and instead of plugging them directly into the pi use a passive USB HUB in between (yes, passive).
• Other is memory consumption, completely deactivate FITS Viewer and avoid opening fits files with it at all cost while running a sequence.
  I could open more or less three images, before it crashed (one by one closing kstars after each one)

In the end I bought an Intel NUC (Gen8 i5), appart from my current issue with flats it works like a charm and every options are activated now

PS: If you go this way there is a Beelink that is much cheaper than the NUC, it is basically the same board and components, only the case and power supply change (also RAM and SSD are already included)

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

Haha tell me about it! This chip requires so much resources and we have mono cams, 6200 debayered color is 750Mb per image

Yes architecture wise that seems like a very good idea. Regarding focusing data, I concur HFR data seems enough, besides if needed focus images can be optionally stored.

I haven't coded C/C++ in 20 years (went the Java/C# way), but had a look at source code (specifically Losmandy INDI driver). I tried fixing the issue I had with my mount, but ended up messing up two state machines Hopefully grbsystems got the pull request right

When I find time I'll dig more into ekos coding, I have a few ideas I'd like to implement.

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.

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.

Glad your issues are solved
Thanks for the feedback.