Open PHD2 Multistar Guiding -Part 2

In part 2, I will go into detail explaining what I found when examining Multistar guiding. I wanted to keep this simple, but it was not possible to do so. I will probably revise this a few times so that it’s easier to follow.

I knew that the debug logs contained a huge amount of data that was screaming out to be displayed in graph form. It turns out that all of the secondary stars’ data is logged, as well as the flagging, error detection, and final results for each guiding exposure. I wrote some programs that would read my debug logs and the debug logs of others.

This is one of my programs where all of the displayed data is from one debug log. The graph at the top is for the X values for the Primary, Multi, and the 8 secondary stars. The timeframe is roughly 7.5 minutes of guiding. In the bottom right corner of the screen, you can see the list of the Secondary stars that were chosen for this guiding session. The SNR, Peak value, HFD, and starmass are shown. The X and Y pixel co-ordinates are also available but not shown in this image. The other table and XY graph are similar to those displayed on the PHD2Trends program that I talked about in part 1 of this series. When I drag the vertical blue cursor line on the top graph left and right, the tables and graph on the bottom of the screen all update accordingly.

How do multiple stars behave?

Fig. 1 illustrates how multiple stars behave while guiding. You can see that when the guiding deviation is big, all of the stars more or less follow each other. When the guiding deviation is small, you can see that virtually every star differs slightly. It’s these smaller differences that Multistar guiding is designed to help with. Using its weighted average calculation, it’s able to find the middle ground and use it to guide your mount. These smaller differences are a result of measurement errors such as atmospheric seeing, transparency, and camera noise, to name a few. There are lots of bigger measurement errors, such as satellites, airplanes, gamma ray strikes, trees, birds, bats, neighbors, etc.

Some of you reading this post may have noticed that, in Fig. 1, the PHD2 version is 2.6.13PW2dev1, which is one of the earlier versions of my multistar guiding. My version does a great job of keeping the 8 secondary stars aligned with the primary star. The official version of PHD2 multistar guiding does not have this ability. Let’s see what the official version of multistar guiding looks like.

Fig. 2 is a graph of Declination values where only 6 secondary stars were available. This guiding session used the official Open PHD2 multistar guiding. The red pen is the primary star, and the green pen is the multistar. The other colors are the six secondary stars. You should be able to see that if most of the star waveforms were raised a bit, all of these stars would follow the primary star similarly to what is shown in Fig. 1. Whether raising a bit or lowering a bit, this phenomenon occurs often with the official multistar code.

Is this just a cosmetic issue?

I believe it is a guiding accuracy issue. The red pen is the primary star, and the primary star is typically the best star available for guiding your mount. The primary star is also the best star for judging the guiding performance of your mount. The green pen is the multistar, which is what is guiding this mount. In fig. 2, there is roughly a 0.5 arc-second difference between the primary star and the multistar. If this stayed this way, it wouldn’t matter much. What I found is that it can change…a lot…completely randomly…and you will never know it’s happening.

Fig. 3 is once again a graph of Declination values for a different location in the same guiding session. Once again, the official Open PHD2 Guiding was being used. The secondary stars have been removed for clarity. This graph represents roughly 22 minutes of guiding. The red pen is the primary star…the green pen is the multistar. The dark blue pen is the difference between the primary star and multistar, with a 5-sample moving window average to make it easier to see the trends. The blue pen indicates that there was no difference present at the beginning. After roughly 4.5 minutes, the difference quickly changed to -0.5 arc-seconds for almost 8 minutes. Then the difference went upwards to +0.2 arc-seconds for roughly 5 minutes. Then the difference went back to -0.5 arc-seconds for roughly 1.5 minutes….you get the idea. These are totally random events. This erratic behavior is triggered by the multistar flagging logic. Secondary star #1 was flagged for RESET 3 times during this timeframe. The flagging logic RESET function caused this star’s position to flip-flop more than 1.5 arc-seconds several times…and this star has the next highest SNR compared to the primary star.

Why is this happening?

