Date
1 - 20 of 49
Adjust CP4 Clock Frequency
|
Roland Christen
I believe if you raise your altitude axis, turn the altitude knob clockwise about 1/4 turn, you will see your RA drift diminish. You can then go from there to null it out.
Roland
-----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Thu, May 7, 2020 7:40 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency Roland,
I ran the clock test for 12 hours and there was no drift in the time. That would indicate the crystal oscillator is well within the accuracy required since a 0.1% drift would be 43 seconds in 12 hours. So the problem is elsewhere. The next test is the ones you requested, but I would recommend that we close this post since it was a question about the crystal oscillator, and we work offline to try and determine why the large discrepancy between the AP model and ATrack. If this is okay, go ahead and send me an email we can then exchange on. Craig |
|
|
|
Craig Young
Roland,
I ran the clock test for 12 hours and there was no drift in the time. That would indicate the crystal oscillator is well within the accuracy required since a 0.1% drift would be 43 seconds in 12 hours. So the problem is elsewhere. The next test is the ones you requested, but I would recommend that we close this post since it was a question about the crystal oscillator, and we work offline to try and determine why the large discrepancy between the AP model and ATrack. If this is okay, go ahead and send me an email we can then exchange on. Craig |
|
|
|
Craig Young
Roland, two tests were requested. The first one I think was to put tape on the mount to measure the RA drift after 24 hours. I believe this was done to check the sidereal rate. Assuming the sidereal rate is calculated correctly using the crystal oscillator then measuring the crystal oscillator will be more accurate than a piece of tape. So I will do this test first. If it shows the oscillator is accurate then it does not prove the sidereal rate is off, only the oscillator is good and we can continue from there.
The second test I believe you wanted was to measure the drift with the scope pointed straight up at the meridian and on both sides. Then a subsequent test at the horizon. I will do this test at the next clear night but as I mentioned, I cannot observe below HA -3 which I will do but not sure if it helps. Next clear night is set for Saturday end of this week. Craig |
|
|
|
Ray Gralak
Craig,
toggle quoted message
Show quoted text
You can connect to the mount via a browser and issue commands without APCC or the driver being connected at all. -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----- |
|
|
|
Ray Gralak
Steve,
Many AP clients doing photometry REQUIRE that kind of 1 arc-sec precision and it seems achievable with theFor photometry you could use APCC Pro's tracking rate correction and auto-guiding. This is better solution because auto-guiding will update mount position more imminently than waiting longer for an image to complete and be plate solved. The drawback of Craig's plate solve method is that it corrects after the tracking error has occurred. So, if a plate solve indicates a correction is required then Craig's software may have already gone outside 1-arcsec accuracy. Auto-guiding + APCC Pro tracking rate correction is definitely capable of sub arc-second tracking over many hours. And with a couple tweaks to the code APPC Pro's tracking rate could be constantly refined to match any residual tracking rate error calculated from snooping auto-guide pulses sent to APCC. But again, this is not the subject of this thread! -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----- |
|
|
|
Roland Christen
So you simply refuse to do the test I asked you for? Why?
Roland Christen
-----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Wed, May 6, 2020 7:39 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency Thanks Roland, that is a big help. So by checking the time we can check the crystal oscillator. And given the clock is not maintained during the power down state I will run the test with the mount always powered on. So it will initialize once and then be good after that. I believe there is a setting in the APCC configuration to refresh the CP4 time but I will wait for Ray to comment. Looks like this will be a good test.
Craig |
|
|
|
Craig Young
Thanks Roland, that is a big help. So by checking the time we can check the crystal oscillator. And given the clock is not maintained during the power down state I will run the test with the mount always powered on. So it will initialize once and then be good after that. I believe there is a setting in the APCC configuration to refresh the CP4 time but I will wait for Ray to comment. Looks like this will be a good test.
Craig |
|
|
|
thefamily90 Phillips
From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of uncarollo2 <chris1011@...> via groups.io <chris1011@...>
Sent: Wednesday, May 6, 2020 8:11:19 PM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Adjust CP4 Clock Frequency a) does the clock share the same oscillator as used by the electronics responsible for sidereal rate? a) There is only one precision oscillator in the CP that does all functions, including setting the sidereal rate.
b) I would have to ask Ray to answer that one
c) the clock time is not maintained when the power is removed. Clock time is set during initialization by the ASCOM driver or by APCC, or by the keypad clock or other external apps, depending on your setup.
The clock inside the CP servo can be updated at any time by external sources, but that has zero effect on the sidereal tracking rate. The sidereal rate is directly set from the precision oscillator.
Roland Christen
-----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Wed, May 6, 2020 6:50 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 |
|
|
|
Roland Christen
a) does the clock share the same oscillator as used by the electronics responsible for sidereal rate? a) There is only one precision oscillator in the CP that does all functions, including setting the sidereal rate.
b) I would have to ask Ray to answer that one
c) the clock time is not maintained when the power is removed. Clock time is set during initialization by the ASCOM driver or by APCC, or by the keypad clock or other external apps, depending on your setup.
The clock inside the CP servo can be updated at any time by external sources, but that has zero effect on the sidereal tracking rate. The sidereal rate is directly set from the precision oscillator.
Roland Christen
-----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Wed, May 6, 2020 6:50 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 |
|
|
|
Craig Young
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 |
|
|
|
Roland Christen
According to our servo engineer:
"The CP internal clock uses a crystal controlled oscillator with accuracy of 25ppm, or 0.0025% One way to test the oscillator is to read time of day, :SL#, and compare
to a wall clock or precision time with similar accuracy (not a computer clock), over a period of time".
:SL# can be entered in the terminal mode in APCC or directly using our Ethernet Terminal app.
Roland Christen
-----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Wed, May 6, 2020 5:40 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 |
|
|
|
Roland Christen
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. Yes of course it does because I artificially change that rate by 0.1%. The internal clock we use is accurate to a very high precision. It does not drift to 0.1%. Your assumptions are wrong.
Now, you did not take the data that I asked for, so I cannot make any determination of the accuracy of the mount. Would you care to try again when the sky is clear? Otherwise we are going in circles. When I get the numbers from you, for test 1, 2 and 3, I will ask you to do the next step and another set of tests.
Rolando
-----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Wed, May 6, 2020 5:40 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 |
|
|
|
Craig Young
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 |
|
|
|
Craig Young
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 |
|
|
|
Craig, where are you observing that seeing allows you to keep a 1 arcsecond accuracy on a single pixel for several hours? Here on Mauna Kea we frequently get sub-arcsecond seeing but we can't even keep the mighty Kecks to that standard of precision for hours at a time. The seeing, even at the summit of Mauna Kea, just simply doesn't allow it. I frequently (with my personal AP mounts) do photometric and millisecond GPS-timing measurements of stellar occultations and using nearby stars for photometric calibration of each FITS frame. My AP mounts don't have abs encoders and I don't even bother to autoguide. What kind of OTA are you using for your measurements? I see lots of gravitational sag in my cheaper APO refractors and compound OTA's. Especially in a 20" RCOS truss OTA that I use. At least the sag is predictable and is directly correlated to the OTA's orientation to gravity. On Wed, May 6, 2020, 11:32 AM Craig Young <craig.young.m8@...> wrote: 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 |
|
|
|
Roland Christen
Measured tracking rate over 600 seconds time period. Each 100 second segment used a precision lab encoder pulse count to determine the exact rate of axis rotation with respect to time. The result is an arc second error graph spanning 6 x 100 second pulse count segments. In the following 700 seconds I added a 0.1% offset error to the servo's sidereal rate so you can see what the effect is.
When the sidereal rate is chosen to drive the mount, the rate of axis rotation is quite accurate over long time periods, but that does not mean that the telescope optical axis will follow that rotation rate. I can easily get a differential rotation rate between two telescopes on the same mount so that if i guide with one scope, the other scope will not keep a star on center for any period of time. So which scope is following the axis rotation rate? The answer is unknown, because both can be flexing in opposite directions from the mount's axis of rotation. Add to that slight polar misalignment and atmospheric refraction effects and I can get easily errors of 5 arc seconds in a 5 minute tracking run.
If you had done the measurements that I asked for, i could continue with the direction needed to solve this for you. But you choose to keep asking for something that is not possible. If you count the encoder pulses, are you able to use a lab standard for the time interval? Computer timers are not accurate enough for meaningful results. We discovered that long ago when we first started to develop our encoder drives.
Your posts are misleading to other people who watch this user group. They are not accurate to what we actually produce and what our mounts actually do.
Roland Christen
 -----Original Message-----
