Dec Weirdness after Dither

[Jerry Lodriguss]

Hi, I had a rare night of good seeing here and experienced some weirdness in dec with PHD2 after dithering.

Here's my setup:

AP130 Main scope

AT65EDQ 420mm f/6 guidescope

Lodestar X2 autoguider

Paramount MYT mount

Skyx 10.3.0  Daily Build 8908 

Using Direct Guide in the SkyX

PHD2 v2.5.0

Dec set to Auto

Initial calibration successful after about 14 steps

I am an experienced user of PHD and have not seen anything like this before.

After the initial calibration with PHD2.5, I had nearly a flat line for the dec guiding during the first 6 minute exposure, but after the dither, the dec guiding went wacky. Then after the next dither it went crazy.

It looks like oscillation after the second dither, but not after the first dither.

The only thing I can think of that has changed (which should be an important clue) is that I was using a Periodic Error Correction curve in the SkyX software that I had just created a couple of nights before.

But I don't know why this would have anything to do with the dec guiding.

The Periodic Error in the mount was about 3.4 arcseconds peak to peak, and after applying the PEC it was 2.7 arcseconds.  Seems like that should have been better, but it doesn't indicate that there was anything stupid wrong with it, at least I don't think.

If I stopped guiding and recalibrated the dec guiding went back to flatline again until the next dither.

I am attaching screen shots of the guide graphs and guide logs.

I was hoping that someone might have a guess as to what is going on.

Thanks

Jerry

[Bruce Waddington]

Hi Jerry.  Well, this is certainly interesting. <g>  To start, the business with the PEC adjustment is almost surely coincidental, I'd ignore that.   The first surprise is that you went for nearly 30 minutes without issuing even one dec guide correction!  Jeez. Almost like you were guiding on a hot pixel. <g>   I think the sawtooth behavior you saw is quite likely over-shoot from the guide algorithm based on the settings you have.  The resist-switch algorithm is intended to deal with a moderate amount of dec backlash, which is the most common state of affairs.  But I suspect your mount may have zero backlash, so the "normal" settings for resist-switch might lead to over-shoot.  I would consider doing one of three things:

 

1. Try the LowPass2 dec guide algorithm.  This algorithm doesn't try to deal with backlash and is the most heavily damped option we have.  

2. If you stay with resist-switch, reduce the aggressiveness substantially.  Since you were rarely doing any dec guiding at all, this shouldn't have much effect during imaging but should help reduce the likelihood of over-shoot.

3. Disable the 'Fast Switch for Large Deflections' on the mount tab of the brain dialog.

 

Let us know how things go.

Bruce

 

---

--
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.

[Jerry Lodriguss]

Hi Bruce,

I think I had really good polar alignment that night so that might partially explain the no dec corrections... but I doubt that the PA was perfect, so that may be another mystery...

It looks like it will be clear here tonight so I hope to get out and try your suggestions. 

Thank you very much for your help.

I will report back.

Jerry

[Bruce Waddington]

Sounds good.  If you don't want to waste imaging time, you could experiment by triggering the dithering from within PHD2 (Manual Guide tool).  So you could get the guiding going, let it stabilize, then trigger the dither operation to watch how the guiding behaves.  In the case that triggered the worst sawtooth response, the requested dither amounts were -0.6 and 0.6 in RA and Dec respectively.  This is just an option in case you are impatient like I am. <g>  Otherwise, you can just run as you normally would.

 

Good luck.

[Jerry Lodriguss]

Hi Bruce,

I did get out last night.

I first tried the exact same settings I used on the night I had the weirdness with the dec guiding, and could not duplicate the problem.

Using Hysteresis in RA, and Resist Switching in Dec seemed to work fine.

I experimented with using Lowpass2 for the Dec and did see what seemed to be a flatter guiding line, but the RMS numbers were close enough to be within a margin of error, so I'm not sure that it made a substantive difference. 

