Tracking and guiding with PHD2 and the Mach2 encoder mount


Roland Christen
 

Hi Astronuts,

We have a clear night tonight, and although the Moon is high up there and bright, I am able to test our new Mach2 with PHD2. Here are the results so far, seeing is 3 out of 5 (Clear Sky Clock):

With MaximDL as a reference, 5 second guide exposures the RA and Dec guide errors are coming in at 0.25" RMS, pretty well equal. Stars perfectly round with less than .01 eccentricity.

With PHD2 set at Dec Lowpass2, with 5 sec guide exposure, RA = 0.18", Dec 0.20" RMS. Good round stars with this setting.

With PHD2 set at Dec Lowpass, 4 sec guide exposure, RA= .16", Dec 0.24" RMS. Dec is consistently higher error with this setting and stars not quite as good.

The main difference I see between the two programs is that Maxim shows a round star in the guider box, PHD2 shows an oblong star, longer in the vertical direction. I believe this is caused by the Lodestar exhibiting the Venetian Blind effect with PHD2, which can be eliminated in MaximDL.

Will post some guider graphs tomorrow.

Rolando


Cheng-Yang Tan
 

Hi Roland,
   I noticed that the guide star that you were using (seen in 2019-05-14_0019.png, and 2019-05-14_0009.png) looks to be saturated at 65535 units. Is this not a problem?

cytan


Alex Helms
 

"The main difference I see between the two programs is that Maxim shows a round star in the guider box, PHD2 shows an oblong star, longer in the vertical direction. I believe this is caused by the Lodestar exhibiting the Venetian Blind effect with PHD2, which can be eliminated in MaximDL."

Just exactly how did you come to that conclusion? What data supports your argument? The camera has nothing do with how PHD processes the data. How could it possibly produce some sort of affect in one piece of software and not another. If you are concerned about the centroiding algorithm used by PHD you're free to look at the source code on github to see how they do it.

Clearly both pieces of software work just fine and achieve similar results. The differences between RA and DEC are within the margin of error of measurement anyway so you really can't conclude one way or another.

Another thing I'd like to point out is that claiming an RMS number is pretty meaningless without specifying 1) the number of data points and 2) the period of time which those measurements were taken. Using the extreme case as an example, I could give you one data point of 0.1" and claim the RMS is 0.1". PHD2's RMS number reported is calculated based on the the data shown on the graph at any given time. That time span is dependent on the exposure time and number of points shown on the graph. While I'm not very experienced in Maxim, I do know that you can configure the window for the RMS metric -- I believe it is something like 1, 3, and 5 minutes. Without N and  the time span, RMS is pretty meaningless.

If you really want to showcase the stability of the Mach2, I'd suggest recording multiple data sets on different nights with good seeing and report the average RMS and average std dev over a set of periods, like 5, 10, and 15 minutes. Data like that would show how stable the entire integrated system can work which is what we all care about at the end of the day -- can my system track this object for 5-15 minutes and have minimal error.


Roland Christen
 

It was close to sat, but as long as it isn't flat topped it worked fine. I could have backed off the exposure to 3 sec, but because of the seeing the longer exposure worked better. I also tried a star with lower levels, but the problem was that the Moon was high and nearby, and the background level was quite high. Lower level stars were buried in background noise.

By the way, MaximDL is different, it works with saturated stars.

Rolando



-----Original Message-----
From: cytan299@... [ap-gto]
To: ap-gto
Sent: Tue, May 14, 2019 1:32 pm
Subject: [ap-gto] Re: Tracking and guiding with PHD2 and the Mach2 encoder mount



Hi Roland,
   I noticed that the guide star that you were using (seen in 2019-05-14_0019.png, and 2019-05-14_0009.png) looks to be saturated at 65535 units. Is this not a problem?

cytan



Michael Fulbright <mike.fulbright@...>
 

The first google search results for "lodestar bin phd2 guider" gives the PHD2 team recommendation for dealing with a Lodestar:

https://groups.google.com/forum/#!topic/open-phd-guiding/ujCHdIzGi5U

