Open PHD2 Multistar Guiding – Part 3

In this blog post, I will try to explain the changes I made to the multistar code to address the issues I discussed in Part 2.

A change of Focus

The flagging code in the official version of Multistar guiding is focused on keeping the secondary star deviations close to zero. This sounds good!…but it completely ignores what the primary star is witnessing. The primary star may be showing that a significant guiding error is occurring, but the secondary stars are being flagged and ignored simply because they agree with the primary star. A secondary star should be flagged and ignored only if it doesn’t agree with the primary star.

The primary star is incredibly important to your guiding. The primary star determines what your PHD2 calibration will be. It is the only star being used to begin every guiding session and every dither. If there is a huge guiding error, it’s the primary star that comes to the rescue. This was true when single-star guiding was the only choice, and it is still true with multistar guiding.

The main principle of auto-guiding is having as good a feedback signal as possible so that PHD2 can accurately guide your mount. If a significant tracking error occurs, your mount’s RA and/or DEC axes need to be corrected by the correct amounts. To be successful, the multistar signal has to be even better than the primary star signal. This is not a simple task.

I have modified the flagging logic so that it is focused on making sure that the secondary stars agree with the primary star. The primary star Deviation is compared to each secondary star Deviation. If this comparison is greater than +/-2.5 Sigma, the secondary star will be flagged and not used to calculate the multistar. This +/-2.5 Sigma is the same value used in the official PHD2 multistar flagging code. Sigma is equivalent to the standard deviation of the primary star Deviations.

Flagging details for the official PHD2 multistar code

The flagging logic in the official PHD2 multistar code has letters assigned to each type of flagging. “U” means that this secondary star will be used to calculate the multistar. “L” means this secondary star cannot be found and is considered Lost. PHD2 will continue to look for it as new exposures arrive. “DZ” means that the secondary star is declared a Hot Pixel and has been removed from the list of secondary stars. If there are more than 8 secondary stars in the list, a reserved secondary star will take its place. “M1” through “M10” indicates that the secondary star Deviation has exceeded +/-2.5 Sigma. “M” stands for “Moved too much”. If a secondary star is flagged for “Moved too much” on consecutive exposures, the flag will change from “M1” to “M2” and could eventually reach “M10”. If a previously “M” flagged secondary star is flagged as “U” for the next exposure, the numeric value will be decremented. Typically, a “M” flagged secondary star could take many more than 10 exposures to reach the “M10” designation. If a secondary star reaches “M10” and is flagged again for violating the +/-2.5 Sigma rule on the next exposure, the secondary star will be flagged with the letter “R,” which stands for RESET. This secondary star’s Reference position will be adjusted so that its Deviation will become zero.

Flagging details for my version of the multistar code

The “L” and “DZ” flagging remains the same as for the official PHD2 multistar code. “U” means that this secondary star will be used to calculate the multistar. In addition, this secondary star’s Reference position will be adjusted by 3% of the difference between the secondary star and the primary star for the next exposure. “M1″ or M2” means that this secondary star is more than +/-2.5 Sigma away from the primary star. This secondary star will not be used to calculate the multistar, and no adjustment of this secondary star’s Reference position will take place. I consider “M1” and “M2” flagged secondary stars as being aberrations that may go away and should be ignored for the time being. “M3” through “M6” means that this secondary star needs attention. This secondary star is not used to calculate the multistar. In addition, this secondary star’s Reference position will be adjusted by 6.66% of the difference between the secondary star and the primary star for the next exposure. “R” flagged secondary stars occur when the star would have been flagged “M7”. “R” flagged secondary stars are not used to calculate the multistar. In addition, this secondary star’s Reference position will be adjusted by 50% of the difference between the secondary star and the primary star for the next exposure. I have found that a 50% adjustment all but eliminates the “overshooting the mark” issue with the official PHD2 guiding “R” flagging code. Overall, you can see that my flagging logic is more proactive.

What do these changes in the flagging logic look like?

Fig. 1 is from the same 2hr40mn guiding session that was displayed as Fig. 4 at the bottom of Part 2 of this blog series. This is a graph of the X-axis RESET adjustments made to the secondary star Reference positions. For this graph, the official PHD2 multistar code was being used. You can see how often these RESETS occur and how large they are.

Fig. 2 is a graph of the X-axis adjustments made to the secondary star Reference positions. For this 2hr25mn minute graph, my version of PHD2 multistar was being used. The incremental movements are largely the result of the 3% adjustments of the Reference positions when the secondary star is used to calculate the multistar. Mixed in are the occasional 6.6% adjustments when a secondary star is flagged as “M3” through “M6”. There were several RESETS, which all occurred during the first 20 seconds of this guiding session. You can see how gradual the secondary star adjustments are. I guess that the slow drift of these adjustments is due to polar alignment error.

Sequencing for the beginning of a guiding session and after dithers for the official PHD2 multistar code

The official version of the multistar code always uses the primary star at the beginning of a guiding session and during dithers. Both of these moments use a settling strategy to delay enabling the multistar calculation until the primary star Deviation is close to zero. Once the settling has completed, the secondary star Reference positions are determined, and the calculation of the multistar begins. It can take upwards of 10 exposures or more for settling to complete. For Fig.1, it took 12 exposures before the multistar calculation began.

Sequencing for the beginning of a guiding session and after dithers for my version of PHD2 multistar code

