increase USB timeout

[ckuethe]

Doing a bunch of USB disk IO was killin' the capture on my rPi. Bumping
up to 1500ms allowed capture to run successfully while copying lots of
data.

[EricClaeys]

ZWO suggests setting timeout to (2 * exposure) + 500 ms, which is what version 0.8 uses.
Version 0.7 used either 200 or 1000, which is less than what version 0.8 uses. (It had captureTimeout set to -1 for night, but that got overwritten by the shorter daytime limit).

How do we know (2 * exposure) + 1500 is the right number? The ZWO developer who's looking into the ASI_ERROR_TIMEOUT issue asked if we've ever tried -1, which waits forever.
I suggest we either set it to -1 or add 5000 ms instead of 1500.

[ckuethe]

Yeah, I saw their recommendation in the comments. Still captures cause bus resets on every exposure, which might be what they're trying to compensate for. Using the old (video) based capture algorithm, I'd get one bus reset transitioning across day or night modes, and no impact from heavy bus activity.

...
[53955.455879] usb 1-1.1.2: reset high-speed USB device number 5 using dwc_otg
[53961.025875] usb 1-1.1.2: reset high-speed USB device number 5 using dwc_otg
[53966.595909] usb 1-1.1.2: reset high-speed USB device number 5 using dwc_otg
[53972.175893] usb 1-1.1.2: reset high-speed USB device number 5 using dwc_otg
...

We can try some experiments; maybe exposure_time+5s might be a good approach which doesn't create unreasonably long timeouts for long exposures, but does leave time for heavy USB traffic.

Imagine someone connects an ASI6200MM to a pi 0W? That could be sending 62Mpx 16-bit raw images over USB2. I doubt anyone would do such a silly thing, but the timeout code should be robust enough to handle it.

What about capture_time + (Pixel size * ceil(byte depth) / 10 ) + 5? We expect the exposure will take as long as we asked for, plus the time to naively transmit a raw capture (10-bit ADC = 2 bytes) at 10MB/s (real world number based on low-quality USB thumbdrives), plus 5s for whatever.

[EricClaeys]

Chris, ZWO describes their cameras as having two modes: "snap" mode where you take a single picture and where auto-* isn't supported, and "video" mode where the camera is constantly taking pictures. AllSky uses "video" mode and produces the USB reset error in kern.log whenever we turn on video mode by calling ASIStartVideoCapture(). Version 0.7 did that once and 0.8 (with "newexposure" on) does it for every picture. Why it does it at all I'm not sure, but ZWO support is aware of it. Personally, I think it's a bug.
Version 0.8 has a longer timeout than 0.7, so it's hard to imagine the timeout value causing the ASI_ERROR_TIMEOUTs, but who knows with ZWO's SDK. If we want to rule out timeout, we can just set it to -1. Or we can do as you suggested and base it on the number of pixels. FYI, the "bufferSize" variable takes into account the number of pixels, depth, and bin, so would be a good value to use. And it's updated if the day and night bin are different.
Eric

[ckuethe]

Yes, usb resets do seem buggy. I haven't fired up my 3d printer to print some more round tuits, but after I get a few I might look at what the library is doing.

Because I also don't trust the SDK to not do broken things, I'm reluctant to go with an unlimited timeout. If something goes wrong, I'd prefer to have a bounded operation time so that allsky doesn't hang. I don't much care if we boost 500ms to 1.5 or 5s, just that by turning it up a bit I avoid daytime capture timeouts under heavy USB load - which tells me that 500.3ms is too short (was taking 150us exposures) under the circumstances. 1500.3ms was long enough.

Gettin' off topic, I quite like the histogram based daytime exposure controls and would love to see it available for night exposures too. To my eyes, it produces better/more useful images than ZWO's auto-exposure.

[EricClaeys]

I'm all for adding 5 seconds (5000 ms) to the timeout.
ZWO is looking at their autoexposure bug, which primarily (or only?) happens during daytime images. Our histogram method takes multiple pictures until it finds a good one, then uses that. For daytime exposures of 1/1000 second, that can be done in a second or two. For nightime exposures of, for example, 30 seconds, it could take several minutes to get to a good exposure. I suppose there could be a cutoff that says if you don't find a good exposure in maxexposure time, then use the best exposure and change the next exposure.

[EricClaeys]

Thomas, this looks good to me.
Eric