When you select "Fixed Binning" in the  ASCOM driver, the driver is essentially reporting to PHD2 that the camera does not bin and that it has large (2x) pixels.  This will work fine.  However, using the fixed binning option in the ASCOM driver is not necessary for PHD2.  I think a better way would be to de-select the fixed binning option in the ASCOM driver and use the binning selection on the camera tab in the brain in PHD2 to select the binning value. The binning option on the camera tab will not be present until you connect the camera in PHD2 since phd2 needs to be connected to the camera to check the available bin modes.

PHD2 can control the binning for the SX camera when you connect using the ASCOM driver or when you connect using the built-in driver, Starlight Xpress SXV.

The PHD2 team expends a great deal of time helping people getting all kinds of equipment working so I would recommend contacting them when you are unsure how to best use their software.  They are a true treasure for the astronomy community and I would wager a very large fraction of AP owners are using PHD2 so it is good that people at AP are learning how to use it.

Michael Fulbright

On 5/14/19 2:42 PM, alexander.helms@... [ap-gto] wrote:
 

"The main difference I see between the two programs is that Maxim shows a round star in the guider box, PHD2 shows an oblong star, longer in the vertical direction. I believe this is caused by the Lodestar exhibiting the Venetian Blind effect with PHD2, which can be eliminated in MaximDL."


Just exactly how did you come to that conclusion? What data supports your argument? The camera has nothing do with how PHD processes the data. How could it possibly produce some sort of affect in one piece of software and not another. If you are concerned about the centroiding algorithm used by PHD you're free to look at the source code on github to see how they do it.




Roland Christen
 


Another thing I'd like to point out is that claiming an RMS number is pretty meaningless without specifying 1) the number of data points and 2) the period of time which those measurements were taken.
The screenshot images I posted actually show the number of data points - 50 data points over a period of 200 seconds in PHD2. For Maxim I usually use 5 minutes which would be 60 data points. The Peak values are due to dithering which I have set at 4 pixels for MaximDL but the actual values are random.

As to your other comments about the "Lodestar and Venetian Blinds", I did not make this up. It is unfortunately a well known problem with the Lodestar. The stretch is always in the vertical direction due to the way the Lodestar downloads the data every other line.

As far as recording multiple data sets over many nights of good seeing, I don't get good seeing that often. Mostly I get average seeing. I do have data over multiple nights taken with MaximDL and can go for hours with similar low rms guiding. There is no limit in the amount of time that the mount will guide in MaximDL. I can do a 2 hour guide run and it will be the same as a 5 minute run.

It really wasn't until last night that I managed to set the right parameters in PHD2 and use the LowPass2 algorithm that produced very good guide results. Up until then i was not successful, thus the response from others to try Lowpass2 was especially helpful. That was the whole point of my posting the guide results.

My take from last night is that during average seeing the best results seem to be taking between 3 and 5 second guide exposures. That gives the guide star time to draw a good average position on the chip. A very short exposure has the star doing a sort of amoeba dance with flaring going off in all directions in a random manner and that causes the guider to chase the seeing and makes thing less stable.

I have had one or two nights where i could see almost no star movements at high power in the 10" Mak and that allows short guide exposures of 1 second or less. The rms errors on nights like that can and do result in 0.1" and sometimes less. How accurate Maxim calculates this error is up for debate, but I can see it on the guider chart that the star positions hardly move from the zero line.

Next time I'm out and the seeing is reasonable I will do a 1 hour guide run with PHD2 set up as best I can and record all the data. Then you all can analyze to your heart's content. Might be tonight yet, seeing looks like it will be a 3 out of 5:
http://www.cleardarksky.com/c/AstrPhyILkey.html?1

Rolando


-----Original Message-----
From: alexander.helms@... [ap-gto]
To: ap-gto
Sent: Tue, May 14, 2019 1:42 pm
Subject: [ap-gto] Re: Tracking and guiding with PHD2 and the Mach2 encoder mount