I mentioned earlier in this post that the official version of multistar guiding cannot keep all the secondary stars aligned with the primary star. This issue is directly tied to the error, or uncertainty, inherent in the star centroid calculation. This uncertainty can be a positive or negative offset that can be characterized as a bell curve of possible values. The star centroid calculation generates an X and Y pixel coordinate for the star’s location. Each of these coordinates has different positive or negative offsets due to this inherent uncertainty. All of the stars (Primary and the 11 secondary) suffer from this uncertainty, depending on the individual star’s SNR.

When a guiding session begins, the primary star and the 8 secondary star centroids are used to establish each star’s Reference position. This means that these Reference positions all inherit these uncertainties. Because these Reference positions are not changed often during a guiding session, their influence can persist for minutes or hours. When the next exposure from the guide camera is received, PHD2 will calculate updated star centroids. The next step is to subtract the Reference positions from the updated centroids so that the star’s Deviation can be calculated. This means that these Deviation values contain even more uncertainty. This Deviation uncertainty exists whether it’s displayed as X & Y or RA & DEC. Fig. 2 and Fig. 3 are graphs of these Deviations. In Fig. 2, it’s the uncertainties in each star’s Reference position that cause each star’s waveform to be higher or lower.

These star Deviations are what drive the multistar flagging logic. As your mount tracks the universe, there are inherent tracking issues in your mount that cause all of these star Deviations to move up and down in RA and/or DEC. When all the secondary star Deviations rise in response to a tracking issue, the secondary star that is always the most positive will be the first to be flagged when it exceeds +2.5 Sigma. When this happens, this secondary star’s Deviation value is immediately discarded and not used to calculate the multistar. This causes a step change in the multistar primarily because this secondary star has the most positive offset due to the uncertainty in its Reference position. Conversely, when the secondary star Deviations move downward as a result of a tracking issue, the secondary star that always has the most negative Deviation is first to be flagged when it goes below -2.5 Sigma. This causes a similar step change but now in the opposite direction. As each secondary star is included or excluded from the multistar calculation, the uncertainty in their Reference positions causes step changes in the multistar calculation. If all of the secondary stars’ waveforms were aligned with the primary star’s waveform, these step changes simply would not happen. What bothers me the most is that all of these step changes always cause the multistar value to stay closer to zero deviation…which seems suspect. This characteristic partially explains why, in Fig. 3, the blue pen moves around so much.

The extreme situation, demonstrated in Fig. 3, occurs when the flagging logic decides that a secondary star has been flagged too many times and must be RESET. A RESET causes the secondary star to be assigned a new Reference position based upon the star’s most recent centroid X and Y values. Essentially, a RESET forces the stars’ Deviation to become zero. This sounds like a good idea, but it doesn’t take into consideration the inherent uncertainty of the centroid calculation or what the primary star Deviation is doing. Why would you force the secondary star to be zero if the primary star is indicating a large positive or negative deviation? These RESETs tend to be very erratic with huge step changes that oscillate back and forth. In Fig. 3, the erratic RESET logic was causing 1.5 arc-second step changes in the Reference position for secondary star #1.

I calculated the total rms guiding error for Fig. 3. The multistar total rms guiding error stayed very close to 0.5 arc-seconds throughout. When the erratic behaviour started, the Primary star’s total rms guiding error rose from 0.5 to 1.0 arc-seconds.

I deliberately chose the timeframe for Fig. 3 because it is bad. There are many other timeframes in this single 2hr40min session where the guiding is great. Fig. 4 is a graph of the total rms guiding error for the entire guiding session, which used the official Open PHD2 multistar guiding. The red pen is the primary star…the green pen is the multistar. What you need to know is that the multistar total rms guiding error hovered closely to 0.5 arc-seconds for this entire session, and it’s only the multistar signal that you get to see both on the PHD2 guiding graph or afterwards, should you use the PHD2 Log Viewer. My opinion is that the primary star total rms tells no lies.

Other issues in the existing multistar code affect its guiding accuracy. This blog is long enough.

Peter