Sharpcap behaviour

Post Reply
Bazzaar
Posts: 6
Joined: Sat Feb 18, 2017 5:07 pm

Sharpcap behaviour

Post by Bazzaar » Sat Apr 08, 2017 2:36 pm

Hi,
Sharpcap doesnt ever seem to show a dropped frame. When I suspect it should it does one of two things;
with MONO8 selected it stops capturing at the exposure time set and goes to what I am assuming is flatout fps, ie 133 fps at 640x480 frame size. Image on screen is noticeably dimmer.
with MONO16 set it just stops capturing.

Baz

User avatar
admin
Site Admin
Posts: 1909
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sharpcap behaviour

Post by admin » Sat Apr 08, 2017 7:05 pm

It'd be handy to know what QHY camera you are using and to see the SharpCap log from after the problem has occurred.

cheers,

Robin

Bazzaar
Posts: 6
Joined: Sat Feb 18, 2017 5:07 pm

Re: Sharpcap behaviour

Post by Bazzaar » Sun Apr 09, 2017 11:13 am

The camera is a QHY 5III 174.
The logs show nothing unusual happening.
After more investigation I find its not Sharpcap, or any application, that has problems.
Firecapture and PHD2 behave oddly too.

I dont hold much hope of being able to dig much deeper into the problems.
I'll just go back to USB 2 until its fixed.

Baz

User avatar
admin
Site Admin
Posts: 1909
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sharpcap behaviour

Post by admin » Sun Apr 09, 2017 7:46 pm

A couple of suggestions...

* adjust the USB Traffic control for the QHY camera - the wrong value for that can lead to slow frame rates or dropped frame issues. Adjusting is usually a matter of turning the value down until suddenly you get no more frames, then turn it up a bit.

* check USB cables. I have had problems with cables longer than a total of about 3.5m for USB3 (it's supposed to go to 5m, but I've never made that work without a hub in the middle).

cheers,

Robin

Bazzaar
Posts: 6
Joined: Sat Feb 18, 2017 5:07 pm

Re: Sharpcap behaviour

Post by Bazzaar » Mon Apr 10, 2017 1:41 pm

Hi,
the USB traffic control doesn't help this problem. My system is good enough to deal with whatever framerate is produced with the control set to 0. There is no position where the frame rate stops increasing.
Some of my testing has been done with unrealistic exposure times, 1 ms for instance. So that should produce 1000 fps. Obviously that cant be achieved, so the frame rate is limited by the max throughput of the hardware. At 640x480 this will be something in the order of 230 fps, with USB Traffic set to 0.
When actually set up to capture Jupiter for instance, I usually end up with an exposure of 20-25 ms giving 40-50 fps. Here the USB traffic is around 11 or 12 when it starts limiting the frames.
I can see it being effective in both set ups.
In both scenarios the framerate will randomly jump to 133 fps. When imaging Jupiter the preview image dims noticeably.
None of the control settings change, just the current fps and the preview image.
Moving a control setting restores proper operation, whether it is the USB traffic, exposure time, gain. The test set up goes back to 230 and the Jupiter set up goes back to 40-50 fps. Nothing is recorded in SharpCap logs at these times.

Yes I agree lead length and quality affects performance hugely. I get best reliability when the camera is directly connected to the PC with the supplied 1.5m lead. Any use of an extension or hub increases the frequency of this issue. If I wiggle a plug I can cause the problem.

As I said, I dont think its a software problem, application level anyway. I see similar things with Firecapture and PHD2.
Its a link layer or transport layer issue. What I would ask is what information is available to apps like SharpCap to inquire about the state of the connection?
Why are no frames reported dropped?
Why can the connection not be re-established by the app?
Where is the camera getting the commands that result in the change to 133fps?

As a application author I guess you have to proceed on the basis that all the hardware and drivers work. What if they dont?
It ends up looking like the app is buggy. I dont envy your position in this situation!

Regards

Barry

User avatar
admin
Site Admin
Posts: 1909
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sharpcap behaviour

Post by admin » Mon Apr 10, 2017 7:23 pm

Hi Barry,

thanks for the further info - I definitely think you are right - the problem is occurring at the hardware/driver/SDK level. Unfortunately the QHY SDK doesn't provide a means to ask about the number of dropped frames, so SharpCap just doesn't show any for QHY cameras unless they are dropped *after* being passed to SharpCap (ie writing to disk can't keep up with frame rate).

SharpCap has to believe that the camera will do what it is supposed to do, or at least that if it doesn't it will return some error code, at which point the standard response (except for a small and carefully considered set of conditions) is to send a bug report and quit. Of course if the camera isn't doing what it is supposed to and isn't giving an error code, then SharpCap continues without knowing anything is wrong.

Well, not quite - SharpCap would know that it hasn't received a frame for a while if the frames freeze up, and for some brands of camera I have code that spots that and basically resets part of the camera SDK to get things going again. Never needed that for QHY up until now, and it doesn't sound like it would help as you get 133fps, so you've got *lots* of frames without the exposure being changed.

I will make sure I have the latest SDK in the next 3.0 build (was going to be 2.10) and think about whether I can put in any code that might be able to catch your issue by perhaps spotting the frame rate is too fast and re-sending the exposure to the camera.

cheers,

Robin

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest