Sharpcap Stalls on data transfer from QHY168C

[Antman72]

Only when using the direct QHY driver instead of ascom the first frame to come through and whenever you change the duration of the capture the frame takes up to and over the amount it took to take the frame.

Example: 2 minute capture takes over two minutes to transfer to the program. Sometimes it does not transfer at all and does not drop either just keeps counts negative time since capture.

Does not happen using ascom but there is no color debayer option in ascom. Does not happen with sg-pro/theskyx/fire capture/ezcap-qt. USB setting in sharpcap has no bearing on outcome no matter where it is put. 0-60. All logs are from same night.

Please advise next steps if any.



Version of SharpCap- 3.1.5.115.0 PRO
Camera and other hardware being user qhy168c / zwo1200mm-s
Operating system version win-10 x64 on a custom built high end PC USB 3.0
Contents of the SharpCap log after the problem has occurred.

Log_2018-04-01T00_49_37-4240.log

(41.14 KiB) Downloaded 138 times

Log_2018-03-31T21_50_36-6912.log

(211.86 KiB) Downloaded 146 times

Log_2018-03-31T13_57_12-1240.log

(46.55 KiB) Downloaded 149 times

[admin]

Hi,

thanks for the detailed report - it sounds like you have been through a lot of troubleshooting steps already without getting any results

There is nothing bad showing in your logs, but that just supports the idea that the QHY SDK is not getting around to sending the frames to SharpCap for some reason. I wonder if the fact that the frames sometimes arrive after an additional 2 minutes indicates that a high proportion of frames are being lost by the SDK, and when one does come through it is after 4 minutes, 6, 8 etc. There is currently no timeout in SharpCap when waiting for a frame from a QHY camera (I have done this in other cameras where the delivery of frames is less reliable and the camera sometimes needs to be reset, but never needed to for QHY).

I don't have a quick solution for this - the version of SharpCap you are using already has the latest QHY SDK in it (no new updates since last year ). The fact that other programs work tends to rule out hardware issues, but if you are using a long USB3 cable, do retry with a shorter one. If you have a second PC you can test on that would be good too.

It would be interesting to know if you find any range of settings that make the camera work propery - for instance

* shorter exposures - 100ms? 1s? etc
* reduced resolution
* binning
* 16 vs 8 bit mode vs RGB mode

finding anything that works and then finding the boundary between what works and what doesn't sometimes helps locate the issue. I suspect that we might need to raise this one with QHY though.

cheers,

Robin

[Antman72]

Hi,

One thing i wanted to add.. Lets say the sharpcap is set to two minutes... The frame will eventually push through when the timer reaches the next frame completion.. IE 2 min sub comes through at end of next two minute sub. I will try the other things you mentioned. Can you report this to QHY? I am sure this is a SKD Dll issue as it does not occur with ASCOM. Here is a photo showing the timer and my settings.

PS: I tried shorter cable 3.0 with no success. I am using Monster brand gold plated cables.

sharpcap stalls.jpg (442.02 KiB) Viewed 3083 times

[Antman72]

Hi,

thanks for the detailed report - it sounds like you have been through a lot of troubleshooting steps already without getting any results

There is nothing bad showing in your logs, but that just supports the idea that the QHY SDK is not getting around to sending the frames to SharpCap for some reason. I wonder if the fact that the frames sometimes arrive after an additional 2 minutes indicates that a high proportion of frames are being lost by the SDK, and when one does come through it is after 4 minutes, 6, 8 etc. There is currently no timeout in SharpCap when waiting for a frame from a QHY camera (I have done this in other cameras where the delivery of frames is less reliable and the camera sometimes needs to be reset, but never needed to for QHY).

I don't have a quick solution for this - the version of SharpCap you are using already has the latest QHY SDK in it (no new updates since last year ). The fact that other programs work tends to rule out hardware issues, but if you are using a long USB3 cable, do retry with a shorter one. If you have a second PC you can test on that would be good too.

It would be interesting to know if you find any range of settings that make the camera work propery - for instance

