AP1600GTOE RA drift


Craig Young
 

I have polar aligned the mount and without using a pointing model I get good pointing accuracy, always close to the center of the ccd sensor.  I have used PEMPRO to check the alignment and it also shows the mount is well polar aligned.

To check tracking I point the telescope at 0 DEC and HA=-0 10 00 (ie, 10 minutes east of the meridian).  At this location there should be no RA drift and only a DEC drift as a result of any remaining polar alignment error.  I then take a 10 second image, wait 5 minutes and take another 10 second image.  I plate solve both images and get this:

Drift:
  Rho (arc-sec): 4.3
  Rho (pixels ): 7.6
  Theta (degrees): 77.3
 
  RA (arc-sec): 4.2
  RA (pixels): 7.4
 
  DEC (arc-sec): 0.9
  DEC (pixels): 1.7
 
Duration (seconds): 317
 
Drift Rate (arcsec/sec): 0.0136 @ 77.3 degrees
 
Drift Rate RA (arcsec/sec): 0.0133
 
Drift Rate DEC (arcsec/sec): 0.0030


Rho is the arc second displacement from the plate solve of image 1 to image 2.  The plate scale is 0.57 arcsec/pixel.


Theta is the direction of the drift.


Notice the drift in RA is 4.2 arcsec and DEC is 0.9 arcsec.  This is where I am puzzled, the DEC drift I would expect because of a slight polar alignment error, but why the very large RA error when this mount has absolute encoders?


My first thought is the encoders or clock is off, or there is a Southern Hemisphere correction being applied that is opposite to what it should be.


Craig




Joe Zeglinski
 

Craig, et al.
 
Interesting – A Supplemental question, from me.
    Now that you mention it, does the “Encoder Option” really only function for positioning during a GOTO?
I didn’t think the encoders play any part during tracking – that’s the servo’s responsibility, with a good polar align to begin with. Don’t know if Encoders even affect PemPro PA improvement, when it does its slews, since it is all about using good “tracking” to begin with.
 
Joe


Jon <jmartin590@...>
 




Craig,
When Roland was at NEAF, the video made by Sky and Telescope explained that the encoders do in fact maintain the scopes position on a dso and will even push back against wind deflection to do it.

Jon

On 4/7/2017 2:54 PM, 'Joseph Zeglinski' J.Zeglinski@... [ap-gto] wrote:
 

Craig, et al.
 
Interesting – A Supplemental question, from me.
    Now that you mention it, does the “Encoder Option” really only function for positioning during a GOTO?
I didn’t think the encoders play any part during tracking – that’s the servo’s responsibility, with a good polar align to begin with. Don’t know if Encoders even affect PemPro PA improvement, when it does its slews, since it is all about using good “tracking” to begin with.
 
Joe



Craig Young
 

Yes, the encoders should be used during tracking, especially to take out periodic error due to the worm drive.  From what I can see, it does this very well so I am sure the encoders are working.  But given the large error in RA tracking I'm thinking it is not calibrated or there is some sort of slippage in RA.

The firmware should be comparing the movement of the encoder over a period of time.  For sidereal tracking it knows what movement should be for a given time period.  But, if the time period is derived from an oscillator and the oscillator is running slow or fast then the firmware will not know that and the sidereal rate will be off by a small amount.  I have had to do this on other mounts so I am suspecting that is the cause here.

Otherwise maybe there is some sort of slippage, at this position the cw's are horizontal so they will have the maximum torque I guess on the RA servo.  Maybe if the axis is slightly out of balance the servos slip, but I would have thought the encoder would see this and adjust for it.

Craig


Ray Gralak
 

To check tracking I point the telescope at 0 DEC and HA=-0 10 00 (ie, 10 minutes
east of the meridian).
At this location there should be no RA drift and only a DEC
drift as a result of any remaining polar alignment error.
Sorry, but that's not true. Even with perfect tracking, RA drift can occur because of even the tiniest amount flexure of the scope, focuser, and camera assembly. For instance, I can measure easily it with my AP Traveler on my 1200 mount.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Friday, April 7, 2017 1:35 PM
To: ap-gto@...
Subject: [ap-gto] AP1600GTOE RA drift



I have polar aligned the mount and without using a pointing model I get good
pointing accuracy, always close to the center of the ccd sensor. I have used
PEMPRO to check the alignment and it also shows the mount is well polar aligned.

To check tracking I point the telescope at 0 DEC and HA=-0 10 00 (ie, 10 minutes
east of the meridian). At this location there should be no RA drift and only a DEC
drift as a result of any remaining polar alignment error. I then take a 10 second
image, wait 5 minutes and take another 10 second image. I plate solve both images
and get this:



Drift:
Rho (arc-sec): 4.3
Rho (pixels ): 7.6
Theta (degrees): 77.3

RA (arc-sec): 4.2
RA (pixels): 7.4

DEC (arc-sec): 0.9
DEC (pixels): 1.7

Duration (seconds): 317

Drift Rate (arcsec/sec): 0.0136 @ 77.3 degrees

Drift Rate RA (arcsec/sec) : 0.0133

Drift Rate DEC (arcsec/sec): 0.0030




Rho is the arc second displacement from the plate solve of image 1 to image 2. The
plate scale is 0.57 arcsec/pixel.




Theta is the direction of the drift.




Notice the drift in RA is 4.2 arcsec and DEC is 0.9 arcsec. This is where I am
puzzled, the DEC drift I would expect because of a slight polar alignment error, but
why the very large RA error when this mount has absolute encoders?





My first thought is the encoders or clock is off, or there is a Southern Hemisphere
correction being applied that is opposite to what it should be.




Craig








Craig Young
 

But given the orientation of the scope, I don't think the flexure is due to the OTA because it would flex in DEC only.  Are you thinking the flexure is then in the RA axis, with the cw's hanging out there horizontal?

The good thing though is once I enter the measured RA drift into APCC it then tracks perfectly.  What it requires though is I need to take two or three 60 second images and measure the drift correction before beginning an imaging session.  If I do this I can then take 10 minute images unguided.

Craig


Ray Gralak
 

is then in the RA
axis, with the cw's hanging out there horizontal?
Yes, exactly... don't you think that the CW is bending the CW shaft with some effect along the RA axis because that CW is sticking out horizontally? (You bet!)

The counterweight side of the mount does not matter but the telescope, focuser, and camera are all bending with some component along the RA axis. As the axis moves away from horizontal (because of RA tracking) the amount of bending continuously changes, which will cause apparent tracking rate changes in both RA and Dec. The pointing model attempts to fix this, but because of temperature changes, refraction, and even cables/tube currents, the corrections are seldom perfect.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Friday, April 7, 2017 7:42 PM
To: ap-gto@...
Subject: [ap-gto] Re: AP1600GTOE RA drift



But given the orientation of the scope, I don't think the flexure is due to the OTA
because it would flex in DEC only. Are you thinking the flexure is then in the RA
axis, with the cw's hanging out there horizontal?

The good thing though is once I enter the measured RA drift into APCC it then
tracks perfectly. What it requires though is I need to take two or three 60 second
images and measure the drift correction before beginning an imaging session. If I
do this I can then take 10 minute images unguided.

Craig


Craig Young
 

Since the tracking measurements were made on the meridian, and the RA drift is much greater than the DEC drift then I would guess the problem is in the RA axis somewhere.  I just got back from the observatory (remote) and did find a couple of loose bolts on the RA head .. I tightened them down and then did some slewing tests to make sure I didn't break anything.  Maybe this was the problem.  We are scheduled for clear skies tonight so will do a new model and tracking tests.  Skies permitting I'll update this thread tomorrow with the new results.

With a 132 point model the best I could do unguided was about 25 seconds imaging before the stars became elongated.  I have read many are doing several minutes unguided, hence my concern something is wrong.  I wrote this Tracking Analyzer program to assist in evaluating the problem.  What it does is similar to the software program FlexRx where images are plate solved and an drift correction in RA and DEC are calculated.  This information is then passed to the mount as an update to its current corrections.  The idea is to take a couple of test images at the beginning of an imaging session to establish the RA and DEC correction rates and then analyze each subsequent image for correction updates (tweaks) to those rates.  Ideally though you could start with the APPM model correction rates and then pass updates if it is not quite right or there is some other drift present, maybe due to temperature changes on the mechanicals or optics that the model could not account for.  As mentioned above, with the 132 point model I could do 25 seconds before star elongation, but with this method I can do 600 seconds unguided with a 1 pixel or less error.

So far it works very well, and eventually it would be great to have this added to either PEMPRO or PHD2 as an alternative guiding method.  PEMPRO has all the tools already available including plate solve and mount control, so this should be easy to add.

Craig


Steven
 

Hey Craig,

Pulse Guide is really good for that. So good that they don't make it any more. Get a copy and solve the problem.

Steve




From: ap-gto@... on behalf of craig.young.m8@... [ap-gto]
Sent: Saturday, 8 April 2017 12:04 a.m.
To: ap-gto@...
Subject: RE: [ap-gto] Re: AP1600GTOE RA drift
 
 