The seeing was good again tonight with Total RMS numbers around 1/3 of an arcsecond. There were long periods with no dec corrections at all.

But looking back, it seems hard to believe that the polar alignment was that good for the portion of the sky I was shooting where there would have been no dec corrections at all for 8 minutes.  

So it was, perhaps, a double weirdness going on...  flat line on the dec with no corrections, or crazy oscillations.

I certainly can't explain it.

But thank you again for your help, I really appreciate it.

[Jerry Lodriguss]

I have to add that I really do love PHD2 and really appreciate all of the hard work that folks have put into it.

I can't recommend it highly enough.

Jerry

[Bruce Waddington]

Well, that just figures, right?  <g>  At least if you see it again, you'll have a few things to try.   I wouldn't expect LowPass2 to be significantly better during normal, small-deflection guiding.  But it might work a little better on very low backlash mounts that encounter a few sharp direction reversals. which is what can happen with dithering.  

 

I did notice you aren't using an Aux mount connection with your set-up.  You might want to do that to allow PHD2 to give you some more help - automatic meridian flips, dec compensation, and better information on calibration results to name just a few.  It won't have any effect on your guiding but it can make the app nicer to use.

 

Good luck - thanks for reporting back.

[Jerry Lodriguss]

Hi Bruce,

I have used the Aux mount connection in the past, I just wasn't using it these nights.

Thanks again for your help!

Jerry

 

[Jerry Lodriguss]

I experienced the dec weirdness after dithering again last night.

This time it was after the second dither, see the attached screenshot.

Here's another weird thing... the stars don't see to be trailed in the actual image.

I even tried turning off all corrections and the graph still went crazy in Dec.

I had Periodic Error correction enabled on the Paramount MYT mount run by the SkyX. The native PE was 3.9 arcseconds and with PEC enabled, it was reported at 0.7 arcseconds.

Polar alignment was excellent at 26.3 arcseconds in Azimuth and 22 arcseconds in altitude from the refracted pole.

I had also built a 324-point TPoint model and applied ProTrack.

I also tried turning off PEC and ProTrack in the SkyX and this craziness in Dec continued.

If this had been the only time this had happened, I might have thought it was just the seeing going bad with a boom, but since it happened previously on a night of really good seeing, I don't think that is it.

I also was using LowPass2 for the Dec guiding algorithm as suggested by Bruce.

I could see dec corrections being issued, but they seemed small considering the apparent deflections... maybe that was the LowPass2 algorithm.

I'm perplexed.

Jerry

[Andy Galasso]

Hi Jerry,

Could you please post your PHD2 Debug Log and Guide Log from the session.  (instructions here)

Andy

[Jerry Lodriguss]

Hi Andy,

Thank you,

I think these are the right logs...  I was not able to post it to this group for some reason, Google has been acting very funny lately... so I posted it to dropbox here:

https://www.dropbox.com/s/5a4pk6hudcuzhlw/20150822_PHD2_LOGS.zip?dl=0

It's a zip fle with the Guide and Debug logs... let me know if you have any problems opening it.

Jerry

[bw_msgboard]

Hi Jerry.  Andy and I will probably need to scratch our heads about this for a bit.  But I notice you are running with neither dark files nor a bad-pixel map.  Is that your customary practice even with the Lodestar?  That’s not an attempted diagnosis, just a question – but I think most Lodestar users apply one or the other, and the bad-pix map implementation was even motivated by the Lodestar behavior.  Just wondering…

 

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Jerry Lodriguss
Sent: Sunday, August 23, 2015 5:00 PM
To: Open PHD Guiding
Subject: Re: Dec Weirdness after Dither

 

Hi Andy,

--

[Jerry Lodriguss]

Hi Bruce,

Yes, I have used Lodestars for several years now and have never found the need to use either darks or a bad-pixel map.

I wouldn't rule anything out since this is so perplexing, but I've never seen anything like this before.

Jerry

[bw_msgboard]

