Workaround for ZWO SDK issue causing camera fail in sharpcap

[SanjeevJ]

Dr Glover, I will provide more context below, but I would like to ask about an idea I can use (or any you have) to get past a stubborn ZWO SDK issue (even with their latest 3.27 release). I am a lifetime subscriber of Sharpcap and it is my primary tool for DSO and planetary live stacking, dso sequences and imaging (everything except focusing and framing, which i do in Nina).

The issue is very simple. I have 10+ ZWO cameras of mixed vintages. On my remote set up, I two instances of Sharpcap - one for the newer 676 as my pier camera (1 second exposure) and second one for my older 2600 MC Pro (say 6 second exposures). Regardless of which sdk (going back a few versions), or stand alone drivers (going back multiple releases) - if I run Sharpcap preview (or live stack) with both at the same time, I get a camera download error on the 2600. This shows up as some USB clog on ZWO ASI Studio's SDK log. If I use ASCOM 6.5 driver from ZWO on Nina for the 676 (which is not ideal for me) and use Sharpcap for the 2600, I can go on endlessly with zero frames dropped - Sharpcap does not even need to try to reconnect.

- Can you think of a clever option to get around this? I have already put these cameras on separate root hub controllers on my remote PC, ofcourse tried all sorts of driver updates. I wish ZWO would update the firmware on my 2600 as they did for two of my 2600 MM Pros in January - thats what it took to get those two cameras into a fine shape working with Sharpcap. They acknowledge my issue and have seen the logs but seem stuck at the next step.

One thought idea I had was to somehow try installling Sharpcap twice, like separate programs. If the primary issue is ZWO's SDK having trouble talking with both cameras and some issue with the 676 interaction is causing a failure to communicate with the 2600 -- is there some way I can force Windows to use two separate instances of the ZWO SDK - one working with the 676, and another with the 2600. So whatever the driver state ends up being with the 676 interaction, the 2600 main imaging camera can still go on? I am not a coder but this is as far as my thinking has allowed me to get to.

Just fyi, I have been on a painful journey trying to get my cameras working reliably in sharpcap - this painful part started roughly in the Nov 2025 time frame when ZWo started making some major changes. I had gone for 4 years prior to that using my cameras in Sharpcap with zero issues. Now amy cameras with mixed vintages, ZWO has trouble with. I must have spent over 200 hours testing since November.. in many cases, simply trying to find a combination of ZWO windows driver and sharpcap program driver that allowed each of my cameras well.

Appreciate any thoughts or help you can provide!

[SanjeevJ]

Needless to say, all infrastructural issues are eliminated, I know enough to do that. All my rigs have 13.8V power supplies, high quality cables, powered Pegasus power box advance etc. For the current issue, I paid the remote observatory to replace all cables (even though they were new). The fact that I can go on endlessly as I described but cannot use the ZWO SDK natively for two instances of Sharpcap in this case leads me squarely to a firmware / SDK / standalone driver issue, and I have tried them all.

[admin]

Hi,

sorry to hear that you are having this sort of problem. Fortunately it's relatively easy to make more than one copy of SharpCap using the different SDK versions, since you can just copy the whole SharpCap install folder to another location on your computer and then put the different SDK into that new location in place of the one that SharpCap installs by default. All you have to do from there is to run the right 'SharpCap.exe' (creating appropriate shortcuts on the desktop might be the best idea) and then you can have two different copies using the two different versions of the SDK. It *should* be fine running both of them with different cameras at the same time, providing that the driver itself doesn't take a dislike to two different SDK versions (which I doubt, but is just possible).

Hopefully that will provide an easier approach than having to copy the SDK into the SharpCap folder each time you want to switch. Unfortunately I'm rather limited in that I can't go back to older SDKs unless there are catastrophic issues with the latest versions, as going back would usually mean losing support for the latest models.


cheers,

Robin

[SanjeevJ]

Ty! To confirm, say I have the latest version of Sharpcap installed in c:|programs\sharpcap or something like that...

do i simply create another folder like c:\programs_second\sharpcap and copy everything that was in the first folder over and add a shortcut to the second?

[SanjeevJ]

I just tried that. Even with a separate instance of sharpcap running, IF I am running the 676 with native driver, Sharpcap in the other instance still gets the camera download error on the 2600. What is common between these two? Are they still dependent on the ZWO Windows Driver install? Do i even need the ZWO windows driver install if I am using standalone drivers in these two instances? Something upsets the 2600 version but only when the 676 instance is running with a native driver.

Warning 12:39:33.401774 #26 Fetching still frame from ZWO camera failed with ExpFailed, exposure is 6000, timeout is 16600 in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, double startingExposure, BufferFrame frame, CancellationToken cancellationToken)
Debug 12:39:33.402237 #26 Finished ZWO Exposure of 6000ms, gotFrame = False

[SanjeevJ]

