Do these problems still apply even if you use FITS Viewer to use always the same window and replace the old image with the new one (as opposed to opening one instance of FITS Viewer for each downloaded image)?

I have been using my APS-C camera (6016x4016 pixels) at its full resolution and with only one instance of FITS Viewer open and never had any problems with it crashing. I only use limited resources mode to speed up download times and get more images per acquisition session.


I made the same exact mistake, too, a while ago.

I didn't want to flash and reinstall everything. I solved the problem by hunting down the KStars configuration file, open it with a text editor and reset the Dither field to "0", I believe. It worked just fine, after that.

Unfortunately, I don't remember the name or the location of the config file - maybe somebody else will help.


That worked, thank you!


I spent the whole part of the morning trying everything possible: from setting the hotspot of Astroberry to work in 5 GHz, to connecting the laptop straight to the Pi with an ethernet cable, to connecting Pi and laptop to the home Wi-Fi. Nothing worked. Connections kept dropping, USB ports wouldn't work, everything broken just like last night.

Finally, I gave the above command a try and reverted to the previous Pi firmware. Everything works as a charm, now. My EKOS imaging profile works in all these modes, now: hotspot, direct ethernet, and home Wi-Fi. Even with hotspot at 5 GHz.

Now I have three possible ways to connect while I am outside. I hope at least one of the three works in my next session(s).

Now the question is: why the developers of Raspberry go and break a perfectly functioning firmware to release one that doesn't work?! If it ain't broke, don't fix it - they say...!


dmsummers wrote: - Pi4 + USB3 + blind hotspot is ok (i.e. NOT mapped back to a 2.4Ghz "infrastructure" internet source).

I use my Astroberry in hotspot mode and VNC into it. Usually everything goes fine, but tonight I couldn't get the hotspot and my devices connected to USB 3 to work.
Could you kindly explain to me how to create a hotspot that works in the 5GHz instead of 2.4?


I have been running Astroberry for quite a few months, but never had as many problems as tonight. Last session was December 18th. Finally I get a clear night, bring out everything, as usual. Connect everything, VNC into the Pi, launch EKOS and my usual profile. Neither camera is recognized (D5300 or ASI 224MC). The only thing I did between December 18th and tonight was plugging in the Raspberry into my ethernet and run "sudo apt update" and "sudo apt upgrade".

I tried everything I could think of. Been outside since well before astronomical darkness (by 6 PM I had everything mounted and running). At 9.45 PM I called it quits and brought everything back inside.

I tried connecting only one camera, it works. Then another one, it works. Then the mount, then the hotspot gets dropped and I am back at square one. Turn it off, plug everything in, turn it back on - hotspot doesn't work, so I can't VNC into it. Disconnect everything, reboot, now the hotspot works. Plug the cameras, launch the profile, no camera plugged in message.

Any idea? I would like to solve this asap, since I am getting perfect skies on Sunday and I don't want to miss another opportunity. Here lately we get only clouds, rain and fog. So missing a clear night is like missing a months opportunity...


knro wrote: Maybe another idea is to release the raw data buffer completely after the initial stretch is done. So no more operations on the raw buffer because it's gone. That would cut utilization by half. Any thoughts on this?

I like this idea the most!

I need FITS Viewer while I do my manual operations and keep track of things while I image (not full automated yet). I also wouldn't like a conversion from RAW to JPEG, as that would slow down download times even more: I just posted a wishlist where I say that I would love if download times wouldn't be affected by dithering or HFR calculations. JPEG conversion would probably add to the time for the image to be displayed and increase the timer before the next exposure is started even more.

But, yes, I would love some RAM optimization. I have a Raspberry Pi 4 4GB and with everything running (KStars, EKOS, PHD2 and FITS Viewer) I am at about 50% RAM consumption. Sometimes PHD2 even hangs and does not issue any command for multiple cycles of guide camera exposures (might be 10-20s, even)...


Fantastic! Thank you, this is exactly what I needed!


Matteo Gaetan created a new topic ' FITS Viewer Optimization' in the forum. 3 years ago


I would like to add a request.

Right now, this is the typical behavior that I am encountering:

- I plan a sequence of n pictures with x seconds of exposure and launch it - I have dithering set to every two exposures
- The first picture finishes acquiring and it's typically downloaded and displayed in 2.5s (the estimated time to download matches that, too) - so far, so good
- The second picture finishes acquiring, the dithering starts - but then, somehow, the estimated time to download gets increased by the presence of the dithering and the new estimate is now around 6.5s - and it stays like that for the rest of the session, also for the undithered frames

Also, I tried turning on the option "compute HFR" so that I can monitor the focus and decide when it's a good time to refocus, based on computed numbers. However, this slows down the images even more and the estimate becomes 8-9s.

Given that the next image doesn't start acquiring until the previous one it's downloaded, this is actually slowing down the whole acquisition: from a nice and fast 2.5s, if I have dithering - which I pretty much have to have - it goes to 6.5s and if I add HFR it goes to 9s. Now, it may not seem much, but when I take about 50 images in one night, it adds up.

2.5*50 = 125s (a little over two minutes wasted).
9s for every picture, means 9*50 = 450s. That's 7.5 minutes just on download times, or 5 minutes longer what it could be if I didn't have dithering or HFR enabled.

Now my questions:

- would it be possible to download the image and then issue the command to dither? That way the estimate for the download time would keep to a nice and constant 2.5s and not increase to 6.5 for all frames, whether I am dithering or not. I understand this would delay the beginning of dithering by the download time, but 2.5s is better than 6.5s - I don't know if this can be optimized even further and I understand that the capture program needs a confirmation that the previous image is complete before starting the next one, and downloading it is a pretty sure way that it is indeed finished. But the download times shouldn't be increased due to dithering
- would it be possible for the HFR to be computed by the FITS Viewer after the image is downloaded and displayed, such that it doesn't slow down the download time and increase the estimate as well? I have plenty of time while the next image is being captured to wait for the HFR of the previous one to be calculated and displayed. Even if I was using very short exposures (say 15-20s), if the difference between no HFR and HFR is 6s added to the download time, there's still a lot of time left while the next image is being captured
- better yet, would it be possible to compute the HFR manually, on request, only when the user requires it? This way, the download time wouldn't be affected at all, and I could ask FITS Viewer to compute the HFR while the next image is already being captured. I don't have an automatic focuser, so I need to be by my rig anyway and I could ask for the HFR every few pictures to see if it's increasing or staying pretty constant and judge when it would be a good time for a refocus. Right now I just refocus every hour, just because, or I have to look closesly at each image until the star "seem" to become bigger. But a mathematically computed number over the whole frame is much safer than trusting my own eyes

Thanks for taking this into consideration!