Comet Guiding on AP1200

[JS]

Hi, I'm struggling with getting PHD2 to do Comet Tracking on my AP1200.

I've tried every permutation I can think of:

1. AP1200 ASCOM tracking at the comet rate (guiding disabled entirely)
   
2. PHD2 guiding at the comet rate (AP1200 ASCOM tracking rate set to Sidereal)
   
3. PHD2 guiding at the comet rate AND the AP1200 ASCOM panel set to the comet rate
   

And the tightest images of the comet nucleus I'm getting is #1, i.e., PHD2 disabled. I just can't get a tight nucleus with #2 or #3.

I'm entering the dRA and dDec values from a CdC into PHD2, and dividing them by 3600 (to get from "/hr to "/s) before entering them into the AP ASCOM driver.

Any suggestions?

Thanks,

JS

[Brian Valente]

Hi Jim

I don't suppose you are using NINA to image? 

--
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/e673c7ec-6231-4ac1-b8a7-c8c7812728b5n%40googlegroups.com.

--

Brian 

Brian Valente

astro portfolio https://www.brianvalentephotography.com/astrophotography/

portfolio brianvalentephotography.com 

astrobin https://www.astrobin.com/users/bvalente/

[JS]

Yes, although these were tests I did using the 'manual' exposure button in the Imaging pane (i.e., I was not running a Sequence).

Why? -- does Nina + PHD2 + Comet = trouble?

[Brian Valente]

NINA has a great plugin called Orbitals that will automatically set your rates for both guiding and/or your mount. 

It may help avoid any calculation or other errors in this, i've had good success with setting both guiderate and mount tracking speed using this tool

 Very easy to use

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/08c7cdbb-e896-4ec0-b0b9-e5946ee47ff4n%40googlegroups.com.

[Bruce Waddington]

There's also a comet-tracking feature in PHD2 that doesn't rely on any features in the mount other than pulse-guiding.  It's described in the Tools section of the manual:

https://openphdguiding.org/man/Tools.htm#Comet_Tracking

Bruce

[Brian Valente]

Bruce FYI that NINA plugin can set those rates within PHD with a button push, based on the ephemeris of the comet (or other solar system object)

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/0a6340ea-9fd2-4ef2-8e06-0ad459b43bdfn%40googlegroups.com.

[Bruce Waddington]

That's cool.  Judging from screen-shot, it looks like NINA supports two methods.  For mounts that don't support continuously varying tracking rates, you can set the 'guider shift rate' - that's the PHD2 feature I was talking about.  For mounts that do support variable tracking rates, it looks like you can take that approach instead.  Seems very thorough.

Bruce

[Brian Valente]

Yes I agree (sorry my arrow was pointing to the wrong button there)

I have experimented a bit and I found setting both seems to be the best approach, although it wasn't scientific. 

Do you think one or the other would interfere with each other?

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/9f9ec7b9-2937-4651-a918-67652a4c281en%40googlegroups.com.

[bw_m...@earthlink.net]

I haven’t done comet-tracking and haven’t thought about this much – but my initial guess is the two would interfere with each other.  But I really don’t know.  The PHD2 feature is really there to handle the job for mounts/mount drivers that don’t support variable tracking rates.

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Brian Valente
Sent: Monday, July 4, 2022 8:52 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Comet Guiding on AP1200

 

Yes I agree (sorry my arrow was pointing to the wrong button there)

 

I have experimented a bit and I found setting both seems to be the best approach, although it wasn't scientific. 

 

Do you think one or the other would interfere with each other?

 

 

 

On Mon, Jul 4, 2022 at 8:50 AM Bruce Waddington <bw_m...@earthlink.net> wrote:

That's cool.  Judging from screen-shot, it looks like NINA supports two methods.  For mounts that don't support continuously varying tracking rates, you can set the 'guider shift rate' - that's the PHD2 feature I was talking about.  For mounts that do support variable tracking rates, it looks like you can take that approach instead.  Seems very thorough.

 

Bruce

 

On Monday, July 4, 2022 at 8:43:44 AM UTC-7 bval...@gmail.com wrote:

Bruce FYI that NINA plugin can set those rates within PHD with a button push, based on the ephemeris of the comet (or other solar system object)

 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i5rZtbQNK0fdvDihTjthB1o90NR61crzttV3e5bCuc-7g%40mail.gmail.com.

[Bruce Waddington]

