ProTrack®

Updated: 11/08/2004

 

Start-up

To get the ProTrack kernel engaged, hit Control-K while in TheSky. You will be presented with a status window as shown.  There are two boxes that must be checked in order to get it going. Thanks to Steve Mandel for pointing this out as it is not documented anywhere.  With the version of TheSky that came with the ME (5.00.017), I found that ProTrack had to be stopped and restarted after a slew, if accurate proper tracking was to be achieved.  This may not be required in later versions of TheSky.

 

 

 

 

 

 

 

 

 

Performance

A 110-point Tpoint model was developed and a pointing accuracy (PSD) of 10.9 arc-sec. was achieved with the following parameters:

 

IH : = +285.21
ID : = +82.38
NP : = -219.83
CH : = -62.68
ME : = -75.68
MA : = -11.81
TF : = +40.39
TX : = -98.41
HHCH1 : = -200.17
HDSD4 : = -14.59
HHSH4 : = -30.27
HDCD3 : = -14.62
HHSH3 : = +16.18
HDCD1 : = +15.83
 

 

With ProTrack engaged, unguided exposures of M13 were taken at 5, 10 and 15 minutes. After the 15-minute exposure, another 5-minute exposure was taken as a check. During the exposure, M13 was between 85° and 77° in altitude. For all exposures, star elongation, as measured in AIP4WIN never exceed 3%! Here are some cropped images of the exposures.

 

         

5 minutes                                        10 minutes

 

         

15 minutes                                        20 minutes

At a 20 minute unguided exposure (!) elongation reached around 12%. ProTrack seems to make a significant difference. However, the increase in elongation from a 15 to a 20-minute exposure seemed a bit abrupt.  It was too late to pick up a 15-minute exposure with ProTrack disengaged, but I will try to get a comparison in the future.

In examining both images, it is clear that there are two specific regions of tracking. The first, region is from near the meridian to approximately 65 degrees and the second, is from 65 degrees on down. Speculating, it almost looks like ProTrack “lets go” of corrections after an error of 20 arc-seconds. The different in slopes changes from 0.18 arc-sec./minute to .56 arc-sec./minute. This may be an anomaly of OTA performance or may be the due to the slight change in altitude between the start and the end of the run.

I decided to assess long term tracking by selecting a star on the west near the meridian.  A short exposure of 1 or 2 seconds was taken every 20 minutes for 4 hours.  This tracks a star down to 35-40° of altitude.  The individual frames are combined.  If the tracking was perfect, there would be only one star in the combined image.  Also, the centroid position of the star in each frame was calculated and a centroid error was measured from the first exposure.  Again, if the tracking were perfect, the centroid error would be zero and the plot of centroid error vs. altitude would be a horizontal line at an error value of 0.  The FITS time stamp was used in concert with TheSky for a given star to determine its altitude at the specified time.  The centroid error was plotted against altitude.  What follows is some data taken over a long period of time.

My optical system consists of an RC with an FSQ-106 refractor mounted on top.  Differential flexure should be minimized, since the FSQ has clamping rings mounted to a Losmandy dovetail plate that is hard mounted to the RC mounting rings.

 

1. OTA comparison

For the first test, individual 100-point Tpoint models were developed with the camera on the the RC and a star was tracked for 4 hours.  This test was repeated with the camera mounted on the FSQ, another 100-point Tpoint model was developed and a star was again tracked for four hours.  Here is the resultant data:


RC Star Track (North up)



FSQ Star Track (North up)

In both cases, the apparent motion of the star as it was tracked was to the east.

ProTrack apparently compensates out any OTA boresight shift.  When I first began investigating the RC boresight shift back in April, the initial centroid error over 50 degrees or so was around 160 arc-sec.  Working with the vendor, many adjustments were made to the mirror mountings and other boresight factors.  When I did the first ProTrack run with the RC and saw the 80 arc-sec. error, I assumed this was residual boresight shift that the adjustments could not take out.  However, after developing a Tpoint model for the FSQ, the curve of its centroid error is remarkably similar to that of the RC. Since the probability of this much shift on the robustly constructed FSQ-106 is very small, I believe other sources need to be considered. Some candidates are:

Pier movement – I am using an elevating pier manufactured by Pier-Tech. Pushing on the pier in many directions with an estimated 10 pounds of force while centered on a star showed a movement of under 30 arc-sec. Since the mount load is very closely balanced, I can’t see how a resolution of load forces of this magnitude can be developed while tracking a star.
 
Mount tracking – There is some kind of cumulative error as a star is tracked over a long period. I can’t see how this can happen but I’ll leave it on the list for completeness.
 
Refraction – atmospheric refraction is not being properly modeled in the ProTrack kernel. The approximate 60 arc-sec. error at 45° looks suspiciously like the calculated 58.1 arc-sec. for that elevation. (I need better heads than mine to evaluate this possibility.)

Atmospheric refraction as a function of elevation follows a relationship equal to 58.1/tan(altitude).  Adding this function into the above plot gives a curve that looks suspiciously like the error is due to a failure to compensate for atmospheric refraction.  Coincidence?

2. ProTrack disengaged

Another star was tracked with ProTrack disengaged and compared to the above data (RC only).

         

The left curve indicates ProTrack is certainly making an improvement in the overall tracking error.  The right curve is a repeat of the data from test 1 with the atmospheric refraction term laid in.  In both cases, the residual error continues to be similar to atmospheric refraction.

3. TheSky version comparison

After seeing what appears to be a continuous error on the order of atmospheric refraction, I inquired what version of TheSky was recommended, given that version 5.00.017 came on the ME CD-ROM and yet there was a 5.00.028 beta on the Bisque web site. Two ME users responded that they were using .028. I decided to load .028 and run a bigger Tpoint model. In the past, I had run the Tpoint model using automap scripts, or Ron Wodaski’s Automapper program, using a 3x3 bin on my ST-8E, which gives a plate scale of 3 arc-sec./pixel. I decided to use 2x2 binning. This gave a much higher hit ratio for the Automapper – around 60% - and a little more precision. The Tpoint model had 183 points with the last three masked.  Again a star test was run with this result.

Even with different Tpoint models and different versions of TheSky, the curves are basically similar. Version .028 seems to provide a little better tracking, unless peak-to-peak error is considered. It should be noted that the method of calculating centroid error as the root-sum-square of the centroid relative to the starting position is sign insensitive. As such the reversal that is obvious in the star track image should send the error negative for the first 6 points or so. Heretofore with version .017, the centroid error was monotonic. I would need and welcome some input from the Bisque software community as to what changed between .017 and .028. Was the atmospheric refraction implementation changed in .028?

Some additional testing and conversation with Rob leads me to discount any contribution from the elevating pier. We agreed that if it is always in the down position, it should not be an issue.

4. Atmospheric Pressure

I am now using TheSky version 5.00.028.  Mike Rice and Patrick Wallace strongly recommended an input for atmospheric pressure be added to the Tpoint data as an important contribution since my elevation is 2900 feet above sea level  , I added a nominal value for atmospheric pressure to the Tpoint model of 916 mB as suggested by Patrick. The resultant track and centroid error is compared against that from 6/11/2002, above. Unfortunately, my run was truncated by clouds.  The data did go through a sign change around 62° so data between 85° and 62° should be considered inverted, if peak-to-peak values are desired. While there seems to be some change in the characteristic of the centroid error plot, changing the atmospheric pressure doesn’t seem to be the major contributor. It may be that my elevation of 893 meters is not far enough from sea level to have the same kind of dramatic impact as Mike sees in New Mexico.  Nevertheless, it does seem to have an impact and should be entered.
 

 


 

5. Drift Rate

I did some quick observations of the ProTrack status window at the nominal declination (30°) of the star that was tracked, above.  Given the similarity of the shape with the star tracking centroid error, I suspect this is as good a metric to assess centroid error as my time-consuming star plot. Doesn’t this also indicate there is a model problem, since ProTrack is predictive and the drift rate is a ProTrack prediction of what is needed to keep the mount properly pointed? Incidentally, drift rate seems to be a good predictor of the length of exposure that can be expected for a given orientation. While this is kind of obvious when you think about it, it does make sense. For example, near the meridian, 15 minute exposures were possible; but at 60° altitude, 3-minute exposures are the limit.  Repeating, the model was obtained by using a CCD camera and the automap function. Initial models were obtained using the automap.vbs; however, since Ron Wodaski’s automapper program became available, I have been using that. I have used a minimum of 100 points over most of the sky, down to an altitude of 35°.
 
