Are the polarity of the graphs correct?

[peter wolsley]

This is what is displayed in PHD2 when I used the simulator just now.  I believe this issue is true regardless of whether the simulator is being used or not.  Note the polarity of the RA and DEC traces.

I closed PHD2 and then used PHD Log Viewer.  Here is how this same session is displayed in the Log Viewer

Note that the polarity of the RA and DEC traces are inverted.

I also took an exerpt of the last few entries in the guide log file....

194,526.640,"Mount",-0.199,-1.943,-1.953,0.028,-0.789,0.000,2000,E,0,,,,40978,4.39,0
195,529.201,"Mount",-0.191,-1.910,-1.919,0.032,-0.790,0.000,2000,E,0,,,,49621,4.01,0
196,531.765,"Mount",-0.206,-1.870,-1.880,0.012,-0.782,0.000,2000,E,0,,,,52096,4.16,0
197,534.330,"Mount",-0.472,-1.912,-1.943,-0.247,-0.791,0.000,2000,E,0,,,,45893,3.74,0
Guiding Ends at 2015-10-06 12:07:06

Log closed at 2015-10-06 12:07:55

The guide log and PHD Log Viewer agree with each other but both of these disagree with the polarity of what is displayed in PHD2?  If this is an issue then maybe the calibration data should also be looked at to ensure that the polarities are correct.

Peter

[Andy Galasso]

Peter,

Thank you for pointing this out. This discrepancy has been pointed out in the past, and when I put out a new version of PHD2 Log Viewer I will update it to use the same choice of polarity as PHD2. The PHD2 log viewer happened to have chosen the opposite convention for the direction of the y-axis compared to the phd2 graph.  This has no significance other than causing confusion when you compare the graphs side by side. The underlying data is the same.

Andy

[peter wolsley]

Andy,

The PHD Server messages, the Guide log file and your log viewer all agree.  All three use the same convention which is simply that a positive value is a positive value.  The issue is that on the PHD2 UI these same positive values are shown as negative values.   

It's my opinion that the entire problem resides in PHD2.  PHD2 needs to ensure that any values displayed on their UI are the same values repeated in their server or log files.

I would suggest that the dx, dy, RARawDistance, DECRawDistance in the server messages and guide logs need to be multiplied by -1 so that the polarity of these values will agree with what is being displayed on the PHD2 UI

The remaining values (RAGuideDistance,DECGuideDistance,RADuration,RADirection,DECDuration,DECDirection,XStep,YStep,StarMass,SNR,ErrorCode) can stay the same because these are all the corresponding reactions that PHD2 took to cater for a guide star movement.

You don't need to make any changes to your log viewer...

Just my two cents...

Peter

[peter wolsley]

I took the time to do some research and found the following issues with the PHD2 UI, Server and Guide Logs

Summary

PHD2 History graph

-The indication for the guide star RA and DEC movements are correct.

-The indication of the corrections for both RA and DEC are inverted. The corrections must always been shown in the same direction as the guide star movements.

PHD2 Guide Log and Server messages

-The values shown for RARawDistance, DECRawDistance, RAGuideDistance, DECGuideDistance are inverted.  Positive values are shown as negative values.

-When the guide pulse is limited to it’s maximum duration the corresponding RAGuideDistance or DECGuideDistance are not limited to their equivalent limiting values.

-The indicated guide pulse direction for the RA axis is inverted.  West pulses are indicated as East pulses…East pulses are indicated as West pulses.

-The indicated guide pulse direction for the DEC axis is correct.

I attached a report which illustrates my findings

Peter

 

[Andy Galasso]

Hi Peter,

Thanks for taking the time for the thorough analysis.

I think we are working from different starting assumptions.  Our goal when we built the graph in PHD2 was to provide a quick and intuitive display representing the current state of guiding and guide corrections.  It was never meant to be an accurate representation of star motion and mount corrections relative to sky directions. For purposes of assessing guiding it is not necessary to know actual sky directions, and we have intentionally not even labeled the axes!  The command to the mount "Guide North" is not guaranteed to move the mount north; the polarity of the guide commands relative to sky directions is not even known to PHD2. But the nice thing is: we don't need to know or care! The calibration procedure ensures accurate guiding regardless of polarity.

The direction of the corrections on the graph was deliberately chosen to be displayed in the opposite direction of the displacements. This was done to make the display more legible. If the corrections are displayed in the same direction as the displacements then the data points overlap and the display becomes unreadable.

The guide log contains the raw data in CSV format so you can to import the data into a graphing program of your choice and display it in whatever way is most meaningful to you.

Andy

[peter wolsley]

Andy,

I appreciate that the UI was designed to be the easiest to read with the primary goal being that smaller squiggles mean better guiding.  I am at a loss as to why there are so many discrepancies in the guiding log files and the server messages.  Both of these are "higher level" features where errors such as I have outlined shouldn't exist.  I understand your concern about North, South, East, West not being guaranteed to move the mount in those directions.  They are just a naming convention to try and give more meaning to a positive or negative jog of the RA or DEC axis. 

The one item that I would really like to see followed up on is...

-When the guide pulse is limited to it’s maximum duration the corresponding RAGuideDistance or DECGuideDistance are not limited to their equivalent limiting values.

Not limiting these values gives a false impression of what is happening.  

I am writing programs based upon the server messages...I hate putting bandaids in my code to cater for issues like these.

Peter

[Andy Galasso]

On Tue, Oct 13, 2015 at 4:17 PM, peter wolsley <wols...@gmail.com> wrote:

The one item that I would really like to see followed up on is...

-When the guide pulse is limited to it’s maximum duration the corresponding RAGuideDistance or DECGuideDistance are not limited to their equivalent limiting values.

Not limiting these values gives a false impression of what is happening.  

I am writing programs based upon the server messages.

Peter,  the RA and Dec guide distances represent the output of the guide algorithms (the input to the algorithms are the raw distance values). The guide algorithm output is not constrained by the RA/Dec max pulse setting.  The RA and Dec Duration values ("RADuration", "DECDuration") represent the actual pulses sent to the mount and are thus clamped by the max pulse setting.  The server GuideStep message has attributes RALimited and DecLimited that are present (and set to true) when the RA or Dec pulse size has been limited by the max guide pulse setting.

Hope that helps,

Andy

[peter wolsley]

Andy,

Thanks for the hint about the RALimited and DecLimited attributes.  I will look for them in the server messages. 

Peter