Sequencer+PHD2+Clouds=UGH!

[Candieman]

I set up a sequence run for last night comprised of an auto focus at the start, and then after every 12 images; dithering after every 3rd image; guiding via PHD2; and the taking of 30-5 minute exposures. Everything went well until right after the 29th exposure was complete, at about 12:35 am. The relevant portion of the SharpCap log file at this time is attached. Essentially, it said: “Event received from PHD2 : StarLost”, and that put an end to the imaging. I viewed the PHD2 log, and this is what it showed starting around the same time.

PHD2.Star2Lost.Image.080723.JPG (123.45 KiB) Viewed 3949 times

The PHD2 log showed that PHD2 lost the star and was no longer guiding starting at about 00:35, because a cloud moved into the FOV (which I was able to verify). The problem first appeared in the SharpCap log file at 00:34:54, and the sequence was stopped completely one second later. I got up just a few minutes after this happened, and by then, PHD2 had found the star again and was happily back in guiding mode, with errors of just 0.31”, no less.

The question I have is: Is it possible to give SharpCap a “grace period” for PHD2, so that if PHD2 loses a star as it did for me early this morning, SharpCap could wait around for a (short) period of time (maybe a minute or two?) to see if PHD2 starts guiding again, and if it does find a star again, then SharpCap would proceed with the imaging sequence; otherwise stop the sequence at that time?

Rich

[yomamma]

This is the tricky part of programming the sequencer. I have had the same problem and have tried a couple of different approaches.

I do not stack my images anymore I just take single image shots in a loop and after each image I issue a "start guiding if necessary" command. If guiding was lost it will attempt to re-establish guiding with PHD2. If guiding is active it will just ignore the command. This way I am assured that if guiding has stopped because of clouds it will attempt to re-establish guiding after every image. This is the best you can do but if guiding has stopped because of clouds, this will check after each image and make an attempt to start guiding if it has been lost.

[admin]

Hi Rich,

could you please share the full SharpCap log from that session with me. The way I would have expected it to work is for the sequencer to discard that frame because of the guiding loss, then wait for guiding to resume and take an extra frame to compensate for the lost one. It sounds like the error handling is incorrect somehow. I will test here to see if I can make the same happen, but just in case I can't the log would be handy.

thanks,

Robin

[Candieman]

Robin,

I’ve attached the log file from 8/7 (I stripped out some lines from the start to keep it under the 1 Mb max), and you can see where the problem w/PHD2 occurred at 00:34:35. I ran my image scripts again last night, and the same problem occurred. I then restarted the sequence script and the problem occurred again. I restarted it again, and then it ran to completion. I’ve also attached the log file for last night (8/8), and you can see the problems occurred at 22:23:50, and then again at 23:03:31.

We’ve had some occasional cirrus here the past 2 days, and I’m sure that’s why PHD2 is occasionally reporting a problem. From the PHD2 logs, it looks like the clouds have not stopped the guiding for very long, in the case of 8/7, only a matter of seconds.

Yomamma,

I already have my sequence run set up to do individual captures within loops, so it will be trivial to put a “start guiding” statement after each capture. I realize this will not be effective if a solid bank of clouds moves in (actually, nothing will be), but in my case the past few nights, it’s been just a few nagging cirrus clouds occasionally moving through. With the increased moisture in the upper levels, contrails have been staying around longer than normal, too. I have a lot of jets flying N/S across my area.

Rich

[admin]

Hi,

ah, I see what's going on - the capture isn't being affected, it's the 'dither now' step that is failing because PHD isn't guiding at the time, which makes sense.

You can put that in a retry and an ignore errors - something like this

Code: Select all

    IGNORE ERRORS FROM ONERROR RUN ""
        RETRY ERRORS UP TO 3 TIMES
            GUIDING DITHER NOW
        END RETRY ERRORS
    END IGNORE ERRORS

