Hello,
I intend to build kstars on ubuntu 22.04-03.
Following the instructions on this page , I got an error about kio-dev & kdoctools-dev not being found.
Are both those dependancies really mandatory ? I can understand kio might, as it seems related to I/O, but kdoctools seems about documentaion - which I don't really mind at this point.
I could not find anything for kdoctools-dev using apt-cache search, but kio-dev gave a correspondance as libkf5kio-dev.
What should I do at this point ?
Rgrds,
J.-Luc

I suggest you to try Nou’s scripts to build kstars and related paraphernalia on Ubuntu: gitea.nouspiro.space/nou/astro-soft-build

What are you running Ubuntu 22.04.3 on? Is there a reason you are trying 'build' Kstars rather than just installing it from the PPA? I have recently upgraded to Ubuntu 22.04.3 on my Rpi 4 and I have loaded Kstars 3.6.8 and Firecapture (which is now available for the ARM processor of the RPI) directly and all seem to be working, with the usual startup kickups.

Hi

Try:
libkf5doctools-dev

HTH

I will give it a try. Seems nice.
Thank-you.

I am running it on a Portégé Z-30 core i5 16GB / 256 GB (soon a 1 or 2 TB NVME one).
Previously used Nikon DSLR driven by qDSLSDashboard, then a Pi4 8GB which was too slow and crashed more than it ought to.
Then bought a Pi5 8GB which I once thought it finally had solved my problem, but since the last update it started lagging and crashing again more than often.
It is bound to a powered USB3 hub, which my CCD is connected to as well as my USB NVME drive.
Since I moved from DSLR to CCD, I could take pictures less than ten times in one year. Mainly because the CCD (ZWO ASI183MC nc) sends too much data that the Pi's cannot deal with correctly.
Unless should there be some other reason that I couldn't find so far.
So I decided to switch to something a little more powerful. I installed Kstars on the laptop from PPA and did some testings that made me confident : despites the high throughput, perfectly suceeded in 3600 shots @0.2 s with no lag (or very little) nor crash.
And the average video rate of 7.6 i/s against 2.8 for the Pi5.
However, I noticed that the versions differ between the Pi and the PC : I suspect the Pi to be latest (2024-01) and the PC stable (2023-12).
So I decided to compile myself so I could check and test.

Yes, that is what I could find from the scripts suggested by Massimo.
Just wondering why apt-cache search could not find it, but now all is OK and I am going to go on.
Thanks.

So, building only Kstars would not have been enough and would certainly have led to problems.
Many thanks for your tip.
Too cloudy and too tired to test anything ATM. Hope I can do it tomorrow or this week end.
Rgrds,

I can only relate my experience. I am using an Rpi4 (8 Gb), also with a USB 3.0 SSD drive to boot from. I am running a server version of Ubuntu 22.04, with a minimum desktop, Kstars 3.6.8, Phd2, Firecapture v2.8 (the latest ARM64 version). I have an Anker 7 port powered USB 3.0 hub that connects to my CGEM, a ZWO EAF, an ASI120MC finder/guide camera (on a small refractor), and either an ASI 533MC or an SBIG 8300M (with SX filter wheel ). I have worked thru all the bugs (it does take some time), and I have been successfully using all this equipment for a couple of years. I can reach 60 fps, using Firecapture, with the ASI 533MC, as that ZWO camera does not have a high speed mode at 8-bit video.

I have the RPI at the scope (I roll my system out of my garage) and connect to it over an ethernet cable using VNC (X11VNC on the RPI). I also attach an Android tablet, (using USB tethering) to the RPi so I have a screen at the scope when I do PA. It is certainly not the fastest or most powerful setup to control the equipment, but I have not found it limiting for doing all forms of Astrophotography, from long exposure to planetary video. I am using a 256 Gb SSD and created a 4Gb swap space to help with memory issues, but I don't know if that is required.

I do have a dedicated power supply (12 volt from AC) that powers all the equipment. I have a 12 v to 5 v Buck converter to provide power to the Rpi, while everthing else is powered directly from the 12 v source or from the powered USB hub. If I can be on any more help in figuring out why your system is not functioning up to expectations, just let me know. But I can probably only tell you what I do, as I am not a pro at this (I simply Google my problems a lot!!).

Hello Ronald,
Formerly user of a DSLR tethered via a PiZW as wifi to usb bridge for qDSlsDashborad ran from a tablet. 1000 shots at 1/8000s lasted roughly 8s.
I then decided to decrease the weight and changed for a ZWO CCD to use with my Pi4B 8GB. Kstars was finally to be used, but since then I never could enjoy my new setup.
I spent (muuuuuuch) more time trying to figure out how to make it work correctly than having fun shooting nebulaes.
With this setup, 1000 shots at 1/32000s would last at least 2500s - yes, you did read correctly : 42 minutes !
After Jasem kindly explained that I had to set to distant instead of local, it would drop to 1200s - 20 minutes.
This is pure theorical, because I never (or very rarely) could take more than 60 to 90 pictures before it began lagging and hanging.
The SM OS together with the SM app did not make things go better.
I then bought a NVME SSD, an USB3 case and an USB3 powered USB hub, hoping this would solve the problem. Which unfortunately it did not.
I then lastly bought a Pi5, which I first thought was the solution. All the tests I did in taking up to 3600 shots at 0.2s were successful.
Unfortunately, there then were updates on both the SM OS and app, and things went bad again : lags and hangs.
I discovered too that every modification I did to the db, such as adding a lens, would make it stop working. And I had then to delete the db from the disk and recreate everything from scratch.
All those issues - except lags and hangs - are still present on my new config on the laptop running Ubuntu : 2+ seconds added to each take, malfunction after modifying setup and malfunction after updates.
Moreover, the indi config is (randomly ?) lost from a session to the other. So I keep a copy that I restore when that happens. This is the ZWO CCD ASI183MC_config.xml in the /.indi folder.
I must - and I will - take some time to list all this and open reports, trying to be as clear and exhaustive as possible.
BTW : I built following the instructions from Massimo's post.

My system is a fanless Celeron J4125, 16GB RAM, 1TB NVMe SSD running Ubuntu 22.04.3 LTS with Xfce Desktop Environment.

I use a 12V powered TP-Link UH720 HUB 3.0 USB hub to link cameras and other devices (QHY268M, QHY5III178M, QHYCFW3, HEQ5, Pegasus Focuscube).

Power is ensured by a Meanwell LRS-150-12 150W 12V transformer.

Right now I'm on the bleeding edge of both Indi, Indi3rdparty, Kstars etc... I have hiccups and error from time to time, but since I'm still perfecting my latest setup (switched from an "easy" 80mm Apo to a dreadful RC8), I do not mind much. In my opinion, the secret is that after you have a flawless configuration (if such a thing exists) in terms of equipment, the next step is to aim for maximum stability in the software and then STOP upgrading!!! At least until you decide that some additional features are necessary... or you want to make your life more difficult .

my two cents.

Best (and thanks again to Nou for making my life easier)
Massimo

Yes, I do occasionally get hangs, but usually not until I have completed the Polar Alignment (PA) as I roll my scope out every night. Once I have completed that then I can just shutdown and reboot the Rpi (if Kstars hangs) and not loose my place in imaging, Kstars will come back up in the last configuration. I have had an issue with the latest version (3.6.8 ) that I cannot create a "NEW" profile consisting of optical train, but I worked around this by using an older equipment profile and then modifying the optical train once it loaded. This seems to work, so I have not researched what the problem is.

