Clarification Please on Comet Tracking Rates

[Kent]

Hi Andy, et. al.

Maybe this has been asked before but I couldn't find it. Originally, tracking rates were in the x-y camera coordinate system. Now they are in RA and Dec. So is the comet RA rate multiplied by the cos(Dec) in PHD2? Or do we need to input RA-rate*cos(Dec) to provide it in the x-y coordinate system? I ask this because I used the actual RA rate and the tracking jumped between subs. Plus, the comet's nucleus was smeared in the subs(41P on 3/17).

Thanks for any clarification,
Kent

[Andy Galasso]

Hi Kent,

The Comet Tool allows the rates to be specified as either sky (RA/Dec) or camera (X//Y) rates.

One possible explanation for the poor tracking could be that the sign of the rate could be off. For example if the ephemeris dec rate is 211 arc-sec per hour, you may have to input "-211" as the dec rate.  PHD2 does not always know the guide direction polarity (RA/Dec guide direction vs true sky direction), so it is possible that the rate entered in the tool could be reversed. Another possibility would be an incorrect pixel scale in PHD2 (incorrect guide scope focal length or camera pixel size given to PHD2.)

Have you tried the Rate Training method? That will get the guiding synchronized to the comet in a short amount of time without requiring you to enter the rate manually and is not susceptible to polarity errors or image scale errors.

Andy

[Kent]

Hi Andy. Thanks for responding. I don't think I had the sign off because the results were not that far off. When I stacked 3 five minute subs, I noticed that the star trails did not line up, primarily in the RA direction, leading me to think the RA rate was bad. Does PHD2 continue to track the comet while downloading or settling between subs? If not, that might explain the offsets I see. The smearing of the nucleus I saw might then actually be real, otherwise there is still a problem.

I am running remotely and automatically, so I don't want to have to do the training.

Regards,
Kent

[Andy Galasso]

On Fri, Mar 24, 2017 at 9:00 PM, Kent <kentd...@cox.net> wrote:

Does PHD2 continue to track the comet while downloading or settling between subs?

PHD2 is not actually tracking the comet, it is moving the lock position at the specified rate, and the motion is a function of time, unrelated to settling, downloading, or anything else.

 

I am running remotely and automatically, so I don't want to have to do the training.

I'm not sure what you mean by that. Was there something in the training instructions that gave you some reservation about doing it remotely or that gave you the impression that you needed to be physically at the scope?  I'm interested because if so I'd like to clarify the instructions.

Thanks,

Andy

[Kent]

Hi Andy,

I use SGP. Just checked the sequence and I only paused PHD2 during backlash comp, but that wouldn't amount to much pausing. It is good to know you keep adjusting the lock point during downloading and settling. Here is a link to my "problem" (one of 'em, anyway) that puzzles me:

https://www.dropbox.com/s/gy18aqaatbzszwd/Screenshot%202017-03-24%2020.37.21.png?dl=0

Again, this is a stack of three 5-min subs. You can see the star trails don't line up (please ignore the bad tracking points at the ends of the first and third subs). This is a fast moving comet but even so I would think they should line up unless the lock point is shifted somehow in addition to the comet's motion. Also notice the streaked nucleus in the same direction as the endpoints of the mismatched trails in the subs. Maybe real, maybe not.
 
The reason I don't want to use the training method is that I may be asleep. The training method, which I could use remotely as you say, still requires "hands on".  I set the sequence up ahead of time and put the rates that the comet will be moving when the sequence starts into PHD2. It sits there until the sequence starts. BTW, I'm 300 miles away from my observatory.

Thanks for your input and any further suggestions you may have.

Kent

[Andy Galasso]

Kent,

You may be on to something with the RA rate conversion not including any compensation for declination.  To get the X/Y shift rates the code is just taking the RA/Dec rates entered and doing a rotation by the camera angle, and then scaling by the pixel scale.  I believe this is over-estimating the RA shift rate by a factor of 1/cos(declination). So I think you should enter (ephemeris_dRA)*cos(declination) for the RA rate.

Could you give that a try and see if gives a better result?  Once we confirm that we are on the right track here, we can look into updating phd2 to make this more automatic.

Thanks,

Andy

[Kent]

Will do Andy, when I get my next opportunity. The WX does not cooperate very well at my observatory. Either too cloudy or too windy. Thanks for looking into it. I can use JPL/Nasa Horizons ephemeris which gives dRA*cos(Dec).

Thanks,
Kent

[Kent]

Well, Andy - the plot sickens. I got some images last night and stacking in Maxim shows a similar effect. I used NASA/Horizons rates with the cos(Dec) factored in. 5 minute exposures again.. See image at:

https://www.dropbox.com/s/xg2uyswhvz4o03k/Screenshot%202017-03-27%2011.08.30.png?dl=0