Since the tracking measurements were made on the meridian, and the RA drift is much greater than the DEC drift then I would guess the problem is in the RA axis somewhere.  I just got back from the observatory (remote) and did find a couple of loose bolts on the RA head .. I tightened them down and then did some slewing tests to make sure I didn't break anything.  Maybe this was the problem.  We are scheduled for clear skies tonight so will do a new model and tracking tests.  Skies permitting I'll update this thread tomorrow with the new results.

With a 132 point model the best I could do unguided was about 25 seconds imaging before the stars became elongated.  I have read many are doing several minutes unguided, hence my concern something is wrong.  I wrote this Tracking Analyzer program to assist in evaluating the problem.  What it does is similar to the software program FlexRx where images are plate solved and an drift correction in RA and DEC are calculated.  This information is then passed to the mount as an update to its current corrections.  The idea is to take a couple of test images at the beginning of an imaging session to establish the RA and DEC correction rates and then analyze each subsequent image for correction updates (tweaks) to those rates.  Ideally though you could start with the APPM model correction rates and then pass updates if it is not quite right or there is some other drift present, maybe due to temperature changes on the mechanicals or optics that the model could not account for.  As mentioned above, with the 132 point model I could do 25 seconds before star elongation, but with this method I can do 600 seconds unguided with a 1 pixel or less error.

So far it works very well, and eventually it would be great to have this added to either PEMPRO or PHD2 as an alternative guiding method.  PEMPRO has all the tools already available including plate solve and mount control, so this should be easy to add.

Craig


Ray Gralak
 

Craig,

I've already implemented that functionality as an upcoming feature so that there will be no reliance on any specific autoguiding program for Ra/dec drift rate fitting and periodic error correction of previously uncorrectable frequencies. :) Like you said, all the pieces have been available(for quite a while).

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Friday, April 7, 2017 9:05 PM
To: ap-gto@...
Subject: RE: [ap-gto] Re: AP1600GTOE RA drift



Since the tracking measurements were made on the meridian, and the RA drift is
much greater than the DEC drift then I would guess the problem is in the RA axis
somewhere. I just got back from the observatory (remote) and did find a couple of
loose bolts on the RA head .. I tightened them down and then did some slewing
tests to make sure I didn't break anything. Maybe this was the problem. We are
scheduled for clear skies tonight so will do a new model and tracking tests. Skies
permitting I'll update this thread tomorrow with the new results.

With a 132 point model the best I could do unguided was about 25 seconds imaging
before the stars became elongated. I have read many are doing several minutes
unguided, hence my concern something is wrong. I wrote this Tracking Analyzer
program to assist in evaluating the problem. What it does is similar to the software
program FlexRx where images are plate solved and an drift corr ection in RA and
DEC are calculated. This information is then passed to the mount as an update to
its current corrections. The idea is to take a couple of test images at the beginning
of an imaging session to establish the RA and DEC correction rates and then
analyze each subsequent image for correction updates (tweaks) to those rates.
Ideally though you could start with the APPM model correction rates and then pass
updates if it is not quite right or there is some other drift present, maybe due to
temperature changes on the mechanicals or optics that the model could not account
for. As mentioned above, with the 132 point model I could do 25 seconds before
star elongation, but with this method I can do 600 seconds unguided with a 1 pixel
or less error.

So far it works very well, and eventually it would be great to have this added to
either PEMPRO or PHD2 as an alternative guiding method. PEMPRO has all the
tools already available including plate solve and mount control, so this should be
easy to add.

Craig


Craig Young
 

Hi Steven,

I took a quick look at PulseGuide, I think APCC already does that.  One of the great features with the APPM model is its tracking correction by changing the RA and DEC rates .. pulse guiding I think.  But the problem is there is no feedback to the correction logic indicating if the corrections are valid.  I think it needs to plate solve images to see if the corrections need tweaking.  That is what FlexRX and my Tracking Analyzer programs do.

Craig


Steven
 

HI Craig,

Yes, I know it can be done in APCC, but the Pulseguide method is practical, dead simple and quick, in real time (as they say), that's why I mentioned it. Wish you luck in any case.


Steve




From: ap-gto@... on behalf of craig.young.m8@... [ap-gto]
Sent: Saturday, 8 April 2017 12:57 a.m.
To: ap-gto@...
Subject: Re: [ap-gto] Re: AP1600GTOE RA drift
 
 

Hi Steven,

