ASI 1600 often fails image save in 2.6.0.0

I haven’t had problems with ASI-1600 in sgp until I updated to 2.6.0.0 - and now it is failing to save roughly every other frame - whether it is a light or a flat.

I did change the gain and offset settings for the camera if that matters.

This is Win10 and 16GB.

This was really unfortunate because I was doing a long sequence with two filters on a nice night - and almost all of one filter did not get saved.

Here is a link to a long log:

https://dl.dropboxusercontent.com/u/37743511/sg_logfile_20161218223840.txt

Typical log msg looks like this:

[12/19/2016 7:46:19 AM] [DEBUG] [Sequence Thread] Entering super dangerous loop to await image completion…
[12/19/2016 7:46:19 AM] [DEBUG] [Sequence Thread] TEMP - Current Event16: 2
[12/19/2016 7:46:19 AM] [DEBUG] [Camera Thread] ASCOM Camera Error : CheckDotNetExceptions ASCOM.ASICamera2.Camera ImageArray Get System.OutOfMemoryException: Insufficient memory to continue the execution of the program. (See Inner Exception for details) (System.OutOfMemoryException: Insufficient memory to continue the execution of the program.)
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 630
at ASCOM.DriverAccess.MemberFactory.GetTargetInvocationExceptionHandler(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 664
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 288
at ASCOM.DriverAccess.Camera.get_ImageArray() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Camera.cs:line 361
at qm.h7(ox A_0, qw& A_1)
[12/19/2016 7:46:19 AM] [DEBUG] [Camera Thread] Error while attempting to capture frame…
[12/19/2016 7:46:19 AM] [DEBUG] [Camera Thread] Adding sequence level notification: Error attempting to capture image (see logs for more information).
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] TEMP - Current Event17: 2
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] Image reported as complete. Continuing…
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] Collecting FITs headers…
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] ASCOM Camera: Could not get last exposure start time. Reported as (unknown)
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] DATE-LOC time provided by SGPro (failed to retrieve valid entry from camera)…
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] Clearing timed monitoring events…
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] Error saving ASCOM image. : Object reference not set to an instance of an object.
at qm.gl(o4 A_0, List`1 A_1)
[12/19/2016 7:46:20 AM] [DEBUG] [Sequence Thread] Failed to save image to disk!

Frank

Not really sure on this. That type of error is issued by the ASCOM driver… not SGPro. When you say SGPro 2.6.0, do you mean that or do you mean starting with 2.5.2 (since we snuck in the minor version increment)?

2.6.0.0 is the latest beta release isn’t it? From dec 17.

I didn’t change the camera driver so the change seemed connected to 2.6.0.0.

I will reboot and test more - but this is new behaviour.

Frank

It is, but is also pretty identical to 2.5.2.8 (with respect to ASCOM camera behavior) so I was just curious when you first saw it.

Oh I see. Yes I think I consistently use the latest betas including 2.5.2.8 and I didn’t see this happen. I will see if it reoccurs.

Frank

Most weirdness that I’ve seen with my ASI1600 has been around setting the USB speed too high. I generally shoot with the camera connected to a USB2 port and the USB speed around 75. If on USB3 I drop it down to 45.

Those values seem correct as they’re coming from memory. My drivers probably somewhat out of date too (probably Octoberish) if that matters.

Thanks,
Jared

I rebooted and then took a series of darks and bias and it was all fine. So I don’t know what caused the problem. I’ll keep an eye on it.

The USB speed setting thing is on the far left - which is what they imply is the best to use to avoid dropped frames.

Frank