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.

Hi Ron,

Just for the sake of narrowing down the possible problem sources - are you able to test the cam with the native touptek windows software/drivers (or N.I.N.A.)?

It's likely to come to that. When I bought the Beelink I cloned the Windows11 installation to another SSD before I installed Ubuntu (not sure I did it completely - I think I still need to make it bootable). I am seriously considering swapping that SSD in and setting up to give NINA a try.

I suppose it would be wise to try just from my Windows laptop the next time I have the camera inside, before I go to all the trouble of setting up the Beelink for Windows imaging. I'd miss you guys A reliable IND driver would be the best solution.

Well, as said, it's to identify the cause - if you have the same problem with windows drivers, then NINA won't help neither. But it's always good to explore - Good luck!

I can say this is most likely a platform/architecture issue. A fair comparison would be to test PHD2 on Linux on the same platform with their native Touptek drivers against KStars on the same machine with INDI drivers. If PHD2 native drivers does not suffer from timeout issues, then it is indeed an INDI driver issue fair and square.

Thanks. I will install the Touptek capture application on a Windows laptop, plug in the Risingcam ATR3CMOS26000KPA and let it run a while.

I wish I had kept better notes about each time the driver crashed or timed out, because it did work much, much more reliably in the past than it does now.

The camera has been capturing frames in the Touptek Windows app for a few hours without a hiccup. Not a totally definitive test, because it will sometimes go 6 or 7 hours in INDI before the driver times out. But it's enough that I will try to spend some time during an upcoming cloudy stretch getting Windows properly installed on the miniPC and starting to figure out NINA.

One more small data point. After the successful tests in windows, I tried a similar configuration in KStars with only the camera connected, no extra hubs, etc.

The INDI driver obliged by crashing immediately, before even trying a test capture. Restarting INDI resulted in the camera driver reporting a failure to read the sensor temp. After a power cycle of the whole system it has behaved itself so far, though I assume it would still be subject to crashing at 3am, as is its habit.

I did learn one thing about my system. I have been in the habit of saving images to a usb flash drive, both for the convenience of bringing them inside in the morning and because that was a much faster storage medium back when I was using a pi + SD card. I have always had an issue where download times would go from 0.16 up to 6 or more seconds after capturing 20 or 30 short exposures (flats, for example), that I had blamed on the camera. As part of the minimal system I was saving to the internal SSD in the mini-PC, and that phenomenon was not there. A full 100-image sequence of 0.5s frames saved, with all having the normal 0.16s download time. Went back to saving to the flash drive, back to long downloads after 20-30 frames. Immediately restarted the sequence but saving to the internal SSD again and all 100 frames downloaded quickly. So that issue is not due to the camera or driver.