Andy pointed out something critical here – the Lodestar is inherently binned 1x2, which means the sampling on RA and Dec (X/Y) is different by a factor of 2.  And that makes it more likely you did get locked onto a hot pixel here.  So we think you should be using at least a dark library and preferably a bad-pix map for the camera.  In other words, you’ve probably just discovered why there *is* a need for these. <g> 

 

There’s also some yet-unexplained behavior with the LowPass2 algorithm which I need to look at.  In the meantime, it’s pretty clear the algorithm has nothing to do with your problem, so why don’t you go back to ResistSwitch until I can understand what’s going on with LowPass2.

 

If you see this problem again, I think the key is the extended periods where the star is showing no movement at all in Dec.  If that happens, capture the guiding image in the FITs format using the menu under ‘File.’  If we’re right, we should see one or more hot pixels right around the lock position.

 

Good luck.

[Jerry Lodriguss]

Hi Bruce,

Excellent suggestions, I will definitely try them the next time I go out.

I also thought about trying an older version of PHD if I experience this again and see if I can duplicate the problem there.

I'm a little unclear as to exactly what is happening when you say the Lodestar is "inherently" binned 1 x 2, and which axis would have higher resolution, if you could explain a bit more about that or point me to a more detailed explanation, I would really appreciate it.

And if the guiding algorithm gets locked on to a hot pixel for an extended period, why would there be movement in either of the axes during that time?

Thank you,

Jerry

[Andy Galasso]

On Mon, Aug 24, 2015 at 12:56 AM, Jerry Lodriguss <lis...@astropix.com> wrote:

I also thought about trying an older version of PHD if I experience this again and see if I can duplicate the problem there.

The evidence is pretty strong it is a hot pixel issue. I'd go with building a bad pixmap as Bruce suggested.   If in doubt, we can confirm it by grabbing a dark frame from the camera and looking at pixel (456,310)

I'm a little unclear as to exactly what is happening when you say the Lodestar is "inherently" binned 1 x 2, and which axis would have higher resolution, if you could explain a bit more about that or point me to a more detailed explanation, I would really appreciate it.

The Lodestar uses an interlaced sensor, and there are two ways to read out the pixels. The first way is to download the even rows while the odd rows continue exposing, then read out the odd rows. This creates a small bias for the odd rows. For ordinary guide exposures the interlaced bias is negligible and does not effect guiding. The Starlight Xpress ASCOM driver uses this method to read the pixels from the camera.

The second method is to bin the even and odd rows together (camera binned 1x2), effectively reading both rows out at once. This eliminates the bias but loses some spatial resolution due to the binning.  The PHD2 internal driver "Starlight Xpress SXV" uses this method. For guide setups using the Lodestar with an OAG, the stars may be somewhat oversampled, so the binning does not matter. For short focal length guide scopes, the binning could cause some undersampling.

You have the option of choosing the ASCOM driver connection to get 1x1 pixels (interlaced), or the native driver for 1x2 pixels (non-interlaced).

 

And if the guiding algorithm gets locked on to a hot pixel for an extended period, why would there be movement in either of the axes during that time?

We believe the effect was caused by the guide star overlapping a hot pixel. The camera x-axis is perfectly aligned with RA and the short axis of the 1x2 pixels. The Y-axis is aligned with Dec and the long axis of the 1x2 pixels. There was not enough dec motion (seeing and drift) for any appreciable flux to land outside the hot pixel on the y axis (~8"/px), but some flux was measured on the x-axis (~4"/px) outside the hot pixel affecting the x-coordinate of the centroid but not the y-coordinate.

Andy

[Jerry Lodriguss]

Hi Andy,

Thank you very much for the detailed explanation. It may take me a while to totally understand it as I don't think I'm as sharp as I used to be (or maybe I was never as sharp as I thought I was...)

I will definitely try using the bad pixel map and I will shoot a dark frame and see where the hot pixels are.

