I experienced the exact same Monday night with my HEQ5 mount. I’ve never experienced it before. I ydes the ASTAP solver, but everytime I moved the star into the middle of the crosshair my error had increased by 2-10’. I tried 3 times all with the same result. Then tried switching to the internal astronomy.net solver and suddenly my error decreased (that is, without making any adjustments to my mount!). One aligment routine later and my error was 11”. One additional run of the PA routine (just to check the error - so no adjustments made) again gave me an 11” error.
It seems my problems got cured by switching from the ASTAP solver to the offline astronomy.net solver.
Unless KStars/Ekos automatically updates itself etc. then this cannot be the answer as the output written in my latest post was from yesterday. And I haven't updated anything since then. However, when I now look at the Julian date written in the output and online convert it I get the date (by removing the number 24 in the beginning of the date) April 22nd - 2020 (today) and not yesterday?
But I hope it works now.
And now it won't crash! I bet that tonight when I set up it crashes...
But last night I copied the output from the command line. Here's the interesting last part of it:
A backtrace from gdb of one of the crashes from my previous install (using the AstroPi3 script) is in my original post.
Ok, I've gotten closer to a possible reason:
AF3 worked great until suddenly it caused Ekos to crash. I've so far installed Ekos using the AstroPi3 script. I decided to test out AstroBerry to see if that made any difference. Then AF3 connected without problems and everything was great again, until I hit the good old:
sudo apt update sudo apt upgrade
All installed at the same time as kstars using the AstroPi3 script. Worked two nights ago and crashed last night. Nothing had been changed or updated between the two nights.
Two nights ago everything ran smoothly without problems. I'm running Kstars 3.4.1 (build using rlancaste's AstroPi3 script a week or two ago) on my RP4 4GB unit.
Last night I had experienced something I've never experienced before with Ekos. I started Kstars/Ekos as usual and connected. I tried focusing, but that failed to find a star. I tried the polar alignment routine, but that failed to plate solve due to a blank image. I tried capturing a 30s light frame but that just came out blank as well (and yes, my lens cap was removed ).
I then tried rebooting my RP4 unit, started Kstars and then opened Ekos. I selected my usual profile but just after that Kstars/Ekos crashed (segmentation fault) - it just managed to open the Indi control panel before the crash. When re-opening kstars and starting Ekos I was told that the indiserver was already running. I shut that down and tried again with the same result - seg. fault. I tried some debugging with just the mount and my ccd camera in a profile. That worked and everything started.... BUT when capturing a light frame as a test it was just blank. Also slewed to other places in the sky resulted in blank frames.
I always start kstars from the command line. I got these messages last night:
I looked at my Indi settings for my camera and noticed that most of the settings had been reset to default, except gain, offset and WB settings. Everything else had been reset.
I disconnected and tried adding my focuser (DeepSkyDad AF3) to my profile again with a seg. fault as my result...
I ran 'gdb --ex run --args kstars' and got this:
As a last resort I tried running kstars as "root" using 'sudo kstars'. This started a brand new instance of kstars and I had to set up my devices etc. again but that worked. Actually it ran better than ever - I've never had the Polar Alignment routine run as smoothly as this time as the refresh just smoothly refreshed the image every second. When running this normally it's sometimes a bit clunky in refreshing. Also the focusing was running like a dream and very fast. I then tried disconnecting my profile, shut Ekos/Kstars down and opened again. Selecting my profile and.... seg. fault! Tried just the CCD and that worked but everything in the settings was back to default again?!
I gave up! It was one of the clearest nights in a very, very long time and I couldn't capture anything. Very, very frustrating.
What's going on?
I can report that I experience the exact same error with videos recorded with my ZWO ASI 294MC Pro camera (and actually also using the CCD Simulator!).
How can I change the SER-file header to see if that helped?
Ok, I just tried using VNC through the ethernet connection instead. That's faster, but still lagging a little bit (but it's nothing alarming). Is there a way to get the Ubuntu server to do the following concerning network connections:
1) If ethernet is connected, WiFi signal is disabled
2) If no ethernet, then enable WiFi and look for a known WiFi (eg. my own WiFi at home) and connect to it
3) If no known WiFi is found, then use the RP as an access point.
I can't even seem to figure out how to connect the Ubuntu server to my home WiFi....
andefeldt wrote: Ok, I installed everything on 32bit Ubuntu using the AstroPiMaker4 file. I rebooted after creating the AP and loaded up the VNC viewer from my Mac. That did NOT look good! It looks like something from the late 80's or start 90's when it comes to color and graphic and text - like something from the good old Commodore 64 days. Text not clear and everything running very slow. I didn't experience this with my old setup (using Raspbian and the AstroPi3 script). Am I missing something here?
Did you configure VNC viewer to use 24 bit color and best quality? Can you share screenshot?
Ok, I installed everything on 32bit Ubuntu using the AstroPiMaker4 file. I rebooted after creating the AP and loaded up the VNC viewer from my Mac. That did NOT look good! It looks like something from the late 80's or start 90's when it comes to color and graphic and text - like something from the good old Commodore 64 days. Text not clear and everything running very slow. I didn't experience this with my old setup (using Raspbian and the AstroPi3 script). Am I missing something here?
I decided to cancel as I had a problem with the AP creation (not sure what happened). Creating the AP just froze - are you supposed to interact somehow?
I’ve started all over with the 32bit Ubuntu.
andefeldt wrote: Hi,
I've just got a RP4 4GB that I want to use instead of my current 1GB (or is it 2GB?) RP4. I decided to give the AstroPiMaker4 script a spin. Is there a particular reason that it uses the 32bit Ubuntu version and not the 64bit?
Good question. In the past, 64 bit was challenging. Keep in mind that the script does not care if it is 32 bit or 64 bit, so feel free to try and report back.
Before doing this, please check if PPAs have 64 builds of kstars and other software.
I've just got an RP4 4GB that I want to use instead of my current 1GB (or is it 2GB?) RP4. I decided to give the AstroPiMaker4 script a spin. Is there a particular reason that it uses the 32bit Ubuntu version and not the 64bit?
El Corazon wrote:
Herrhausen wrote: I don't think so. When I look at the results that I get I'm not worried at all.
I don't know....
I think Andy Grove was on to something when he coined the phrase:
"Only the paranoid survive"
Maybe you should be afraid.... VERY afraid....