Sgp keeps crashing

I have already sold one of my two 6Ds and the other one is listed now on Astromart. Since it is not connected up in my obs now I won’t be able to test it in a live configuration. I will try to do so in my office. Will keep you posted.
A successful run on my office pc will not be as definitive a result compared to a run on my obs pc where I have had all the failures.

[deleted - having a senior moment]

Make sure it’s in Bulb mode.

Thanks
Jared

Running 2.5.1.16 for the first time with SBIG camera. Set up for ten 60 second darks. Program crashed after the fifth image. I rebooted and restarted and this time it got to the second image before crashing. I went back to 2.5.1.14.

doh!

Interesting - obviously Nebulosity uses a different API control

Manual should work but I believe there are some minor things between “bulb” and “manual” that cause issues. That probably needs a little more research. However bulb should work without issue.

Thanks,
Jared

If you could supply the info above in this post that would be helpful.

Thanks,
Jared

Hi,
I was working those days with 2.5.1.15 without problems.
Yesterday night I updated to 2.5.1.17 and at the third image SGP crashed.
I realized this morning.

I use a QHY9 Mono camera, Lodestar for guiding, Mount Neq6 pro II.
I was imaging OIII Lights of 30 min. each one.

Previously I saw, before going to bed, that SGP was in Recovery Mode, due to a PHD problem, I think.
In the last weeks I’m having persistente errors in PHD guiding. I Use PHD 2.6.1 dev 9. I’ll update today to dev 11.

I add log files for both SGP and PHD. It seems SGP crashed at 1:33 a.m.
The debug PHD log file is too big for uploading.
I add a dropbox link.

sg_logfile_20160627224841.txt (335.7 KB)
PHD2_GuideLog_2016-06-27_230023.txt (789.9 KB)

https://dl.dropboxusercontent.com/u/41489676/Foros/PHD2_DebugLog_2016-06-27_230022.txt.zip

I have had untroubled operation for months and suddenly I have had strange guider issues too on the last two nights. The guider starts ok, AF routine kicks in and then guidestar is lost. I’ll have to do some digging. I have not changed the PHD2 version for some time, but I did change to 2.5.1.17 recently. Bizarre

Hey all,
I have not experienced a single crash with .17, I’m on Windows 7 64bit at the moment.

I was imaging last weekend and got x30 Lights each for 2 different objects, x31 Bias frames,
x31 25sec darks and x31 180 sec darks, a whole library of Flats with x31 each of ADU 8000,
12000, 15000, 17000, 20000, 22000, 25000, 27000 and 30000.

That’s a lot of flats at x279…No crashes, everything went perfect.

Why I have not experienced the crashes you guy’s are I have no clue but Glad I have not.

If I was I have to admit I would roll back to the last older version that worked for me.

Hope they Identify the cause soon for you all
Paul

No problems here on my Win10 Dell laptop using 2.5.1.17 with a variety of cameras and other ancillary equipment.
(Maybe I should find some wood to knock on!)

2.5.1.17 is pretty stable. We have received pretty minimal crash reports on .17 (one I think). .15 and .16 had some issues and .17 addressed those. If you look at this thread most are from previous versions of SGP with only 1 report from .17

So I’m not sure where the idea that .17 is unstable is creeping in…but the data doesn’t seem to back that up. If you search through the forum you’ll likely find multiple “.17 fixed my crashing” reports.

Thanks,
Jared

Hi Jared - I just traced the problem to a bad Starlight Xpress driver - reverted back to the prior version and the issues seemed to have gone away. As soon as I get another clear night I’ll hopefully prove you are right.
regards
Chris

Add my complete vote of confidence for version 2.5.1.17. I have been using it exclusively since it was released with no issues. Night after full night of automated imaging with no crashes. Well done Ken and Jared.

@jmacon
I think I have done something stupid somewhere, or I have a hardware issue. I was having weeks of reliable operation and suddenly I keep on getting guider ascom exceptions after a dither and random ones at other times too.

Are you using PHD2 and a Lodestar by any chance? If you are, can you confirm what versions of PHD2 and ASCOM driver? I cannot exactly recall if I can tie this to an update.

I’m going to uninstall and try again but maybe not to the latest levels. (Win 10 x64)
cheers Chris

I am running PHD2 2.6.1dev11, and ASCOM 6.2 that I downloaded in January. And I guide with a Lodestar X2 using the SX off axis guider. However, the picture is not quite this clear. I also am using the SX AO unit, which I might add, is giving me the best guiding I have ever seen. I am mostly using Andy’s suggested parameters with the following changes: fixing the interval at .5 or 1 second seems to give me the best results. Recently I have just been using 1 sec. And I changed the AO Travel parameter from my initial 36 to 12. If you are not familiar with the AO unit, it has a maximum x/y travel number of units. If the adjustments stay in the range of ±36 in each direction, then no correction commands are sent to the mount. When it exceeds the limit, it starts a gradual series of corrections that then center the guide star in the guide field. This is fine if you only have 1 scope. In may case I am imaging 2 or 2 scopes. The guider is on the long fl scope at 1960mm (RC12). The result was very bad guiding for the middle fl scope at 714mm, which would normally be much better because of the shorter fl. By reducing the allowed range down to 12 I am getting very nice guiding on the 714mm because the guider does the centering much more often. It could be my imagination, but it seems to have even improved the guiding on the RC12.

With this setup, my total RMS error is almost always in the range of .5 to 1 arcsec and usually better than .7. Prior to the AO, .6 to 1.5 and rarely as good as .6.

Now, the not so clear part. Prior to the AO install, I was having a lot of trouble getting PHD2 to guide continuously. Even though there was no error, such as lost guide star, indicated, it would still just sit there not posting any new corrections, often for 20-30 seconds. Last night I shifted back to non AO mode just to see what would happen, and this was its behavior, so I shifted back to AO mode. Never had any issues in AO mode.

Not sure this will be of any help to you, assuming you are not using the AO. I do not get ascom exceptions, and I am not dithering.

Thanks - what version of the Starlight Xpress ASCOM driver are you using? - or are you using the PHD2 Starlight SXV driver connection?

I am using “Starlight Xpress SXV”.

Cheers - I will give that a go - so far so good. I have the unique situation (for the UK) of a forecast of 4 clear nights in succession. I’m half way through M27 and because of my urban setting, plan to do 30 hours to get the shot noise down.

The Starlight Xpress SXV driver worked fine all night- which suggests it is not a hardware issue. I will reload the ASCOM driver and if the issue returns let the Starlight team know.

@jared update - SGP 2.5.1.17 is pretty stable as you say. Three full nights unattended operation without any hitches.