Steady RA drift while guiding, all night long?

[Steven Bellavia]

Hi,

Last night, while auto-guiding, I had a very steady drift in RA.  Why?  I was guiding? My errors were all symmetric about zero, not all in one direction?

I had good polar alignment (under 0.2')

My calibration was fine.

I was not dithering.

I had excellent DEC guiding.

The Ra guiding was not terrible (maybe 1 arc-sec RMS error, with occasional spikes, in either direction, due to wind/seeing)

All night, the stars move steadily from frame-to-frame, in an Easterly direction, as if I was set on lunar rate, not sidereal (which I checked, and I wasn't, and even then, guiding on a star should have tried to prevent that).

I also checked to see if I was maybe, by a very odd coincidence, tracking on an asteroid or comet, and nothing shows up in that part of the sky.

This image is stacked, deliberately not-aligned, for 43 minutes of data on a giant portion of the sky (over 3 degrees). Top-bottom is RA., left-right is DEC:

https://drive.google.com/open?id=1C9RFYPp49K65mb7hahfTaWj2ZkyzDD_T

And my log files, as well as snapshot of the reviewed Calibration data, and some guiding screenshots, are here:

https://drive.google.com/open?id=17Q0KZE3ktXIcDIlLw6DEE9EC1hqfuF7j

Any help is appreciated!

Steve

[Steven Bellavia]

Oh, and an ultra-light rig (camera+135mm lens, and 50mm guidescope,  rigidly attached to mount, and tiny little counterweight, set slightly East-heavy):

https://drive.google.com/open?id=1PnKc6KxKfPa9q74V_ICodZUGmHLKvXL4

[peter wolsley]

Steven,

Your RA guiding looks ok to me.  I believe you were tracking at Sidereal rate.  There was a little RA drift which seemed to start around 20:50 and steadily grew to about 75" in 30 minutes.  Certainly PHD2 had no problem correcting for this drift.  There were strange RA spikes all thru your session #11.  Almost every minute...I don't have a clue what they were.  PHD2 was correcting them quickly and they were always in the same direction.  These spikes seemed to disappear for session #12.  Your DEC guiding was also OK.  Some drift...but small.

My guess is differential flexure. Are the stars in the individual subs round? 

Peter

[Steven Bellavia]

Hi Peter,

Thank you for responding!

The stars look OK on individual 5-minute subs.

It has to be flexure.  I am guessing the camera, though strapped down to the aluminum support I made, must have been shifting steadily, as that is the "long" (RA) direction, where the star motion is.

The spikes may have been wind and/or cable tug.

I can't think of anything else it could be (unless, like I said earlier, I was tracking on an asteroid)

[peter wolsley]

Steven,

If you were guiding on a comet or asteroid I would expect PHD2 to show much more RA drift.  Bruce and I discussed RA drift a fair bit on this forum just this past week.  He made an excellent point that it takes virtually nothing in the way of flex to cause RA drift.  In this case we were discussing drift caused by gravity pulling against the mount and scope.  Tiny, tiny, tiny amounts of flex can cause 100s of arc seconds of RA drift.  So unless your rig is cut out of a solid block of metal you are going to see some amount of flex.  In practice this flex tends to be unexpected so you end up just expecting some RA drift and always check your set-up as much as you can before each session.  Bruce also declared that with a separate guider scope you are doomed to some differential flexure.  Obviously you understand what differential flexure is.  To me it means securing both ends of the guidescope.  In your case it should also include both ends of your camera/telephoto lens rig.  Something that I do is to ensure that the guidescope is being slightly pulled...a little tension on the cable...maybe some stiff foam jammed under the guidescope objective.  This creates a pre-load which I believe helps to minimize gravity induced differential flexure.

I think those spikes are too repetitive to be the wind.  They were occurring every 50 to 60 seconds which I would have a hard time believing was cable tugs. Next time you see spikes like that you should hunt around your rig.  You might also use windows task manager to see if your computer was experiencing high CPU usage....just a thought.

Good Luck

Peter

[Steven Bellavia]

I am not disagreeing.  In fact, I think I once posted that as the mount moves in RA. it is possible for the gravity force to increase by about the weight of one nickel (5 grams) every minute.  Of course, it depends on orientation, etc, but imagine after an hour having a stack of 60 nickels on your rig!

I am 99.99% sure it is flexure. I was just throwing the asteroid thing out there.

Hmm.  CPU usage.  I do hate this new windows 10 laptop.  An imager from CloudyNights suggested I put it into airplane mode, which I did for the first time this session.  Good suggestion, and easy to do.  But it is possible the spikes are from that.  But why just in RA?

You guys are the best.  I don't know what we would do without all of you.

:)

[Steven Bellavia]

And I hope you do not think I was complaining about PHD2.  Just looking for help!

Considering I was using a $139, no-name camera lens, a 4-year-old Canon EOS camera and a Celestron AVX mount, I am very happy with my results from last night, which would have not been possible without PHD2:

https://www.astrobin.com/330050/0

https://www.astrobin.com/330050/B/

[Andy Galasso]

On Fri, Jan 19, 2018 at 9:32 PM, Steven Bellavia <stevenb...@gmail.com> wrote:

Considering I was using a $139, no-name camera lens, a 4-year-old Canon EOS camera and a Celestron AVX mount, I am very happy with my results from last night, which would have not been possible without PHD2:

Wonderful images, such a beautiful object. Personally I like the greyscale Ha version best. Especially impressive considering only 6.5 hrs exposure with very modest gear!

Andy

[peter wolsley]

Steven,

I think it's great that you are trying every combo you can think of.  You are learning lots and scratching your head lots as well.

As far as why only RA...the RA axis motor is in constant motion 15a-s/sec Sidereal tracking rate.  It takes only 1/3 second of hesitation for the RA axis to fall 5a-s behind and need to catch up.  It makes sense that if a problem arises because a laptop gets too busy it will show up in your RA guiding first.  If you believe your Laptop's CPU usage is causing problems you can create a power plan where the processor power management is set to 100%...it draws down the battery faster so you need to stay plugged in.

Peter

[peter wolsley]

Steven,

I think I should clarify my last post.  I did not mean to give the impression that a high CPU usage will cause RA guiding issues.  I just meant that if there is a possibility of a high CPU usage causing a problem with your guiding it will most likely show up in your RA guiding.  In my specific case I use the Nexremote app to align/calibrate etc.  If a high CPU usage situation occurs I believe it might cause Nexremote to hesitate slightly when communicating to my CGEM.  This might cause the RA motor control firmware to hesitate.  The likelihood is probably very low but I was trying to give you some possibilities for explaining the RA spikes that I consider to be quite frequent and unusual.

Peter

On Friday, January 19, 2018 at 10:58:24 PM UTC-5, peter wolsley wrote:

Steven,

[Steven Bellavia]

Thank you for the clarification and all the attention you are giving this.

And yes, I understand it is unlikely, but a potential cause, and would effect RA more than DEC.  So thank you for that!

This hobby is fraught with possible gremlins.  Sometimes you think you are achieving good (or bad) results for a specific reason, only to find out that the reasoning is totally flawed, and you are getting good (or bad) images DESPITE what you thought, not because of it.

If it were not so cold out that night, I would have stuck around and tried some things (like gently slapping the cables against the tripod legs, etc) to see if I could reproduce the spikes.  And looking at my homemade camera-lens-guidescope-finderscope dovetail thingy, I see it is flawed, in that the camera can rotate from the single 1/4-20 attachment screw, despite having lots of sticky rubber pressing against the bottom of the camera and lens (which also prevents focus drift).

Bruce has trained me well to seek out obvious mechanical issues, rather than blame electronics, and I am slowly becoming a disciple of that type of thinking.  When you hear hooves, think horses, not Zebras.   But I have also had brand new  cables go bad, etc.  So it takes much effort to diagnose these problems.  But if this was too easy, I may not want to do it.

Is there some way to determine if there is a signal-to-response lag?  I guessing this is impossible with the system itself, since it is the same system you are trying to diagnose?

:)

