Possible Improvement - Autoselect new guide star is the first one is lost.

[Jacob Heppell]

From time-to-time, PHD2 will lose the star on which it is guiding for whatever reason (probably related to the mount). While that isn't the problem per se, what is means is that PHD2 stops guiding altogether and just beeps until I restart the guiding (I may not be at the laptop at the time this happens). Could an option be made (a checkbox perhaps under the guiding tab) that will allow PHD2 to simply auto select a new star and start guiding in the event that it loses it's first guide star? If this option is already available then please show me where it is.

[Lawrence Lopez]

I'd like multiple concurrent star guiding, myself.

I don't want to switch stars in midflight.

You might start tracking on something with propper motion.

On Thu, Mar 12, 2020 at 8:38 AM Jacob Heppell <jhepp...@gmail.com> wrote:

From time-to-time, PHD2 will lose the star on which it is guiding for whatever reason (probably related to the mount). While that isn't the problem per se, what is means is that PHD2 stops guiding altogether and just beeps until I restart the guiding (I may not be at the laptop at the time this happens). Could an option be made (a checkbox perhaps under the guiding tab) that will allow PHD2 to simply auto select a new star and start guiding in the event that it loses it's first guide star? If this option is already available then please show me where it is.

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/dab48c8d-6bf7-4d55-b05b-6c6d5f18efec%40googlegroups.com.

[Bryan]

Jacob

While PHD2 will stop guidng on a lost star, it will try to re-acquire the original guide star within the tracking rectangle. See

https://openphdguiding.org/manual/?section=Basic_use.htm#Guiding

That may not be adequate for your needs.

Bryan

[Bryan]

Lawrence

See this thread for some discussion on multiple star guiding

https://groups.google.com/forum/#!msg/open-phd-guiding/0TQSSURgqYw/9eRAKioECQAJ

P.S. 

The highest proper motion star known (Barnard's Star) moves just 10 a-s per year.

Bryan

On Thursday, March 12, 2020 at 8:03:32 AM UTC-6, Lawrence Lopez wrote:

I'd like multiple concurrent star guiding, myself.

I don't want to switch stars in midflight.

You might start tracking on something with propper motion.

On Thu, Mar 12, 2020 at 8:38 AM Jacob Heppell <jhepp...@gmail.com> wrote:

From time-to-time, PHD2 will lose the star on which it is guiding for whatever reason (probably related to the mount). While that isn't the problem per se, what is means is that PHD2 stops guiding altogether and just beeps until I restart the guiding (I may not be at the laptop at the time this happens). Could an option be made (a checkbox perhaps under the guiding tab) that will allow PHD2 to simply auto select a new star and start guiding in the event that it loses it's first guide star? If this option is already available then please show me where it is.

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[bw_msgboard]

Hi Jacob.  The reason we don’t want to do this is because automatically selecting another star in the field is going to leave the scope positioned off-target, often by many arc-minutes.  This will mean that subsequent images taken through the main scope will be incorrectly framed and may not even have the target in view.  With a properly working imaging system, the most common reason for lost stars will be poor visibility – fog, clouds, whatever.  In those cases, staying on-target iusually delivers the best hope for recovery.

 

If you’re doing unattended imaging, I assume you’re using an imaging application that has enough automation features to deal with these kinds of problems.  It’s very easy for the imaging app to direct PHD2 to try re-selecting a guide based on a full-frame search, then do a plate-solve and re-center if a guide star is found.  Or the app can decide to let things run for awhile because it has paused imaging.  The point is that automated recovery from lost stars really belongs at the automation level because there’s more context available and the imaging and guiding operations can stay in-synch.

 

Regards,

Bruce

 

 

 

---

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.

[Jacob Heppell]

Yeah fair enough. In my case, when the star is lost,for whatever reason, it is because the star suddenly moved out of the tracking square (less than half an arc minute really). My image acquisition software is BackyardEOS as I use a modded DSLR. I haven't found a feature on BackyardEOS that can handle lost stars. Might be time to give SGP a try!

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[Brian Valente]

>>> I haven't found a feature on BackyardEOS that can handle lost stars. Might be time to give SGP a try! 

yes, this :)