* shorter exposures - 100ms? 1s? etc
* reduced resolution
* binning
* 16 vs 8 bit mode vs RGB mode

finding anything that works and then finding the boundary between what works and what doesn't sometimes helps locate the issue. I suspect that we might need to raise this one with QHY though. 1 minute same results. 2 minutes

cheers,

Robin

Hi again Robin. Here is what i found,

* shorter exposures - 100ms? 1s? etc: Issue starts at 30 sec subs & greater at RGB24 4952x3288. most of the time it takes the exact same time as the sub for the transfer to come through then it levels out and works as it should. same results at 2 minutes takes 2 minutes to push through then returns to normal..Same at 3 minutes. Obviously the first frame on any sub greater then 30 seconds is hung up.
* reduced resolution RGB 3712x3228 starts at 8sec , 3712x2466 started at 8 seconds. went down to 320x240 same issue starts at 8 seconds.
* binning same issue at 2x2 no matter the resolution.
* 16 vs 8 bit mode vs RGB mode raw 16 starts at 4sec to 8 seconds no matter resolution. raw 8 same issue same start time 4 to 8 sec. Debayer preview off same results. Same across the entire spectrum of settings. ASCOM driver= never happened once. from 1 sec up to 3 minutes. takes ascom about 1-2 seconds to transfer frame regardless of size or if force debayer is on. I have tried on all intel and asmedia usb ports with same results. I even overclocked the pc tp 4.8 ghz and turned off s3 modes with no effect.

I am lost Robin... Please help

Anthony

[admin]

Hmm, let me have a think - I run QHY cameras that can support video mode in video mode (even for longer exposures). I wonder if this camera doesn't like that and would prefer to be in still mode. I have the code for that already to support non-video cameras - I will see if I can put together a build that will either switch to still mode above a certain exposure or always run this camera in still mode and you can test - give me a day or two.

cheers

Robin

[Antman72]

Hmm, let me have a think - I run QHY cameras that can support video mode in video mode (even for longer exposures). I wonder if this camera doesn't like that and would prefer to be in still mode. I have the code for that already to support non-video cameras - I will see if I can put together a build that will either switch to still mode above a certain exposure or always run this camera in still mode and you can test - give me a day or two.

cheers

Robin

Thank you for the support. I will continue testing on my side.

[Antman72]

Hmm, let me have a think - I run QHY cameras that can support video mode in video mode (even for longer exposures). I wonder if this camera doesn't like that and would prefer to be in still mode. I have the code for that already to support non-video cameras - I will see if I can put together a build that will either switch to still mode above a certain exposure or always run this camera in still mode and you can test - give me a day or two.

cheers

Robin

Responded to your PM with error report on beta.

[admin]

Thanks for the reply and the bug reports - I wasn't expecting that outcome as the option works with the QHY cameras I have here. Looking at the details of the bug report it's not something simple like SharpCap not passing enough memory to the QHY SDK to hold the image data, so I suspect a bug in the SDK or some other subtlety. I will pass this bug on to QHY.

Please can you just check first that you have the latest version of all QHY drivers and other associated installs on your PC.

thanks,

Robin

[Antman72]

Thanks for the reply and the bug reports - I wasn't expecting that outcome as the option works with the QHY cameras I have here. Looking at the details of the bug report it's not something simple like SharpCap not passing enough memory to the QHY SDK to hold the image data, so I suspect a bug in the SDK or some other subtlety. I will pass this bug on to QHY.

Please can you just check first that you have the latest version of all QHY drivers and other associated installs on your PC.

thanks,

Robin

Hi Robin, All drivers / programs / Dll's are latest. Thank you for the help. Is there anything else i should do with QHY? Also it there any chance its my camera? Its brand new and now i am a little worried. Thanks, Anthony

[admin]

Hi,

I'm suspecting some weird software mess up between SharpCap and the QHY SDK that only happens sometimes - since your camera is working fine with other applications then I think it's unlikely to be a hardware error.

cheers,

Robin