This time, I used Maxim to display a "Range" screen stretch (i.e. none, I think). It is obvious that the tracking of the comet is good, as you can see from the three little nuclei (from each of the subs). Interestingly, they are offset at right angles to the star trails. This seems to indicate a problem with Maxim comet stacking. I used "1 point manual". You can see, though, that the length of the points trail is about the same as the distance from the endpoints of the star trails from the first to third sub. The relatively pointy nuclei in the subs indicates your offset tracking is good, If Maxim did it's job right, the three little nuclei would be one and the star trails would line up. It does, however, look like PHD2 should multiply the RA by cos(Dec). Or should the user do it? What does Carts Du Ciel do? Maybe there should be a choice between raw RA and RA*cos(Dec).

On a somewhat related note, I had a hard time with SGP telling me "Waiting for Guider to Report Done Settling" even though the RMS guiding was less than 0.5". It goes through the SGP settle then waits and waits for PHD2. Twice, SGP told me "something terrible happened"after several minutes. Recovery worked so I didn't have to abort. I looked up on the forum and found that other people have that problem and just stop and restart PHD2. So I did that and it seems to work but even there, I got one SGP "something terrible happened". This problem is responsible for the big time lag between subs that you see in the star trails.

On yet another note, I had offsets in both RA and Dec that remained constant at maybe 0.5" above and below the zero line. The RMS was good at less than 0.5". I was tracking at a high Dec (61 deg) and I presume that is the reason. Although I have adjusted the mount alignment multiple times I am not exactly on north but I thought I was close judging by drift analysis. I have seen this other times. Would this be responsible for the guider not reporting it is settled? How, exactly, does PHD2 determine it is done settling? I couldn't find a setting that might affect it.

Regards,
Kent

[Andy Galasso]

On Mon, Mar 27, 2017 at 2:11 PM, Kent <kentd...@cox.net> wrote:

It does, however, look like PHD2 should multiply the RA by cos(Dec). Or should the user do it? What does Carts Du Ciel do? Maybe there should be a choice between raw RA and RA*cos(Dec).

Thanks for confirming that!  I guess we need to update the PHD2 comet tracking UI to add a place to enter the comet's declination along with the ra/dec rates. I'll contact Patrick so we can get the CdC communication updated too.

 

On a somewhat related note, I had a hard time with SGP telling me "Waiting for Guider to Report Done Settling" even though the RMS guiding was less than 0.5". It goes through the SGP settle then waits and waits for PHD2. Twice, SGP told me "something terrible happened"after several minutes. Recovery worked so I didn't have to abort. I looked up on the forum and found that other people have that problem and just stop and restart PHD2. So I did that and it seems to work but even there, I got one SGP "something terrible happened". This problem is responsible for the big time lag between subs that you see in the star trails.

Starting/stopping PHD2 has no bearing on the problem, any apparent correlation is coincidental. (see below)

 

On yet another note, I had offsets in both RA and Dec that remained constant at maybe 0.5" above and below the zero line. The RMS was good at less than 0.5". I was tracking at a high Dec (61 deg) and I presume that is the reason. Although I have adjusted the mount alignment multiple times I am not exactly on north but I thought I was close judging by drift analysis. I have seen this other times.

please post your guide log so we can see what you are talking about

 

Would this be responsible for the guider not reporting it is settled?

sure, possibly, since the settling is based on the guide error

 

How, exactly, does PHD2 determine it is done settling? I couldn't find a setting that might affect it.

The imaging app (SGP) gives the settling criteria to PHD2.  The settings you are looking for are in SGP's Control Panel, Guider tab.  It sounds like your settling criteria are too strict and need to be relaxed a bit -- try increasing the distance setting.

Andy

[Kent]

Hi Andy,

Thanks for responding in such a timely manner (always)!

Can you not get the comet's declination from the ASCOM telescope at the time you're using it to adjust the rates? But entering it manually would be ok too. Actually, you should have it since you use it to adjust Dec movement. Can't you do the same for the RA rate? Just thinking (or not)...

I am glad to hear that starting and stopping doesn't effect the progression of the comet with the rates. Actually, though, the thrust of my comments was that the waiting for PHD2 to report settled is the problem since it takes so long (but not always). Why is it that it will pass SGP's filter but not PHD2's filter (back-to-back) if they are the same? I suspect that SGP looks at RA and Dec RMS while PHD2 looks at the actual error, from what your clarification of what it does. Any way to restrict having to pass the test twice? Maybe SGP could just pass the filter to you and not do it in SGP. That's possibly a question for Ken and Jerod. Am I off base here?

I know the actual error should have a mean of zero. Sometimes it doesn't for me though (see the link) yet the actual tracking can be quite good but it won't start integration because of waiting on PHD2. Frustrating.

https://www.dropbox.com/s/juj55bwz4gl5m38/PHD2_GuideLog_2017-03-26_200605.txt?dl=0

In the log, using phdlogview, Sections 1, 4, and 6 all show the offset effect. On the real-time graph, RA was above the line while in phdlogview it is below the line; wondering why that is? I tried a really high aggressiveness to try to get the tracking closer to zero; didn't seem to have an effect.

