Multi-Star Guiding

[kor....@gmail.com]

Is anyone currently working on multi-star guiding?  If so, I'd like to help.  If not, I figured I'd give it a shot.

- Shane

[Andy Galasso]

Hi Shane,

As far as I know, nobody is working on it. You are welcome to give it a go. Instructions for building phd2 on Windows, Mac, and Linux are on the open-phd-guiding google code wiki.

We have an abstract base class, Guider, and a concrete derived class GuiderOneStar. In theory all you need to do is implement another Guider-derived class.  Of course the devil is in the details :)

Andy

[Bill McLaughlin]

Would love to see this, At least theoretically it has the potential to reduce seeing induced corrections. The question is just how much.

[as...@kor.cotse.net]

Bill,

I was at SWAP last week and saw many example of planetary imaging where you could easily see differences in seeing on Jupiter's disk.  This seems to indicate that seeing can vary quite a bit in very small regions.

I realize that a multi-star solution will likely not work for all situations--long focal length off-axis guiding may not provide enough decent stars at high enough separations to help.

Anyway, I'm going to get started on this, but don't expect a quick implementation.  I've not yet even looked at the PHDv2 code and I'm not a fast coder.

- Shane

[ma...@shelleyz.co.uk]

It's definitely something I'm interested in. 

 

I love PHD2 and see it as definite step forward from the highly regarded PHD, with lots of new useful features so I downloaded the code to take a quick look at feasibility.  By chance, I then came across this thread.  My preliminary idea was that the user would calibrate and start guiding on a single star as usual.  Once guiding is under way then click on additional stars.  Each star would have its own rectangle.  The contribution of each star would be weighted by its SNR or some other weighting function since, for a single star, the accuracy of the star centroid calculation is very dependent on both the SNR and FWHM.  I strongly suspect that the effect commonly referred to as "chasing the seeing" often has large element of "chasing the centroid caluation errors".

 

The only odd behaviour I can foresee for multi-star guiding is that where field rotation occurs (e.g. due to polar mis-alignment) then instead of the image rotating about the single guide star, it will rotate around the weighted centroid of the multiple guide stars and this rotation point could potentially jump around within the group of selected guide stars, for example as one or more guide stars are lost and subsequently recovered or as the moving averages of SNR and FWHM change.

 

Mark

 

[as...@kor.cotse.net]

Mark,

Field rotation is something that I have been thinking about a lot.  I've got some ideas, but they haven't quite gelled yet.  I'll post a possible algorithm for comments in the next couple of weeks.

- Shane

[Bruce Waddington]

Hi Shane.  I've been watching this thread with interest because I initially had this project in mind when I started doing work with the PHD2 project.  I subsequently decided it wasn't likely to be worth the effort.  But that's just me. :-)   But I would like to point out that the lunar/planetary stuff you were seeing at SWAP is quite a different animal.  That type of imaging is typically using image scales of, say, 0.15 arc-sec/pixel (or considerably less) and exposure times of 1/30 to 1/100 of a second.  And yes, at those scales, you can see relative distortions from one point in the frame to another.  If there were stars in those frames, they might have FWHM sizes of 15 pixels!  But contrast this with a typical PHD2 user doing deep-sky imaging.  Those people are probably guiding at upwards of 3 arc-sec/pixel, using exposures in the 1-5 second range.  And star profiles there can be painfully small, maybe 2-3 pixels.  As you point out, users working at much smaller image scales are unlikely to have many stars to choose from, so a multi-star guiding algorithm may be available only to people working with the kinds of scales I mentioned.  And for them, is it worth it?  In any case, you guys may want to develop a "proof of concept" first before you go to the trouble of integrating it nicely into the PHD2 UI which I think will present a number of challenges. 

Good luck.
Bruce W.

[as...@kor.cotse.net]

Bruce,

I understand what you are saying and do not disagree with any of it.  The more I look at it, the more cases I find in which it may not be possible or may not be of benefit.  But, if it can work, I think it opens up several interesting possibilities.

In my own system, I have a small periodic error and take the time to do a good polar alignment.  My guiding is dominated by corrections due to seeing and centroid measurement.  I don't _know_ that multi-star will help, but maybe I can find out. Anyway, it's a very interesting idea and I'm already learning many new things.  I've got a couple of ideas that reduce the issue mainly to one of image processing and let PHD2 do the heavy lifting--at least as a proof of concept.  PHD2 should make a wonderful test platform.

So, wish me luck!

- Shane

[Bernd Gooßmann]

Hi Bruce, hi Shane,

