332 replies to this topic

[freddie]

I tried it last night. The difference was frankly pretty astonishing. It was too windy for any meaningful test with imaging, but I did some somewhat qualitative testing between gusts since multi-star guiding has no particular advantage when dealing with wind. 

 

The idea behind multi-star guiding is that the majority of seeing effects are localized to areas on the order of arcseconds in apparent angular diameter. This means that each star that is any meaningful distance away from another star in the guide field will experience completely different seeing. Since seeing results in random displacement of star images, averaging the displacement of multiple stars will cause the displacement to add in quadrature just like noise does. PHD2 uses (up to) 9 stars for its multi-star algorithm so we can expect to see "seeing" effects reduces by a factor of the square root of 9, or 3.

 

My test was to run PHD2 unguided and observe the Declination RMS deviation for both the single star and multi-star algorithms. I selected Dec to remove tracking error as a variable. If theory holds, the RMS deviation in Dec should be about 3 times higher for single star guiding compared to multi-star guiding. I found that using single star guiding, my Dec RMS was about 0.45". Using multi-star, it was about 0.21" for a difference of a factor of 2.1. Not quite the 3 that theory predicts, but probably within the error bars of my subjective test. I say "subjective" because I had to reject data that to my eye appeared to be the result of wind gusts. I look forward to trying this on a calmer night.

 

I will say that the effect was pretty remarkable. It was literally like flipping a switch as I toggled multi-star on and off. With it on, the graph would turn to a beautiful near-flat trace, and with it off, the trace would jump around quite a bit more. As for actual guiding, I only caught glimpses between puffs of wind, but during particularly gentle times, I saw patches with each axis less than 0.3" RMS and Dec often dropping below 0.2". My typical guiding performance is around 0.5" per axis, so that is a dramatic improvement.

 

One thing I did notice is that the multi-star algorithm reduced seeing effects enough to reveal the roughness in my mount's RA tracking. There would be times for minutes on end between gusts where Dec would be below 0.2" RMS, and even periods when it dropped below 0.1" for meaningful periods of time. But my RA seldom dropped below 0.25". So it appears that my mount is just not capable of tracking in RA below 0.25" RMS. That's not a complaint, just an observation. Tracking at 0.25" RMS is actually pretty remarkable. 

 

Anyway, my preliminary thoughts are that multi-star guiding is a huge step forward for guiding.

 

Tim

If the test was run with PHD not guiding, doesn’t that just show that with no actual improvement in physical guiding, the multi star just calculates a lower RMS than single star. You could therefore reasonably expect that when guiding is enabled you would still see an improvement in calculated RMS but the physical guiding may actually be no better.

[LCWASTRO]

Wouldnt it take forever to calibrate?

[polslinux]

Well, I just finished building it. For some reason, running ./phd2 like the guide said, opened up the regular PHD2 (2.6.9) that's already installed.

So, I went ahead and run "sudo make install" - now when I run PHD2 (whether with the ./phd2 command or by the icon I have always been using), the newer version starts: 2.6.9dev2. I guess I successfully overwrote (or, rather, updated) the existing PHD2.

To free up some space, I assume I can delete the "phd2" folder created by git along with all its contents. Right?

EDIT: just to confirm everything worked fine! I fired up the Simulator profile both in EKOS and in my newly built PHD2 and everything works. Even the multi-star option. First clear night available I am going to give it a try. I guess I could update KStars/EKOS in the same way - by building it from source and then running "sudo make install". Now I don't have to wait on developers anymore...

Overwriting files installed from the repo is not a best practice because:
1) with the next update (even a simple rebuild) you'll lose your compiled version
2) depending on the Linux distro, next update may fail due to integrity checks
Usually, when compiling software from source, you either should install it in /usr/local or /opt (the former is always in the PATH, the latter depends on the distro)
In this case, you can do that by using the following option in cmake:

cmake -DCMAKE_INSTALL_PREFIX=/usr/local

Edited by polslinux, 03 December 2020 - 03:59 PM.

[imtl]

This topic is about the new multi star feature. For installation stuff please open a new topic. Let's keep this focused please.