Thanks for looking at all this stuff, hope I'm not too long-winded; I appreciate your help!

Kent

[Andy Galasso]

On Mon, Mar 27, 2017 at 4:17 PM, Kent <kentd...@cox.net> wrote:

Can you not get the comet's declination from the ASCOM telescope at the time you're using it to adjust the rates? But entering it manually would be ok too. Actually, you should have it since you use it to adjust Dec movement. Can't you do the same for the RA rate? Just thinking (or not)...

That's a good idea to get the declination from the scope at the time guiding starts, we'll go with that approach.  That way we do not need to change anything with the CdC integration either.

 

I am glad to hear that starting and stopping doesn't effect the progression of the comet with the rates. Actually, though, the thrust of my comments was that the waiting for PHD2 to report settled is the problem since it takes so long (but not always). Why is it that it will pass SGP's filter but not PHD2's filter (back-to-back) if they are the same? I suspect that SGP looks at RA and Dec RMS while PHD2 looks at the actual error, from what your clarification of what it does. Any way to restrict having to pass the test twice? Maybe SGP could just pass the filter to you and not do it in SGP. That's possibly a question for Ken and Jerod. Am I off base here?

Actually, there is only one "filter". SGP tells PHD2 what the settling parameters are (error below X pixels for Y seconds), and PHD2 tells SGP when settling is done.

 

I know the actual error should have a mean of zero. Sometimes it doesn't for me though (see the link) yet the actual tracking can be quite good but it won't start integration because of waiting on PHD2. Frustrating.

I think you'll find that the problem is easily fixed when you update your SGP settling parameters.

 

In the log, using phdlogview, Sections 1, 4, and 6 all show the offset effect. On the real-time graph, RA was above the line while in phdlogview it is below the line; wondering why that is? I tried a really high aggressiveness to try to get the tracking closer to zero; didn't seem to have an effect.

Ok, the guide log looks normal for having comet tracking running.  PHD2 is slowly moving the lock position to match the comet motion, so the guiding is always a bit "behind" and making continuous RA and Dec corrections to keep pulling the guide star onto the (moving) lock position. Even so, the total RMS error was around 0.5 arc-sec -- very good!

RA was above the line while in phdlogview it is below the line; wondering why that is?

What version of phdlogview do you have? Version 0.5 has a fix to make the output plotted in the same orientation as PHD2, but older versions had the output going in the opposite direction.

Andy

[Kent]

Hi Andy,

I Downloaded your latest phdlogview. That fixed the display. Since you take the settling parameters from SGP and use them directly in PHD2 that answers my question about whether the algorithms for settling are the same; they are. In my case, I guess SGP settles then when PHD2 gets them, the tracking has deteriorated and it doesn't settle. Got it! I've increased the settling parameters and will see how that goes.

I think I see that the offsets are due to the comet motion with PHD2 playing the catchup game. Is that right? Won't that have an effect on settling since you're constantly shifting the lock point thus offsetting the tracking and causing it not to hit zero or possibly not be in the settling range? Do I need to increase my settling parameters more for comets than sidereal objects?

Regards,
Kent

[Andy Galasso]

On Mon, Mar 27, 2017 at 7:23 PM, Kent <kentd...@cox.net> wrote:

I think I see that the offsets are due to the comet motion with PHD2 playing the catchup game. Is that right?

exactly

 

Won't that have an effect on settling since you're constantly shifting the lock point thus offsetting the tracking and causing it not to hit zero or possibly not be in the settling range? Do I need to increase my settling parameters more for comets than sidereal objects?

yes, it's the catchup game that is causing the average offset to be non-zero.  But this effect is so small, I do not think it should matter for settling -- unless you have your settling parameters set very aggressively (which you do!)

[Kent]

OK. Thanks Andy. I appreciate the help and I'll try with less aggressive settling parameters. One reason why I have them is to try to get a period of relative calm for tracking. I have a lot of wind here and it affects my tracking. I'll see if I can find the sweet spot. Thanks again for the help and I'm looking forward to the fix for RA-rate= f(declination).

Best Regards,
Kent

[Andy Galasso]

Thank you for reporting the issue and suggesting the solution!

[Kent]

You're welcome, and thank you for such a great guiding program.

Kent

[Andy Galasso]

Hi Kent,

The new dev build 2.6.3dev2 (the one for which I just posted the announcement with Predictive PEC) has the changes to adjust the RA comet tracking based on the scope declination. Feel free to give that version a try and let us know how it goes. No need to make the cos(dec) correction when inputting the RA rate as PHD2 will do that automatically now in the new version.

Andy

[Kent]

Hi Andy,

I used rates from C2A and tried it on 41P; works great. Maybe I should hit Philippe up to send it automatically to SGP like CDC. That would be nice.

Thanks,
Kent

[Andy Galasso]

On Fri, Mar 31, 2017 at 12:41 AM, Kent <kentd...@cox.net> wrote:

I used rates from C2A and tried it on 41P; works great.

Excellent! Thanks for the update.

Andy