in my opinion the key benefit of multi-star-guiding for us amateurs (which seems to implemented in the actual MaximDL 6 version - it's a listed new item but I'm not using MaximDL) should be a better S/N for a given exposure time if you stack selected guiding stars together fromout one picture. It should give us a more stable star profile - and this should give us a smoother and more stable tracking behaviour ! I think it's really worth a try!

Bernd

[ma...@shelleyz.co.uk]

I downloaded the code and was following the rest of the instructions for building PHD2 on Windows and that's when I hit my first problem:  Visual Studio Express 2013 for Windows Desktop will only install on Windows 7 or more recent.

 

So my aged WinXP machine won't hack it :(

 

So this is something I'll have to put on hold until I upgrade.

 

Mark

 

[Andy Galasso]

Mark, That's too bad it won't run on XP. I just updated the Wiki page making note of that fact.

Andy

[ma...@shelleyz.co.uk]

I've replaced my XP desktop with a shiny new W7 desktop.  I've successfully built the project and run the code.  Now to think about how to put together a multi-star prototype.

Mark

[Andy Galasso]

Hi Mark,

Just to be clear, Shane has started working on this, so it would be great if you could coordinate with him.

I guess it is a good thing that we have multiple folks stepping up to contribute in this area, but I would not want to see you ending up duplicating effort where Shane has already started.

Andy

[as...@kor.cotse.net]

Hi Mark,

As Andy mentioned, I am currently working on it.  I a bit of time reading and thinking and started coding a couple of weeks ago.

