183MC-Pro weirdness with SC 4.1.12025.0 (64-bit)

[admin]

Hi,

the line of interest in the log is this one, which comes after you switched to 90s exposure

Code: Select all

Warning	19:29:10.535530	#30	Fetching still frame from ZWO camera failed with ExpFailed, exposure is 90000, timeout is 114500

The key there is that the result from the ZWO SDK was the error 'ExpFailed' - the ZWO SDK knew the exposure hadn't worked, but unfortunately we don't get any more info as to why. I suspect that the fan shut off was another symptom of caused by whatever caused the exposure to fail - probably a camera glitch.

It's good to see that closing the camera and re-opening got things going again - that points to being able to potentially auto-recover, but doesn't help identify the underlying cause. I think the first things I would check are cabling issues - are the USB cables good, relatively short with minimum extensions/hubs, and is the power supply working well.

cheers,

Robin

[MarMax]

Even though I started this topic based on the 183MC-Pro, I'm having what I think is a similar issue with the 2600MC-Pro so I will continue here. I'm up in Darwin, CA for some dark site EAA and the past two nights have been a struggle. There are two main issues, the first being the fetching frame error where the live stack ceases stacking and the second being a failure of darks.

I have logs that will hopefully show what was going on regarding the ceasing of stacking frames. I had this happen three times during the past two nights and I tried the "reconnect camera" which did not work. When I noticed that stacking new frames had ceased I would pause the stack and then try to reconnect the camera. The camera would continue to act like it was taking exposures but no new frames would be stacked. And after reconnecting and attempting to pause and reset it seemed like SharpCap stopped responding and I had to force quit one time. I have a few screen grabs if you would like them.

Moving on to the issue with darks it took me quite a while to figure out that the root of the problem was using a dark under preprocessing. I've been taking darks the exact same way for two years now and have never had a problem like this before. The effect of the problem is black clipping. I know to increase my Brightness/Offset when at a dark site, this I've learned from past experience. But this time the live stack histogram was significantly clipped even when using a Brightness of 70 with the 2600MC-Pro. I use a Brightness of 25 at home.

To figure out the cause I made one change at a time under preprocessing until it was clear the dark was the problem. I tried with and without all of the following:

- flat, dark, linear gradient reduction and satellite removal

As long as I did not apply a dark the histogram was not black clipped. As soon as I applied a dark the histogram was clipped. I have all of the darks in question and can provide them if necessary. I'll attach two log files for now and a screen grab of the clipped histogram.

M67_2600fail1_05072024s.jpg (289.95 KiB) Viewed 193 times

I'm continuing to review the saved as seen PNG live stack image histograms in Photoshop to see if I can provide more input. I've also not yet reviewed any of the 32-bit FITS stacks but will do so. Thanks in advance for any assistance you can provide.

Mike

[admin]

Hi Mike,

on the dark frame issue, the first step I would suggest is a 'check the plug' test on the dark frame and the light frames - open the dark you were using and one of the raw light frames in a tool like FITSLiberator and check that the average pixel value of the dark frame really is lower than that of the light frame. I'd like to rule that out entirely - if the frames do turn out to be OK, check to see if you can repro the issue using the folder monitor camera and the same data and then send some frames in my direction so I can debug the problem.

The loss of stacking is interesting - we aren't seeing the failure to get frames from the camera in those logs, but there are dropped frames being recorded with the type 'PreviousFrameNotProcessed'. This only happens if a new frame arrives from the camera while the previous one is still being handled by the SharpCap code. Since it looks like you were taking 30 or 60s exposures, it seems quite likely that the live stacking has become stuck somehow trying to add the previous frame.

I will have a poke around to see if I can see any obvious way that sort of thing could happen, but it's not an easy thing to find by just looking at the code. If you catch it happening again, please do the following...

* Press CTRL+SHIFT+ALT+H
* SharpCap will prompt you to simulate the program not responding - click Yes
* Wait about 60s or so - SharpCap will freeze during this time
* SharpCap will prompt you to report the stopped responding problem - choose report
* Enter a text description in the next window that pops up - you need to type 20 or so characters minimum
* Follow through and submit the bug report - if you are not online then hit the little downarrow next to 'Send and Quit' and choose 'send report manually'

A crash report file created that way will contain info about what all the different parts of SharpCap were trying to do at the point when it was frozen, and that *should* include what the live stacking was stuck doing.

cheers,

Robin

[MarMax]

Robin,

I must apologize because I'm terrible at doing the things that would be most helpful to you for troubleshooting the dark frame issue. I did not save any RAW frames and I did not even save a FITS stack with the histogram cut off. Next time this happens I will do both. The only thing I have with the cut off histogram is a PNG saved as seen stack.

It was windy and cloudy last night so I did not get a chance to do any more imaging. We are packing up and heading home today but I will be more diligent in doing things that will be more helpful for you in the future.

Regarding the dropped frames I did notice in the Alignment tab that when this problem starts it shows zero stars for alignment. Even though this does not make sense for a 600mm f/6 scope with SQM-L 21.60. I did try toggling optimize for faint stars on and off and could not tell if it helped or hurt. It has me wondering if I had optimize for faint stars ON and there were so many that it caused the alignment problem. My normal practice is to leave optimize for faint stars OFF unless I need it.

I'm attaching a screen grab of FITS liberator of a master dark and its text file.

Mike

[admin]

Hi Mike,

no worries - when you do get a chance to repro either of the issues, let me know the results. You can see the frame average value in FITS liberator for the dark, but there isn't much we can do with that data without a light frame (unprocessed) to compare it to.

There was previously an issue where the non-linear background subtraction modes could over-subtract and lead to a black-clipped image, but that was fixed by 4.1.12025, and it looks like you were using 4.1.12100, so that won't have been the issue.

cheers,

Robin