(I must fix how the ignore errors is written to code as it doesn't read nicely, anyway...)

That snippet will try the dither 3 times and then give up and move on, which will then go round your capture loop and capture the next frame (if necessary, the capture will restart guiding).

I will just check what happens when the dithering is integrated into the capture using the 'Dither every X frames' step to make sure that will not misbehave if PHD2 is not guiding when the time comes to dither.

cheers,

Robin

[admin]

Actually, on second thoughts I am going to modify the code so that the 'GUIDING DITHER NOW' step will try to restart guiding if it is not active rather than just fail. I can't see a downside to that.

cheers,

Robin

[Candieman]

Robin,

Thanks. It sounds like I shouldn't do anything to my script since you are building the fix into the SharpCap code. I'll just download the latest code when I see that a new version is available.

On the bright side, I did 2h 45m of imaging last night and everything worked as I planned, even though some thin cirrus and contrails moved through the area a couple of times, ruining a couple of my exposures. PHD2 ran throughout this without ever losing the guide stars; and the auto-focuser worked great too, using a smaller scan size than I used to use. I did include a "Start guiding if necessary" after each capture as was suggested yesterday, although it doesn't look like that was necessary this time around.

A couple somewhat related questions:

1. Is there any thought being given to having a command such as "Auto-focus every 'X' frames" included, as there is for dithering?

2. Does the script language in SharpCap allow for variable names and if-then-else structures?

Rich

[admin]

Hi Rich,

glad to hear that things are largely working well at the moment. I think the best bet is to wait for the next update on Monday which will contain the 'auto start guiding to do a dither' fix.

There is currently no built in autofocus every X frames, but you can build something similar - there is an advanced block called 'Run a periodic task every X seconds', which you can use. Set the interval to how often you want to focus, and put the steps needed to focus (and put settings back to capture) inside the periodic block. You need to use another block - 'Stop running a periodic task...' to stop it when it is no longer appropraite.

Like dither operations, these periodic tasks run at idle points in the sequence - that is between steps and between frames when capturing more than 1 still frames in a step.

Variables and if-then-else would be a big change, particularly the amount of work to support that in the editor would be very large. I'm quite reluctant to do it at the moment as it removes the fairly predictable nature of the sequencer in its current form.

cheers,

Robin

[Candieman]

Robin,

I think I found a reason for at least some of the cases involving SharpCap's interaction with PHD2 and dithering. I call it "user error". I do my imaging using a relatively powerful laptop. I remember this happening a few nights ago, but I didn't connect the two, but it happened again last night, and I finally put two and two together. While the imaging was going on, I opened PixInsight and started processing some data there. In particular, last night I was running BlurXTerminator, and it was during that time that SharpCap stopped my sequence because of the "dither" issue. I've found that some processes in PixInsight, such as BXT, take a LOT of resources of the laptop, and in this case, I could barely even move my mouse pointer while BXT was working. I'm thinking this interrupted flow of information between SharpCap and PHD2, and the imaging sequence was then stopped. I was able to stop BXT, and then I restarted my imaging script and let it run without me doing any other processing on the laptop. The sequencing ran successfully from then on. The lesson learned (I think) is not to do heavy processing on the imaging machine while imaging is going on. Live and learn.

I'm going to investigate running a periodic task to do the auto-focus at set intervals. That sounds like it could really simplify what I want to do. It also means I won't need variable names and if-then-else constructs. That should be music to your ears.

Rich

[Candieman]

Robin,

I looked at that "Run a periodic task every x seconds" command tonight. Looks like that will work for me, although I was too chicken to implement it on my 5+ hour imaging session tonight. I was a bit confused by it at first, because the way I have looping set up in my current script, I auto-focus every x images, while the "repeat" command will auto-focus every x seconds. They both may wind up doing the same thing, it's just a different way of looking at it. I'll test it some more before implementing it for good. It certainly shortens my script, and with the way I'm setting it up, the image count number in my filenames will no longer always be "1" as they are now, it will be the actual number of the image that was taken.

Rich