ATrack monitors a science images folder for new images recorded by the camera.  New images are added by Voyager/MaximDL.  When a new image is detected ATrack does a plate solve and measure both drift (difference between last image and this image) and shift (difference between a reference position or image and this image).  The drift is then used to adjust the tracking rate, the shift is used to temporarily change the motor speed for a period of time to recenter the next image.  Through an observing run of several hours ATrack will change the tracking rate (RA, DEC) to minimize the drift rate and keep the image centered.  It does this very accurately.  ATrack does not care what the cause of the drift, it simply measures it and readjusts the motor speeds to cancel it.  Through the night the changes are very small and consistent .. there is no wild jumps.  It is also very repeatable, from night to night.  No matter what the temperature is .. a warm summer night or a cold winter night .. the tracking corrections are always the same.

Now, if I turn off tracking correction on ATrack and turn on tracking correction in APCC then the stars drift away very quickly .. pixels per minute .. about 1 arc sec a minute.  This happens whether I use a 25 point model or a 200 point model.  When I compare the correction rates in APCC with ATrack I see the same difference no matter where I am pointed.  East side or West side.  The mount is always tracking in RA too fast and has to be slowed down.  This is consistent with ATrack which always shows the mount tracking too fast and it uses correction values that are negative .. in other words, it tries to slow down the sidereal tracking rate.

The fact that DEC is similar would seem to indicate there is a base constant in the motor speeds that is incorrect.  DEC is always a positive number in the range 0.02000 to 0.01200 arcsec/sec and is the same in both East and West sides.

Craig

Roland,
I do agree with you that errors in polar alignment, tube flexure, mirror shift, cables, etc can all contribute to factors that will reduce the effectiveness of using APCC for long duration unguided imaging on larger SCTs.  I have seen this also on Parmount mounts where ATrack is used to correct tracking over long periods of time, so it is not just an AP problem.  ATrack doesn't really care if the sidereal tracking rate is wrong or polar alignment or any other problem with the system, it is similar to using an autoguider which also corrects tracking, but in a different way.  So there is no real need to try and diagnose the system when it is not really needed.

It is best to simply accept the limitations of the system, which includes the mount, the optical train, the pier and foundation, sky conditions, etc and just plan to use an autoguider or a program like ATrack.

Craig

Craig,

Nothing indicates an error in mount clock rate.

As I said before the tracking rate errors you are seeing in the APCC version you are using are almost certainly caused by unmodeled pointing errors in your truss tube OTA. There is a solution coming using a combination of temperature modeled pointing terms and machine learning.

No matter what the temperature is .. a warm summer night or a cold winter night .. the tracking
corrections are always the same.

Refraction and flexure changes caused by temperature don't affect tracking? I suppose your focus never shifts either with temperature?

Why don't we take this offline?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Tuesday, May 5, 2020 7:08 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Adjust CP4 Clock Frequency

ATrack monitors a science images folder for new images recorded by the camera. New images are added by
Voyager/MaximDL. When a new image is detected ATrack does a plate solve and measure both drift (difference
between last image and this image) and shift (difference between a reference position or image and this image).
The drift is then used to adjust the tracking rate, the shift is used to temporarily change the motor speed for a
period of time to recenter the next image. Through an observing run of several hours ATrack will change the
tracking rate (RA, DEC) to minimize the drift rate and keep the image centered. It does this very accurately.
ATrack does not care what the cause of the drift, it simply measures it and readjusts the motor speeds to cancel it.
Through the night the changes are very small and consistent .. there is no wild jumps. It is also very repeatable,
from night to night. No matter what the temperature is .. a warm summer night or a cold winter night .. the tracking
corrections are always the same.

Now, if I turn off tracking correction on ATrack and turn on tracking correction in APCC then the stars drift away
very quickly .. pixels per minute .. about 1 arc sec a minute. This happens whether I use a 25 point model or a 200
point model. When I compare the correction rates in APCC with ATrack I see the same difference no matter
where I am pointed. East side or West side. The mount is always tracking in RA too fast and has to be slowed
down. This is consistent with ATrack which always shows the mount tracking too fast and it uses correction
values that are negative .. in other words, it tries to slow down the sidereal tracking rate.

The fact that DEC is similar would seem to indicate there is a base constant in the motor speeds that is incorrect.
DEC is always a positive number in the range 0.02000 to 0.01200 arcsec/sec and is the same in both East and
West sides.

Craig

Craig,

So Atrack is essentially an autoguiding program. It's been done before in many different ways. Closed loop guiding is usually more accurate, so nothing new here. Wait for machine learning though and you will see improvements without closed loop responses.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

Ray,
No problem, let me know if you want to discuss further offline.

But as I said above, it is not really necessary because ATrack provides excellent tracking with whatever condition the scope/mount are in.  APCC tracking is not that robust, it blindly sets the tracking rate, based on a model, with no feedback.  Given any factors not accounted for accurately in the model you should not expect a perfect tracking solution.  Both ATrack and autoguiders use feedback to correct tracking rates.  So rather than try to research the source of the tracking error it is a lot simpler to let ATrack or an autoguider correct for it and not use a tracking model.

