PHD2 - This Might Explain Why My Guiding Graph Isn't Flat...

[StuartJPP]

I know we shouldn't obsess about PHD2 graphs and look at the captured image instead...however something doesn't feel right about that and seeing as imaging is out of the question at the moment I thought I'd investigate this issue a bit further. This has probably been done before and possibly an answer has been found but I couldn't find it...

Anyway I do occasionally obsess and I was quite perplexed how some people's graphs look as flat as a pancake and other's, including mine look like a mountain range. Sometimes however it is the fact that "they" haven't set up the pixel scales correctly and what looks flat is actually not so, especially when viewing PHD1 graphs with no scale. Sometimes a PHD2 graph does indeed look flat and everything looks to be entered correctly so it is possible.

Tonight I decided to eliminate as many variables as possible by using a synthetic star, a single 50% grey pixel on a black background on my monitor. I disconnected the motors on the mount once the calibration phase was complete and then started guiding. In theory this should produce a flat graph since all I am doing is recording a fixed position "star" and no movement in RA or DEC. The results weren't quite as flat as I had expected and confirmed something I had suspected for a while...

I wanted to eliminate as much as I could, seeing, mount, ASCOM control, guiding pulse lengths, hysteresis, aggressiveness etc.

First of all I guided on the synthetic star. I made sure that there wasn't any movement between the mount and the "star" and left it "guiding" for a short while. This is the result:

The 2nd test I performed was to guide on a "hot" pixel. This would hopefully eliminate any guide scope optical issues. A lot flatter but still not as flat as I would have expected.

What does this show? Not 100% sure, but it does explain a few things that I have seen on my graphs...that they can be a bit erratic for no apparent reason...I did run the tests with the guide stars slightly defocused and the results were very similar...

I am suspecting some sort of dithering/rescaling applied to the incoming image, either within PHD2 or at driver level as it doesn't appear to be running at its native resolution.

Any comments? Is this test nonsense? Am I doing something fundamentally wrong?

[Pompey Monkey]

I've seen this pattern superimposed on on some of my guide graphs too. I also use a QHY5.

I can't replicate your first graph as I don't have a solid enough floor in my house to guarantee stability to that accuracy, but I might have a go at guiding on a hot pixel tonight after work. How do you do that BTW? Do you just leave the cap on the guider?

Also, 0.1 seconds integration time? That might cause a problem in itself, even on a static target:  There are quite a few calculations going on in the background in PHD/ASCOM/camera driver/Windows etc.

[sharkmelley]

I believe that what you are seeing are random noise effects.  The image created by the guide camera is of a star (whether it be real, synthetic or hot pixel) but degraded by random read noise and photon shot noise - maybe thermal noise as well.  PHD then has to determine the centroid of the star.  The centroid calculation is degraded by the random noise so it will "wrong" by a random amount each time. 

This random error can be reduced by choosing a star with high SNR (signal to noise ratio) and with adequate FWHM.  An SNR of 30 is good and a FWHM of 2 or more is good (the guide camera can be defocused slightly to achieve a larger FWHM).  This should keep the random centroid errors to be less than 0.1 of a guide camera pixel.

Remember that when using a real star, the seeing will also cause more random positional errors - depending on the integration time - even with a perfectly tracking mount.  So guiding with a perfectly tracking mount would actually degrade tracking accuracy.  An interesting thought!

Mark

[glowingturnip]

interesting that the scatter graphs show an almost perfect 45 degree line between the RA and Dec 'errors' though, would argue that it's not actually noise as such.

Do you happen to know which way PHD thought RA and Dec were aligned vs up and down on the guidecam frame ?  (doing an RA-Dec overlay from the view menu would show that).

I'm wondering if the first is from the way the monitor scans each line it displays, with some interlacing or whatnot ?  If so, then a longer integration time would average that out.  I wonder if the camera has a scanning/interlacing thing going on too.

Interesting experiment

[strutsinaction]

Interesting test, Stuart!

Maybe include the SNR plot in the 'artificial star' guiding graph to see how that is changing. For me, I've found that a varying SNR can give rise to a 'mountain range' guiding graph, even though the SNR is still high (typically > 30 with my Lodestar X2). My stars are still round though so I tend not to worry about this.

