Weird behavior SC 4.1.11824

[Anthony Quintile]

I am not sure I am following? PHD is running constantly during all of this and the failure to stack the first frame is a new occurrence since v4.1x. I guess I can turn of the 'Only stack while guiding is active', but the behavior is new and different.

"guiding wasn't active during that first few seconds and dumping the frame because of it. If that's happening, it would be recorded in more detail in the small log on the right of the live stacking area"

I was checking that log, (figured it would also be in the log file...) and I think that there is a message that guiding was active at the initiation of the imaging, but then a message that the frame wasn't stacked and I cannot remember why. Like I said, I figured it would be in the log file.

It may be a couple/few weeks before I get to image again, but I'll check that Status window for some stats, and the Log window, and try to screenshot or something. To reiterate, this is new and different behavior with v4.1x

[admin]

Hi,

yes, PHD may be running, but without live stacking turned on, SharpCap doesn't connect to PHD, so it only *knows* that PHD is running once live stacking is activated and the connection to PHD has succeeded.

The old code for monitoring PHD in 4.0 was a bit horrible - if PHD was guiding OK at the end of a frame then that was enough, even if guiding had dropped during the frame. The new code in 4.1 looks for any overlap between times when PHD wasn't guiding and the time when the frame was captured. In theory it's a better solution, but I hadn't anticipated this particular situation - I will have a look to see if I can deal with it more nicely.

cheers,

Robin

[ChrisR Oz]

Hi Robin,

How do you define “good guiding” for a frame in v41.? Does a frame get rejected even if it losses only a few seconds?

I would suggest that if guiding was active for more than some threshold (e.g 75%) then that’s a good frame, remembering that even if PHD2 lost the plot for a few seconds, it may still have not wandered far and may be a very good frame. I’d rather let the downstream stacking decisions to accept or reject a frame.

Cheers, Chris.

[admin]

Hi Chris,

a good question, and at the moment the 'good guiding' is determined by having guiding throughout the whole frame. I should probably adapt that, since the sequencer does a better job when capturing frames with guiding (uses a 5% threshold). On the other hand, the use case for capturing with the sequencer is that there will be later review and processing of frames, whereas with live stacking you could just be stacking, meaning a bad frame getting through can spoil your stack...

The other nice thing would be to drop the exposure while guiding is lost (like it does while dithering), which would reduce the amount of time lost due to dropped guiding.

cheers,

Robin

[admin]

Hi,

Ok, so I have tried to repro the issue with the missing first frame after exposure change today and the first annoying thing is that I can't repro the issue . What I have learned along the way is that it doesn't look like this is todo with PHD2 guiding after all - if guiding is lost and that causes a frame to be discarded then the fact is recorded in the main SharpCap log. We don't see that in Anthony's log, so it isn't related to the guiding. Back to square one...

Looking at the log again, I can see these key lines... (with my added comments)

Code: Select all

// switching from 4s to 240s exposure after focus scan complete
Debug  	23:00:11.999247	#19	Finished ZWO Exposure of 4000ms, gotFrame = True																		in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, BufferFrame frame, CancellationToken cancellationToken)
Debug  	23:00:12.002280	#19	Starting ZWO Exposure of 240000ms																						in bool SharpCap.Cameras.ASI.ASICameraProxy.StartExposure()

// activating live stacking
Info   	23:00:13.898449	#1 	Toolbar/Menu input : SharpCap.ViewModels.Actions.TransformAction Live Stacking executing								in async Task SharpCap.ViewModels.UIAction.ExecuteAsync()

// live stacking connects to PHD2
Debug  	23:00:16.347659	#1 	Notification (Status=OK): PHD2 is guiding again.																		in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info   	23:00:16.353723	#10	Event received from PHD2 : GuideStep																					in void SharpCap.Base.Guiding.Phd2Api.ProcessNotification(EventBase typedEvent)
Info   	23:00:16.354911	#10	Guiding SettleState changed to Settled																					in void SharpCap.Base.Guiding.GuidingBase.set_SettleState(SettleState value)

// first 240s frame finishes as expected 4 minutes after being started
Debug  	23:04:12.388713	#19	Finished ZWO Exposure of 240000ms, gotFrame = True																		in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, BufferFrame frame, CancellationToken cancellationToken)
Debug  	23:04:12.391351	#19	Starting ZWO Exposure of 240000ms																						in bool SharpCap.Cameras.ASI.ASICameraProxy.StartExposure()

// First 240s frame is processed by live stacking about 20s after being captured
Info   	23:04:31.859414	#28	New stack first frame processed, mount co-ordinates are RA=13:16:57.4,Dec=+36:39:18										in BufferFrame SharpCap.FrameTransforms.LiveStacking.LiveStackTransform.HandleFrame(BufferFrame frame)

So, from a closer inspection of the log, it seems clear that the first 240s frame after the exposure change is making it to the live stack, since the 'New Stack First Frame processed' log entry only appears after adding the first frame to a new stack. Maybe the display isn't updating once the frame is added to the stack (no histogram, no image) for some reason, but it looks like the frame is being used.

Now, further down the log at (for example) 23:51:03, I can see that after re-starting live stacking the first frame is being ignored because live stacking is paused when it arrives. Maybe that's what is happening here? If you close down live stacking and re-open it, it re-opens in 'paused' state if there is an existing stack, and it needs to be resumed to allow stacking to continue if that's what you want to happen. As far as I can recall though, this behaviour isn't new in 4.1...

cheers,

Robin