Steve

[Steven Bellavia]

One thing I did that has stopped my laptop from unexpected high CPU usage is to disable the Chrome Software Reporting Tool.

I cannot tell you if this will cause other problems, but it is what I did (and yes, I am stating this on a Google Group forum - hope that isn't blasphemous):

https://www.ghacks.net/2018/01/20/how-to-block-the-chrome-software-reporter-tool-software_reporter_tool-exe/

:)

Steve

[peter wolsley]

Steve,

You could characterize the overall system response in stages.  The easiest part would be to use the "Adjust Lock Position" feature to introduce a step into your guiding.  This will tell you how your system responds once PHD2 sees a problem.  You want to ensure that your step does not cause the resulting guide pulse to use the entire max duration limit otherwise the values you get tend to become skewed.  The next item to characterize is how long it takes for PHD2 to "see" a change in your guidestar position.  This can be estimated to simply be the exposure time you are using.  The reality here is that the image your camera delivers to PHD2 has been integrated over the entire exposure time.  If a change occurs at the beginning of the exposure then the image will show a full representation of the change.  If it happens towards the end of the exposure then the image will only partially show the change.   It ends up being a guess with a worst case scenario being the full exposure time.  The time that PHD2 needs to process the image and calculate the required guide pulse is a small fraction of a second.  This brings us to the last time lag which is how long is the guide pulse.  This is greatly influenced by whatever autoguiding rate you have selected for your mount.  If you choose a very slow (<30%) autoguiding rate then PHD2 will be forced to use long guide pulses.  This introduces a lag that is added to your exposure time because PHD2 will not tell your camera to take another image until the guide pulse has completed.  This can significantly slow the cycle time of PHD2.  Slowing this cycle time will directly slow the response of PHD2 to a disturbance.  Using higher autoguiding speeds (>50% up to 100%) allows PHD2 to use much quicker guide pulses which helps PHD2 to respond faster to a disturbance.  Just remember...faster exposures also makes you vulnerable to chasing seeing.