On the other hand, if you are working on improvements to an unguided solution and need a test site I would be glad to help.  ATrack is both a correction tool but also an analysis tool.  Because it gives you the exact tracking rates required for unguided imaging, you can compare the values with a modeled approach and see where the problems are.  The goal of the model should be to provide tracking as good as ATrack or an autoguider.  The problem with an autoguider is it doesn't tell you what the tracking rates should be .. ATrack provides that.

But hopefully a model solution will be coming, and from what I have heard over the last year, it might be coming from AP.  Looking forward to it.

Craig

On the other hand, if you are working on improvements to an unguided solution and need a test site I would be
glad to help. ATrack is both a correction tool but also an analysis tool. Because it gives you the exact tracking
rates required for unguided imaging, you can compare the values with a modeled approach and see where the
problems are. The goal of the model should be to provide tracking as good as ATrack or an autoguider.

But why? Using APCC Pro's modeling I have had no problem doing 20-30 minute images unguided at 1.74 arc-sec/pixel with round stars. I've posted maybe about a dozen here before. A number of users have also done unguided images.

Some scopes need closed loop guiding because they are hard to model. I think yours is one of them.

Even the concept of using drift to set the tracking rate was done long ago. My own PulseGuide did something similar over 15 years ago. You would center a star, start a timer and let the star drift. The user would re-center the star and click another button andPulseguide would set the tracking rate in both declination and right ascension. It could be used for any object too, like comets.

And what might be even more crazy is that PulseGuide could do this *before* custom tracking rates could be set in the AP control boxes. It did this by sending evenly spaced, well-timed guider pulses, thus its name, "PulseGuide". You can still download it from here: https://www.pulseguide.com.

And it's not like I don't have experience with lots of telescopes, from refractors, SCTs, MakCass's, Newts, RC's, etc. I've experience with scopes with serious flexure issues that can make dramatic changes in focus as temperature swings, like my old18-inch Newt on a 1200GTO circa 2003 (and a younger me! :-)

https://raygralak.smugmug.com/Astronomy/18-CPT/

For now, APCC hasn't been able to do miracles with your particular truss tube scope so it's necessary for you to do closed loop autoguiding. For people with solid, repeatably pointing scopes APCC Pro's tracking rate correction already sets the tracking rate well enough to do unguided imaging, and even to dither without having to do plate solves. :-)

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Tuesday, May 5, 2020 7:49 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Adjust CP4 Clock Frequency

Ray,
No problem, let me know if you want to discuss further offline.

But as I said above, it is not really necessary because ATrack provides excellent tracking with whatever condition
the scope/mount are in. APCC tracking is not that robust, it blindly sets the tracking rate, based on a model, with
no feedback. Given any factors not accounted for accurately in the model you should not expect a perfect
tracking solution. Both ATrack and autoguiders use feedback to correct tracking rates. So rather than try to
research the source of the tracking error it is a lot simpler to let ATrack or an autoguider correct for it and not use
a tracking model.

On the other hand, if you are working on improvements to an unguided solution and need a test site I would be
glad to help. ATrack is both a correction tool but also an analysis tool. Because it gives you the exact tracking
rates required for unguided imaging, you can compare the values with a modeled approach and see where the
problems are. The goal of the model should be to provide tracking as good as ATrack or an autoguider. The
problem with an autoguider is it doesn't tell you what the tracking rates should be .. ATrack provides that.

But hopefully a model solution will be coming, and from what I have heard over the last year, it might be coming
from AP. Looking forward to it.

Craig

Ray,
So if I understand correctly, using your scope, unguided, and with APCC corrective tracking, you can plate solve your first image, three hours later plate solve your last image and the difference in plate solutions is less than 1 arc-sec?

Craig

Hi Craig,

So if I understand correctly, using your scope, unguided, and with APCC corrective tracking, you can plate solve
your first image, three hours later plate solve your last image and the difference in plate solutions is less than 1
arc-sec?

No, I'm not saying that at all, although I'm sure under some conditions that would be possible.

What I'm saying is most people would not want to do that. Most want to randomly dither the telescope position between images to average out differences in pixel sensitivity and noise when stacking images. Dithering obviously will change the image center between images. And cases where low pixel resolution (e.g. camera lens) dithering can be used to increase effective detail in an image.

So acceptable unguided performance is needed only for the duration of the longest exposure. There's little advantage for tracking to be better than that, but it's great that you are able to do that via a closed loop process.

Anyway, hopefully you can try Roland's test so you can validate your mount's sidereal tracking rate.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Wednesday, May 6, 2020 7:02 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Adjust CP4 Clock Frequency

Ray,
So if I understand correctly, using your scope, unguided, and with APCC corrective tracking, you can plate solve
your first image, three hours later plate solve your last image and the difference in plate solutions is less than 1
arc-sec?

Craig

