Something you may be able to do to recreate (and what I used previously) was to just take a lot of dark frames over a long period of time, especially if you need to build a darks library for specific temperatures and haven't had time yet.
Otherwise, can just take a lot of covered photos even if they aren't needed for calibration frames; the bug tended to reproduce itself when doing something like that for me.
There are also some
ways you can log RAM usage
over time.
Could use something like one of the answers to log RAM, CPU usage of Kstars over time to a local file and cross-reference, such as a one-liner I quickly cobbled together based on that answer:
while true; do ps -p <kstars_PID> -o %cpu,%mem,cmd; sleep 5; done | while read memStats; do echo "$(date): $memStats"; done | tee -a memtest.logs
This was my experience as well - I delved waaaay into the rabbit hole when I was having this problem and found the "turn notifications off" potential solution (there are a number of threads on this, with this proposed solution), and it didn't seem to matter.
Read More...
Can do!
I am more than happy to help - I think I lost some significant chunk of my overall life expectancy getting the GEM45 working, so if I can save anyone even a fraction of that grief, it's worth it haha
Read More...
Try `dmesg -Tw` on the command line while swapping cables out, that may give you more information around the Pi actually detecting / allocating the USB port correctly (or not) at least.
I also recall running into weird issues where just having the cables plugged in during boot versus plugging in after would sometimes cause problems, but I wasn't able to delve into that further to figure out if that was actually the cause or not =(
Read More...
I was running this version as well, it still crashed aplenty (may or may not be related).
My particular problem was almost certainly two things in conjunction:
This may not be the problem nor solution - I debugged this *endlessly* with my GEM45, and a powered hub didn't help (but I did spend money!).
See the culmination of my mostly-complete "saga"
here
.
The USB to RJ12 adapter however did *not* work, and the guiding issues were because I suck at polar alignment.
I did run into the "[ERROR] Failed to connect to port (/dev/ttyUSB0). Error: Port failure Error: No such file or directory. Check if device is connected to this port." problem as well - it was because the Pi couldn't assign it a USB adapter correctly, iirc because of the mount itself (was often the problem with the GEM45 when going direct-to-mount with the Pi).
You can see this on the Pi4 terminal by running:
dmesg -Tw
Alright, I've returned after much frustration to at least provide a bit of an update for folks that may be having the same problem; things I tried and how they ended up (and current progress)
Welp, I'm farther back than I was before, with no reason as to why.
All of a sudden tonight I'm getting a huge number of mount I/O errors and timeout errors, it won't slew correctly, can't even set initial calibration to guide now.
Nothing I've done differently, in fact I even shelled out for a powered hub which seemed to solve the problem, also got a fancy USB cable just for the absurdity of the GEM45 mount. Even had a few nights with superb guiding, images, etc.
Now it's every ~5s I get an I/O error and timeout errors; nothing has changed, I'm even using the same USB ports...
Honestly, I don't even have the heart to keep fooling with it at this point; I'm going to try to reach out to iOptron but they've not returned any emails, otherwise I may try to initiate a return and get a NUC or something. Not enough painkillers in the world to deal with this headache at this point, seemingly purely based on the whims of fate.
Read More...