Try increasing the exposure time and see what effect that has.

You might also want to post your findings to the PHD yahoo group and see if one of the developers has any advice:

https://groups.google.com/forum/?fromgroups=#!forum/open-phd-guiding

Regards

John

[StuartJPP]

Also, 0.1 seconds integration time? That might cause a problem in itself, even on a static target:  There are quite a few calculations going on in the background in PHD/ASCOM/camera driver/Windows etc.

I had to choose a short exposure time because it wasn't quite dark when I first started the test, the blinds were closed but there was still enough light leak as the sun happened to shine on that evening. Though later on in the evening I did change the exposure time and it didnt' seem to affect the results much if at all...

I might have a go at guiding on a hot pixel tonight after work. How do you do that BTW? Do you just leave the cap on the guider?

I could see the pixel with the guide scope on as usual as the rest of the screen was black...they were easily identifiable as pushing on the guide scope lightly didn't move these few stuck pixels but did with the simulated star.

...Remember that when using a real star, the seeing will also cause more random positional errors ...

Thanks for the analysis Mark...all valid. I accept the above but I can't expect a flat graph if it isn't flat under "ideal" conditions. I know I shouldn't expect flat but it just seems wrong...

interesting that the scatter graphs show an almost perfect 45 degree line between the RA and Dec 'errors' though, would argue that it's not actually noise as such.

Do you happen to know which way PHD thought RA and Dec were aligned vs up and down on the guidecam frame ?  (doing an RA-Dec overlay from the view menu would show that).

I'm wondering if the first is from the way the monitor scans each line it displays, with some interlacing or whatnot ?  If so, then a longer integration time would average that out.  I wonder if the camera has a scanning/interlacing thing going on too.

Interesting experiment

Stuart, I noticed the 45 degree anomaly as well...I can't quite say exactly how the alignment was for the guide scope but it didn't seem to matter. All interesting thoughts...

Interesting test, Stuart!

Maybe include the SNR plot in the 'artificial star' guiding graph to see how that is changing. For me, I've found that a varying SNR can give rise to a 'mountain range' guiding graph, even though the SNR is still high (typically > 30 with my Lodestar X2). My stars are still round though so I tend not to worry about this.

Try increasing the exposure time and see what effect that has.

You might also want to post your findings to the PHD yahoo group and see if one of the developers has any advice:

https://groups.google.com/forum/?fromgroups=#!forum/open-phd-guiding

Regards

John

John, I will try to do this again and add some more info, it was a quick test, though it never ends up being quick...I'll try it when it is properly dark then I can get a decent exposure length. I know we should look at the end result and not the graph...but I like to know why things are like they are, even if I don't understand the science fully behind it. I'll refrain from posting to the PHD group just yet in case there is something wrong with what I am doing (though the hot pixel can't be explained away easily).

So thanks guys, just wanted to see people's views on this. I will revisit it as no doubt we will get more time to image synthetic stars than we will real stars, especially for the next few months...

As I and many have said, as long as the stars are round who cares...but I do...until I can explain it away that is.

[Earl]

first things first set your guide sub to 3 seconds and see what you get then.

Dont forget you need to recalibrate when you change sub lenght afaik.

[Phillyo]

Why would you need to recalibrate for change in sub length?

[msh1]

i dont bother to recalibrate if i change sub length not noticed a difference

mark

[Earl]

I recalibrate out of habit every time i use it or change a setting

Not sure if it is needed though.

[Phillyo]

Calibration takes me about 5-10 min so I only do it once unless I change targets during the night and it's in a vastly different part of the sky.

Sent from my GT-I9505 using Tapatalk

[kens]

For your hot pixel test you should show the graph in pixels. See how the guide star is 1 pixel FWHM (well 0.99). This is very small compared to a real star. If an adjacent pixel lights up through random noise or stray light this will shift the centroid of your hot pixel guide star significantly. Assuming you have, say, 5 arc-seconds per pixel your biggest random shift on the graph is just 0.2 pixels corresponding to an adjacent pixel only 20% as bright as your hot pixel (or is it 40% - whatever). If its the same pixel every time you'll get the linear plot your are seeing. The orientation depends on which pixel and the calibration angle. e.g. if your calibration is 0 degrees so your camera left-right aligns with RA then the plot indicates a diagonally adjacent pixel.

