qhy 585m mono8 keep droping frame in ROI high fps
qhy 585m mono8 keep droping frame in ROI high fps
When use qhy 585m with mono8 , set ROI to 3856x80 and exposure time with 1ms to get the high fps, preview or capture the images , the number of droped frames may slow increases. But with mono16 and same ROI and 1ms , it's stable and no drop frame. I have change another PC, or USB cable, it's still the same so.
-
admin
- Site Admin
- Posts: 17369
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: qhy 585m mono8 keep droping frame in ROI high fps
Hi,
I just tried this with my QHY585 (colour version), and I see roughly the same - I can get about 760fps in RAW8 at that ROI but there are a few dropped frames. From the log it looks like the frames are lost within SharpCap (rather than at the camera) as one of the frame processing steps is sometimes not quite ready for the next frame that arrives. I might be able to do something about this, so will investigate.
cheers,
Robin
I just tried this with my QHY585 (colour version), and I see roughly the same - I can get about 760fps in RAW8 at that ROI but there are a few dropped frames. From the log it looks like the frames are lost within SharpCap (rather than at the camera) as one of the frame processing steps is sometimes not quite ready for the next frame that arrives. I might be able to do something about this, so will investigate.
cheers,
Robin
-
admin
- Site Admin
- Posts: 17369
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: qhy 585m mono8 keep droping frame in ROI high fps
Hi,
just to follow up on this - I looked into trying to stop the intermittent dropped frame issues at very high frame rates and nothing really worked perfectly - I could sometimes reduce the dropped rate a bit, but there were always some once the raw frame rate goes high enough.
There are two possibilities that could explain this
1) Sometimes the frames from the camera arrive in a burst of 2 or 3 or more, rather than being spread evenly over time. The burst would have very small gaps between frames which means that the next stage of the processing pipeline is not ready in time for the second or third frame in the burst
2) Windows is sometimes introducing delays of a millisecond or two into the code that does the work of processing the frames after grabbing from the camera. From a normal usability of Windows point of view, an odd delay of 1-2ms isn't much, but when the frames are arriving every 1.5ms it can make all the difference.
In theory I could allow the frames to queue up to avoid dropping them, but that would have knock on effects in other situations, so I think I will avoid that as the effect we are trying to deal with here is quite minimal.
cheers,
Robin
just to follow up on this - I looked into trying to stop the intermittent dropped frame issues at very high frame rates and nothing really worked perfectly - I could sometimes reduce the dropped rate a bit, but there were always some once the raw frame rate goes high enough.
There are two possibilities that could explain this
1) Sometimes the frames from the camera arrive in a burst of 2 or 3 or more, rather than being spread evenly over time. The burst would have very small gaps between frames which means that the next stage of the processing pipeline is not ready in time for the second or third frame in the burst
2) Windows is sometimes introducing delays of a millisecond or two into the code that does the work of processing the frames after grabbing from the camera. From a normal usability of Windows point of view, an odd delay of 1-2ms isn't much, but when the frames are arriving every 1.5ms it can make all the difference.
In theory I could allow the frames to queue up to avoid dropping them, but that would have knock on effects in other situations, so I think I will avoid that as the effect we are trying to deal with here is quite minimal.
cheers,
Robin