I also update my darks a couple of times a year. I take them using a fridge to reach the desired temperature, I usually take them every few degrees. I image at a fixed gain (50) and exposure (I use 12 seconds as I find that is long enough to pick up faint stars and yet not produce noticeable star trails), so I only need to match the dark to the camera temperature (I store the temperature in the Dark Frame Name, so it is easy to search on and find the one closest to the image temperature). I have ImageMagick loaded on the Rpi and run command line routines like "level" and "brightness-contrast" to sort of stretch the image. All of the image storing and processing routines are run in shell scripts that are called from subroutines in the main capture.cpp (C++) program.
I have thought about changing the camera (ZWO ASI 120MC) parameters when the moon is out, but I have not found camera settings that deal with a bright moon and can still image stars. I will look into how you are dealing with this. I also like the idea of determining sky brightness and logging this with the AP images I take with my telescope, on the same night. It may help set my expectations when I process the images.
I have had a lot of fun with the AllSky camera project over the past 3 years, it is probably time I did some updating of the program and equipment. I am on my second Rpi as the USB ports on the first one stopped working after about 2 years outside (the Rpi and camera are in a water tight junction box container with the usual plastic dome.)
So thanks for providing an alternative approach.
I am interested in your project, I have been running my own modified version of Thomas's software on a Rpi 3B with a ZWO camera, for several years. In my version of the software I make use of darks, to remove hot pixels, and stretching algorithms to bring out the most in the images. I have found that I need to take darks over a range of temperatures, because the hot pixels for my ZWO camera depends on the camera temperature. And in order to cancel them out I have to match both the exposure time (which I fix) and the camera temperature when the image is taken.
Can you briefly outline how you handle darks and any additional image processing.
I did find 3 asteroids (already known but not by me) by imaging an object over an extended period of time with multiple exposures. The image sequence clearly showed 3 objects moving relative to the stable background stars. So the process is certainly viable.
Concerning the crashes of Ekos using a Raspberry Pi 4, that is what I use a Raspberry Pi 4 with 8 Gbits of memory, running EKOS 3.5.0. However, I too had crash issues, especially during plate solving before I changed the operating system to 64 bit Ubuntu. I found that the 32 bit operating system was not consistent in performing the plate solving operations and would sometimes crash. I consulted with someone involved in writing the PHD2 code and we concluded that changing to a 64 bit operating system resolve the issues and it did. I would suggest you explore that path as an option.
I think I read someplace that the Kstars team is only (mostly) supporting the LTS (Long Term Support) versions of Ubuntu, which would be 20.04 LTS, you may have a longer wait for the newer but less supported versions.
I am running Ubuntu 20.04 64 bit on a Rpi 4 with 8 Gb RAM and my latest installation is Kstars 3.5.3 stable; as I recall it had all the components and my ZWO and SX camera were working.
Ubuntu 20.04.2 LTS
I installed only the Ubuntu Server and then then the lubuntu desktop, I am running it with Lightdm as the desktop manager.
Kstars 3.5.3 stable Build 2021 -04-26T13:22:43Z
It has the EKOS tab and as I indicated my cameras all seem to work.
However, this is not what I am currently using (I set this up an a new SD card), my current system at the telescope boots from an SSD and is still running Kstars 3.5.0 in which everything is working and I am reluctant to update it until I am positive I will end up with a working system.
I have always had this issue with my CGEM mount as well. It also comes up with crazy numbers for how much the mount should be moved during PA. I set the PA option to manual move, then I open up the "motion control' panel in the mount tab and note the 'hour angle' I then use the 'motion control' panel to move the mount 1 hour for each 15 degrees of motion I intend to use for PA. I don't have to go outside to see the mount, the panel tells me what direction the mount is moving, I can control the speed of motion with the 'motion control' panel. It works fine and quick and performs PA exactly as it should. The only time I have to go to the mount is to make the final PA adjustment, for that I start the PA looping (after it has presented the correction arrow or line) and at the scope I monitor the progress of my 'adjustments' using a tablet that is linked wirelessly to the Rpi running Ekos using VNC.
I never have resolved why the PA angle motion numbers are so large or that it does not move as intended, I have just continued to manually move it and it works just fine.
It seems I may need to build indi-core first, but I get errors when I try to build that also.
yet on a command line if I run indiserver indi_sx_ccd it says startup: indiserver indi_sx_ccd so something is working. It is just that EKos is not recognizing it somehow at it still shows it is not connected.
tried enough for tonight.
I have a CMAKE error 285 of "could not find INDI include directory"
looking at the log now, it does not help much.
Yes, I found that and I did that and now I have Kstars 3.5.3, but the SX CCD still does not show up in the Indi Control panel, but I do get a message that I should check and see if it is powered and connected. It is as it shows up in lsusb and it runs under PHD2, it also seems to connect if I just run the device manager and run its service. But it does not connect in Kstars/Ekos. I am going thru the process of building the 3 rd party drivers now, installing all the dependencies .
I am installing all the dependencies to build now. But still unsure of how to build the 3rd party drivers for SX CCD. I will have to look on the git page when I get to that point.
I had an indication from Jasem that the PPA had resolved the issue (a day or so ago). When I use the ppa and install Kstars-bleeding I ended up with Kstars 3.5.4 Beta and my SX CCD still did not show up in the Indi Control Panel. So I was trying to find a way to get to 3.5.3 stable. I found this info on one of the download pages:
"If you would like to stop using Nightly PPA builds and instead return to using stable PPA builds then run the following commands:
sudo apt-get install ppa-purge
sudo ppa-purge ppa:mutlaqja/indinightly "
So I did that and I ended up with Kstars 3.5.3 Stable, but my SX CCD is still not connecting. However now I get a message from Indi(?) that the SX CCD is not connecting and I should check if it is connected and powered up. It is connected, it shows up in lsusb as the Starlight Express Lodestar and it runs fine in PHD2.
I seem to be making progress as at least now I get a warning about the SX CCD but I don't know how else to debug the connection to Kstars/EKOS
If I go to the Device Manager in Kstars and select the SX CCD and hit Run Service it says:
"Driver Indi_sx_ccd pid=2074 rfd=4 wfd=11 efd=12
Client 5: new arrival from 127.0.0.1:46726 - welcome!"
so somewhere it seems to be recognized, but not in Ekos?
the log does not tell me much more than it is not connecting.
Having run the ppa:purge above will I now only get 'stable' versions of Kstars rather than nightly builds? Yet installing kstars-bleeding seems to imply that you will get the latest (nightly) build. I have not tried it but can you just run:
sudo apt-get install kstars (instead of kstars bleeding)
Not sure any of this has to do with the SX CCD issue. It does seem that this update of release of 3.5.3 stable has a lot fewer issues than a few days ago. I am just trying to let the developers know that there are still some issues.
I did not purge the previous 3.5.3 but went to the ppa and installed Kstars-bleeding and it left me with Kstars 3.5.4 Beta instead of 3.5.3 Stable? I am trying to purge the nightly build ppa and try again. Could you explicitly show the commands you used to install Kstars 3.5.3 Stable. The Kstars 3.5.4 Beta was still not showing my SX CCD in the Indi Control Panel, so I am still trying to get a stable working Kstars for my equipment.
I am still having an issue with my SX CCD (Lodestar camera). I did the update/upgrade on my Ubunto 20.1 system and it upgrade Kstars to 3.5.4 Beta (?) instead of stable. I created a new profile with all my equipment and everything shows up in the Indi Control Panel, except the SX CCD. The CGEM, ZWO CCD, SX Filter Wheel all are there but no guide camera. The SX CCD loads in PHD as stand alone and works, but I cannot connect in EKOS because there is no panel for it.
I tried re-installing indi-full and Indi-sx but it tells me I already have the latest version. I indicated this to Jasem in my initial camera issue thread, but thought I might run this by you as well.
thanks for any help you can offer.
I just did an update and upgrade to Kstars 3.5.3 on my Rpi 4 running Ubuntu 20.1 and the SX CCD still does not show up in the Indi control panel. The SX FilterWheel does and so do the Zwo cameras and all seems to be working, but there is no tab for the SX Lodestar. The SX camera works when directly connected to PHD2, but I cannot connect to it in EKOS.
thanks for all your efforts in this latest release.