Thanks

[Madratter]

I definitely look forward to trying this. Has anyone gotten this to work with Voyager? I know we will end up having to turn off the stuff about Voyager picking the guidestar (or at least I assume we will). So this may be a mixed bag.

[StephenW]

>doesn’t that just show that with no actual improvement in physical guiding, the multi star just calculates a lower RMS than single star

 

The lower RMS with multi-star should indicate that PHD2 will be sending more "accurate" guide corrections to the mount, as it is now accounting for potential seeing variations within the guide camera view, and for errors in centroid calculation (now averaged across multiple stars instead of just one)

 

How / whether this translates to "better guiding" at the mount depends on a myriad of factors.  In many cases, there may indeed be no noticeable improvement at the mount, but that will be despite the more "accurate" guide commands coming from PHD2

[endless-sky]

Overwriting files installed from the repo is not a best practice because:
1) with the next update (even a simple rebuild) you'll lose your compiled version
2) depending on the Linux distro, next update may fail due to integrity checks
Usually, when compiling software from source, you either should install it in /usr/local or /opt (the former is always in the PATH, the latter depends on the distro)
In this case, you can do that with:

cmake -DCMAKE_INSTALL_PREFIX=/usr/local

I wish I knew how to keep the two installations separate!

 

I don't know much about Linux and I just tried following the instructions, but for some reason the "new" PHD2 wouldn't load, and the "old" one kept coming up. I then followed the last step ("sudo make install") thinking that it would install the "new" in its own path, but it ended up overwriting the "old" one instead.

 

Just so we don't steer this thread away from its original purpose - I already hijacked it enough - if you would be so kind to write me a procedure in a PM to keep the standard PHD2/KStars/EKOS separate and also build my own in case I am impatient and don't want to wait for the official update, I would greatly appreciate it.

 

Thanks!

[imtl]

So, even though clouds rolled in last night and I didn't get a chance to do a real test on the light frames themselves, I was still able to grab a few 600s Ha images, with and without the new method.

 

As expected (at least by me), I don't really see a difference in the light frames (still need to properly check them) FWHM.

I am seeing limited and not mount limited as are most people with at least a decent mount and average seeing. 

 

But I would say one good thing about this new implementation (out of more good things), which is that if this takes down the guiding rms then I hope that it will help people to not mess around with their guiding parameters so much (chasing seeing etc) and just let the thing be in the background where it should belong. That will probably yield better images for beginners just because they won't be worried about guide rms numbers so much.

 

Just my 2 cents.

[spokeshave]

If the test was run with PHD not guiding, doesn’t that just show that with no actual improvement in physical guiding, the multi star just calculates a lower RMS than single star. You could therefore reasonably expect that when guiding is enabled you would still see an improvement in calculated RMS but the physical guiding may actually be no better.

Sorry, the part about guiding was a bit buried: "As for actual guiding, I only caught glimpses between puffs of wind, but during particularly gentle times, I saw patches with each axis less than 0.3" RMS and Dec often dropping below 0.2". My typical guiding performance is around 0.5" per axis, so that is a dramatic improvement."

 

Tim

[endless-sky]

But I would say one good thing about this new implementation (out of more good things), which is that if this takes down the guiding rms then I hope that it will help people to not mess around with their guiding parameters so much (chasing seeing etc) and just let the thing be in the background where it should belong. That will probably yield better images for beginners just because they won't be worried about guide rms numbers so much.

I can relate. I think I have touched every single parameter that I could possibly interfere with, in order to make guiding "good enough". Needless to say, none of them made any difference. If PHD2, mount and seeing condition decided that RMS was going to be 0.8" for that session, it would stay there no matter what I did.

 

To be honest, I don't even know why I bother with low RMS values, anyway, since my image scale is 2.08 arc-sec/pixel, and I am always guding sub 1". I guess it just feels good and gives you more bragging rights if you can get it closer to 0.5", though... 

 

Anyway, the multi-star made everyone's guiding better by a good amount, so far. So I hope I can say the same, too, as soon as weather permits.