@Brian:   But wait! <g>  After drinking 3 more cups of coffee, I've changed my mind.  I think running both the mount and PHD2 versions of comet tracking might work well after all - assuming the orbital element info and the internal math produce the same results in both areas (they probably do).  PHD2 does comet tracking by using the orbital data to forecast where the comet should have moved since the previous exposure.  It then changes the lock-point to that location and pulse-guides the guide star to that lock-point.  If we imagine a perfect mount, the adjustment will already have been made by the mount before PHD2 takes the next exposure, so PHD2 would always find the guide star already at the new lock-point - nothing further to do.  The mount isn't perfect of course, so the comet model used in the mount isn't going to account for polar misalignment, PE, all the usual stuff.  That implies that the guide star won't always appear magically at each new lock-point but will be off-the-mark because of these errors - hence there *is* some work to be done by PHD2 and pulse-guiding.  Now I suspect your impressions about this were right.

Bruce

[JS]

Wow, what a great find. Thanks, I had no idea that this plug-in existed. Interestingly, I don't see Any of those buttons in your screen shot, although I'm offline and using the simulators to play around. Is that screen shot from the Framing, Sky Atlas, Sequencer, or Imaging tab?

[Brian Valente]

imaging tab, make sure you download the Orbitals plugin

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d9db3816-6193-415b-ba2d-a0a7826b09b0n%40googlegroups.com.

[JS]

Been playing around with Orbitals in NINA. Really terrific plug-in, thanks for the recommendation.

Things seem to work well unless or until PHD2 momentarily loses the guide star. Last night, for example, it lost the guide star and then started "runaway guiding" where it continuously pushed the mount pretty hard so that all of my subsequent exposures were severely trailed to the tune of about 3.7 arc-min (of trailing) in a 4min exposure. I can see the moment in the PHD2 log file when it lost the guide star, and this correlates exactly with when the trailing starts.

Is there a known issue with PHD2 "re-converging" (or recovering) from a lost guide star when comet tracking is enabled?

[Brian Valente]

Hi Jim

We need to see the guidelog to see what's going on.what target were you tracking?

When you set this up, did you also change the rate on the mount? I found that made a big difference for how hard PHD had to work to keep things on track. 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c7a5b3a2-1877-41a4-a4a1-4715b3c30f9bn%40googlegroups.com.

[JS]

Comet is C/2022 E3 (ZTF), which is moving pretty quickly in RA (-0.0285 "/s mount, -102.5 "/h PHD2), and fairly slowly in DEC (-0.0015 "/s mount, -5.27 "/h PHD2).

Yes, I had the Orbitals plug-in set the comet rates in both PHD2 and the mount. I confirmed with the AP ASCOM logs (and visual inspection, but that was before the problem started) that the mount was tracking at the comet rate.

The first 17 exposures worked like a champ. Comet nucleus is sharp, and stars are elongated exactly the amount you'd expect given the rates mentioned above. But at about the 3min (of 4min) mark of the 18th exposure, everything went haywire, and every exposure from that point onward has massive elongation/star trails. See attached.

Logs are in this folder:  https://drive.google.com/drive/folders/1v0wd9fiDmOyGKJZMdbAzjuszUh-6gGam

I think the exact moment the problem happened, by inspecting the timestamps of the (imaging camera) exposures, are these lines here, particularly this first one.

00:08:12.181 00.002 17788 Error thrown from C:\cygwin\home\agalasso\projects\phd2\guider_multistar.cpp:940->UpdateCurrentPosition():newStar not found
00:08:12.183 00.002 17788 SchedulePrimaryMove(0C34BD78, x=0.00, y=0.00, opts=14)
00:08:12.184 00.001 17788 Enqueuing Move request for scope (0.00, 0.00)
00:08:12.186 00.002 7072 Worker thread wakes up
00:08:12.186 00.000 7072 worker thread servicing REQUEST_MOVE scope ofs (0.00, 0.00) opts 0xe
00:08:12.186 00.000 7072 Handling offset move in thread for scope, endpoint = (0.00, 0.00)
00:08:12.186 00.000 7072 move complete, result=0
00:08:12.187 00.001 7072 worker thread done servicing request
00:08:12.293 00.106 17788 Throw from C:\cygwin\home\agalasso\projects\phd2\guider.cpp:1352->unable to update current position

Let me know if you want the NINA or AP logs too.

[Bruce Waddington]

PHD2 can't guide if it can't find a guide star.  You lost the guide star at 00:08 but didn't try to find new guide stars (auto-find) until 00:31.  So in that time interval, PHD2 wasn't guiding at all. Even after the auto-find at 00:31, the lock position shifting produced such a huge offset that the comet-tracking was disabled.  Unless you have diagnostic image logging enabled, there's no way to know why the guide star was lost.  If you know the skies were clear and stars were available, perhaps the guide star wandered outside the tracking region.  For a fast-moving comet, maybe you could try increasing the size of the search region.  Enabling the diagnostic image-logging features (Global tab of Advanced Settings) might be a good idea to help track down these kinds of problems.

Good luck,

Bruce

[JS]