[ollypenrice]

I don't think you can simply ignore the guide graph and look at the final picture. You'd be using the round star test, presumably? But if the errors in guiding are random you'll get round stars but big ones. The round star test is not enough so this thread is well worthwhile.

It seems disturbing that 'guiding' on a hot pixel does not produce a dead flat graph. Since there is no possible way for the hot pixel to drift, and since a correction sent to the mount can't affect the position of the hot pixel, I'd have thought that the graph should be a dead straight line in a healthy setup. If there is some noise which the software reads as associated with the hot pixel then it may calculate a centroid which is not the centre of the hot pixel. But is this really likely? It seems to me that the bumps in the hot pixel graph come from some source of error but I have no idea where.

Olly

[sharkmelley]

Try adjusting the gamma slider for the guide camera display.  You might then be able to visualise the source of the random events that bias the centroid calculation.

Mark

[Big Jim Slade]

I don't think you can simply ignore the guide graph and look at the final picture. You'd be using the round star test, presumably? But if the errors in guiding are random you'll get round stars but big ones. The round star test is not enough so this thread is well worthwhile.

It seems disturbing that 'guiding' on a hot pixel does not produce a dead flat graph. Since there is no possible way for the hot pixel to drift, and since a correction sent to the mount can't affect the position of the hot pixel, I'd have thought that the graph should be a dead straight line in a healthy setup. If there is some noise which the software reads as associated with the hot pixel then it may calculate a centroid which is not the centre of the hot pixel. But is this really likely? It seems to me that the bumps in the hot pixel graph come from some source of error but I have no idea where.

Olly

The SX Lodestar driver does Gaussian blurring at driver level, so its possible the QHY driver might be doing something similar. It there is any image processing going on, that's a possible vector for introducing noise. Something as simple as not zeroing memory before it's used could do it.

[StuartJPP]

When I get the time I will try this again with some of the suggestions above, but anybody is welcome to add their testing as well...especially with a hot pixel as you don't have to worry about rig stability etc. Unfortunately I can only set this up late at night due to not having a dark enough room with the long days...

...It seems disturbing that 'guiding' on a hot pixel does not produce a dead flat graph....

Olly

This is what I was thinking. No wonder I couldn't get a flat(ish) graph under the skies when under "ideal" conditions it won't produce a flat graph. But there is more at play here that I need to figure out.

[StuartJPP]

The SX Lodestar driver does Gaussian blurring at driver level, so its possible the QHY driver might be doing something similar. It there is any image processing going on, that's a possible vector for introducing noise. Something as simple as not zeroing memory before it's used could do it.

Yep think I mentioned this above as a possibility but if the SX does it then there is a possibility the QHY does it...something at the driver level or perhaps how PHD(2) rescales the native resolution of the camera (if it does). The displayed image is certainly not at native resolution, but if the calculations are done on the scaled for display image then that could explain a few things...though that would not be a very clever thing to do and I doubt it is done like that....but you never know.

Thanks for the info regarding the SX Lodestar...

[sharkmelley]

I've just tried the "guiding on a hot pixel" experiment with my own QHY5 in PHD2.  Even with a SNR as high as 50.0 I was seeing very similar occasional deviations as you.  As I said earlier, I'm certain this is caused by random pixel values in the background noise causing randomness in the calculation of the centroid - it is entirely expected.  If you move the gamma slider well over to the left then you'll be able to see the random pattern noise, including the random "banding" which is quite severe on the QHY5 and without doubt affects its performance. 

One other thing of note is the way PHD performs the centroid calculation.  Contrary to what most people might expect, it includes ALL the pixels in your 15x15 box (or whatever size your defined box is) into the centroid calculation.  It doesn't attempt to identify the pixels that define the "star" and take the centroid of just those pixels.  However, the PHD calculated centroid does seem to be pretty robust and works well under most circumstances.

Obviously I'm unable to determine if my explanation is the complete cause of your guiding issues but it is perfectly normal for PHD guiding on a QHY5 hot pixel to behave in the manner you are seeing.

Regards,

Mark