just to reconfirm:
my config:
- Pi 4 4GB
- Stellarmate beta channel (last update approx. 2 weeks ago)
- Asi 2600 MC
- Asi 290 (guidescope)
- EQmod (AZ-EQ 6)
- Celestron focuser
- Deep Sky Dad focuser
- Joystick
- Skysafari

I ran this system live last week (first clear sky for weeks; only one night, unfortunately). Took approx. 100 exposures whith guiding enabled. No crashes.

I had a very similar problem with my system crashing while operating the 2600 MC in parallel to my QHY 178III. This problem did not occur when I used Zwo cams only and it completely vanished now. I had this cam temporarily used on my equipment with a 50mm CCTV lens I attached, which gives me a 8 degree fov for the new PA routine. Again, no crashes.

I should mention that we use ZWO cameras only, also for guiding. And the crashes only happen if we use the FITS viewer a lot. The issue with the blank images also happens during sequences. Sometimes there are horizontal bands, sometimes just blank images. Very strange.

Yet another week of full clouds with no chance to test anything.

I’m also using ZWO camera’s for autoguiding as well.

Hopefully newer build fix this as a lot of folks are upgrading to these newer chips.

You can try to reproduce the crashes during daytime by covering your telescope with a white t-shirt to dim the entering light and taking 60 sec (for example) images. No need to wait for a clear night. As a matter of fact, with a bit of luck you can solve this before the next clear night so you won’t waste that!

For this specific issue I need to be able test this with guiding, mount control etc etc. I don't have an issue taking multiple subs like for calibration subs (darks, flats, bias) as this is only occurring during imaging runs for some reason.

I have upgraded my Pi4 onto the beta channel yesterday so if/when I get some good weather I'll be able to test it.

One of the first clear nights for an hour or two and I got to do some more testing with v3.5.2. Bad news and good news here.

I managed to get it stable for a short 30min session with the 2600mc by leaving the new adaptive setting "enabled" but had to disable WCS and debaying in the FITS viewer configuration. It ran through 15 x 2min subs until I got clouded out so this looks like at least folks will be able to image with these settings applied, so that's a small win.

Below are a number of Kstars crash dump logs from the debugger so am hoping this helps get to the bottom of the problem.


Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0xb439d428 in QThreadStorageData::get() const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#0 0xb439d428 in QThreadStorageData::get() const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#1 0xb49190c8 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".




Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0xb439d428 in QThreadStorageData::get() const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#0 0xb439d428 in QThreadStorageData::get() const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#1 0xb49190c8 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".



Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0xb439d428 in QThreadStorageData::get() const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#0 0xb439d428 in QThreadStorageData::get() const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#1 0xb49190c8 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

I have a similar setup as pug916: EQ6R, ASI2600MC, ASI290. I'm seeing crashes during imaging in both the Stable MacOS 3.5.2 to remote Beta SM, as well as Stable 3.5.2 SM on the SM device (via VNC).

I see some SQLITE_CONSTRAINT errors in /var/log/syslog:

