After working for so long without clear success, a simple chatgpt recommendation was hard to ignoreadmin wrote: Mon Apr 27, 2026 12:42 pm Hi,
well, that's a weird outcome, since the 'frame rate limit' option in SharpCap doesn't (shouldn't) have any impact on the USB traffic to the camera in question. Rather than slow down capture from the camera (which is often not possible), it ignores selected frames after they have arrived from the camera if the rate at which they arriving is above the specified limit. I would expect use of that to reduce CPU load and possibly GPU/user interface update loading, but do little to change the USB system loading.
On the other hand, if it works for you, it works....
cheers,
Robin
The clog I believe was never in the usb itself. Thats just a log artifact indicating the outcome (download failed) rather than the cause. The ZWO SDK log is not very helpful but Sharpcap logs are great when used in conjuntion with ZWO's.Both my computers are high end gaming, with multiple root hubs, cameras are separated onto root hubs, recent NVidia graphics processors, and high quality cables and power supply. I have not coded in some years but I suspect the way the windows low level driver set up is working, it (the low level windows process) is not able to handle simultaneous interactions with these cameras, quite possibly because the interaction with this specific planetary camera works differently for this driver. There is no breathing room at all. The fact that introducing even a 0.1 s gap works flawlessly is really amazing. Somehow it interrupts the constant and clogged chatter with the 676 to let the 2600 interaction start talking. I realize this is not how it was supposed to work. Even if I speed up the 2600 downloads to 1s or 2s, it works flawlessly now and I am not seeing any significant latency in the 676 pier camera or a sense of outdated frames in live preview of the pier etc. Live preview runs for the day with 1 fps on the 676 again with zero issues.
This 676 camera is directly connected into a root hub port, so there should be very little latency...... unless the 676 interaction is lumpy and has inconsistent latency or is clogging the lower level process supported by the windows driver. If say the driver stays busy with the 676 low level process for whatever reason, and while not crashing its consuming more than 1 fps, it might be sufficient to disrupt the 2600 download statistically once in 20 mins to an hour or something like that. I have not noticed any issues in the 676 Sharpcap log at all - no dropped frames or slow frames but it might be happening at a lower level. In your design, would you expect zero output from the 676 in that case (meaning a dropped frame), since 0.9 s is smaller than 1.0 s?
Interestingly, I have used a 462 or a 662 as my all sky cams on the ota many times with zero issues to either the all asky or main cam. I think the windows driver handles these fine, and they also generate smaller files.