indilib
Touptek 585-based cameras still disfunctional
Describe the bug Touptek 585C with latest (2025-01-24) firmware, libindi 2.1.4 and indi_3rdparty git 4ac3071f on arch linux arm, running on Rock Pi 5B+ still has issues:
- Images are often garbled, exampes here (3rd image is an example of the expected result)
- Images taken with hcg (gain 250, offset 60 is the setting), are excessively noisy, always with false color artifacts, see above pictures
- Images taken with HDR are either good, or half-downloaded, or have color artifacts)
- Driver is still unstable has a tendency to hang on end of exposure. Reset of driver does not solve anything, beides resetting the driver has a tendency to crash kstars/ekos A combination of indi 2.1.2/3 and touptek firmware from january worked well, but with 2.1.4 this specific camera became unusable.
To Reproduce
- Start up kstars, indi with camera, schedule a session, and wait. Short exposures seem to trigger the hang less often, than long ones (in this case 240s)
Expected behavior No hanging, no color artifacts, no half-downloads, images with a level of noise that is in accordance with the settings (one such included in the linked album)
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: arch linux arm aarch64 on Rock pi 5B+
- Version GIT
Log Files https://drive.google.com/file/d/1YjxWC_9ypT_StsgJB0aeeTusBRR7fW0O/view?usp=drive_link
Unfortunately not possible to make any exposure, just times out. I do not know how the driver interacts with the SDK, but it looks like a callback signalling the successful exposure never arrives.
[2025-08-07T16:33:07.570 CEST DEBG ][ org.kde.kstars.indi] - Adding managed driver "Touptek" [2025-08-07T16:33:07.622 CEST DEBG ][ org.kde.kstars.indi] - Driver "Touptek" is adding device ToupTek ATR585C (heuristic match) [2025-08-07T16:33:09.662 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" DSLR Cameras Info: [2025-08-07T16:33:09.662 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" QList(QMap(("Height", QVariant(qlonglong, 3464))("Model", QVariant(QString, "Canon DSLR EOS 600D"))("PixelH", QVariant(double, 4.29))("PixelW", QVariant(double, 4.29))("Width", QVariant(qlonglong, 5196))), QMap(("Height", QVariant(qlonglong, 2912))("Model", QVariant(QString, "Canon DSLR EOS 5D (normal mode)"))("PixelH", QVariant(double, 8.2))("PixelW", QVariant(double, 8.2))("Width", QVariant(qlonglong, 4368)))) [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureFormatS" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureEncodingS" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "FilterPosCombo" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureTypeS" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureISOS" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "videoDurationUnitCB" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "fileUploadModeS" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureExposureN" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureGainN" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureOffsetN" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "cameraTemperatureN" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "videoDurationSB" not found! [2025-08-07T16:33:09.663 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureFrameWN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureFrameHN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureBinHN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureBinVN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureFrameXN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureFrameYN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureCountN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "captureDelayN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "formatSuffixN" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "darkB" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "cameraTemperatureS" not found! [2025-08-07T16:33:09.664 CEST DEBG ][ org.kde.kstars.ekos.capture] - "[]" Option "enableDitherPerJob" not found! [2025-08-07T16:33:09.763 CEST DEBG ][ org.kde.kstars.ekos.capture] - Registering new Module ( "Mount" ) [2025-08-07T16:33:51.511 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Warning: option "Always Reset Sequence When Starting" is enabled and resets the sequence counts." [2025-08-07T16:33:51.513 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Idle" to "In Progress" [2025-08-07T16:33:51.514 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Warning: Guide deviation is selected but autoguide process was not started." [2025-08-07T16:33:51.515 CEST DEBG ][ org.kde.kstars.ekos.capture] - Preparing capture job "/home/lehel/Pictures/Dark/120@250_off60_temp-10_Dark" for execution. [2025-08-07T16:33:51.525 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Job requires 120.000-second images, has 0/100 frames captured and will be processed." [2025-08-07T16:33:51.540 CEST WARN ][ org.kde.kstars.ekos.capture] - No frame info available for "Primary" [2025-08-07T16:33:51.545 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "In Progress" to "Setting Temperature" [2025-08-07T16:33:51.545 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Setting temperature to -10 °C..." [2025-08-07T16:34:33.904 CEST DEBG ][ org.kde.kstars.ekos.capture] - Sequence job: capture preparation succeeded [2025-08-07T16:34:33.904 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture preparation succeeded, start capturing. [2025-08-07T16:34:33.904 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Setting Temperature" to "In Progress" [2025-08-07T16:34:33.904 CEST DEBG ][ org.kde.kstars.ekos.capture] - Executing the sequence job. [2025-08-07T16:34:33.994 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "In Progress" to "Capturing" [2025-08-07T16:34:34.006 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Capturing 120.000-second image..." [2025-08-07T16:34:34.006 CEST INFO ][ org.kde.kstars.ekos.capture] - "Capture exposure = 120 sec, type = Dark, filter = , upload mode = 0, gain = 250, offset = 60, batch mode = true, seq prefix = %t%T_%F_%t_%E@%G_off%O_temp%C_%T_%F_Dark, format = RGB, encoding = FITS, binning = 1x1, ROI = (0+3840, 0+3840)" [2025-08-07T16:39:33.619 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Exposure timeout. Restarting exposure..." [2025-08-07T16:39:33.621 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Capturing" to "Idle" [2025-08-07T16:39:33.621 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Idle" to "Capturing" [2025-08-07T16:44:33.620 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Exposure timeout. Restarting exposure..." [2025-08-07T16:44:33.621 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Capturing" to "Idle" [2025-08-07T16:44:33.621 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Idle" to "Capturing" [2025-08-07T16:49:33.620 CEST INFO ][ org.kde.kstars.ekos.capture] - "[ToupTek ATR585C] Exposure timeout. Restarting exposure..." [2025-08-07T16:49:33.621 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Capturing" to "Idle" [2025-08-07T16:49:33.621 CEST DEBG ][ org.kde.kstars.ekos.capture] - Capture State changes from "Idle" to "Capturing"
Is there any way I could help with the work, I am a sw designer, albeit not a very good one, as I was not yet able to figure out how these drivers should work. Seems to be that somewhere between 2.1.2 and 2.1.4 a change was introduced in indi or the driver which breaks the interworking, as 2.1.2 happily worked with the 202504 SDK without crashes, or botched exposures. The current indi stack does not work with that SDK. Even 2.1.3 was possible to make work with the same SDK by incorporating the timeout fixes, at least I used it that way until the 2.1.4 upgrade, which broke support for this camera.
Well, it's either the driver or SDK. One thing to do which might be time consuming is to GIT bisect until you find the offending commit. If you believe this is a driver issue, then you can use the latest SDK and git-bisect the driver.
It will take some time, because that requires to rebuild kstars and indi stuff on arm :), but I shall give it a try.
Rick chip has a bug: it only supports setting the USB 3.0 burst length to 0. If the kernel version is above 5.10, enable the CPU "performance" mode. If the version is below 5.10, apply the patch and enable the CPU "performance" mode.
Well, if I want to bisect, and the issues popped up with a new indi version, which now does not work with an sdk, that worked for the previous one, then it would be prudent to suppose, that the change breaking it would be in indi itself, wouldn't it? For downgrading indi I understand I also have to downgrade kstars, too, so that I am able to apply incremental builds on top to see where the behavior starts to show up.
Running tests on x86_64 now, the current driver&firmware combo seems to be stable on a Lenovo T440p, but practically all images downloaded are uselessly garbled, just like on the ARM machine.
Also tried yesterday evening on the Rock Pi 5B+, too, had a succesful run of 10 30seconds dark exposures, but after shutting down to do take out the gear under the sky, after the restart even after setting the CPU governor to "performance" mode all exposures failed with timeout. Unfortunately I am not able to test on other arm platform, as my only other one available is an RPI3, which is not able to run kstars/indi anymore due to RAM limitations.
I was only able to make it work on a 12th gen intel based laptop and USB3.1... All other devices, that I own display a similar issue, garbled data when downloading the frame.
Now after another restart of both camera and Rock PI 5B+ SBC it works fine, no hangs, collecting 240s dark subs, and no garbled data. I have yet to figure out how to sequence events (startup, governor change, connecting hardware) to get the error, and to get the proper functionality. But still no luck on older laptop, it seems to be, that USB3 is not handled properly by the driver.
Tested some more: when disconnecting from indiserver, ekos will hang. After that a complete power-cycle of the camera is needed to be able to start ekos again, as otherwise (even after killing the hanging processes with kill -9), ekos will freeze again. This behavior is consistent, and can be reproduced each time.
[2025-08-09T15:01:31.429 CEST DEBG ][ org.kde.kstars.ekos] - Disconnecting "ToupTek ATR585C" [2025-08-09T15:01:31.429 CEST DEBG ][ org.kde.kstars.ekos] - Disconnecting "Wave 150i" [2025-08-09T15:01:31.430 CEST DEBG ][ org.kde.kstars.ekos] - Disconnecting "ZWO CCD ASI290MM Mini" [2025-08-09T15:01:31.430 CEST INFO ][ org.kde.kstars.ekos] - "Disconnecting INDI devices..." [2025-08-09T15:01:31.496 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] dispatch_command: ":f1", 4 bytes written " [2025-08-09T15:01:31.496 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] read_eqmod: "=501", 5 bytes read " [2025-08-09T15:01:31.496 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[MOUNT] StopMotor() : Axis = 1 " [2025-08-09T15:01:31.497 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] dispatch_command: ":K1", 4 bytes written " [2025-08-09T15:01:31.497 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] read_eqmod: "=", 2 bytes read " [2025-08-09T15:01:31.497 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] dispatch_command: ":f2", 4 bytes written " [2025-08-09T15:01:31.497 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] read_eqmod: "=501", 5 bytes read " [2025-08-09T15:01:31.497 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[MOUNT] StopMotor() : Axis = 2 " [2025-08-09T15:01:31.498 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] dispatch_command: ":K2", 4 bytes written " [2025-08-09T15:01:31.498 CEST INFO ][ org.kde.kstars.indi] - ZWO CCD ASI290MM Mini : "[INFO] Camera is offline. " [2025-08-09T15:01:31.499 CEST DEBG ][ org.kde.kstars.ekos] - "ZWO CCD ASI290MM Mini" is disconnected. [2025-08-09T15:01:31.499 CEST INFO ][ org.kde.kstars.ekos] - "ZWO CCD ASI290MM Mini is disconnected." [2025-08-09T15:01:31.507 CEST DEBG ][ org.kde.kstars.indi] - INDI server disconnected from BLOB manager for Device: "ZWO CCD ASI290MM Mini" Property: "CCD1" Exit code: 0 [2025-08-09T15:01:31.517 CEST DEBG ][ org.kde.kstars.indi] - Wave 150i : "[COMM] read_eqmod: "=", 2 bytes read " [2025-08-09T15:01:31.530 CEST INFO ][ org.kde.kstars.indi] - Wave 150i : "[INFO] Wave 150i is offline. " [2025-08-09T15:01:31.530 CEST DEBG ][ org.kde.kstars.ekos] - "Wave 150i" is disconnected. [2025-08-09T15:01:31.530 CEST INFO ][ org.kde.kstars.ekos] - "Wave 150i is disconnected." [2025-08-09T15:01:31.550 CEST DEBG ][ org.kde.kstars.indi] - INDI server disconnected from BLOB manager for Device: "Wave 150i" Property: "ALIGNDATA" Exit code: 0 [2025-08-09T15:01:31.554 CEST DEBG ][ org.kde.kstars.indi] - INDI server disconnected from BLOB manager for Device: "Wave 150i" Property: "HORIZONLIMITSDATAFITS" Exit code: 0 [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 19: read EOF" [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 19: shut down complete - bye!" [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 16: read EOF" [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 16: shut down complete - bye!" [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 17: read EOF" [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 17: shut down complete - bye!" [2025-08-09T15:01:31.607 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "" [2025-08-09T15:01:31.608 CEST DEBG ][ org.kde.kstars.ekos] - "ToupTek ATR585C" is disconnected. [2025-08-09T15:01:31.608 CEST INFO ][ org.kde.kstars.ekos] - "ToupTek ATR585C is disconnected." [2025-08-09T15:01:31.613 CEST DEBG ][ org.kde.kstars.indi] - INDI server disconnected from BLOB manager for Device: "ToupTek ATR585C" Property: "CCD1" Exit code: 0 [2025-08-09T15:01:31.715 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 18: read EOF" [2025-08-09T15:01:31.716 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "2025-08-09T13:01:31: Client 18: shut down complete - bye!" [2025-08-09T15:01:31.716 CEST DEBG ][ org.kde.kstars.indi] - INDI Server: "" [2025-08-09T15:01:33.718 CEST DEBG ][ org.kde.kstars.indi] - INDI: Stopping local drivers... [2025-08-09T15:01:33.718 CEST DEBG ][ org.kde.kstars.indi] - Removing managed driver "EQMod Mount" [2025-08-09T15:01:33.718 CEST DEBG ][ org.kde.kstars.indi] - Managed driver "EQMod Mount" has device "Wave 150i" that will be removed [2025-08-09T15:01:33.719 CEST DEBG ][ org.kde.kstars.indi] - INDIListener: Removing device "Wave 150i" [2025-08-09T15:01:33.719 CEST DEBG ][ org.kde.kstars.indi] - Removing managed driver "Touptek" [2025-08-09T15:01:33.719 CEST DEBG ][ org.kde.kstars.indi] - Managed driver "Touptek" has device "ToupTek ATR585C" that will be removed
ps ax | grep indi 938 ? Sl 0:00 /usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/panel/plugins/libsystray.so 6 12582921 systray Status Tray Plugin Provides status notifier items (application indicators) and legacy systray items 147175 ? S 0:01 /usr/bin/indiserver -v -p 7624 -m 1024 -r 0 -f /tmp/indififof39345e8 147176 ? S 0:00 indi_eqmod_telescope 147177 ? Sl 0:00 indi_toupcam_ccd 147179 ? Sl 0:00 indi_asi_ccd 149487 pts/0 S+ 0:00 grep indi
Restarting the driver from the indi control panel results in a sigsegv in kstars, seems like the "yes" button handler is not impelemnted properply?:
Thread 1 "kstars" received signal SIGSEGV, Segmentation fault. 0x0000aaaab4b903d4 in ?? () (gdb) where #0 0x0000aaaab4b903d4 in ?? () #1 0x0000aaaab4b9190c in ?? () #2 0x0000ffff8503cbe4 in ?? () from /usr/lib/libQt6Core.so.6 #3 0x0000aaaab4997fc4 in ?? () #4 0x0000ffff8503cbe4 in ?? () from /usr/lib/libQt6Core.so.6 #5 0x0000aaaab4997944 in ?? () #6 0x0000ffff8503cbe4 in ?? () from /usr/lib/libQt6Core.so.6 #7 0x0000aaaab4997a44 in ?? () #8 0x0000ffff8503cbe4 in ?? () from /usr/lib/libQt6Core.so.6 #9 0x0000ffff8503cbe4 in ?? () from /usr/lib/libQt6Core.so.6 #10 0x0000ffff862f7028 in QAbstractButton::clicked(bool) () from /usr/lib/libQt6Widgets.so.6 #11 0x0000ffff862f7348 in ?? () from /usr/lib/libQt6Widgets.so.6 #12 0x0000ffff862f8d88 in ?? () from /usr/lib/libQt6Widgets.so.6 #13 0x0000ffff862f8fd0 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libQt6Widgets.so.6 #14 0x0000ffff8621e71c in QWidget::event(QEvent*) () from /usr/lib/libQt6Widgets.so.6 #15 0x0000ffff861af754 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt6Widgets.so.6 #16 0x0000ffff861ba19c in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt6Widgets.so.6 #17 0x0000ffff84fc2dac in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt6Core.so.6 #18 0x0000ffff861b95b0 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) () from /usr/lib/libQt6Widgets.so.6 #19 0x0000ffff862352f8 in ?? () from /usr/lib/libQt6Widgets.so.6 #20 0x0000ffff86237ef8 in ?? () from /usr/lib/libQt6Widgets.so.6 #21 0x0000ffff861af754 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt6Widgets.so.6 #22 0x0000ffff84fc2dac in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt6Core.so.6 #23 0x0000ffff858264d4 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /usr/lib/libQt6Gui.so.6 #24 0x0000ffff858a2b64 in QWindowSystemInterface::sendWindowSystemEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQt6Gui.so.6 #25 0x0000ffff7b1bdd1c in ?? () from /usr/lib/qt6/plugins/platforms/../../../libQt6XcbQpa.so.6 #26 0x0000ffff82d8a05c in ?? () from /usr/lib/libglib-2.0.so.0 #27 0x0000ffff82d8c9a8 in ?? () from /usr/lib/libglib-2.0.so.0 #28 0x0000ffff82d8d3c4 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #29 0x0000ffff85313ce4 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQt6Core.so.6 #30 0x0000ffff84fd2e8c in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQt6Core.so.6 #31 0x0000ffff84fcc944 in QCoreApplication::exec() () from /usr/lib/libQt6Core.so.6 #32 0x0000aaaab427457c in ?? () #33 0x0000ffff837a20d4 in ?? () from /usr/lib/libc.so.6 #34 0x0000ffff837a21b8 in __libc_start_main () from /usr/lib/libc.so.6 #35 0x0000aaaab4939b70 in ?? ()
On the rockchip, the only way to get the camera working (and thereafter it seems to be quite stable, until a power recycle of both board, and camera):
- start up
- sudo -i
- echo performance > /sys/devices/system/cpu/cpufreq/policy6/scaling_governor
- power cycle camera and unplug/replug USB from computer
This procedure was successful 3 times. If starting up without the echo, even though the board is already in that configuration, the camera will fail to download the frame, and only hang thereafter.
After aforementioned crash happens, camera can only be recovered by following this procedure, simply power cycling and unplugging the camera will not help.
FYI: I will only be able to test issues with this vendor for a limited time, as based on the past 8 months experience I decided to get rid of all touptek related products from my gear.
Even if image download seems OK, platesolving fails, seemingly none of the possible the extractors gets access to the image. This is only an assumption, as in the logs there is no trace of the image taken, neither the alignment subsystem trying to do anything with it.
Rick chip has a bug: it only supports setting the USB 3.0 burst length to 0. If the kernel version is above 5.10, enable the CPU "performance" mode. If the version is below 5.10, apply the patch and enable the CPU "performance" mode.
Performance mode partially solves the problem, but not completely: one also has to power the camera down by removing the 12V power supply, disconnect it, then re-connect, and power up. This usually allows the user to take 3-6 sub-frames, then the camera freezes up again, and a camera+driver re-start is required.
Another issue is, that platesolving is not possible, because the frame, although is taken, is never forwarded for processing. The last log messages is "image received", thereafter no logs related to imaging/alignment are displayed.
This applies to both USB3.1 and USB2 ports of the SBC.
I observe the same behavior when connecting the camera to my "astrolaptop" a Lenovo T440p. It would be strange that two systems so far away from each other in release time, and achitecture would display such similar issues.
This also effects the guide camera, if connected through the 585, both cameras are patchy. When connecting the ZWO 290MM directly to the SBC, it does not display any issues similar to the 585C. This suggests that maybe the way the camera handles the USB data transmission is the issue, and
Another issue is, that platesolving is not possible, because the frame, although is taken, is never forwarded for processing. The last log messages is "image received", thereafter no logs related to imaging/alignment are displayed.
Switching to the guidescope with the ZWO 290MM has no issues downloading images. Also when exchanging the 585 to my old Canon 600d, that one has no issues either. Are you sure it is the only the usb issue(s) mentioned in the patch, that cause these downloading errors?
I recompiled and moved to indi 2.1.5, and indi-3rdparty git HEAD, the camera is pretty much unusable on all of the testbeds:
aarch64 and gen4 intel: see above comment 12th gen i7: exposure never ends.
x86: Switching to 2.1.4 in both indi and indi 3rdparty, and reverting d2844d0c makes the camera work again. capture, platesolving works.
Same applies to aarch64 with one major difference, the driver quite often crashes when changing settings on the related control panel, and it has a tendency to take down ekos, and kstars alongside with itself.
Trying to restart the toupbase driver also kills ekos and kstars with segv
I believe I am encountering a similar issue. I am not a programmer or Linux expert (I am a chemist by trade), so please excuse any imprecise statements.
I am running StellarMate OS on an x64 mini-PC with Kubuntu 24.04, and I see the same behavior on both version 1.8.0 and the latest 1.9.0. My Touptek 585C crashes after a large number of exposures, whether short or long, and when this happens it brings down both Ekos and KStars.
An important point is that my camera firmware is updated to version 4.49, which requires drivers from 2025 or later; older drivers do not work. As far as I know, there is no way to downgrade the firmware. In my testing, the only driver that works reliably is the one based on LIBTOUPCAM_VERSION "57.28200", specifically the x64 libtoupcam.bin from commit #1067 (“update Touptek & OEM lib, version: 57.28200.20250408”). Every other 2025 libtoupcam version fails with this camera and firmware.
To restore stability, I rebuilt only the libtoupcam module from indi-3rdparty 2.1.4 (I assume it would also work with 2.1.5) and replaced the x64 libtoupcam.bin with the one from commit #1067. After a normal make and make install, the crashes disappeared. From what I can tell, the only stable option for the 585C with firmware 4.49 is the driver from commit #1067, while all later versions have issues and 2024 drivers are unusable.
it goes randomly from a minimum of 30-40 to more than 200 ... then segfault
Ok I updated toupcam_test binary now to take exposures directly with the SDK without using INDI. Just to see if the INDI driver is causing these issues or not. After you compile the driver, you'll see toupcam_test binary that can you run like this. For example, to capture 10 images each 5 seconds logn:
./toupcam_test -n 10 -e 5
Then test it for 200+ and see if it crashes or not.
Same experience as baro666 the most stable combo is 2.1.4 with 20240408 SDK both for x86_64 and aarch64. Might be worth testing it with a raspberry pi or a stellarmate pro, so that the result does not get polluted by the aforementioned rockchip bug.
We will set up the environment for testing. Please wait for our report. Thank you for your patience.
Same experience as baro666 the most stable combo is 2.1.4 with 20240408 SDK both for x86_64 and aarch64. Might be worth testing it with a raspberry pi or a stellarmate pro, so that the result does not get polluted by the aforementioned rockchip bug.
Probably you meant 20250408 SDK (20240408 doesn’t exist, right?!?). According to Touptek and also in my experience, 2024 builds don’t work with upgraded firmware.
With 20250408 SDK the camera runs but I still see random crashes after ~50–200 exposures (however, I have to test on a fresh system install...).
Looks like an SDK-only issue to me: regardless of the indi3d revision, stability depends solely on the version of the libtoupcam.bin file included. Isn’t that file actually just the libtoupcam.so from the SDK???
Yes, but actually on x86_64, indi 2.1.2/2.1.2.1, it was stable, at least I was able to do multiple nights of shooting without any crashes. But that was with an earlier firmwares (I remember ate least 4 updates since 202409 all related to HDR mode, and I patched the camera with all of them as they were issued). At least I do not remember any particular frustration during springtime.
We tested it on the Raspberry Pi with 1000 images, and everything was OK. Next week, we will test it on Rockchip.