My version of the multistar code uses the first exposure to also generate the Reference positions for the Secondary stars. For the next four exposures, the flagging logic is used to make adjustments to the Reference positions. For the first two exposures, a 50% adjustment is made to bring the secondary stars closer to the primary star. For the 3rd and 4th exposure, 6.6% adjustments are also made. When the 5th exposure is received, the multistar calculation is enabled, and typically, the majority of the secondary stars are flagged “U” and are used to calculate the multistar. This means that, by the 5th exposure, the multistar mode is fully enabled and all of the secondary stars are now following the primary star closely. This sequencing is also achieved during dithers.

How are special cases handled?

In Part 1, I listed 4 special cases for the official PHD2 multistar code. In my version, these have been either abandoned or modified.

–Special case #1: If the multistar code determines that the difference value for the Primary star is too large (>5 Sigma), it will abandon the multistar and use the Primary star difference. This continues for the next few exposures until the Primary star difference returns to a small value (<2 Sigma). This special case is typically activated during a guiding session because of a big RA tracking error or the Primary star centroid is corrupted (i.e., Gamma Ray burst, satellite trail, etc.) This special case is required for the official OPEN PHD2 Multistar version for the following reasons…

A big RA tracking error would have caused all the stars to track the error, but the secondary stars would all be flagged for deviating too far from zero. This would essentially abandon the multistar calculation. If this persisted for several exposures, this would cause RESETs to occur, which are problematic and would require several additional exposures to correct.

If only the Primary star was affected (gamma-ray burst, Satellite trail, etc.), this would typically affect one or two exposures. The secondary stars would not be flagged for deviating too far from zero. The Multistar calculation would not be abandoned. Ironically, this would cause only a small guiding spike…the Multistar value would deviate far less than the Primary star because the Multistar value is a weighted average of all the unflagged stars. Because this would have been a better solution for this type of Primary star issue, I conclude that special case #1 is to protect against large tracking errors causing issues with inappropriate secondary star RESETs.

Special case #1 has been abandoned for my version of the Multistar code. If a large RA tracking error occurs, my code does not care. The secondary stars would move in synch with the Primary star, which would cause the secondary stars not to be flagged. The X and Y axis adjustments don’t react because the Primary and Secondary stars are moving in synch with each other. If a Gamma ray burst, satellite trail, etc, affects only the Primary star, then all the secondary stars would be flagged. The Multistar would be abandoned, and the Primary star deviation would result in the same size guiding spike as the official OPEN PHD2 Multistar code. Because the flagging logic would only need to react for one or two exposures, the probability of a RESET is extremely small. I have never seen this happen.

–Special case #2: For each exposure, if there are no Secondary stars that haven’t been flagged, the multistar will be abandoned, and the Primary star difference will be used. For my version, I modified special case #2 so that the multistar will be used only if the weighting factor indicates that the available secondary stars represent a 50% increase in the summed weighting factor. This ensures that the secondary stars that are available are not very low SNR stars. It doesn’t make sense to use the multistar if it only uses noisy secondary stars.

Special case #3 describes the sequencing that happens when guiding starts or immediately after a dither. I have already described the differences in sequencing earlier in this post.

Special case #4: If the Primary star difference is less than the multistar, the multistar will be abandoned, and the Primary star difference will be used. I abandoned special case #4. The whole idea here is that the multistar is a better quality signal than the primary star…so why not use it?

Any more comparisons?

Fig. 3 is of the same 2hr25mn guiding session as seen in Fig. 2. My version of multistar guiding was being used here. The red pen is the primary star RA deviation, and the green pen is the multistar RA deviation. The dark blue pen is the difference between the primary star and multistar signals, with a 5-sample moving window average to make it easier to see the trends. For the entire session, the difference between the two signals is less than +/-0.2 arc seconds. You can compare this graph with Fig. 3 in post #2.

Fig. 4 is a comparison of the primary star total RMS guiding with the multistar total RMS guiding for the same 2hr25mn guiding session as seen in Fig. 3 and Fig. 2. The red pen is the primary star, and the green pen is the multistar. The two signals stay close to each other even when the guiding gets worse. The multistar Total RMS is always slightly less than the primary star total RMS, which I believe is more in line with what can be achieved. You can compare this graph with Fig. 4 in post #2.

Why haven’t you approached the PHD2 folks about your version?

I did contact them over the 2023/2024 winter. After exchanging several e-mails, they said that they were not interested in what I was doing. After the past year studying and editing the official multistar guiding code, I can say that the PHD2 folks have done a lot of work putting together the official version of multistar guiding. I am always hopeful that the PHD2 folks might be interested in what I have come up with.

Can I try your version?

Of course you can. The only caveats regarding my version are that the PHD2 folks will not help you with any guiding problems if you are using my version. They also insisted that I brand my version with a unique identification that will be visible on the main window and in the debug and guide logs. Of course, I complied with this request. My version is identified as 2.6.13PW7dev7. This means that it is the 7th generation of my version and that it is built using the 2.6.13dev7 version of PHD2 guiding.

You can download my version by using this link. This will download PHD2PW7.exe. You should then copy it into the folder where you have already downloaded and installed the official 2.6.13dev7 version of PHD2. It will not overwrite the official PHD2 guiding program. You will need to use administrator privileges to copy the file to this folder. You will also need to create a shortcut for this executable. The shortcut will automatically be placed on your computer’s desktop. Just remember that you cannot have both versions running at any time…even minimized. Once you have calibrated with one version, it will be used by either version. You can also use my PhD2Trends program from Post #1 to watch what is happening with either version.

Thank you for taking the time to read my blog series on multistar guiding.

Peter