As you mentioned before, field rotation does complicate things.  The solution that I am implementing uses a polygon centroid to minimize its impact.  So far I have not modified any existing code (except adding .h files to phd.h and a changing one line in myframe.cpp to call the new guider.  I have added the following three classes:

StarList - based on Star::AutoFind() and builds a list of suitable stars for multi-star guiding
PolyStar - manages a polygon whose vertices are stars
GuiderPolyStar - implements the guider and actually derived from GuiderOneStar rather than the abstract Guider class

RIght now, I can build the star list (but I'm still working on it...) make the polystar and find its centroid, set the lock point, and let the polystar drift as the stars move across the image.

The next step is to figure out how to calibrate.  Should it use the PolyStar or just calibrate on a single star.  Calibration is also a chance to ensure that no hot pixels got through the star selection and, if necessary, to fix the actual spacial relationships between the stars in the PolyStar.

There is still quite a bit to figure out and a whole lot to do.  If you want to work on this with me, that would be fine--we can figure out how to split stuff up and I'll figure out how to make a new branch (help, Andy!!!!) and check some code in.  If you have a different idea for an implementation, let me know; I'm pretty sure that the PolyStar will work, but I am not opposed to trying something better.  I also don't have a problem with having two different solutions as I suspect that different solutions may work better for different situations.

I also have a friend at work looking into other options for managing rotation.  He is much smarter at math and physics than I am ...

- Shane

[Andy Galasso]

On Tue, Nov 25, 2014 at 8:30 PM, <as...@kor.cotse.net> wrote:

I'll figure out how to make a new branch (help, Andy!!!!) and check some code in.

Shane, yes, a branch is a good idea for sharing the code changes. The SVN book has a good chapter on branching, it's pretty straightforward. You'll want to keep the branch in sync fairly frequently, reintegrate when the work is complete, and finally, archive the branch.

Andy

[as...@kor.cotse.net]

 
OK, I'll read up on it.  I've got a lot of cleanup to do before I let anyone see this stuff!  Maybe some time this weekend...
- Shane

[ma...@shelleyz.co.uk]

Hi Shane,

I'm glad you've started work on this.  My current thinking is that I'd like to "hack" a few quick ideas together just to what might work and what might not.  I also need to familiarise myself with the code in any case.  At some point in the future I'll be happy to collaborate.  I think once we've done some initial experiments it will be possible to specify exactly how it should work.  My maths is pretty strong and that's one of the elements that really needs to be done correctly.

Mark

[as...@kor.cotse.net]

First Guide! 

Yea!  Tonight I did an <ctl-s> to auto select a group of stars suitable to guide on, formed the PolyStar, calculated the centroid, calibrated, and guided on the PolyStar's centroid!

There is still a lot of work to do:

• Figure out what star selection parameters can be set in stone and which need to be user modifiable.
• Figure out what needs to be on the config panel, what it should look like, and how to do it.
• Figure out what the whole MassChecker thing is all about and how to adapt it to multiple stars.
  
• Figure out what to do about the "Star Profile" panel.  I'd like to keep it as I find it useful for focusing, but I'm not sure how to relate it to the PolyStar.
• Clean up my very ugly C++ code.
• Document, document, document.  Code, user guide, probably the wiki also.
  
• And, of course, test with real hardware.  Hopefully I'll get some clear nights soon.
• Probably more that I don't know about yet ...

But, hey, I'm pretty happy right now!

- Shane

[Mark Striebeck]

Congratulations!

... I can only imagine how you must feel!!!

--
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.
For more options, visit https://groups.google.com/d/optout.

[bw_msgboard]

Congratulations!  But if I may, I’d like to propose that you re-order your list a little.  I’d like to see step 7 – proof of concept – moved way up to the top.  The most convincing approach would be to run a sequence of alternating guide sessions on the same night – 30 minutes with single-star guiding, 30 minutes on the same FOV with multi-star guiding, then repeat.  The question is whether any difference between the two alternatives is statistically significant.  If would really be great if the answer was ‘yes’ – but I have my doubts. J   Anyway, it’s good to see you have been able to make progress…

 

Good luck.

Bruce W.

 

---

--

[as...@kor.cotse.net]

Thanks Mark,

We all owe a great deal of thanks to Dr. Stark, Bret, Andy, Bruce, and everyone else who help to make the code robust and extensible.  The hardest part (after figuring out what I really wanted to do) was adapting the star autofinder to return a list of stars instead of just the best one.  I actually just started on the calibration tonight and after a couple hours of looking the code, added two lines and it calibrated and guided!

- Shane

[as...@kor.cotse.net]

Bruce,
That is exactly what I intend to do the next time I get a clear night.  I suspect that in many cases, there will be no real difference though I really don't think it should be any worse.  I also think that, if there is an improvement, it will be so slight that it may not matter unless your guiding is really limited by seeing--you have well managed PE and a great alignment.  Still, it's been a lot of fun learning the code and figuring this out.  I'm (well, OK, a really smart friend of mine at work who knows a lot more about math and modeling than I do is) also thinking about some other ways to extract data from the group of stars that may lead to better solutions.
- Shane

[bw_msgboard]

Thanks for taking my suggestion constructively – I was a little concerned you’d think I was just bad-mouthing the project. J  I’m definitely not doing that.  Looking at what I suggested, I think the test sequences would need to be shorter, maybe more like 10 minutes, in order to get enough samples to support statistical testing.  One of the issues your math friend might have is not being aware of the underlying physical processes we’re wrestling with.  Many of us – really a lot of us based on the data I’ve seen – routinely get guiding results that are seeing-limited.  That probably means RMS guide star displacements of 0.3 to 0.7 arc-sec with guiding enabled.  And the seeing limit is really a bit of a “brick wall” for conventional guiding, any place where we’re trying to push 50-100 pounds of gear around.  To deal with displacements driven by seeing, we need something like an AO device with sampling rates of at least several hundred/sec.  And even then, studies have shown that most of the benefit from amateur-class AO devices comes from moving a small optical element instead of the 50-100 lbs of highly inertial gear.  In fact, the issues you mentioned with things like PE and polar mis-alignment are rather easily handled because they are usually (hopefully) characterized by slower, steadier deflections.  

 

You might want to consider doing an experiment that I did just last month.  I added some debug code in PHD2 to log the incremental (not cumulative) shifts (frame to frame) in the X/Y position of the guide star.  I ran that for about an hour with guide commands disabled.  I loaded it all into a spreadsheet and found that “signal” was comprised of 3 low-frequency, predictable elements - Dec drift, RA drift (probably flexure), and PE – underlying higher frequency seeing fluctuations having a substantially higher amplitude.  I then enabled guiding and ran for another hour.  The RMS of the star deflections was essentially the same with guiding on or off.  So the guide algorithms had done a great job of eliminating the cumulative, low-frequency stuff but could do nothing about the seeing errors – I was running at the limit of the seeing.  The logging code is in the latest build, so you might want to extend it to record the data for poly-star guiding.  That might help you guys see if there was more data to be gotten from the star group algorithm.  

 

Let us know what you find out…

Bruce

[ma...@shelleyz.co.uk]

Well done Shane.  That's a great first result.  It'll certainly be interesting to see how it behaves in real life.

Mark 

[as...@kor.cotse.net]

OK, I got a little bit of testing done tonight.  The main thing I learned was that my star finder still needs some work.  I guess the sky is a little more picky than the emulator.  So, I'll work on that some more this week and hopefully do more testing later.

But, I did get one run with a 3-star polygon.  I let it go 200 cycles and then started up normal PHD and guided for another 200 cycles on one of the stars that was in the polygon.  Here are screenshots from both runs, taken just after the run ended:
<www.kor-astro.net/PolyStar/PHD2-PolyStar-1.png>
<www.kor-astro.net/PolyStar/PHD2-OneStar-1.png>

You can see the differences in the guiding graphs.  The RMS errors are also a little different, though much of that is probably due to the initial centering of the lock point after calibration.  So, I pulled the guide logs into PHDLab.  The guiding logs are available here:
<www.kor-astro.net/PolyStar/PolyStar-GuideLog-1.txt>
<www.kor-astro.net/PolyStar/OneStar-GuideLog-1.txt>

If I tell PHDLab to "Trim start: 10" on each guide log, I get the following:
          RA RMS  DEC RMS
One Star  0.56    0.53
PolyStar  0.50    0.43
It's not a big difference, but on this run, with only 3 stars in the polygon, it is encouraging.


Finally, I pulled the PolyStarLog file, a CSV file that you can find here:
<www.kor-astro.net/PolyStar/PolyStar-PolyStarLog-1.txt>
into MS Exel and did some graphing, averaging, and standard deviationing.  You can get spreadsheet here:
<www.kor-astro.net/PolyStar/PolyStar-Analysis.xlsx>
The big graph shows that the PolyStar Centroid tends to be a little bit inside (less extreme) than the 3 stars' centroids.  The smaller graphs show that the PolyStar Centroid scatter plot is a little tighter than the individual stars' plots.

All of this data represents only a single test and should not be considered positive proof of anything!  But, if anyone wants to look at it, I'd welcome opinions.  Hopefully later this week, I can run some additional tests with polygons containing more stars.

- Shane

[Hans]

Very interesting first results !

How does the algorithm work when 1 of the guide stars is lost ? The algorithm should be able to continue, just not with the previous PolyStar Centroid.
With a limited number of guide stars N you can maybe calculate all centroids for when up to N-1 are lost ?

-- Hans

[as...@kor.cotse.net]

Hans,

It doesn't yet handle loss of any of the stars yet.  I'm still in prototype/test to see if the idea even works mode.  I _think_ that shifting the guide lock point to the centroid of a different polygon will cause problems due to field rotation (single guide stars don't rotate--multiple guide stars do), but I have not yet explored that fully.

I'm also thinking of various ways to identify and compensate for the movement component due to field rotation.  If we can do that, then there are probably better ways than simply guiding on the centroid of the polygon.

There is still lots to do.

- Shane

[Duczmal]

Hi Shane,

Really interesting experiment. One thing that is in plain view is the reduced correlation between the RA and Dec curves when using 3 stars (the yellow and green curves in the graph run more "aligned" using only one star, compared to the more "mixed" curves in the multiple star mode). We can also observe this same effect in the target graph: it is more round when using multiple stars, and a bit stretched along the 135 degrees direction with only one star. It seems that multiples stars give distinct random "pushes" that tend to compensate each other, resulting in a less aggressive overall correction. It would be nice to see the graphs for the RA and Dec corrections too.

Best,

Luiz 

[as...@kor.cotse.net]

Luiz,

I did notice the difference but I didn't associate it with the reduced correlation that you point out--Thanks. 

The thin triangle in the PolyStar PNG is not exactly the kind of polygon I was hoping for.  Once I get the star finder fixed, maybe I'll get a better polygon and we can see a bit more difference.

- Shane

[SiriusOmegaBeta]

This looks really promising -- well done to Shane for taking the initiative with it.

Has there been any further progress made here?  

I am very keen to try this out using my ONAG because from a technological standpoint, aside from having AO to compensate for physical/mechanical disturbances at the mount level (PE, Wind, etc), 

multi-star guiding on the optical axis is about as good as it gets (without resorting to deforming optics and artificial guide stars) and doing it at 750nm to 1000nm wavelength will be very interesting indeed since the effects of seeing are already greatly reduced there, albeit at the expense of slightly increased exposure time on the guide camera.

In most cases, multi-star won't be an option when using an OAG and even if you were at a focal length which allowed for several candidate guide stars to be accessible from within the OAG field of view, they wouldn't cover an area wide enough to make a worthwhile difference.  Of course, a guide scope would offer a considerable improvement over an OAG but you would still be left at the mercy of differential flexure, not to mention the less-than-ideal optics that are present in a lot guide scopes (Orion 70mm is one that comes to mind...).  Nevertheless, multi-star guiding would have a measurable impact and is something worth pursuing.  

[as...@kor.cotse.net]

I have a "pre-alfa" implementation that I am in the process of (slowly) trying to test.  The weather here has been terrible all winter, so my opportunities are limited.

What I've found so far:  SNR is king.

• It is better to guide on a single star with SNR 25 than on one with SNR25, one with SNR 18, and 4 more with SNR < 10.  Adding bad stars to a good star gives worse guiding.
  
• If you have multiple high SNR stars within about 10% of each other, multi-star guiding beats out single star.  Ex: if you have three stars that are 25, 18, and 10, single star guide on the 25.  If you have 5 stars that are 25, 24, 22, 18, 10, and 6, multi-star guide on the 25, 24, and 22.
• If all you can get is bad stars (for example: several that are around SNR 7) you can pick the top 3 or 4 and improve guiding fractionally--though, at least for me, it will still not be good.  If this is because of seeing, I don't even bother to image--I'll just end up discarding those subs anyway.  If it is because of lack of stars in the general area, I offset the guide scope somewhere that decent stars--this rarely happens.
• All of my testing has been with a QSI5II-L mono in a guidescope.  As you pointed out, I do not expect to acquire multiple usable stars in an AOG.
  

The code currently has auto-star-select capability and runs the standard single star auto-select.  It then scans all stars to see if there are more stars at about the same SNR as the auto-selected star.  If so, it creates a poly-star with those stars.  If not, it falls back to single star guiding and operates as it would have originally.

- Shane

[Bret McKee]

Shane:

Great progress report, I can't wait to try it out.

We have had great luck in the past developing with simulators.  Given your comment about weather, I wonder if you might really help yourself by thinking of how to create a new simulator (or modify the old one) to help you with your testing. It seems like you would have to add some model for seeing to the simulator that would "ripple" the stars in some interesting way.  That might be too hard to model correctly, but I thought I would at least suggest it.

There also seem to be people here excited enough about the feature to help you with your testing, knowing full well it is alpha quality code.  If you continue to have weather issues, you might think about what other people could do to help you in a couple weeks when the moon is full enough to keep everyone from imaging anyways.

Bret

--

[SiriusOmegaBeta]

I'm willing to provide whatever assistance you need with this and I'm happy to devote whole nights to testing if it will be of any help.  The weather here in the Southern Hemisphere isn't too bad at the moment, there are a few of clear nights per week.  I can test at various focal lengths with a variety of CCDs.  It would be interesting to see what variables other than SNR, if any, effect the behaviour of multi-star configurations.  If you can make a alpha binary available for download somewhere I can get started as soon as you like.  Are you able to incorporate a flag that allows for overriding of the auto-select fallback, so that it will still go ahead and create a poly-star regardless of SNR variations?

There really is a lot to be said about SNR. In terms of how much of an impact it has on auto-guiding performance, the importance of having a high SNR cannot be stressed enough and I think that it ranks pretty high in terms of what a lot people overlook when trying to achieve accurate auto-guiding.

I have a handful of cameras by various manufacturers which have all been used for auto-guiding at some point. Surprisingly, a tight polar alignment and good seeing can be utterly wasted by using a camera which doesn't deliver a clean image for PHD to work from.  I found that on most cameras at the lower end of the market, noise reduction techniques and binning only provide a marginal improvement at best.  Some cameras need a significantly longer exposure time to equalize the noise, leading to less frequent corrections and subsequently inaccurate guiding.  Other cameras, like the Orion Starshoot, exhibit more noise at longer exposure times.

There are other factors which influence guiding camera performance, such as the Bortle rating of your site and where in the sky you are pointing and so on.  Overall, however, a better camera can only lead to better guiding.  After experimenting with various cameras, I tried a camera with active cooling (Atik Titan Mono).  Although marketed as an entry-level deep-sky imager, it's low resolution makes it less than ideal for such work at anything other than the longest of focal lengths but with respect to guiding it's a true performer (see screenshots attached) and my guiding went from average at best to pretty much within the limits of both seeing and the unremarkable EQ6 mount I'm using.  These samples were taken with the mount at just over half of the maximum rated weight capacity and on nights with average seeing and light wind.

[Bruce Waddington]

These graphs don't look right to me.  If you are saying you have a guiding RMS of 0.03 arc-sec, I'd say you are probably "guiding" on a clump of hot pixels.  Do you have a long-exposure DSO image that matches this guiding sequence?

Bruce

[as...@kor.cotse.net]

Wow.  Are you sure that you are guiding on a star and not a hot pixel?  I am happy when I get my guiding down to 30 arcsec RMS and very happy when I get it under 20.  I cannot imagine 3 arcsecs!

Anyway, the code currently allows you to click stars to add them to the polystar--mainly so I can test out various combinations of stars.  For auto star select, it lets you specify the maximum number of stars, min and max SNR, min mass, and a background noise sigma to help it filter noise and hot pixels.  Like I said, you can ignore all of that and just click on whatever stars you want in the polygon also.

Guiding is simple.  It just calculates the polygon centroid and uses that as the guide point.  This will be the mode until I can figure out some way to deal with field rotation. (If ever ....)  There is not yet code to deal with a lost star or large mass change, so you'll have to test it on decent nights when yo don't lose your stars.  The star profile graph is also not yet useful.  I really don't know what to do with it when there are lots of stars to keep track of and no star at the guide point.  Right now, it displays the profile of the first star and nothing in the crosshairs.  The other graphs, however, work fine as they don't care about stars, just corrections.

Give me a couple of weeks to run another test or two and make sure I can give you a copy that has a chance at working.  Note, that it is based on the source trunk as of Nov (v2.4.0 rc1) and does not have a lot of the latest and greatest features.  For example, I don't know if it will run with the current SGP betas.  It will run with the current release (late 2014).

- Shane

[as...@kor.cotse.net]

Oops, I meant 0.30, 0.20, and 0.03 arcsecs ....

[SiriusOmegaBeta]

Hi Shane, Bruce,

No pressure, Shane -- whenever you are ready to let it out for testing I'll take it for a spin and  collect whatever useful data I can.  I have a few thoughts on how field rotation could be addressed but I'll have to take a look at the source (trunk version) before I can make any useful suggestions.  One thing that comes to mind is that it might be useful to implement subframe clipping around the polystar boundary to compliment existing single-star subframing; if cheaper than reading the whole frame. 

With respect to the star profile graph, perhaps you could implement multiple tabs or a listbox control in this window, allowing the user select one star from the polystar.  Alternatively, you could generate a simulated star and display some sort of median value derived from the FWHM of each star in the polystar.  The latter would make more sense, since it would provide a better overall indication of the guiding potential of the whole polystar.

If the poly-star center point is derived from the centroid of all the stars within it, is there any change in this center point which is exclusive of the expected movement of the whole field (i.e., due to subtle oscillations in star centroid value because of atmospheric turbulence)?   If so, are you able to approximate how this compares to variations in centroid value in a single star scenario?  Please excuse the naive questions, I am not deeply familiar with the underlying mechanics of PHD.

The guiding camera I'm using now doesn't exhibit hot pixels, at least not at the short exposures times used here.  Guiding was definitely done against a real star and I have a couple of images that were taken during those sessions, which I'm happy to post if you want to have a look.  They're nothing special, since I am only using a one-shot color with a CLS filter to combat the street lights around here.   I'll gladly share my method for setting up the equipment to create those conditions also if you're interested, there's no dark arts involved, just a bit of patience (and reasonable seeing).  My equipment is by no means exceptional.

[Bruce Waddington]

With respect to your guiding results, this is simply not credible.  I would say you are off by an order of magnitude.  The PHD2 graph shows that an RMS of 0.18px equates to 0.03 a-s, so right there we know something is wrong.  The spec sheet on your camera says it has 7.4u pixels, so we can run those numbers back through the image scale equations and conclude that you must be guiding with a 9-meter telescope.  Really? :-)  You haven't actually told us anything about your set-up which makes this even harder to evaluate.  But the labels on the screenshot images says "900mm1" and "900mm2".  So did you possibly add an extra zero when you specified the focal length in PHD2?  Is so, you would be getting RMS guiding errors of 0.3 a-s, which is very good indeed but more believable.  But taking that a step further, are you really guiding at 900mm?  Are you using an OAG on your primary imaging scope?  Or did you mistakenly enter the imaging focal length instead of the guide scope focal length? 

Bruce

[Bill McLaughlin]

Yes, the results looked a bit too good to be true if you take the numbers at face value. If I saw those numbers on my system, my first thought would be that I had made a mistake in the setup somewhere. Of course I also have an SBIG seeing monitor at my observatory so have an independent check on the seeing as well.

[SiriusOmegaBeta]

Hi Bruce, Bill,

I am moving the dialog regarding guiding results into a new thread, so that we can keep this one clear for the topic of multi-star guiding.

[as...@kor.cotse.net]

Andy, Bruce, Brett, or any other developer who can answer this:

Is there a test framework for the server interface?  I tried to guide an image last night with the multi-star code and SGP would not start.  It gave an error that the autoguider has been set, but is not guiding.  Since it works fine with the normal version, I have obviously not implemented something that I need to.  I've gone through the code again and am simply not finding it--I'm probably just missing something obvious.  Can someone point me in the right direction and let me know if and how I can test the server without having to actually start an SGP sequence?

Thanks - Shane

[Andy Galasso]

Shane,

I usually just use telnet to test the server interface, testing individual methods by pasting them into the telnet session. There is no regression test at this time.  You could also use netcat (nc).

The primary methods that SGP 2.4 uses are:

  get_app_state

  guide

  dither

  set_paused

  stop_capture

There may be others, you could look at an SGP log file or a PHD2 log file to see exactly.

SGP 2.3 uses the socket server interface.

Andy

[Mark Striebeck]

Just checking in on this thread - has any progress been made on the multi-star guiding?

[as...@kor.cotse.net]

Mark,  I have some code that works, but it is based on a much earlier version of PHD2 because I haven't updated recently.

Here is what I have found so far:

If you have 5 or six stars with similar (<10% difference) SNR, multi-star guiding can reduce your RMS error by about 20% versus guiding on any one of those stars.  But, if there is another, single unsaturated star with a higher SNR, guiding on that star will be better than the multi-star solution.
So, to be effective you need the situation where there are several stars with the highest SNR in the field.  I don't seem to have that happen very often.

I do plan on learning git and the new build environment so I can update the multi-star code to the current PHD2 version.  This will be a bit of work since my current code doesn't interface to the single star guiding framework very well.  Improvements to the single-star solution should follow to the multi-star stuff, but the way I've got it coded right now, they mostly don't.  Bad design on my part ...

Anyway, I still think multi-star guiding can show an improvement, but I think the conditions necessary to do so are fairly rare.  I'll try to get back into development mode soon and see if I can get caught back up.

- Shane

[Mark Striebeck]

Interesting.

I thought it to be interesting when imaging under not-so optimal conditions where your guide star isn't very stable. If guiding on several stars (so I thought) those effects would be mitigated.

     Mark

[Attila Mádai]

Hi,

Is anyone dealing with this development nowadays?
This is almost three-year old topic but I cannot see the final result; maybe this project has been cancelled?

Unfortunately, our seeing conditions are extremely poor at the bottom of the Carpathian Basin.

So this improvement would mean a huge improvement in the efficiency of auto-guiding.

Thanks a lot in advance,

Attila

[Andy Galasso]

Attila,

Some prototyping was done but we found that multiple centroids did not produce any measurable improvement and development stopped.

The current plan is to try full-image guiding based on work by Bob Majewski.  We do not have a timeline for when that work will be done.

Andy

[Bill McLaughlin]

The current plan is to try full-image guiding based on work by Bob Majewski.  We do not have a timeline for when that work will be done.

I had a look at that video on full image guiding. It looks promising. I was a bit unclear on whether he was using his main camera or a guide camera.

Of course his application was not aesthetic imaging so his requirements were very different from most so that probably affected his approach.

What I was a bit unclear about is whether this system would potentially work with a standard off-axis system or does it need to be guide scope or on-axis to work well?

[Bryan]

If you are not interested in also implementing the Zero-Drift method, which is a separate tool, then you can use whatever you are using now.  You would just replace the centroid tracking method that PHD2 and other guide packages use with the image autoguiding algorithm.  I suspect that PHD2 Team would just add in another algorithm in the dropdown box, somewhat like PPEC.  Behind the scenes, however, it is much more complex, because the approach and associated data needed is very different.

Note that Bob Majewski admits that is a lot of work to be done just on the base methodology.  He is looking for beta testers.  At the time of the video (Mar 2017), the system worked only on Macs and only with SBIG camera, because that is what he uses.

This is NOT a trivial addition for PHD2!!

Bryan

[Andy Galasso]

On Mon, Sep 11, 2017 at 3:57 PM, Bill McLaughlin <ic5...@gmail.com> wrote:

What I was a bit unclear about is whether this system would potentially work with a standard off-axis system or does it need to be guide scope or on-axis to work well?

It's an alternative way of looking at the guide camera image to determine how the current image is offset relative to the reference image (lock position).

Andy

[bw_msgboard]

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Bryan
Sent: Monday, September 11, 2017 1:59 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] Re: Multi-Star Guiding

If you are not interested in also implementing the Zero-Drift method, which is a separate tool, then you can use whatever you are using now.  You would just replace the centroid tracking method that PHD2 and other guide packages use with the image autoguiding algorithm.  I suspect that PHD2 Team would just add in another algorithm in the dropdown box, somewhat like PPEC.  Behind the scenes, however, it is much more complex, because the approach and associated data needed is very different.

 

Offhand, I don’t think we’d treat this as an alternative guiding algorithm.  It’s really an alternative to the centroid algorithm for locating the guide star position, so it’s another way of measuring how far the image has moved from one exposure to the next.  Once that’s known, all the usual guiding algorithm features still need to be available.   We haven’t really talked yet about the UI implications, but yes, it’s a substantial amount of work.

 

Bruce

 

Note that Bob Majewski admits that is a lot of work to be done just on the base methodology.  He is looking for beta testers.  At the time of the video (Mar 2017), the system worked only on Macs and only with SBIG camera, because that is what he uses.

 

This is NOT a trivial addition for PHD2!!

 

Bryan

On Monday, September 11, 2017 at 1:57:34 PM UTC-6, Bill McLaughlin wrote:

The current plan is to try full-image guiding based on work by Bob Majewski.  We do not have a timeline for when that work will be done.

 

 

I had a look at that video on full image guiding. It looks promising. I was a bit unclear on whether he was using his main camera or a guide camera.

Of course his application was not aesthetic imaging so his requirements were very different from most so that probably affected his approach.

 

What I was a bit unclear about is whether this system would potentially work with a standard off-axis system or does it need to be guide scope or on-axis to work well?

--

[Bryan]

FYI to all

I attended Advanced Imaging Conference this last weekend.

Some of the following product lineup is still a little unclear to me, but the approach is still intriguing.  

Innovation Foresight (IF) has a real-time focusing solution available called FocusLock ($100), developed jointly with Optec.  Generically called 'astigmatic focusing.' 

You do need the ONAG device, which is $1000 to $1400 (US), depending upon type of imaging camera.  Alternatively, Optec has a new product, Lacerta, that allows the use of FocusLock on any OAG by adding a small tilt-tip mirror that generates the astigmatic star image required by FocusLock.  Lacerta is presently available for Lodestar X2 and costs $250.  They are adding other guide cameras with time.  

http://optecinc.com/astronomy/catalog/focuslock/index.htm

Of more interest to us is their almost commercial version of FocusLock that also does real time full-frame guiding.     

The software will work with any guide camera that has an ASCOM driver (virtually all of them now).  It also integrates with PHD2 via ASCOM.

The guiding relies on statistical analysis of the entire guide camera image, somewhat like Fast Fourier Transform analysis.  The result looks somewhat like the PSF of a star.  It may be similar / identical to the analysis that Bob Majewski is using.

The software captures a reference image at the beginning of guiding and generates this result.  Then it captures a new guider image, generates a new "PSF" result, and compares it to the reference image.  Any shift indicates a shift in the tracking and corrections are sent back to PHD2 just as if a single star were tracked.

Gaston Baudat (IF, also inventor of ONAG) was giving demonstrations.  I didn't get a chance to get 'in to weeds' with Gaston on topics like guide exposure impacts, algorithm impacts, specific hardware requirements beyond the ONAG.

Bryan

[Brian Valente]

I purchased the ONAG a few months back.

 

As you’ve pointed out, it’s promising, but I have yet to implement it. It takes quite a bit of time and fiddling to get it functional

 

Among the challenges:

 

You need a really good guiding camera that can be heavily binned. I ended up getting an ASI1600M and binned it 4x. you end up guiding in infrared, so the amount of light available is much less than usual.

 

You need fairly precise backfocus calibration between the imaging camera and the guide camera. It’s not difficult, but it is time consuming and challenging.

 

You also have to account for filter offsets. I haven’t yet done this and the approach is not entirely clear to me yet

 

 

Gaston was great in answering my questions and generally being available.

 

I am hopeful but not there yet. It’s funny because this topic came up just as I’m getting back in to seriously integrating this into my imaging system

 

 

 

 

Thanks

 

Brian

 

 

Brian Valente

Brianvalentephotography.com

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Bryan
Sent: Monday, October 2, 2017 9:44 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Re: Multi-Star Guiding

 

FYI to all

--

[Andy Galasso]

Hi Bryan,

Thanks for the update from AIC.

Adding full-frame guiding to PHD2 is definitely on our agenda, hoping to get around to it soon.

Andy

[Brian Valente]

That is so awesome to hear Andy!

 

Thanks

 

Brian

 

 

Brian Valente

Brianvalentephotography.com

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Andy Galasso
Sent: Monday, October 2, 2017 2:25 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Re: Multi-Star Guiding

 

Hi Bryan,

--