btw SGP has a recovery process that if it completely loses the guidestar (imagine cloudcover) it can retry for an extended period of time until it clears again. totally configurable. I don't think SGP is the only game in town, but it has really nice features for this part 

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/01c5164a-e91b-4a3e-879f-3fe7cad37bd8%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Bryan]

This suggests that something else is going on. 

Guide and debug logs might enlighten us!

Bryan 

[Jacob Heppell]

Yes SGP is well reputed within my astronomy groups! Most however use dedicated astro cams, which I may eventually move to as the bank account allows. It was expensive enough getting setup with the mount, OTA, plus a lot of other random things. For me a DSLR (randomly saw a good special on Amazon!) was better value for money. Then got it modded for astro.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/01c5164a-e91b-4a3e-879f-3fe7cad37bd8%40googlegroups.com.

[Andy Galasso]

Here's link to another discussion thread where a similar question was discussed: https://groups.google.com/d/topic/open-phd-guiding/Lq2MIcPnJc8/discussion

Andy

[Manning Butterworth]

I should have used the Web-based reply tool because my reply got separated from this thread, so let me try again.

I support Jacob’s original request.  Admittedly, the problem he describes does not happen for me a lot, but it does happen.  I image at a somewhat long FL and thus because the guider FOV is small and the number of potential guide stars is small, it is not uncommon for PHD2 to pick a guide star that is near the edge of the field.  Eventually that guide star drifts outside the allowed field for guiding.  

 

Is there any way to tell PHD2 to select a new guide star?  Not to make a correction based on an assumption that the old guide star has moved to the new guide star location thereby moving the scope perhaps several arc-minutes. In other words is there a way PHD2 could recognize that a guide star has drifted unusably close to the field edge and then auto-select a new guide star?

If not, how would one programmatically command PHD2 to do this?  Are there properties exposed in the PHD2 API that would enable such a calculation?  I hope my use case is clear.

Thanks,

Manning  

[Andy Galasso]

On Sun, Mar 15, 2020 at 12:58 AM Manning wrote:

Eventually that guide star drifts outside the allowed field for guiding.  

I assume you mean it drifted while the clouds were overhead, then when the clouds are gone, you would like guiding to resume automatically, right?

Personally that is a scenario that I would like my imaging app to handle, since it will also re-center my target (which has also drifted), but I think I understand what you are asking for.

If you follow the link in my prior post (the post you respond to), it will take you to a script which will do just what you are asking for (I think).

Andy

[Manning Butterworth]

No.  Sorry, Andy.  In my original post on this topic I elaborated on the reason why the guide star became unusable.  It has nothing to do with clouds.  The guide star chosen happens to be near the edge of the field of view because I am imaging at a long FL and the FOV is small and the best guide star PHD2 can find happens to be near the edge of the FOV.  As imaging continues, due to slight field rotation due to slight polar misalignment that star becomes unusable resulting in Star Lost.  What I would like is for PHD2 to recognize that the guide star it was using has now moved sufficiently that it must pick a different guide star and continue guiding on the new guide star.  

The target has drifted to the same degree the guide star has, but the stacking during post-processing handles that.  If the selection of a new guide star would happen relatively soon, any other drift of the target is negligible.  Hopefully, I have better explained the scenario this time.

Would your script accomplish what I am seeking?

If so, it is unfortunately for me, written in Perl which I don't know.  Can it be expressed in VBS? Or, won't that work?  I found an example you provided of a VBS script controlling PHD2 at this location:

https://groups.google.com/forum/#!topic/open-phd-guiding/DI0tzXyn8Ew

I think you have offered some hope of a solution, but I don't know yet how to put it together.  

Thank you,

Manning

[Andy Galasso]

On Sun, Mar 15, 2020 at 10:53 PM Manning wrote:

As imaging continues, due to slight field rotation due to slight polar misalignment that star becomes unusable resulting in Star Lost.

I would like to understand that more. As long as guiding is proceeding normally, the selected star ought to stay locked in place and field rotation will be around the guide star (the guide star will be the center of rotation.)  Do you have a guide log showing an example of the scenario you are looking to solve?

[Manning Butterworth]

Hi Andy,

Your comment about the guide star being the center of the field rotation is interesting.  I use an AO.  I am unsure how that may or may not affect the field rotation.   As you say, it would seem that the guide star should remain fixed.  As to a log, I may be able to find a relevant one.  If so, I will upload it.

Thanks,

Manning