It appears, unless I am missing something obvious (very possible) that either ProTrack is not responding to the model properly or the method of acquiring the model is flawed. I guess the basic question is: Why does ProTrack have varying drift rates at various parts of the sky?

 

Summary and conclusions

Software Bisque acknowledged this tracking problem on June 19 as an issue that needs to be investigated. I have been informed that the issue is still under investigation.  The results on this page have been duplicated by another ME owner.  There appears to be an issue in the tracking kernel that needs correction.  Once one is released, I will evaluate it using the same methods described in this report and add the results to this page.

1/2/2003 Update:

Knowing how busy the Bisque guys are, I decided to test the ProTrack tracking accuracy just in case a change was made quietly.  I used the same test methodology as described above to track SAO58164 from an altitude of 87° to 37° with a 1 second exposure every 20 minutes.  I engaged the ProTrack Kernel on TheSky version 5.00.040.  Earlier in the evening, I had developed a 65-point Tpoint model, which yielded an RMS pointing accuracy of 16.7 arc-sec. with 10 terms in use.  The model indicated I was within 8 arc-sec. of the true (not refracted) pole.  Here is the results of that data:

Combined image

Note: This image is at the same pixel scale as those above.  This is a significant improvement.

 RMS Error

                                    


Note the dramatic 4:1 reduction in tracking error over a 60° change in altitude!  The RMS error is relative to the 87° starting point.  To further illustrate this result, here is another look at the same data:

In this plot, the average centroid of the star is calculated and the deviation from the centroid is plotted for each altitude point.  The peak-to-peak difference is around 10 arc-seconds.  For reference, the topmost point corresponds to 87° and goes CCW to 37°.  This is an open-loop, unguided result!  I should mention that my environmental conditions were not precisely entered, such as atmospheric pressure.  All I did was run an automapped T-point model, point to the star and set the exposures going.

I should also point out that this was done with a different 10" RC, a prototype open truss from RC Optical Systems at an image scale of .83 arc-sec./pixel.  Centroid calculations were done in Mira.

This is an impressive preliminary result!  Either Software Bisque slipstreamed the fix in one of the beta releases of TheSky or the happenstance of pointing at the true pole made the result more accurate.  I intend to do some more testing in the future, time permitting.  But at this point, ProTrack looks like a winner!

1/3/2003 Update: I repeated the entire above test again last night.  Sync, 65-point Tpoint run, 1 second exposures of SAO78143 were taken every 20 minutes as the star moved from 85° to 35°.  Here is the average position plot:

Note that the results are very similar to the previous evening's.  Somehow or another, a very substantial improvement has occurred! 

11/4/2004 update:  Since January 2004, I have been using unguided imaging at an image scale of 0.58 arc-sec./pixel with excellent results.  This corresponds to a focal length of approximately 2418 mm or 95 inches.  Typical exposures are 3 - 4 minutes.  I have had sufficiently round stars and resolution was quite acceptable as exemplified by recent images of Stephans' Quintet and NGC7331, the Deer Lick Group.  For me, the keys were as follows:

bullet

A sufficiently deep Tpoint model of over 300 points.  These were acquired with the Automapper II, a now free program, courtesy of Software Bisque.  Terms were carefully chosen to represent first the mount mechanics and secondarily, additional terms while keeping a close eye on the value to sigma ratio to make sure terms with that ratio less than 4 were not used.
 

bullet

A good periodic error correction taken on a night of very good seeing.  My overall periodic error after correction is 1.2 arc-sec. peak-to-peak.
 

bullet

Exposures that are as short as possible, consistent with my desired readout noise contribution to overall noise.  At my image scale, I use 3 minutes exposures for Luminance and/or Clear filtered data binned 1x1 and RGB data binned 2x2.  This was determined in accordance with the techniques described here.  A calculator based on these techniques is here.