[klaussius]

I think the bigger benefit will be robustness to lost star events and hot pixels.

 

You could get better performance (real, beyond graphs) but only if you tune your parameters for multi-star (maybe lower the min-move and reduce exposure time), and still it's not very likely to make a huge difference.

 

The point being, it won't make a difference without multi-star specific tuning, but it will make it more robust.

Edited by klaussius, 03 December 2020 - 04:31 PM.

[spokeshave]

I think the bigger benefit will be robustness to lost star events and hot pixels.

 

You could get better performance (real, beyond graphs) but only if you tune your parameters for multi-star (maybe lower the min-move and reduce exposure time), and still it's not very likely to make a huge difference.

 

The point being, it won't make a difference without multi-star specific tuning, but it will make it more robust.

I disagree and that is borne out by my admittedly limited testing. I did not change any of my guiding parameters - just toggled multi-star on and off. The jitter from seeing was dramatically reduced and it stands to reason that incorrect guiding pulses that result from seeing jitter would likewise be dramatically reduced, which is precisely what I saw. 

 

Tim

[endless-sky]

Also, from my understanding, everyone that posted a comparison so far didn't change any other setting and the improvement was massive (almost halving the error is massive, to me).

 

Some of them reported the improvement as being immediately evident as soon as the multi-star button was checked, only to return to "normal everyday guiding" as soon as it was unchecked.

 

As I said above, I fiddled with any possible setting present in the current PHD2 and the difference, if there was any (for the better or the worse) took many minutes to manifest itself. Nothing immediate as an ON/OFF behavior like stated in this thread, when talking about multi-star.

 

Some mounts actually benefit from fast guiding (around 1s exposures) but then you'd inevitably have to deal with seeing fluctuations. This new algorithm should definitely benefit in this scenario, as well. More stars being followed means averaging the seeing and rendering the fluctuations harmless, while enabling short exposures to better "tame" the mount.

[klaussius]

I disagree and that is borne out by my admittedly limited testing. I did not change any of my guiding parameters - just toggled multi-star on and off. The jitter from seeing was dramatically reduced and it stands to reason that incorrect guiding pulses that result from seeing jitter would likewise be dramatically reduced, which is precisely what I saw. 

 

Tim

That only means your minmove was too low to begin with I'd say.

 

Did you see a difference in the subs themselves?

[khursh]

Has anyone done eccentricity comparisons?

[klaussius]

Also, from my understanding, everyone that posted a comparison so far didn't change any other setting and the improvement was massive (almost halving the error is massive, to me).

 

...

 

Some mounts actually benefit from fast guiding (around 1s exposures) but then you'd inevitably have to deal with seeing fluctuations. This new algorithm should definitely benefit in this scenario, as well. More stars being followed means averaging the seeing and rendering the fluctuations harmless, while enabling short exposures to better "tame" the mount.

 

Exactly.

 

FTR, I'm talking about actual improvement in the subs, not graph improvements. Of course the graph will improve, as measurements will better filter the noise from seeing.

 

But whether that actually translates to better subs is the point. Without changes to minmove, and assuming minmove was set properly for the seeing conditions, it should make no difference to the subs save some extreme fluctuations that should happen only rarely.

 

But the more accurate measurements means you are safer from seeing effects, and can both guide faster and more aggressively (lower minmove), and that could improve subs. Slightly.

[TelescopeGreg]

So I can't wait to try this out with my overloaded AVX mount, as it can use whatever help it can get. 

 

That said, how much of the reported improvement is essentially cosmetic, simply being due to PHD2's report having less jitter in it?  I expect that having better centroid data should help the guiding, but then there is the mechanical reality to deal with.  As suggested by others, the real proof will be in the measurement of the resulting stars...

[StephenW]

>the reported improvement is essentially cosmetic, simply being due to PHD2's report having less jitter in it?

 

It's more than just cosmetic: PHD2 will be sending less jittery guide commands to your mount.  How the mount handles the less jittery guide pulses is up to the mount (plus a bunch of other factors)

 

.

[endless-sky]