From: Craig Young <craig.young.m8@...> To: main@ap-gto.groups.io Sent: Wed, May 6, 2020 4:32 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 |
|
|
|
Craig Young
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 |
|
|
|
Roland Christen
Craig's posts bring up significant points that are quite relevant and should be considered seriously. Which points did he bring up that are significant to you.? You realize that tracking to sub-arc sec levels is quite possible and has been possible for many years. In your opinion, what are we missing?
Roland
-----Original Message-----
From: Steven Steven <steven447@...> To: main@ap-gto.groups.io <main@ap-gto.groups.io> Sent: Wed, May 6, 2020 3:53 pm Subject: Re: [ap-gto] Adjust CP4 Clock Frequency
Ray,
Many AP clients doing photometry REQUIRE that kind of 1 arc-sec precision and it seems achievable with the right approach. A number of us would like to know more about how to achieve it. Dithering is not an option in photometry. Craig's posts bring up significant
points that are quite relevant and should be considered seriously.
Steve
From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <groups3@...>
Sent: Wednesday, 6 May 2020 10:50 AM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 > |
|
|
|
Steven
Ray,
Many AP clients doing photometry REQUIRE that kind of 1 arc-sec precision and it seems achievable with the right approach. A number of us would like to know more about how to achieve it. Dithering is not an option in photometry. Craig's posts bring up significant
points that are quite relevant and should be considered seriously.
Steve
From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <groups3@...>
Sent: Wednesday, 6 May 2020 10:50 AM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Adjust CP4 Clock Frequency 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 > |
|
|
|
Ray Gralak
Hi Craig,
So if I understand correctly, using your scope, unguided, and with APCC corrective tracking, you can plate solveNo, 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----- |
|
|