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:

• Much larger camera files (new camera)
• Astroberry most people get is a 32-bit OS (and may not even have a 64-bit OS)

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)

• Different USB configurations (the cheapest option)
  • Still using various USB type A cables that I had laying around; had not bought any new ones yet
    • Used mount-included cable, as well as other cables I had (4 total)
  • Going USB from mount directly to the Pi4 did not work, no matter the USB port nor the udev rules
  • Using the hub on the camera worked okay, but ultimately I still had some errors and it was still inconsistent; not really acceptable from a trust perspective
  • Tried udev rules for all of the above attempts; didn't make any difference unfortunately
• Bought a new, higher quality USB cable
  • This didn't work; still having connection issues directly to Pi4 on all ports as well, same with ZWO CCD camera USB hub
• Bought a powered USB hub and even a fancy dovetail-compatible bracket for it
  • Figured this would solve my woes, but this ended up leading to my previous post and immense frustration
  • This was going from mount (with new USB cable) -> powered hub -> Pi4 USB3 port
  • Updated udev rules to account for the new hub; didn't matter and was wildly inconsistent; usually manifested in random "read/write" errors on the logs, which would sometimes manifest as full-on timeout errors which would completely ruin any guiding / tracking and happened randomly
• What ended up getting it working? A stupid unpowered USB hub that is actually currently connected to a USB 2.0 port on the Pi
  • No udev rules for the hub, only udev rules for the mount still in place; not sure if this matters or not at this point and will test to see how it behaves with no udev rules
  • USB setup here is mount (new USB cable) -> unpowered hub -> Pi4 USB2 port
  • I suspect this would also work on a USB3 port on the Pi4 but haven't tested this yet
  • Absolutely zero problems with read/write errors or timeout errors last night
  • HOWEVER as full disclosure, I ran into a lot of guiding calibration issues last night as well halfway through the session
    • I'm not sure if this is related though, so I would caution anyone away from thinking that the hub solved one problem but introduced another (I don't have enough info yet to be sure)
• Something I am going to try is getting a USB to RJ12 adapter to go directly from the Pi4 to the HBX input on the mount and see if that also has good stability
  • Not super confident about this, but might as well try different things at this point to save other folks with these problems a lot of time and $$$

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...