Some folks on the Paramount forums are telling me that there is an option in the Paramount ASCOM SX driver to "square" the pixels, but I don't know how they implement that or if it would help in my situation.

http://www.bisque.com/sc/forums/p/25346/120302.aspx#120302

Thanks again to you and Bruce for helping me with this, I truly appreciate it.

Jerry

[Andy Galasso]

On Mon, Aug 24, 2015 at 3:21 AM, Jerry Lodriguss <lis...@astropix.com> wrote:

Some folks on the Paramount forums are telling me that there is an option in the Paramount ASCOM SX driver to "square" the pixels, but I don't know how they implement that or if it would help in my situation.

(I couldn't follow that link to the SB forum as it appears to be a closed forum.)

I don't think enabling the Square Pixels option in the SX ASCOM driver or the PHD2 native SXV driver will make any difference for your issue. The Lodestar pixels are 8.2 x 8.4 uM; both drivers have a "Square Pixels" option to resample the non-square pixels onto a square pixel array.

I do not think the non-square pixels has any relevance to the issue you reported.  PHD2's calibration handles non-square pixels perfectly well. The only case I can think of where having non-square pixels might matter is if you have a Lodestar in an OAG behind an instrument rotator. When phd2 is connected to the rotator and adjusts calibration for the rotator position it assumes the camera has square pixels, so that's the only case I can think of where it would really matter at all (and where the square pixels option would be needed for best guiding).

Andy

[Jerry Lodriguss]

Hi Andy,

Thanks for the feedback on the square pixel aspect. 

I will definitely check for hot pixels and report back.

Jerry

[Jerry Lodriguss]

Hi Guys,

Here is a 3 second exposure at room temp in my office showing the hot pixels.

I did a bad pixel map at 5sec exposures and used it and took another exposure at 3 seconds and the second image is the result. 

I don't know if this is normal, but it seems like there are some hot pixels still left.

Both of these images have an extreme digital development stretch applied.

Jerry

[Jerry Lodriguss]

Hi Guys,

I don't see any hot pixels at 456, 310.

So perhaps we still have a mystery?

Jerry

[bw_msgboard]

Anything’s possible I guess. But the driving fact here is that every time you saw a problem, you had run for an extended period of time with the Y coordinate of the centroid being constant to within 0.01 px. That has to be bogus, no mount working through the atmosphere is going to do that. J And of course hot pixels can come and go, particularly with hotter temps. I’d like to see you try real guiding again with your bad-pix map and see what you get. If you see the problem again, capture the guide frame image so we can see whether the star is adjacent to uncorrected hot pixels or some other image defect. And since you are working at a short focal length, you could even consider slightly de-focusing the star to improve the sampling.

 

Good luck.

Bruce

 

 

---

From: Jerry Lodriguss [mailto:lis...@astropix.com]
Sent: Monday, August 24, 2015 11:24 AM
To: Open PHD Guiding
Cc: lis...@astropix.com; bw_m...@earthlink.net
Subject: Re: Dec Weirdness after Dither

 

 

Hi Guys,

[bw_msgboard]

 

Hi Jerry. Did you take a look at the bad-pix map documentation? Usually, you need to do a little tuning on this stuff, and you can also manually select hot pixel areas that aren’t being identified by the statistics. The other thing to remember is that the bad pixel areas need to be compared to an actual usable guide star. So looking at the ADU values of the hot pixels that remain can tell you whether they are likely to interfere with guide star tracking.

 

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Jerry Lodriguss
Sent: Monday, August 24, 2015 11:20 AM
To: Open PHD Guiding
Cc: lis...@astropix.com; bw_m...@earthlink.net
Subject: Re: Dec Weirdness after Dither

 

Hi Guys,

--

[Andy Galasso]

Jerry,

Could you post a dark frame fits file (File => Save Image), with bad-pixmap disabled to show the raw data from the camera?

Andy

[Jerry Lodriguss]

Hi Bruce,

Thanks again for your help, I will definitely try your suggestions the next time I go out.

I usually do defoucs the star a little bit.

Jerry

[Jerry Lodriguss]

Hi Andy,

Sure, here is a 3-second exposure with no pixmap.

Jerry

[bw_msgboard]

I’m still grinding my molars about your problem.  Let’s back up a minute and look at the big picture.  I think in the past you never saw this problem but now you’ve seen it on at least two nights.  What’s changed with your set-up, hardware or software?  How long were you running on 2.5.0 before you saw the first problem?  Have you always used the same driver for the Lodestar?  What is the guide scope?  Anything at all different about the guiding rig?

 

One thing you might do is go ahead and get us a FITs image even before you see the problem.  Just get set up, get going on a guide star, and save one of the guider images.  I’d like to reassure myself that the star is “big enough” to support accurate centroid calculations.  You can also use the Star Profile tool to assess the FWHM of the star.  We’re looking for a star profile that is several pixels across.  I just want to cover the bases here and not have you getting frustrated with bad imaging sessions.  You might also try rotating the guide camera a bit so the Dec axis doesn’t fall precisely on a row or column of the sensor.  I know this is counter-intuitive, but it won’t affect your guiding and it could help you avoid falling victim to buzzard’s luck.

[Jerry Lodriguss]

Hi Bruce,

I think I may have seen this problem on three nights.

To support the hot pixel theory, these were summer nights. Temps about 65 degrees F the first two times. It was in the low 50's the last time.

Nothing has changed with the setup at all.

I don't remember exactly when I switched from 2.4 to 2.5 but I want to say not too long after it first came out... my first documented use of it that I have is May 19, 2015. The first Dec weirdness was August 13, 2015.

Attached is a screen shot of some similar weirdness in RA from June 9, 2015.

Yes, I have always used the same driver for the Lodestar.

Nothing different about the guiding rig. I'ts an AT65EDQ with a diagonal and the Lodestar X2. It's at 420mm of focal length guiding the AP 136EDFGT working at either 819mm of focal length or 614mm of focal length with 0.75x focal reducer. Everything in my setup is pretty tight. I used it with a Takahashi EM200 with no problems before I got the MYT mount.

So the only two variables are the mount and PHD2.  I have gotten really good guiding with the mount, but I know that doesn't prove much.

Just to complicate things even more, and possibly give one bit of evidence that would possibly point away from the hot pixel theory... I went back and looked at the lights that I shot during the last weird dec run.  The images were dithered between frames and the stars did move in each sub frame. 

I don't think the guidestar was overexposed as it did not have a flat top to the star profile plot, and the star had a good s/n ratio, and no hot pixels were found near the guidestar location in the darks I just shot.

On the other hand, the flatline behavior seems to suggest, as you pointed out, that it was locked onto something that was not moving.

The FWHM of the star on the last night with the dec problem was 1.4. I did re-focus the guidestar that night so the stars were pretty tight.  I calculate the angular diameter of the Airy disc with my guidescope to be 4.26 arcseconds, and the FWHM angular diameter to be about 1.78 arcseconds, and the image scale with the Lodestar was 4.08 arcsec per pixel, so I was definitely undersampled.

Is the FWHM readout in PHD2 in pixels or arcsec?

I will capture a FITS file as soon as I start next time, and try the bad pixel map, and also try rotating the guider head.

I'm frustrated, but having the best (you guys) helping really eases the pain. :-)

Jerry 

[bw_msgboard]

Hi Jerry.  This is good info, really gives me a better context.  I think there may be a fair amount of back-and-forth getting your problem resolved, so I’m going to send you a direct response, copying Andy.  That will cut down on the forum traffic and we can summarize the outcome later when you’re back to being a happy camper. J

[Mark Striebeck]

No, please don't (follow up off-forum). I for myself find this discussion super interesting and educating.

My $0.02

    Mark

--