I am really lost regarding why a better graph shouldn't translate in better images. Honest question, here, to whoever feels like explaining it to me.

Say I am normally guiding at 1" RMS. That is what PHD2 records as errors in the RA and DEC centroid positions over time of the star while it deviates from the its original lock position, once guiding began. It will then issue RA and DEC corrections to try to bring back the star in the lock position.

Now let's look at a 75% RMS improvement thanks to multi-star (value taken from the previous posts). The RMS now will be 0.57". The average of the multi-stars centroid errors is a lot lower. PHD2 will need to issue a lot less RA and DEC corrections to bring back the main star to where it should be, given that the error of the positions is averaged using 9 different stars, instead of just one. The mount is not moving as much as it was, to endlessly chase just the one star and its fluctuations.

Also, with one single star, if I wanted to "average seeing" I need 3-4s exposures. In that time, the mount can wander on its own (due to periodic error or DEC drift, for example) all the while PHD2 doesn't even know what it's doing until the exposure is finished. With more stars, I don't need long exposures to average the seeing, since the 9 stars seeing fluctuations are being averaged "on the fly": I can then use 1-2s exposures and keep the mount in check more often.

Unless I am missing something, I see this as a win-win. Both in terms of better graph, but also in terms of actual better mechanical guiding (and therefore, star shape and bloat in the final image).

Edit: also, say that the 1" RMS error is indeed due to seeing fluctuations, then PHD2 is actually telling the mount to move, while in reality there was no star movement at all. At least, not due to mount misbehavior. Again, using the multi-star will counteract this.

Edited by endlessky, 03 December 2020 - 06:12 PM.

[imtl]

I am really lost regarding why a better graph shouldn't translate in better images. Honest question, here, to whoever feels like explaining it to me.

Say I am normally guiding at 1" RMS. That is what PHD2 records as errors in the RA and DEC centroid positions over time of the star while it deviates from the its original lock position, once guiding began. It will then issue RA and DEC corrections to try to bring back the star in the lock position.

Now let's look at a 75% RMS improvement thanks to multi-star (value taken from the previous posts). The RMS now will be 0.57". The average of the multi-stars centroid errors is a lot lower. PHD2 will need to issue a lot less RA and DEC corrections to bring back the main star to where it should be, given that the error of the positions is averaged using 9 different stars, instead of just one. The mount is not moving as much as it was, to endlessly chase just the one star and its fluctuations.

Also, with one single star, if I wanted to "average seeing" I need 3-4s exposures. In that time, the mount can wander on its own (due to periodic error or DEC drift, for example) all the while PHD2 doesn't even know what it's doing until the exposure is finished. With more stars, I don't need long exposures to average the seeing, since the 9 stars seeing fluctuations are being averaged "on the fly": I can then use 1-2s exposures and keep the mount in check more often.

Unless I am missing something, I see this as a win-win. Both in terms of better graph, but also in terms of actual better mechanical guiding (and therefore, star shape and bloat in the final image).

Edit: also, say that the 1" RMS error is indeed due to seeing fluctuations, then PHD2 is actually telling the mount to move, while in reality there was no star movement at all. At least, not due to mount misbehavior. Again, using the multi-star will counteract this.

That is because in majority of cases your images are seeing limited. If your guiding rms (and p2p) is half of your typical seeing the your tracking errors will not be as significant as seeing on your lights. Hence seeing limited.

For those rare nights that seeing is superb you might seean improvement also depending your image scale.

[klaussius]

I am really lost regarding why a better graph shouldn't translate in better images. Honest question, here, to whoever feels like explaining it to me.

Say I am normally guiding at 1" RMS. That is what PHD2 records as errors in the RA and DEC centroid positions over time of the star while it deviates from the its original lock position, once guiding began. It will then issue RA and DEC corrections to try to bring back the star in the lock position.

It's because you're comparing apples to oranges.

 

A single star's centroid fluctuates at 1" RMS lets say, to make the numbers round.

 

If multi-star reports 0.5" RMS for the same conditions, that's not to say stars wiggle less, it's how averages work.

 

