Dropped Frames

Discussions, Bug Reports and Issues related to Beta versions of SharpCap
Posts: 1
Joined: Sun Sep 01, 2019 2:09 am

Re: Dropped Frames - QHY-174M-GPS

Post by jmooreou » Sun Sep 01, 2019 2:56 am

I have some general questions regarding how to eliminate dropped frames when running SharpCap.

I record occultations and my group makes extensive use of the QHY-174M-GPS cameras. We are attempting to capture high cadence recordings to get the best possible timing resolution on small asteroids that will become increasingly observable with the accuracy provided by the GAIA DR2 release. Dropped frames are avoided at all cost due to the negative impact they have on the timing results.

I have used SharpCap for occultation recordings since participating in the 2017 mu69 (New Horizons) campaign and several other missions since. Our targets on those earlier missions involved slower cadence due to longer exposures. Recently we have been attempting to capture at 10.0 ms (100 fps), 640x480, binned 2x2, gain 300, 8-bit FITS and when I attempt this speed I get dropped frames - about 3% - 5% on a 10 second test or 2 dropped frames out of 1000 to be captured. SharpCap only reports 5 dropped frames with this example, but I do a frame by frame analysis and can confirm a much higher number of actual drops - more like 30 to 50 drops during the 1000 frame capture.

Currently I am running SharpCap Pro 3.2.6086.0
My current laptop is
i3-7100U @ 2.4 GHz
C: is SSD - recording target
D: is SSD - can also record there but C has slightly better I/O performance so I use it
The QHY camera is connected to a dedicated USB3 port on this laptop.
Win10 Home

I have a new i7 laptop ordered with 32GB memory and SSD and I hope it will allow me to achieve a faster capture rate.

With my current configuration the fastest fps I can sustain without any dropped frames is about 30 fps - 8bit FITS - 640x480

My question is what are the important system resources when attempting high cadence captures with SharpCap? Does SharpCap exploit large memory space? Is the CPU overhead significant when doing +100 FITS file writes per second - I would expect it is? I'm sure I/O bandwidth is important, but I have heard from others that seem to be successful writing to slower devices (USB connected external SSD) than I currently am, so I'm curious about how important that resource is.

Thanks for any advice on the best configuration (Windows) to be able to consistently capture high frame rates while avoiding dropped frames. My organization (International Occultation Timing Association) is planning multiple campaigns using SharpCap and the QHY cameras where we want to be able to capture at these higher frame rates, so any advice regarding what is required to do so would be much appreciated. Thanks!

Camera Settings File for this sample run:
Output Format=FITS files (*.fits)
Capture Area=640x480
Colour Space=MONO8
Force Still Mode=Off
Enable Live Broadcast=Off
USB Traffic=1
Amp Noise Reduction=Off
Frame Rate Limit=Maximum
Calibration End Pos=13109
Calibration Start Pos=3252
GPS Calibration LED=Off
Timestamp Frames=Off
Target Temperature=0
Cooler Power=255(Auto)
Banding Threshold=35
Banding Suppression=0
Apply Flat=None
Subtract Dark=None
#Black Point
Display Black Point=0
#MidTone Point
Display MidTone Point=0.5
#White Point
Display White Point=1

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

Re: Dropped Frames

Post by admin » Sun Sep 01, 2019 8:17 pm


The first thing to do is to distinguish between dropped frames that only happen when you are capturing images and those which happen regardless of whether capturing is active or not. If you're only seeing drop frames while capturing then the cause is almost always that the program isn't be able to write the images to disk as fast as they are arriving from the camera. This can be down to things like a slow or nearly full hard disk, or down to using one of the still image file formats (fits, PNG, etc) for high-speed imaging.

I do wonder if your use of the fits file format when trying to capture a high speed is the underlying problem here – it will be easy enough to test changing the output format to SER and see if that resolves the issues. While fits files to get an exceptionally large amount of header information added, they are also the slowest file format to write.

If you need to dig any deeper, look at the SharpCap log which will have some detailed lines in it logging dropped frames of different types – if you post those log files here then I can help you interpret what they might mean.

Cheers, Robin

Posts: 1
Joined: Fri Sep 20, 2019 9:10 am

Re: Dropped Frames

Post by Vigo79 » Fri Sep 20, 2019 9:18 am

Hello :) I have a lot of dropped frames too with my ASI174. Before I post some log Files I would ask, are the changes of this "special version" here implented in the actual version? Or can I try this download link above?

Greetings Vigo

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

Re: Dropped Frames

Post by admin » Fri Sep 20, 2019 8:10 pm


Not sure what you mean about a special version – there isn't a special version download link in the thread above. Just occasionally I put out a special version for someone to test something, but there are none of those at the moment, so just test with the latest version.

Cheers, Robin

Post Reply