Hello all, I'm running into an issue I'm hoping someone can help me out with. I've got a new rig i'm getting set up and am having an issue with Ekos freezing during image download. I'm running on a RPi4 imaging with an ASI1600MM. What i'm seeing is the image will capture and when Ekos goes to download the software just locks up. I can't change tabs and it is taking several minutes to come back to life. Whats curious to me is that the image download time is still coming back at like .5 seconds. I'm plugged directly from the camera to the RPi via a USB 3 cable. I'm using PHD2 for guiding and thats moving along just fine in the background as well as it appears that the mount is still tracking. I also noticed the RAM usage on the RPi4 spikes during the download. I'm not sure if thats related. Any ideas?

For this camera, you probably need 4GB+ RAM. is this what you have?

I use a QHY 183M that produce raw images of 40MB, and there is a little freeze of 1-2sec just the time to download and show the image in the Viewer. RPI with 4GB is good enought to do this work.
Take a look at your sd card, some have problems of speed with the RPI4, I use a Lexar 633x, Samsung Evo (red card). I had problems with Kingston and other cards

I do have the 4GB model. I should have added for context that this is my second second rig I want to use for traveling. My home rig uses separate a 4GB RPI4, but on that one I shoot with a ASI 294MM. When I’m running in Bin 1 mode the single subs are quite large compare to the ~30MB image size coming off the 1600. In that case it does take a bit of extra time to download. However, during that Ekos doesn’t completely lock up. To my comment in the first post, the download time listed in the imaging tab reflects that too showing the 3-5 second download.

The fact that Ekos thinks downloads are only taking 0.5 seconds but in reality are taking upto 10 minutes is what I’m having trouble resolving.

I should also add that I’m writing the data to a usb stick. I’ve swapped that out and it doesn’t seem to make a difference.

My first thought was like a bus traffic or communication issue, but I’m not sure how to check if that’s what is going on.

I had a similar problem but in the end it turned out to be the HFR calculation (have you switched that on by chance?). For some strange reason this took up to 5-10 seconds on a relatively powerful Mini-PC. I only figured it out by looking into the logs.

Benjamin,FYI, if compute HFR is taking a lot of CPU on a fast computer, there are two things you should do that will likely improve that.

1) Use the "Quick HFR" setting just below the auto-compute HFR setting.
If you do that, it will just look at stars in the center of the image (about 25% of the area) and so should speed it up by a factor of 4.




2) In the HFR SEP Profile that you use (edit it using the pencil icon just below Quick HFR)
make sure your "Initial Keep" value is no more than a few hundred (but not 0).
This will mean it will do the HFR calculations on e.g. no more than 300 largest stars.
In a crowded star field you can have 10000 stars in the image.

Thanks, Hy Murveit, I appreciate your help!

I tried both, with and without Quick HFR, with no noticable effect. Also, my HFR Profile is very similar to yours (see screenshot). So there must be something else behind this. As soon as weather allows it (very rarely these days), I'll do some more tests and keep you posted.

Best,
Benjamin

I thought I'd figured out my problem, but the error has struck again. I'd done some more searching around on the forum and found some discussion on the ASI1600 and the USB bandwidth setting. I had it set as the default of 80, but many were saying to lower that to the minimum of 40. The looked to have fixed the issue temporarily, but i'm having very slow/no downloads again. I also did try the quick HFD suggestion, but like Benjamin I already had the optimal settings selected.