Thanks Bruce. I'm trying to make sense of all of this and I think multiple things are going on:

First, your analysis is really helpful.  The chart below plots the guide corrections and the StarMass. The latter is certainly going down until it is "lost", but when I look at the sky background of all of the good and all of the bad exposures (imaging camera), there is no indication that the sky background is getting brighter over this time (e.g., due to clouds at my fairly light-polluted location). What I think might be happening is that the selected guide start is drifting further out of the well-corrected and un-vignetted field of my OAG and guide camera. Compounding this is that the OAG has a small porthole that further vignettes (if that's even the right term) the light to the guide camera. So, I think that's the explanation for the StarMass going down. This generally isn't a problem at Sidereal, but when tracking a fairly fast moving comet (like this one), it becomes very problematic, as we can see here.  I'm wondering if NINA/Orbital should actually tell PHD2 to find a new guide star for every exposure, rather than only when it stops to auto-focus. If any of this makes sense, I'm happy to take it up with the very helpful gent who wrote Orbitals.

The other thing, and this is a mystery to me -- the mount basically "takes off" at a rate fast enough to create a streak in all of the stars. The streak is ~136px long in 4min, which at 0.61"/px = 0.92"/s of sky angle, or about 0.076 RA seconds/s, although my arithmetic might be off. I can't see anything in the PHD2 logs or in the AP ASCOM logs that would explain that, until much later when Orbitals loses its mind and starts sending crazy comet tracking rates to PHD2. (Bug fix for that is in progress!)  But my point is, that streaking starts well before the first "crazy" tracking rate is sent to PHD2, and therefore I'm wondering if there's some other cause for this "runaway" guiding (tracking?) behavior. Theoretically, if PHD2 is not sending guide commands to the mount at all, then either (1) the stars should be essentially "perfect", modulo periodic error, polar alignment error, etc., if the mount is at Sidereal, or (2) the stars should smear a handful of pixels because the mount is tracking at the comet rate. But in either case, there shouldn't be really long streaks. I'm perplexed by this one.

Thoughts on the sanity of the first analysis, and thoughts on what might explain the second, would be very much appreciated.Thanks so much for your help!

[Bruce Waddington]

I don't know what was going on with the mount tracking after PHD2 stopped guiding and I'm not convinced there's much point in doing this "dumpster dive" after the guide star was lost <g>.  You should be aware that the isolated guide commands starting at around 00:17  became increasingly large and were soon capped by the max duration setting of 2500ms.  I also notice you're running with the default Min-HFD value of 1.5 px which I suspect might be too small for your system.  You should adjust that based on your experience with the size of the smallest, usable real stars your guide system returns.  If PHD2 accepts sensor noise as a guide star during a cloudy period, you can also get this sort of runaway behavior.

Bruce

[JS]

Touche. Love me some dumpster diving. LOL. Thanks for the Min-HFD tip. Much appreciated.

Can you clarify something for me? -- in the Comet Tracking window, is the RA value in arcsec/hr to be interpreted as "seconds of Right Ascension per hour", as in, the ss portion in hh:mm:ss of Right Ascension expressed in hours, or is it to be interpreted as "arc-seconds of sky angle per hour", as in, the ss portion of an angle in degrees expressed as dd:mm:ss per hour?

The quick experiment I did suggests the latter interpretation, whereas my mount (and Orbitals, if I'm not mistaking) is using the former.

As an example, a quick check in Orbitals of C/2022 E3 (ZTF) gives the following: RA = 17:17:25, DEC = 35:41:45, RA rate = -0.0273 arcsec/sec, DEC Rate = -0.0025 arcsec/sec

Is PHD2 expecting a straight conversion of that RA rate to arcsec/hr, as in, -0.0273 RAsec/sec * 3600 sec/hr = -98.28 RAsec/hr?

Or is it expecting the conversion of that to sky angle, something like: -0.0273 RAsec/sec * [15 * cos(DEC)] arcsec/RAsec  * 3600 sec/hr = -1197.23 arcsec/hr?

[bw_m...@earthlink.net]

If you’ve checked the box for ‘mount coordinates’, I think you would do the “straight conversion” of the RA rate to arc-sec/hr.  The declination dependency only comes into play when the rates are converted to camera coordinates, something PHD2 does for you.  You can see what was done if you open the PHD2 debug log file and do text-searches on ‘UpdateLockPosShiftCameraCoords:’

 

Bruce

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of JS
Sent: Sunday, August 7, 2022 10:09 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Comet Guiding on AP1200

 

Touche. Love me some dumpster diving. LOL. Thanks for the Min-HFD tip. Much appreciated.

--

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/d89632cd-d5c6-43ef-8664-8a4f6ea8bde3n%40googlegroups.com.