Sequence ends after guide star lost

Sequence Generator
#1

Hi all,

I know that SGP will not keep guiding on a lost guide star, but is there away of stopping the end sequence pop up ? or can the image that it wants to end have a choice to KEEP ? I’m currently imaging 15 min exposures & twice now I have had a cloud interrupt my guiding although the cloud didn’t last long the “end sequence” popped up after say 14.5 mins out of 15 & I lose the frame.

It would be nice to have an option and not to lose 15 mins data after exposing for 14.5. I have noticed this in the past that it does this quiet easy in my opinion.

#2

@roger

Are you after stopping the popup dialog or are you after trying to stop the sequence from aborting? You can’t do either, but I am curious what you’re after here.

SGPro does not support partial exposures. Mostly, because:

  • Partial exposures, when stacked, can degrade the final image because it is not as deeply integrated (other methods will use std dev based methods and just cull data from the frame anyhow).
  • Partial exposures would only be useful if the sequence aborts and the exposure is ~ > 90% complete. I think? I can’t think of another reason anyone would want this.
  • A sequence is not likely to abort if the current image is fine (thus the abort)
  • PHD2 does not issue star lost messages unless a clear pattern is established. This takes long enough that, unless the mount’s polar alignment is precise and mechanical errors are minimized, that your image is likely not a candidate for stacking anyhow.
  • Not all cameras support it so it would be a conditional feature (Not sure what camera you are using, but ASCOM partial exposure capability is determined by Camera.CanStopExposure). Because it is conditional, there are several UI and workflow changes required to express capability (and also to turn it off if you have it, but don’t want it). Changes to the help files, addition of general complexity (more options) and finally, we need a way to flag it so it does not masquerade as a normal image. It’s just software and it’s possible… just hasn’t been a huge demand for it.

This has had some consideration in the past… this is just a summary of our thoughts. Again, like any request, if the demand is high, we certainly use it to weight addition of new features.

#3

Hi Ken thanks for the reply,

What I’m after is for me to choose if the exposure isn’t worth putting in the stack. Take last night for example on a 15 min exposure the timer was at 14 mins and a few seconds. Then I had a rouge clout that affected the guiding after a little while the sequence stopped due to the cloud and the current frame was ditched. I know that a 14 min exposure would well fit into the stack of 15 mins exposures without any problems. This happened at least 3 times last night & I ended up just giving up.

you say

•A sequence is not likely to abort if the current image is fine (thus the abort)
How does SGP know that the current image its taking is fine ???

So if that I am hit with a bit of cloud is to keep exposing the frame until the time is up, Then I can decide if it goes into the stack or not. Or have the ability to save the frame before it aborts.

rog

#4

since i regularly use 1800s exposures it would be nice to be able to keep the current frame on abort. just wanted to add my support for the idea.

rob

1 Like
#5

I guess I don’t really understand then…

Maybe I don’t understand all the scenarios in play here. The sequence can only abort during an exposure one of three ways:

  1. Complete disconnect or power loss to primary gear
  2. Safety monitor triggers immediate shutdown
  3. Guide star is lost

Case 1: Obviously nothing to be done here.
Case 2: This might be a candidate for partial download.
Case 3: The one illustrated in this thread, for this frame to be useful, it must have:

  • Integration time ~90% of other lights
  • Near perfect polar alignment
  • Almost no mechanical error in tracking

I am not arguing that if these things are true (they often won’t be) that it would not be nice to have the frame. In reality, it will likely not be common that all these things are true at the same time. Since PHD2 does not issue lost star messages until it can establish a clear trend (validating the star is indeed lost), the frame is probably no good. Given this, I’m not sure how highly it would be prioritized along with other stuff…

BUT… the reason we do this in a public forum is so that people can tell us when we are wrong and features we don’t think are all that useful would actually be pretty popular.

#6

The only senario I’m on about is loosing the guide star.

I think it would be nice to have the option to save that current frame before SGP aborts and chucks it away. ( let me decide if I want it not SGP)

If I use PHD as a stand alone without SGP and lose the guide star will SGP abort ? As this may be the only option

Rog

#7

@roger

I get that you want to decide… my argument is that it’s not likely to be a good image and I’m trying to understand how to prioritize this feature with others.

You can, but you lose dithering. It’s entirely up to you which is more important. My advice is to go with dithering.

#8

Can it not be added if you pass 90% of the timed exposure it will save the file before the sequence aborts.

I only had about 30 seconds left on one when faint cloud interrupted the guide star.

I understand if it cannot be implicated to the excellent software I just find it frustrating that the exposure that could have been used was wasted, Twice

Rog

#9

could you add a tag to the image such as “aborted frame” so the user would know which was the potential bad frame to check before aborting the sequence?
Or have an Abort choice of “download current frame and mark as bad” or “abort without download” and the user can choose which option they prefer?.
Just some random thoughts.

#10

@DaveB

Appreciate the comments, but “how” to implement this is not the issue. That much is clear. I am looking more for the “why” part so we know how to prioritize.

#11

there have been occasions where i am watching the session; it’s starting to get cloudy, or i’m going into the trees, or the mount is about to stop due to meridian limits. i want to end the exposure slightly early, but i can’t because i’ll lose the frame. it would be nice to have the option to end early and keep the frame whether unattended or interactively imaging. it sucks to get to 1600s and lose the frame.

rob

1 Like
#12

I think the real issue is that this is not likely to be supported by most cameras. I know we can’t do it with ASCOM, pretty sure SBIG, FLI and QSI don’t support this either. That leaves Nikon and Canon which I know would support this.

I think before we could really look at doing this in earnest the camera manufacturers would need to change their drivers to allow us to cancel or interrupt an image and ALSO be able to fetch the current data. Currently if you cancel an image the image data is empty on pretty much any camera. I don’t think I’ve ever seen this feature on any capture software and the lack of support for it in the driver is almost certainly the reason.

Canon and Nikon are different as we use bulb to trigger that data. So we theoretically could still fetch this data after an abort happens since we would just be terminating the bulb exposure like normal.

Thanks,
Jared

#13

the sbig ascom driver might not support it but the camera hardware itself does - when i was using equinox image on os x it was able to download an image before its scheduled finish time.

#14

When I used Maxim DL before the switch to SGP I know that I was able to capture the from on a stop even if it was halfway through. Using a SXh9.

Rog

#15

The ASCOM specification will allow a partial exposure to be stopped and the image downloaded. It’s the StopExposure() command. AbortExposure() on the other hand does not allow the image to be downloaded.

I can’t say what cameras support this, I think that the ATIK ones do.

#16

Right… I’m fully aware of the status of hardware support, from above…

SBIG supports it, ASCOM supports it, FLI supports it… all this is, unfortunately not the primary concern.

I need to weigh the usefulness of such a feature against its invasiveness to both the current data and work flow and the SGPro UI (more options, clutter etc.)

#17

Sure, it’s perfectly reasonable for you to make the decision not to support this. But Jared’s post gave the impression that ASCOM is the reason you aren’t doing it.

#18

Right. Just an old ASCOM misconception that both Jared and I had at one point.

#19

This is going over my head a bit, lol.

Are we saying that this cannot be added into SGP ? to saveor have the choice to save the image before SGP decides to abort the sequence ?

If so I may just use PHD outside of SGP

Rog

#20

In summary, this thread validates that it definitely can be added to SGPro, but will require modification to sensitive parts of the image data workflow, changes to each camera type, changes in the UI (more options) and documentation. The intent was to attempt to ascertain the “why” in order to understand if / when we should implement.