These are just some thought about characterizing guiding.  There is no exact solution...but understanding the concepts can sometimes help understand what to avoid.  Tweeking your response to get that last bit of performance is a huge time consumer that is highly subjective.

Peter

[Steven Bellavia]

I will have to try "Adjust Lock Position".  I assume I don't pick "sticky lock position", as this is just to move the scope by tiny increments to see the response (?)  And will I see changes "live" while moving around the lock position?  I'm a little fuzzy on how to see the response, and determine if it is OK or not.

I run at 80% of sidereal. (But PHD2 says it is 81%).   I will up it some more - maybe go to the 99% (hand controller won't let me enter 100%), as that does increase the "range" since you can enter any aggression oh PHD2.  In fact, having said that, I guess it is silly to not always run at 100%, as your aggression can go from 0 to 100, which means you have effectively just changed your range from 0 to 200, with the only drawback is perhaps less discretization (which I doubt matters).

Need some clear nights, which are not around.  And fighting some health issues is not helping.  :/

[peter wolsley]

Steve,

The sticky lock position feature only kicks in when you stop and start guiding.  Normally when you re-start guiding, PHD2 will generate a new lock position and then bumplessly resume guiding.  When Sticky lock position is enabled PHD2 will use the previous lock position which could cause PHD2 to quickly move your guide star to this sticky lock position...not a bumpless process.

You adjust the lock position while your are guiding.  PHD2 will immediately react to this change.  Your graph will show a sudden spike which then should quickly and smoothly come back to zero.  You don't want to see oscillations or overshoot.  Ideally PHD2 is not trying to correct for a storm of activity.  The best control is "smooth and steady".

I have my CGEM autoguiding rate set at 50%.  Works just fine.  One caution is if you have an RA backlash value set in your AVX mount.  If you use 100% autoguide rate I have heard that it is possible for the RA backlash comp in the mount to trigger which will put the mount into terrible oscillations.   I would leave your autoguide rate at 80%...that should be plenty fast.  The autoguide function in your mount (actually most mounts) acts very crudely...I call it a "bang-bang" style of control. At 50% autoguide rate, or gain,  this means that the RA motor will normally be turning at 15a-s/sec but will drop to 7.5a-s/sec or jump to 22.5a-s/sec when a guide pulse is received.  At 100% autoguide rate, or gain, the RA motor will normally be turning at 15a-s/sec but will drop to 0a-s/sec (it will actually stop turning) or jump to 30a-s/sec when a guide pulse is received.  You could get instability if you try to combine 100% autoguide gain with 100 aggression gain in PHD2.  A good analogy would be to take your car out for a drive down a sidestreet at 40MPH...now slam your foot on the brake so the car stops...now slam your foot on the gas and get the car moving at 80MPH...I don't think your car will last very long doing that!  Just be cautious if you choose to increase these values.  Lots of people don't operate this way because it causes problems for them...it's not the "pot of gold".

Peter