I took a quick look at PulseGuide, I think APCC already does that.  One of the great features with the APPM model is its tracking correction by changing the RA and DEC rates .. pulse guiding I think.  But the problem is there is no feedback to the correction logic indicating if the corrections are valid.  I think it needs to plate solve images to see if the corrections need tweaking.  That is what FlexRX and my Tracking Analyzer programs do.

Craig


Craig Young
 

Excellent Ray, I look forward to the update and how you implemented this.  Having a real time feedback loop to the APPM model (tracking) will be an excellent feature.  The mount is very capable of precise tracking, and currently, having the RA and DEC corrections being applied is exactly what is needed to take advantage of this.  But as you said earlier, the model is not perfect, and environmental conditions are always changing, so a feedback is needed.  Also, I would imagine with a feedback loop during imaging that a smaller APPM model could be used, ie, instead of 200 points you could get away with 60 or so.

Thanks heaps for all the hard work you are putting into APCC.

Craig


Craig Young
 

An update to my tracking tests.  After tightening down the bolts on the RA head, and then doing a new 72 point model, the tracking is much more stable.  After two nights observing, I found that most locations in the sky, the tracking model is perfect with nice round stars at 4 minute integration time.  Plate scale is 0.57 arcsec/pixel and focal length is 3250.  Camera is an STXL-6303e with 9 micron pixels and a well depth of 100,000 electrons.

I also found that at some locations in the sky, the model would exhibit elongated tracking, but turning it off would result in nice round stars.  And finally, in all cases, when the tracking analyzer is used to derive the tracking correction rates it always resulted in round stars.  As expected, when the analyzer generated the same correction rates as the model then they both worked.

So as Ray pointed out in an earlier posting to this topic, the model is not perfect for all locations, but an average across the sky.  And since these tests used a small model of 72 points then I would expect some variation.  But it was encouraging to see the tracking analyzer always nailed it.  This indicates when Ray adds the feedback function to the tracking model that it should result in unguided imaging over long periods of time, even with long focal length, small plate scale systems.

For example, last night I wanted to record twenty images of an open cluster, each image 240 seconds in duration, unguided.  I turned off the tracking model and reset the mount to sidereal tracking, ie, RA correction and DEC correction are both 0.00.  I recorded two, 240 second images, both images showing elongated stars.  I then used the tracking analyzer program to measure the drift over the two images and got the recommended tracking corrections (arcsec/sec).  I manually entered these into the rate/correction boxes and activated them, then verified the RA and DEC correction rates being applied to the mount matched the corrections recommended by the tracking analyzer program.  Two new images showed nice round stars so I continued on with the next 18 images, monitoring the drift over the images and applying some small tweaks to the tracking rates as needed.

At the end of the session I activated the tracking model and compared the model correction rates to the tracking analyzer rates and found a significant difference.  So as pointed out above, in this case the tracking model would not have worked, but with feedback it works perfectly.  Deriving the initial correction rates using two images took about 10 minutes in this case, but it did result in perfect tracking over the next hour.

I look forward to Ray's implementation of this methodology which will automate and simplify the process.

Craig


dave@...
 

wheres this "travking analyzer"?


dave@...
 

tracking analyzer...


Craig Young
 

The Tracking Analyzer software is one I wrote to solve why I was getting elongated stars.  It uses Pinpoint and UCAC4 catalog.

Craig


Craig Young
 

A public program similar to Tracking Analzyer is FlexRX written by Andre Paquette up in Canada.


Roland Christen
 

There is no slippage. RED HERRING!

Roland Christen


On Apr 7, 2017, at 6:51 PM, "craig.young.m8@... [ap-gto]" <ap-gto@...> wrote:

Yes, the encoders should be used during tracking, especially to take out periodic error due to the worm drive.  From what I can see, it does this very well so I am sure the encoders are working.  But given the large error in RA tracking I'm thinking it is not calibrated or there is some sort of slippage in RA.

The firmware should be comparing the movement of the encoder over a period of time.  For sidereal tracking it knows what movement should be for a given time period.  But, if the time period is derived from an oscillator and the oscillator is running slow or fast then the firmware will not know that and the sidereal rate will be off by a small amount.  I have had to do this on other mounts so I am suspecting that is the cause here.

Otherwise maybe there is some sort of slippage, at this position the cw's are horizontal so they will have the maximum torque I guess on the RA servo.  Maybe if the axis is slightly out of ba lance the servos slip, but I would have thought the encoder would see this and adjust for it.

Craig


Craig Young
 

Yes indeed, there is something fishy going on.  With patience and determination I will net it in.

Craig