So, given this situation, I have a question for Dr Glover (since I dont know how the lower level ZWO driver files (from the ZWO Windows Driver Installation) work with Windows and Sharpcap..

The issue seems to be the ZWO Windows Driver, since it repeats even with separate instances (entire separate program directories and files)...

Is it feasible to basically duplicate the Windows Driver as well and assign one to each camera?

So for eg:

1. Install ZWO Windows Driver 3.25 (which works perfectly with the older cameras)
2. Copy the directory over to another (just like I did with Sharpcap)
3. Install ZWO Windows Driver 3.27, let it over ride the default directory
4. Device manager -- assign the older 2600 the 3.25 driver, and assign the 676 the 3.27 driver
5. Point one entire instance of Sharpcap to 2600, and another at 676
6. SInce the WIndows Driver interaction creates a "driver state" issue, if it can stay contained to that instance of the driver (say 3.27), I am hoping the 3.25 driver can continue to work with Sharpcap and 2600 (which is the only camera in this combination that has the download isssue).

Is this worth a shot?

[admin]

Hi,

well, that might work, but I have never tried anything like it - I suppose it is worth a shot.

Another thing I would suggest if at all possible is to try a different PC and see if the issue still shows up on a second PC. In the past there have been cases where the USB system of a particular PC would cause issues with some cameras, but changing to a different PC (different motherboard chipset, etc) resolved the problem.

One more thing to check if you haven't already is the power supply to the PC. We have had several cases recently of similar symptoms when using mini-PCs (Beelink, etc) and multiple cameras. These have ended up being down to the PC 12V power supply not being powerful enough to supply the power required when the PC is busy (2 or more cameras) and supplying power to run the cameras. Sometimes these issues have appeared on formerly working systems, which might imply that the power supply ages or the PC draws more power over time (perhaps dust in the cooling system makes the fans run harder or similar).

cheers,

Robin

[SanjeevJ]

I decided to use chatgpt for help... this situation is not an easy solve although its a painful issue. I literally have a library of asicamera2.dll files and zwo windows driver installs I have saved from various versions of zwo and sharpcap releases over time and a matrix that says which model and vintage works with which driver(s) and sdk.

In about 15 minutes flat, ChatGPT gave me a solution for the current problem after working with me on a Q &A basis. Actually its a work around but that workaround is so good, it qualifies to be a solution.

It accurately assessed that the issue is with the windows level low-level driver files that ZWO requires to be installed. There is no workaround to those files at the operating system level, and you cannot copy them based on how Windows works with these low level files (so thats the answer to my question above). Playing with the SDK will do nothing in this specific situation (although it helps in others).

It then told me, the issue is the 676 camera and how ZWO's low level driver interactions are leaving insufficient room for the 2600 downloads to succeed.

It then suggested I use a Sharpcap feature I have never used that has always available to me in the camera panel. This feature is the frame rate limit! TY Sharpcap!

By setting an exposure that is smaller than the frame rate limit on the 676, you are essentially creating a little space for the 2600 camera to get its download started. This works perfectly with even a 0.1 second gap set for the 676, showing that basically this is a code / config issue in ZWO's low level driver for Windows. A ZWO code/ config issue and a Sharpcap camera setting addresses it. What a brilliant solution from AI!

Wanted to pass this on so it will help others. I know of at least two other people that have been struggling with the same issue, and I have let them know directly. Please -->> If Sharpcap can include just one more setting in the frame rate drop down -- a frame every 1.5 seconds (currently 1s, 2s are choices) that would make it a solve for nearly all secondary imaging situations without having to spend more time tuning.

I dont kow if there is a pool of testers who actually test how well ZWO stuff works in Sharpcap as they roll in changes, sometimes fast. I am spending so much time "out of cycle" testing and validating ZWO's updates with Sharpcap when i run into issues, I am happy to volunteer a bit of my time to do some validation testing as we go (and as I can) at major releases. Since I have 10+ cameras of mixed vintages and other ZWO tech, its a good asset.

[SanjeevJ]

Hi,

well, that might work, but I have never tried anything like it - I suppose it is worth a shot.

Another thing I would suggest if at all possible is to try a different PC and see if the issue still shows up on a second PC. In the past there have been cases where the USB system of a particular PC would cause issues with some cameras, but changing to a different PC (different motherboard chipset, etc) resolved the problem.

One more thing to check if you haven't already is the power supply to the PC. We have had several cases recently of similar symptoms when using mini-PCs (Beelink, etc) and multiple cameras. These have ended up being down to the PC 12V power supply not being powerful enough to supply the power required when the PC is busy (2 or more cameras) and supplying power to run the cameras. Sometimes these issues have appeared on formerly working systems, which might imply that the power supply ages or the PC draws more power over time (perhaps dust in the cooling system makes the fans run harder or similar).

cheers,

Robin

I have two high end gaming PCs I use for both set ups, also use professional 13.8V power supplies, professional or DSO camera grade USB3 cables etc. Luckily found the root cause and a fix with ChatGPT's help!

[admin]

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