unfortunately, I made the experience that the Indi driver for touptek cameras works very unreliable and I'm very frustrated now, because I have tried all kinds of problem solving attempts with no success but would really like to use Indi and EKOS for my setup. Really, I like EJOS a lot and would like to cobtinue using it.
Why do I think it is a problem of the driver?
1) it works reliably with Windows 10 and the exact same hardware (Lenovo Thinkpad, dual-boot), same cables, USB hub, other gear...
2) my two QHYCCD cameras (QHY 5II-L, QHY 168C) work fine with the same cables, USB hub, EKOS version
3) same problems with either Intel notebook or RPI4 (astroberry 2.04, 4GB RAM)
What is the problem exactly?
Usually after power on, boot , Indiserver start and connect it does work. I can take a picture with the touptek camera (usually 2x binned), plate-solve, take a picture again etc. Then I start guiding using the QHY camera and try to focus the main camera. This usually involves a changed exposure time, gain, binning and subframing. On the first attempt this usually works, sometimes the first failures (exposure timeout, rexposure attempt #2, final timeout) start to appear. Then I take the first test picture with the final imaging parameters but a short exposure time of a few seconds. In maybe 20% of the evenings this does work, but almost never as it should. The exposure starts counting down and just before download finishs a long break occurs. In lucky evenings the FITS viewer will appear and everything is fine if nothing major changes, I can do my exposure series. Unfortunately most of the time nothing will happen. The download will never start or if started will stop a few hundreths of a second before finishing. After waiting for some time, I can stop and redo the exposure. Usually with the same result. Sometimes reloading the driver, reconnecting using the Indi panel or changing some parameters will help after many, many tries but most of the time only a reboot will reliably make it wokr again for some time. Even if it works, any change like going back to focusing or plate solve will trigger the problem again.
What can I do to help solving the problem?
I have tried all kinds of permutations of hardware (new cable, hub, RPI4) and software (local Linux, remote Linux, remote Windows client) March version, January version. The error message about the exposure timeout does not help. I was unable to activate the debug mode, maybe that could help.
I had the same problems. There are some changes in the indi-toupbase driver ongoing. I have proposed a reset of the download estimation time after a change of the ROI that solved some issues. I have seen that user wlatanowicz has also made a proposal to overcome timeout problems. I think these changes will be deployed soon.
I had similar problems with my DSP 2600c Pro (IMX571 sensor) using the ToupTec driver. Timeout failures after setting a subframe (during AF) and switching back to full frame again. For me, AstroMax' solution solved the problem. But at the moment you have to build the driver from Max' GitHub fork by yourself until it will be deployed.
same happens here. Disconnecting my DSP 2600c in Indi control panel (KSTars and Ekos still running), disconnecting cam from USB, re-connecting USB and connect again in Indi control panel. Driver crashes immediately (KStars/Ekos as well).
I built everything from the latest git sources. Good news here: Timeout errors due to m_DownloadEstimation are gone.
254/1450 mm Newton, 130/730 mm APO, 70/336 mm APO, EQ6-R, ZWO EAF focusers, DeepSkyPro 2600c, ASI183MM, Intel NUC 8i5, Ubuntu 22.04
Thanks for the test Bernd. I have started to investigate this a bit deeper, The problem seems to be following:
When the driver ist started it enummerates all Touptec and Touptec OEM Cameras.
For each camera it creates a new instance of ToupBase and stores the information from the enummeration process (m_Instance) that is needed to open the camera with the Touptec library.
When the camera is unplugged and reconncted some USB parameters change. I am not an USB expert... but I think it is the USB bus number.
When the user disconnect the driver, unplug and plug in the camera and reconnect the driver the connect inforation for the Touptec library is no longer valid and the driver is not working correctly. This causes a crash of the driver
What I have done is to enummerate the cameras when the user reconnects the driver after the initial connect.
This code works fine for me but the solution has still some problems:
It will only work with cameras that can be enummerated by the touptec (or Omegon) libraries.
This driver has a very tricky solution to enummerate also OEM Cameras that are compatible to Touptec but that can not be found by the Touptec library. This process has to be incooperated to the enummeration process in the Toupbase class.
After the reconnect of the driver, the instance of Toupbase has to find the camera that was connected before if there is more than one Touptec camera connected.
I did not found a good solution for this problem until now. If I store the serial number of the camera when the instance of Toupbase is created and try to find this serial number later I have to open the camera with the Touptec library to get the serial number. If the camera is already opend by another instance the driver crashes. So I store the the display name of the camera to find it back, The display name is part of the enummeration information from the library. As a result, this solution works only if you have different models of the camera connected.
I do not understand completely the id that is retured by the Touptec libary enummeration function. If the camera can be clearly identified by this id, this would be the solution. Does anybody have more information about the Touptec library?
I found some rare random instabilities when the cameras were reconncted and images were taken. I will work on this issue.