My CCD camera (SBIG) is much slower in downloading images, it may take it up to 2 second to download its 6 Mpx image, That is just the nature of a CCD chip. So I have never tried video with it. My ZWO ASI cameras (the ASI120MC and ASI533MC) are CMOS chips and download much faster (a fraction of a second). But they too have a frame-per-second (fps) limit based on how deep of a 'well' you are collecting (10 bit or 12 bit) and how large of an image you are collecting; full frame size for your ASI183 is 5496x3972 and at 12 bit its maximum frame rate is listed as 19 fps. If you reduce the well depth (this is set able in the Indi control panel or in other software such as Firecapture) to 10 bits and you reduce the size of the image by collecting only a Region Of Interest (ROI) such as 640x480, then the frame rate can go up to 180 fps.

When I am imaging Deep Sky Objects (DSO's) that have low 'brightness' my exposure times are in tens of seconds (typically anywhere from 5 sec up to 180 sec depending on how well the mount is behaving in guiding) and so the download time becomes negligible compared to the exposure time. So three hours of data collecting (at 10 sec exposures) will only net me around 1000 images. This is normal. The images are multi Megabit size and 1000 of them will start to take up disk space, so I make sure my 256 Gbit SSD drive has enough free space (usually not a problem for this type of session). I do download the images, after the session, to a tower pc for processing.

If I am imaging planets or the moon, the objects are brighter and the exposures become much shorter (maybe a few milliseconds). The way to capture this data is to use 'live-streaming' from the CMOS camera (I cannot do this with the CCD chip very effectively). In the Indi-Control panel, for the ASI camera, you can set-up the required ROI for the object and the exposure time and then tell it to 'live-stream' to the screen. That live-stream can then be captures in a file which has a Sequence of all the frames (an SER format). Now I am capturing at a frame rate of 60 fps, so it will collect 10,000 frames in 3 minutes (which is the longest exposure time for Jupiter as the planet rotates fast enough to cause blurring in the final stacked image - unless you are able to use de-rotation in the post processing software). You can also use Firecapture software to collect these 'videos,' it has a complex but more accessible interface to the camera for adjusting and optimizing the collection process. These video SER files will be multi-Gigabit in size and I have, on occasion, run out of disk space on the 256 Gbit SSD. That will definitely cause issues.

I have set up the Ubuntu server version 22.04.3 with a lite desktop, but I added a few extensions, so I can monitor both the CPU and Disk activity (and temperature) along the upper task bar. With this I can see if what I am doing is stressing the RPi4. Usually the CPU will peak as a program starts, but then immediately settle down to a low mid range activity, as most of the time it is doing nothing while I enter the collection parameters. I make sure I have downloaded enough index files to be able to plate-solve with my smaller camera. On rare occasion, the scope gets lost and I have to "Blind" solve (not use current position information) and that has always worked to get the scope synced to its correct pointing location.

There is the rare night (maybe 2 or 3 times out of 100) that nothing seems to work, everything crashes or hangs no matter how many times I reboot. I chalk this up to a power issue, I have a regulated 30 amp 13.8 volt power supply that runs off of our AC. We live out in the country and occasionally we have 'brown outs' or flickering lights, so these things happen.

There is no doubt that Kstars/Ekos has evolved into a complex collection of programs and algorithms as it tries to do more and more. I tend to stick to the next to last 'stable' version that has been used for at least several months, so that there has been some time to work the 'bugs' out. I have three SSD's they contain; Ubuntu 20.04 LTS with Kstars 3.5.3, Ubuntu 20.04.3 LTS with Kstars 3.6.2 and now the latest with Ubuntu 22.04.3 with Kstars 3.6.8. So I always have a fall back to an earlier version which I have successfully used many times, if something comes up that I cannot resolve and it prevents me from having a successful imaging session. Of course, the latest version has many improvements that are helpful, but not always necessary. So if there is something I want to capture (like during the current Jupiter opposition) I make sure I have plenty of options.

Hope this helps in explaining another users experience. I have been using Kstars for probably the last 5 years and I am too familiar with its interface and capabilities to want to change.