Discard images after excessive Phd drift

Issue #1036 closed
Cedric Raguenaud created an issue

For unsupervised operation, it is essential to be able to take action when Phd drifts above a certain amount so that images aren’t recorded and counted when they’re essentially garbage. Ideally, a maximum drifft would be specified (bonus: in arcsec) and if the RMS goes over that limit, the image is cancelled and not counted.

Thanks for the good work.

Comments (11)

  1. Ara Jerahian

    Hey Cedric, just curious, wouldn’t the existing “center after drift” instruction keep this issue from occurring? As it stands, this instruction has no overhead on imaging time as it plate-solves to check for drift in parallel to the primary imaging flow.

  2. George Hilios

    If I understand Cedric properly, he’s referring to aborting exposures if PHD2 drifts during the exposure beyond a threshold. That would be a signal the exposure is garbage anyways, and that it would be better to start from scratch.

    Cedric, assuming I understood you right - it’s not something we’re planning to implement in the near future. It could be done as a plugin, and that’s the form we’d prefer it in. At the moment, none of the contributors have voiced an interest in addressing this, as they/we are focused on other areas.

  3. Cedric Raguenaud reporter

    Hi all,

    Yes George, that's it. Center after drift wouldn’t work since the drift won’t be permanent ad PhD will try to bring the guide start back to its position, usually fairly quickly. But in the widow when the star drifted, it trashed the image.

    Ok, I’ll look into writing such a plug in at soon as I have time. I’m surprised nobody had been interested in this. It's a fairly common problem and with long exposures (20, 30 minutes) there is a lot of time to be lost on garbage exposures.

    Thanks.

  4. George Hilios

    Users have been interested, but the people building the things haven’t. My personal thinking here is that if you have enough clouds to interrupt your 5-10 minute+ exposures, it’s unlikely that starting new exposures each time is going to yield you much. The biggest thing though for me is the opportunity cost of adding other features, such as the model builder I just finished or the satellite tracker I am working on now.

  5. Cedric Raguenaud reporter

    It’s not just clouds. It’s wind (even a small breeze can push an exposed telescope), seeing, polar alignment, mount imperfections, backlash, etc. Lots of things can make the guiding drift a bit. It can be more or less visible depending on distance, duration, focal length, etc.

    I understand it’s not convenient to add at the moment. I'll have a look at plug ins.

  6. George Hilios

    Awesome. Can’t wait to see your contribution. If I may suggest taking a look at the center after drift trigger implementation. it kicks off a background thread and checks into it periodically whenever the trigger fires You’d need a similar pattern for this to work

  7. Cedric Raguenaud reporter

    Thanks. Yes I was thinking something like that. A background thread that monitors the PhD total RMS and triggers exposure cancellation if it goes over a threshold.

  8. Kyle Goodwin

    I would definitely find this useful. My use case is wind. When I get a few gusts of wind during an exposure it’s pretty likely it’s garbage that I’m going to throw away. If I’m imaging at 0.6” and guiding for a sub is at 1” there’s essentially 0 chance it’s a usable image.

  9. Log in to comment