Hi. I am confused as to the current status of what is fully fixed and available. For me, building from latest GitHub on Ubuntu 20.10 amd64 still has at least the Pegasus drivers broken. Reviewing this thread there are conflicting statuses. In somer instances the problems are pegged to bad packages, but building from source supposedly works (not my experience); other entries point to possible C++ inheritance issues (so building wouldn't fix that).

Can Jasem or other knowledgeable individual please recap the current status and whether those of us still out-of-luck should be looking for a source update from which to compile a working version or if it is best to look to nightly builds.

Just to confirm that I am building properly on Ubuntu 20.10 amd64, my steps are:

1. Make sure environment is up-to-date (sudo apt update && sudo apt full-upgrade -y)
2. Install all required build pre-requisites as well as ccache
3. Then perform the following (completing the set of operations for each package before proceeding to the next package):
   1. Clone (or pull latest) master branches from the following links:
      1. indi: github.com/indilib/indi.git
      2. indi-3rdparty: github.com/indilib/indi-3rdparty.git
      3. kstars: github.com/KDE/kstars.git
   2. cmake options:
      1. indi: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug "$SRCROOT/indi"
      2. 3rdparty-library: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DBUILD_LIBS=1 "$SRCROOT/indi-3rdparty"
      3. 3rdparty-drivers: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DWITH_FXLOAD=1 "$SRCROOT/indi-3rdparty"
      4. kstars: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo "$SRCROOT/kstars"
   3. make -j $NCPU
   4. sudo make install

FYI: I am running Ubuntu 20.10 (amd64) and tried building from latest source, but it cannot connect to my Pegasus units (PPBA and DMFC). Fails in HandShake (gets no response).

Read More...

Last message from me on this topic...

I ran  AstroPi3 to set-up my 64-bit OS raspberry and after that the magnification problem I mentioned in my earlier posts went away. It might have been something specifically in that script or it might be that - as part of the script - it does an 'apt update' and an 'apt upgrade' and with a new beta of the 64-bit OS just released on April 9, it may have picked up a fix from that.

I don't really know, but all I know is it all works now so I'm happy.

Read More...

I have more information now.

I built on a 4GB RPi4 using the standard raspbian 32-bit OS and ran essentially the same tests that I ran yesterday on the 64-bit OS build using a ASI6200MC camera.

Firstly, the auto-stretching automatically happening when adaptive sampling is turned on did NOT occur (as it had yesterday on the 64-bit OS). So either that was fixed or I hallucinated it yesterday.

In any event, I ran a sequence of 20 Bias image captures with debayering turned on, adaptive sampling turned on and auto-stretch turned on. I got the message about not being able to allocate the debayering buffer while processing the 9th image in the sequence, after which kstars crashed. Note: the memory monitor says the system has 3.32GB available and the monitor never showed resource use exceeding 2GB, but of course there could have been a spike that did not register prior to the crash.

Next I ran another 20 bias image sequence with debayering turned off, limited resource turned on, adaptive sampling turned on and auto-stretch turned on. The entire 20 sequence completed successfully.

Next I ran another 20 bias image sequence with debayering turned off, limited resource turned on, adaptive sampling turned OFF and auto-stretch turned on. KStars crashed after about 3 images.

So, what I get out of this is the following:

• adaptive sampling allows kstars to handle large sensor cameras WITH NO debayering on a 32-bit OS 4GB RPi4.
• with or WITHOUT adaptive sampling, kstars can handle large sensor cameras WITH debayering on a 64-bit OS 8GB RPi4.

So, I think I have some good news to report.

On the 64-bit Raspbian OS and 8GB RPi4 that I am experimenting on, I tried rebuilding Indi and kstars again today using fresh clones from GitHub.It reports as being Version 3.5.3 Beta. It not only built, but this time I was able to use it to capture images from my ASI6200MC, which I was unable to do earlier.

I used the FITS Viewer with debayering checked and adaptive scaling checked, but auto-stretch not checked and also set it to reuse the same FITS window for each image. I then took 20 bias images with my camera (I am at my desk so I could not attach the camera to the telescope and take Lights) and they all displayed with no crash.Incidentally, though auto-stretch was NOT checked, it still auto-stretched. That appears to be a side-effect of having adaptive scaling checked.

I then unchecked adaptive scaling and ran another 20 bias captures. Incidentally, this is when I noticed that auto-stretching was occurring with adaptive scaling because it wasn't happening now, so I went ahead and checked auto-stretching. Anyhow, again, no crash.

In the first instance the system memory monitor reported usage fluctuating between 3GB and 3.75GB. In the second case it was between 3GB and 3.6GB. Those numbers are just from eye-balling it.

Unfortunately I don't know whether the good news is because of the 64-bit OS or because of adaptive scaling or just some other improvement in 3.5.3 Beta.

I have yet another 4GB RPi4, so I will attempt to get the bleeding-edge copy loaded on to that over the next day or two and try to determine if the 64-bit OS had any hand in things not crashing or if it was the other possibilities.

I do have one outstanding question on a related matter that I hope I can get help on (feel free to create a new thread to answer -- I am not fully up to speed on this interface to do that)... anyhow, when I use the version I built under the 64-bit OS, it appears as if all windows, icons, fonts, etc. are magnified by about a factor of 2. Even the start-up splash screen is oversized (I am attaching a screen shot). I have tried playing with the system settings to reduce font and icon sizes, but that isn't fixing the root problem (e.g., no effect on the splash screen). Is there some -geometry or other setting that I need to imbed in some start-up file so that things are properly scaled? It is very annoying as the EKOS window extends outside of my VNC window and I have to drag the window up and down to alternate access the top of the window and access the bottom of the window.

Read More...

Hi. I have a ASI6200MC and if I shut-off the FITS viewer and am careful about quitting the Preview window after each use and use some binning when focusing / aligning, I can get by barely. Any slip up and it crashes. Even when careful, a crash is likely after several hours of continuous operation. I have a RPi4 with 4GB and an RPi4 with 8GB. I tried loading the 8GB with the arm64 raspbian OS (beta) and compiling Kstars/EKOS from scratch to get a 64-bit version to determine if the extra memory access alleviates the problem. I have run into a showstopper with that approach ("Exposure failed after 3 attempts") so I don't know if it would help. Has anyone successfully built an arm64 version? If that solves the problem, that seems like the best way to make all users happy (those that don't need it and want to stick with their current Raspberry and those that want it enough that they would not mind springing for an 8GB Raspberry and using the 64-bit OS.

Anyhow, for the here and now, perhaps a software binning option just for the FITS Viewer display (i.e., independent of workflow image capture) is another alternative?

It is definitely worthwhile to provide an option to release all FITS Viewer image related memory once the image is displayed. That should save having to kill the previewer and should also allow one to keep the FITS Viewer option on.

I am new to astrophotography having recently retired and taken it up as a hobby. I am both amazed and thankful for KStars/EKOS/INDI. Big sensor, however, are only likely to become more prevalent and need to be addressed, the sooner the better (IMHO).

Read More...

I was trying to compile kstars using the (beta) 64-bit raspbian and hit this problem from a change made to the source 20 days ago:

./Projects/kstars/kstars/indi/indistd.h:35:38: error: ‘Properties’ in ‘class INDI::BaseDevice’ does not name a type
 using Properties = INDI::BaseDevice::Properties;
                                      ^~~~~~~~~~