The ATrack design is very similar to DONUTS, introduced in 2013: https://www.jstor.org/stable/10.1086/670940?seq=1#metadata_info_tab_contents

For high precision photometry it is very important that the image remain centered on the same pixel over the cadence run of several hours.  Dithering is not used.  Given that there can be random drift corrections during the run, the accumulated error can move the target off a pixel, which is why careful re-centering is required in addition to drift correction.

I will find a more precise method for measuring the actual sidereal tracking rate of the mount instead of using a piece of tape, which is not precise enough to yield the metric needed to correct it.  I still don't see why reporting the pulse count from the encoder is proprietary.  I can see "what you do with the pulses in an algorithm" would be proprietary but I don't see why reporting the pulse count is proprietary.  I will find another way then.

Craig

The graph shows clearly that a small change in servo sidereal rate will result in a significant drift in RA, 10 arcsec over 700 seconds.

Last night ATrack showed an average drift in RA of -0.01500 arcsec/sec.  The drift range for RA on my system is always between -0.01200 and -0.02000 no matter what the temperature or where the scope is pointed.  It says the RA tracking rate is always too fast.  The range is most likely due to refraction, polar mis-alignment and other mechanical deviations.  But the underlying base (e.g., -0.01000) is constant.  Using an average of -0.01500 arcsec/sec means a drift rate of 10.5 arcsec over 700 seconds .. very similar to what you see in the graph above.

Even more important is when I use the APCC model correction it has a different value for the RA correction, BUT it tracks in parallel with ATrack correction.  Meaning, the two corrections are in parallel.  This would indicate a tracking error constant that APCC is not accounting for.  The likely reason is a 0.1% error in the servo sidereal rate.  But I would also agree it could be something else.  If the model is not accounting for actual mechanical changes in the mount then there will be a divergence over time between the APCC model tracking correction and ATrack tracking correction.

One thing I can try, ATrack has the ability to provide a "base" correction to the motors, this is to take into account a constant between the motors and the real time tracking.  On my next clear night I will set the base tracking rate and then turn APCC tracking correction back on.  In effect this will simulate changing the servo sidereal rate which is then modified with the model correction rate.  I should see a much improved tracking anywhere in the sky, depending of course on how accurate the model reflects actual sky conditions.  But it should be better than it is without the base correction.

Craig

Hi Christopher,
Take a look at the DONUTS article I posted above, ATrack, a software program I developed, follows closely what they did.  In other words, to maintain the very high tracking accuracy, ATrack does both drift correction AND re-centering.  After three or four images ATrack has corrected the drive rates to achieve tracking errors less than 1 arc-second per 60 second images.  But small errors in drift can add up and move the image away from center.  But re-centering done very carefully after each science frame (see DONUTS article) maintains an absolute centering over several hours, on my system, of about 0.2 arcsec for both RA and DEC.

My location is in New Zealand, and the seeing is about 2.5 arcseconds.  I use Pinpoint to provide very accurate plate solves which gives subpixel accuracy (after I fine tuned the plate solve parameters).  The OTA is a GSO 16" RC, and the optical train behind the mirror is a Moonlite NC and a SBIG 6303 camera and FW.  If this system was poorly designed then I would see some significant random jumps in the plate solves .. I do not.  So the system is very solid and predictable .. which is why ATrack works so well.

For example, last night I did four photometry runs: HA 0 to HA +3, HA -3 to 0, HA 0 to +3, HA -3 to 0.  In all four cases the ATrack drift rate corrections for RA and DEC were pretty much the same, so it didn't matter the DEC or the HA.  And in all four cases the difference from the last frame and the first frame was less than 0.5 arcsec.  This shows the stability of the entire system, including the mount, OTA and instrument optical train at the back of the mirror.  Temperatures went from +10C down to +3C by the end of the night.  And there was a full moon up which really didn't affect the imaging much due to the very small FOV and angular distance from the moon.  There was no significant cloud or fog in the sky to scatter the moon light.  So overall, a very successful night.

Craig

I am not absolutely certain the RA drift is due to an offset in the clock frequency, it is only a possibility among others.  But I do like the idea of measuring the clock using the method you described.  I have a couple of questions though,

a) does the clock share the same oscillator as used by the electronics responsible for sidereal rate?
b) is the clock on the CP4 updated from APCC and if so how do I disable that, and how frequent or when does APCC update the CP4 time?
c) I assume the clock time is maintained after I power down the mount.  Do I need to keep the mount powered on for the test?

I can then use SL# to record the time and then 24 hours later do the same thing.

One thing I noticed a couple of years ago is when I powered up the mount and slewed to a set DEC,HA did a plate solve that each subsequent trial (park, power off, power on, slew) resulted in an increasing error in the position.  It was as if the time base was drifting.  I have not tried this in a while so may schedule that for the next clear night.  But it may be that Ray fixed this in one of the APCC/firmware updates since then.

If the clock does indeed share the same oscillator as the sidereal electronics then this will tell us if the clock frequency is off a bit.

Craig