With the Toupcam ATRCMOS2600KPA driver I will (fairly often) get a failure where the image capture times out repeatedly. Some times the driver eventually crashes, but not always.

I have taken to running a set of 50 or more test captures before I do anything else, as the issue *usually* shows up in those. If it makes through 50 captures it *usually* is OK for the whole session. When it fails, I can exit KStars and restart with a fresh INDI service and often the 2nd connection will be good. I have changed out the usb cables and usb hub with no change in the behavior.

I turned on verbose logging for the CCD driver, but it does not report anything other than the same "Capture timed out" message that is displayed without CCD logging on. One such log is attached. Is there some other way to log things that would help determine if there is a problem with the driver?

Have you played with the timeout and usb settings of the driver?

I had not (thinking that was more a usb2 thing). After your suggestion I poked around and found the settings. Speed has only 0 1 or 2 available, I changed it from 2 to 0. Timeout has values from 1 to 10 labeled "Factor" that I changed from 1 to 10. Those changes *maybe* made some improvement, but did not eliminate the problem.

The most common symptom comes from taking a series of short exposures (flats, for example). Download times start at 0.16s and stay there for usually somewhere between 20 and 40 frames, at which time download times start increasing to 6 or more seconds, until eventually the camera times out.

After changing the two settings above I shot a series of 100 1-second exposures, which the camera made it through (though with some slowing down). I hoped that meant your idea had conquered the problem. But once the real imaging sequence started, the camera timed out while trying to focus - even though this was at least two hours after the test exposure series!

I can recover camera function by shutting down KStars *plus* unplugging and reconnecting the camera usb before restarting an INDI server. I *think* the unplugging is needed to reboot the camera.

My current (hopeful) workaround is to add a delay in between short exposures (still working out how much is required - when I took flats this evening 4s was not enough). I have, however, had the camera time out during an imaging run of 60s exposures (though I believe I had taken a series of flats at the start). Interestingly, the camera recovered on its own after maybe an hour and the sequence resumed.

I did try switching to usb2 by plugging the cable from the scope-top hub into a tripod-mounted usb2 hub, but the touptek driver crashed immediately in that configuration, so I went back to usb3.

I think I have the same cam model (cooled imx571 Color) - what works for me is to leave the usb setting at 2 and timeout >6. The cam is connected to usb3 of pi4 with cooling and fan active. Other than that pi is used only to run drivers and occasionally phd - all pictures are loaded up to my client computer via 1gb cable Ethernet.I had occasionally timeouts but the above removed them and now it happens very seldom, and never for calibration frames. Also, the driver description says it is sensitive to power fluctuations, so make sure the power supply works fine with enough power if you use the usb hub on the cam.

Thanks. I am running KStars on a mini-pc, as I found the pi just not up to the task of the large files produced by the IMX571 camera. I will leave usb=2 and timeout=10 for now. Tonight, hopefully, I will run a schedule without any short calibration captures (the imaging train has not been altered since I last took flats). Hopefully it will just run all night without timing out.

I run on mains power, so I have the luxury of having a separate 12v power supply for just the camera. The mount and everything else runs off of the 12v brick that came with the CEM40. That includes the powered usb3 hub through which the camera is connected to the pc, but I don't think the camera draws much, if any, power through its usb port. If I have trouble tonight I will try swapping in a different 12v supply for the camera.

well, this looks legit and should work. The only tuning I've done to the cam hardware was replacing the fan with Noctua's but this should not change much. Good luck and let us know how did it go - the sky clears here too so I'll try to do few shots myself.

Mariusz

Thanks. I went ahead and swapped out the power brick for a different one. Made it through one full night. So, cautiously optimistic.

interesting, hopefully it works for you - what's the difference between the power sources?

Both power bricks are 12v 3A. I have so many of them - I should get into the habit of labeling their original sources. I can't recall if the RisingCam ships with a brick? If so, then that is the "old" one. The "new" one, I cannot recall when or why I acquired it.

Ugh.

The driver / download timeout issue is back. There are two configuration changes. One is that the rig is indoors, with the telescope on the ground rather than in the saddle (I just needed to take some flats) - so the usb cable routing is different. The other is that I just updated KStars to the latest stable build. It downloaded and installed several camera drivers during the process, including Toupcam.

Whichever is the culprit, the driver times out quite frequently and would be useless for an imaging session.

This is a known issue with this driver, especially if you have two Touptek cameras connected at the same time. I don't know what is causing it, I've introduced lots of workarounds for the SDK timeouts, but it appears this is not sufficient.

Thanks for the information, Jasem. I have only the one Touptek camera, by the way. Are any of the known workarounds on the user side?

I switched everything off and re-seated some connectors and was able to get through some test captures OK after that, but it's worrisome to maybe have to rely on luck after driving an hour to a dark site. Hopefully a real solution can be found someday.