<code>Mar 8 10:41:04 stellarmate ekoslive[941]: 2021-03-08T16:41:04.810Z info: [{"action":0,"directory":"/home/stellarmate/Pictures","file":"Test"}]
Mar 8 10:41:05 stellarmate kernel: [ 4016.914923] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Mar 8 10:41:09 stellarmate ekoslive[941]: 2021-03-08T16:41:09.718Z info: [{"action":0,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_001.fits"}]
Mar 8 10:41:09 stellarmate ekoslive[941]: 2021-03-08T16:41:09.968Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_001.fits"}]
Mar 8 10:41:10 stellarmate ekoslive[941]: 2021-03-08T16:41:10.319Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_001.fits"},{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_001.fits"}]
Mar 8 10:41:17 stellarmate kernel: [ 4029.235424] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Mar 8 10:41:19 stellarmate ekoslive[941]: 2021-03-08T16:41:19.698Z error: SQLITE_CONSTRAINT: NOT NULL constraint failed: metadata.bitpix
Mar 8 10:41:21 stellarmate ekoslive[941]: 2021-03-08T16:41:21.765Z info: [{"action":0,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_002.fits"}]
Mar 8 10:41:22 stellarmate ekoslive[941]: 2021-03-08T16:41:22.065Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_002.fits"}]
Mar 8 10:41:22 stellarmate ekoslive[941]: 2021-03-08T16:41:22.416Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_002.fits"},{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_002.fits"}]
Mar 8 10:41:30 stellarmate ekoslive[941]: 2021-03-08T16:41:30.939Z error: SQLITE_CONSTRAINT: NOT NULL constraint failed: metadata.bitpix
Mar 8 10:41:31 stellarmate kernel: [ 4043.265287] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Mar 8 10:41:35 stellarmate ekoslive[941]: 2021-03-08T16:41:35.821Z info: [{"action":0,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_003.fits"}]
Mar 8 10:41:36 stellarmate ekoslive[941]: 2021-03-08T16:41:36.072Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_003.fits"}]
Mar 8 10:41:36 stellarmate ekoslive[941]: 2021-03-08T16:41:36.322Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_003.fits"},{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_003.fits"}]
Mar 8 10:41:39 stellarmate kernel: [ 4051.825418] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Mar 8 10:41:44 stellarmate ekoslive[941]: 2021-03-08T16:41:44.704Z info: [{"action":0,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_004.fits"}]
Mar 8 10:41:44 stellarmate ekoslive[941]: 2021-03-08T16:41:44.955Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_004.fits"}]
Mar 8 10:41:46 stellarmate ekoslive[941]: 2021-03-08T16:41:46.065Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_004.fits"},{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_004.fits"}]
Mar 8 10:41:51 stellarmate kernel: [ 4063.176279] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Mar 8 10:41:56 stellarmate ekoslive[941]: 2021-03-08T16:41:56.388Z info: [{"action":0,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_005.fits"}]
Mar 8 10:41:56 stellarmate ekoslive[941]: 2021-03-08T16:41:56.638Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_005.fits"}]
Mar 8 10:41:56 stellarmate ekoslive[941]: 2021-03-08T16:41:56.889Z info: [{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_005.fits"},{"action":2,"directory":"/home/stellarmate/Pictures/Test/Light","file":"Test_Light_005.fits"}]
Mar 8 10:42:03 stellarmate ekoslive[941]: 2021-03-08T16:42:03.192Z info: bournbr: Ekos media client user disconnected from websocket server.
Mar 8 10:42:03 stellarmate ekoslive[941]: 2021-03-08T16:42:03.194Z info: bournbr: Ekos message client user disconnected from websocket server.
Mar 8 10:47:27 stellarmate systemd[1]: Started Session 5 of user stellarmate.</code>

Also seeing these:

just a thought: may this problem be related to the usb speed setting ? I have mine at 40%. No crashes.
Are you using USB 3.0 cables or USB 2.0 cables ?
How did you connect your mount ? via USB cable or blutooth dongle ? Somehow I had crashes with my setup, when I did connect my mount via the blutooth dongle. My mount has the newer board revision with the buit-in usb. I have no crashes when connecting directly via usb.

Definitely using USB3 cables and ports. EQ6R is connected via USB2. Where do you specify a USB speed?

Another thing that I noticed is that the images out of the 2600 are huge (52.2MB) when set to RAW 16 bit and 1x1 bin.

I think the speed setting ist called "usb bandwidth" and you can set it in the controls tab (the tab where you set offset, gain, WB etc.).
The images are huge indeed, but 20 megapixel with 2 byte per pixel plus some overhead give you exactly this size when not compressed.

Interesting - you mean the "Bandwidth" setting? It' set to 40 now. (Also set the "Auto Bandwidth" - give that a try)

UPDATE - I turned off "Auto Debayer" and "Adaptive Sampling" and haven't seen a crash yet (Config screen shot attached). Still testing.

UPDATE: Configuration as in the above screen snap.
"Auto Debayer" OFF
"Adaptive Sampling" OFF
"Auto Bandwidth" ON

Successfully generated 225 images from 2600MC without a crash.