It's the same principle that makes stacking work. The variance in the average decreases proportional to the amount of samples. But what defines FWHM in your lights is the variance of each star's centroid individually.

 

The two graphs aren't comparable. Half the RMS is not doubly-better guiding, since you're comparing different scales. It's like comparing pixels vs arc-sec, a meaningless comparison.

 

The only way in which the better measurement can make a difference in the lights, is by enabling better decisions. And it will. But not without further tweaking.

 

Under proper tuning you should never be chasing the seeing. That should not be a factor. You should have a minmove that will not react often to seeing fluctuations. So if the RMS goes down... there's no difference.

 

It's only when you get that 75% improvement across the board when you can fighten parameters. You can send corrections more often. You can decrease minmove to make smaller corrections when needed. You can, because you have better measurements. But unless you do tighten parameters, the difference should be negligible.

 

If you do see a difference, it means you were out of tune before enabling multi-star and were chasing the seeing.

[Jim Waters]

Good discussions here but I would like some of the PHD2 Multi-Star developers to jump in.

[spokeshave]

That only means your minmove was too low to begin with I'd say.

 

Did you see a difference in the subs themselves?

My MinMo was set quite high actually. I always keep it high because my mount is very well behaved. As I said in my original post, it was too windy to collect any decent subs.

 

Tim

[spokeshave]

 

If you do see a difference, it means you were out of tune before enabling multi-star and were chasing the seeing.

I completely disagree. My seeing is typically 2" or so. That means that I can expect my single star guiding graph to jump around between +1" and -1" from seeing alone. Setting MinMo is always a compromise. I could set it at 1.0" for both axes and that would ensure that most of the seeing-related guide star movement would be ignored, but not all of it. There would still be excursions above or below those limits and the guider would respond. The problem with that is that it is responding to the seeing not the tracking. So it has a 50% chance of making things worse. If I raise MinMo to, say, 1.5", that will probably prevent most of the incorrect moves due to seeing, but now I have let my mount drift 1.5" before a correction is sent. That's too much for me. So I keep my MinMo at around 0.75 which allows the majority of seeing-related excursions to be ignored and still keeps tracking in check.

 

With multi-star guiding, the amount of seeing-related movement should theoretically be reduced by a factor of 3. Now the graph will jump around between +0.3" and -0.3". If I keep the MinMo the same at 0.75, there will almost never be a seeing-related movement that induces an incorrect guide response. If the results I saw last night continue, I'll be able to drop the MinMo quite a bit and still not respond to most of the seeing-related movement. That should result in meaningfully improved guiding. That does not mean that I was out of tune with single star guiding. It just means that I have to make fewer compromises in tuning with multi-star.

 

Tim

Edited by spokeshave, 03 December 2020 - 08:43 PM.

[klaussius]

I completely disagree. My seeing is typically 2" or so. That means that I can expect my single star guiding graph to jump around between +1" and -1" from seeing alone. Setting MinMo is always a compromise. I could set it at 1.0" for both axes and that would ensure that most of the seeing-related guide star movement would be ignored, but not all of it. There would still be excursions above or below those limits and the guider would respond. The problem with that is that it is responding to the seeing not the tracking. So it has a 50% change of making things worse. If I raise MinMo to, say, 1.5", that will probably prevent most of the incorrect moves due to seeing, but now I have let my mount drift 1.5" before a correction is sent. That's too much for me. So I keep my MinMo at around 0.75 which allows the majority of seeing-related excursions to be ignored and still keeps tracking in check.

 

With multi-star guiding, the amount of seeing-related movement should theoretically be reduced by a factor of 3. Now the graph will jump around between +0.3" and -0.3". If I keep the MinMo the same at 0.75, there will almost never be a seeing-related movement that induces an incorrect guide response. If the results I saw last night continue, I'll be able to drop the MinMo quite a bit and still not respond to mose of the seeing-related movement. That should result in meaningfully improved guiding. That does not mean that I was out of tune with single star guiding. It just means that I have to make fewer compromises in tuning with multi-star.

 

Tim

 

Ok... so yes. You'll get better behavior.