SharpCap Forums

Hi Robin,

I know that this has been discussed in several different areas but hadn't found it officially logged as a bug. To me it feels more like a bug than a new feature request.

For everyone else's benefit, the "issue" is that each time SharpCap performs a dither (through PHD2), it doesn't pause the capture process to do the dither but rather keeps the current exposure time in motion and uses one of those blocks of time to do the dither even if it doesn't take that much time to actually do the dither.

For example, if I'm using 2 minute exposures, the dither process only consumes a few seconds but SharpCap won't start capturing the next light frame until 2 minutes later. So the cost of a dither is always equal to your exposure time, even if the dither time would have been much less. If I'm dithering every 4th frame in a 4 hour time slot, I would only capture 3 hours of data because I take a full exposure time to do the dither. In other words, dithering is extremely costly when time is precious.

I'm a huge SharpCap fan for it's excellent live stacking capability and have been reason that other people in my club now use it. This one issue is my only frustration with it.

Thanks for Listening,

Mark

Hi,

I think you may be right that this needs a fix in version 3.2 is a bug fix as version 3.3 is still a long way from being ready.

Cheers, Robin

Thanks Robin!!

Well I hacked together something quick and hopefully effective last night and it's now in the very latest build that you can download from the usual place. Because I was in a hurry I only tested against all PHD2 in simulator mode, but it seemed to work. Basically it changes the exposure down to 1s when it starts dithering and then puts the exposure back once the dither has settled.

Please give it a try and report any problems if you can. The thing I was most worried about was that it might decide to discard the first full length frame after the dithering is complete, but I couldn't see any evidence of that in my testing so hopefully it is okay.

Cheers, Robin

Excellent!! I'll download it and give it a try as soon as we get some clear skies and let you know if I find anything unexpected.

Mark

Hi Robin,

Tnx for the dither upgrade. Unfortunately for me the resume doesn't always occur and it drops a 1sec frame when this happens. I either manually resume or let it resume on the next exposure. Sometimes it works and alternates and then it will not resume for several exposures.

Don

I've tested the new dithering mode in Live Stack in both 32 and 64 bit versions and it's working very well for me. I was online with Don as he was having issues with the system not resuming after the 1 sec frame loop during settling. I think in Don's case this may be a timing issue. His mount is connected to his computer via iOptron's StarFi WiFI RS232 dongle. We both have iOptron CEM60 and latest PHD2 and SC. Difference is that my mount is connected directly to the host PC via RS232 to USB adapter. Not sure if adjusting dithering settings will fix this or if more under hood work is needed.

noticed these these types of frame drops in his log

Info: 23:39:35.9649222 Thread:Image Process Thread#31 SharpCap.Base.DroppedFrameLogger.Count(DroppedFrameType type, Int32 count) :: Dropped frames : 476 of type LiveStackReject
Info: 23:39:35.9649222 Thread:Image Process Thread#31 SharpCap.Base.DroppedFrameLogger.Count(DroppedFrameType type, Int32 count) :: Dropped frames : 34 of type ZWOTimeout
Info: 23:39:35.9649222 Thread:Image Process Thread#31 SharpCap.Base.DroppedFrameLogger.Count(DroppedFrameType type, Int32 count) :: Dropped frames : 2 of type ZWOFromSDK

Robin,

An update on my dithering issue. It seems that every other dither worked properly. When the Pause was not initially released a short exposure frame is dropped (not ignored) and the timing bar count's up and quits and then the imaging exposure restarts the timing bar with Pause still in effect. I then manually Resume, if I'm paying attention, if not then the next frame will cancel the Pause and ignore the exposure.

Don

Hi,

Mixed results so far then... Don, there's nothing obvious in that log that you posted that would help me track down the issue, but there may be additional info in the live stacking log page (the right-hand most tab in the live stacking UI). Info ends up being put in there that doesn't get put into the main log. In particular with the latest update there should be information going in about status updates received from PHD 2. When PHD reports that the dealer command has settled, the code will then reset the exposure to the normal length and then hopefully the next frame to arrive will resume the stacking.

Just looking at the code now, I'm concerned that perhaps the resume isn't happening until after the first full-length frame after the dealer has finished – in other words one frame too late.

Cheers, Robin

Try this version

https://d.sharpcap.co.uk/download.html? ... 3.2.6110.0

That should correctly include the first full frame after the dither in the stack.

Cheers, Robin