"The main difference I see between the two programs is that Maxim shows a round star in the guider box, PHD2 shows an oblong star, longer in the vertical direction. I believe this is caused by the Lodestar exhibiting the Venetian Blind effect with PHD2, which can be eliminated in MaximDL."

Just exactly how did you come to that conclusion? What data supports your argument? The camera has nothing do with how PHD processes the data. How could it possibly produce some sort of affect in one piece of software and not another. If you are concerned about the centroiding algorithm used by PHD you're free to look at the source code on github to see how they do it.

Clearly both pieces of software work just fine and achieve similar results. The differences between RA and DEC are within the margin of error of measurement anyway so you really can't conclude one way or another.

Another thing I'd like to point out is that claiming an RMS number is pretty meaningless without specifying 1) the number of data points and 2) the period of time which those measurements were taken. Using the extreme case as an example, I could give you one data point of 0.1" and claim the RMS is 0.1". PHD2's RMS number reported is calculated based on the the data shown on the graph at any given time. That time span is dependent on the exposure time and number of points shown on the graph. While I'm not very experienced in Maxim, I do know that you can configure the window for the RMS metric -- I believe it is something like 1, 3, and 5 minutes. Without N and  the time span, RMS is pretty meaningless.

If you really want to showcase the stability of the Mach2, I'd suggest recording multiple data sets on different nights with good seeing and report the average RMS and average std dev over a set of periods, like 5, 10, and 15 minutes. Data like that would show how stable the entire integrated system can work which is what we all care about at the end of the day -- can my system track this object for 5-15 minutes and have minimal error.



Roland Christen
 

I believe I set the binning to 1x in PHD2. Normally when you bin 2x2 with Lodestar the Venitian Blind problem goes away and guide stars are round. However i really wanted to use the higher resolution of 1x1, and it seems to work ok even with the star stretched out vertically. I used the same guide star in MaximDL also at 1x1 binning. The star measured 1.36 pixels at 0.065 roundness in a 5 second exposure. If you want to see what it looks like, I just posted the image to the Files section.

Rolando



-----Original Message-----
From: Michael Fulbright mike.fulbright@... [ap-gto]
To: ap-gto
Sent: Tue, May 14, 2019 1:57 pm
Subject: Re: [ap-gto] Re: Tracking and guiding with PHD2 and the Mach2 encoder mount



The first google search results for "lodestar bin phd2 guider" gives the PHD2 team recommendation for dealing with a Lodestar:

https://groups.google.com/forum/#!topic/open-phd-guiding/ujCHdIzGi5U

When you select "Fixed Binning" in the  ASCOM driver, the driver is essentially reporting to PHD2 that the camera does not bin and that it has large (2x) pixels.  This will work fine.  However, using the fixed binning option in the ASCOM driver is not necessary for PHD2.  I think a better way would be to de-select the fixed binning option in the ASCOM driver and use the binning selection on the camera tab in the brain in PHD2 to select the binning value. The binning option on the camera tab will not be present until you connect the camera in PHD2 since phd2 needs to be connected to the camera to check the available bin modes.

PHD2 can control the binning for the SX camera when you connect using the ASCOM driver or when you connect using the built-in driver, Starlight Xpress SXV.

The PHD2 team expends a great deal of time helping people getting all kinds of equipment working so I would recommend contacting them when you are unsure how to best use their software.  They are a true treasure for the astronomy community and I would wager a very large fraction of AP owners are using PHD2 so it is good that people at AP are learning how to use it.

Michael Fulbright

On 5/14/19 2:42 PM, alexander.helms@... [ap-gto] wrote:
 
"The main difference I see between the two programs is that Maxim shows a round star in the guider box, PHD2 shows an oblong star, longer in the vertical direction. I believe this is caused by the Lodestar exhibiting the Venetian Blind effect with PHD2, which can be eliminated in MaximDL."

Just exactly how did you come to that conclusion? What data supports your argument? The camera has nothing do with how PHD processes the data. How could it possibly produce some sort of affect in one piece of software and not another. If you are concerned about the centroiding algorithm used by PHD you're free to look at the source code on github to see how they do it.