History
I have been interested in the use of Software Bisque's TPoint program on applied to the LX200 telescope for some time. I purchased the program in August of 1997. It is not an inexpensive accessory costing some $249. I expected it to magically turn my 12" LX200 into a telescope that would at least meet its specifications of GoTo accuracy of a few arc seconds. It did not do this for reasons that are complicated and not the fault of the TPoint program. I still have the program and plan to use it eventually when I get a telescope that will respond better to its application.
In October of 1997, there was a series of posts regarding this issue. Again in April of 1998 there was a brief series of posts which discussed the origins of the TPoint concept which was developed in England by Patrick Wallace for use on professional telescopes and the application of the program Software Bisque in the Windows environment. More recently, November 1998, there has been a very much larger series of posts which have been much more detailed but have reached no new conclusions that I can detect. The total number of posts has exceeded 50. I have in addition had several conversations with Bisque about the program and several posts from Patrick Wallace.
In Fall 0f 1997, I tested the program rather extensively with my LX200 12" scope which is polar mounted on a permanent pier and inside a roll off building. I found that the program worked to the extent that the telescope performed better with it than without it. I did not consider the performance adequate to establish control that could be relied on for a totally remote operation. Thus I have not used the program for about a year but plan to use it again in a new observatory setup which will be ready in Spring of 1999 and which will have a much more mechanically stable mount.
The following is a summary of how TPoint operates and why it was not completely satisfactory in my application to the LX200.
Basics of Operation and Trial Run of the TPoint Program
The basic concept of TPoint is fairly simple. This is not to imply that either designing the algorithms nor carrying it out in practice are simple matters. I feel that Bisque has done a very fine job of implementing the original program and of integrating it with their fine SKY planetarium program. The idea of the program is to measure the coordinates to which the telescope points when it is told to point to specific coordinates, to remember this information and make a map of the sky so that when the telescope is told to point to specific coordinates it will actually do so. This is done by making a small pointing correction each time a coordinate set is requested.
It works this way. The program is trained by telling the telescope to point to a set of stars, generally 40 to 50 are selected, then manually centering the stars and allowing the program to determine and remember how much position correction is required. This is done over the entire visible sky. The program then can be made to point the telescope in such a way as to take account of the fact that the telescope has to be slightly mispointed to have it go to the correct position.
In theory and fact this concept works. The major problem that one finds is that a mechanically unstable telescope or one that is very sensitive to loading will have a different mapping correction for each mechanical condition. The program can take care of this situation by remembering a different mapping for each major change in loading of the telescope. One can for example have a map for visual work, another for loading with a camera and guider telescope and still another for a guider and heavy piggy back camera and so forth. Problems arise when the mechanics of the telescope are weak or marginal in some way. That is, if the telescope does not repeat its GoTo position with repeatability. This is a very fundamental limitation with the particular LX200 telescope on which I tried to apply TPoint This telescope did not point reliably because it had significant flexibility and looseness in the bearings that did not appear to be repeatable or that changed from use to use. It was not determined if this was due to temperature changes, shifting of parts, inadequate bearings or whatever. It was clear that basic pointing accuracy was no better than 5 to 10 arc minutes at best and often as bad as 20 arc minutes from the desired location. The manufacturer claims 5 arc minutes with normal GOTO pointing operations. This accuracy was never approached with the original telescope. It has since been modified so that better results have been obtained. This issue is discussed later.
It was hoped that the pointing accuracy might be improved by as much as five to ten times. This was not the case. For a few limited trials, with light loads and visual equipment only, the pointing became as good as 2 to 5 arc minutes. This is quite adequate for visual work but falls short of what is necessary for imaging and remote control. It was determined only that the telescope was weak enough mechanically that it could not be improved as much as desired using TPoint This was not felt to be the fault of the TPoint program but a fundamental mechanical limitation of the telescope structure. When the telescope was heavily loaded with a separate guide scope and a heavy camera, the pointing results were much poorer.
In order to stabilize the mechanical performance, I was careful to keep the clutches locked so the gears were used over the same ranges and the load and balance were also kept as constant as possible. Cables were carefully routed to reduce strain on the OTA. The mirror was also locked in position. These measures helped but did not produce fully satisfactory results.
Discussion of These Results
After these experiments of Fall 1997, which went on for some weeks, brief discussions were had with the Bisques about this application of TPoint and some posts were exchanged with Mr. Wallace who is one of the principles in the development of the basic concepts behind TPoint They both seemed to agree that the program cannot make perfect a telescope that changes mechanically from time to time with little apparent reason such as mirror flop and that it cannot account for lash in the drives that is nonlinear. One of the major problems with the LX telescope that I used was the poor quality of the declination drive, lash in the drive and stickiness of the drives and bearings.
In the meantime, my 12" LX200 has been modified considerably. The declination bearings have been replaced and the drives have been tightened to remove most of the lash. The TPoint program will be tried again in the near future to see if the improved telescope mechanics will improve the performance of the system enough to make TPoint more effective.
Summery of Reports From Others Who Have Used TPoint on the LX200
This summary of reports from the posts on MAPUG-Astronomy essentially support the experiments and conclusions drawn above. But there have been some better and some worse results.
A series of no less that six posts on November 12, 1998 ran from one that said TPoint simply could not model an LX200 to one that said that TPoint worked fairly well. The words used were that the telescope pointed better with it than without it. Faint praise indeed, but at least an optimistic report. One report was that the telescope had fixed mechanical misalignment problems which might be the problem. Of course, it is just these problems that TPoint is supposed to and does fix.
On the next day, a nicely detailed report on a TPoint application came in. The report indicated that before applying TPoint a GOTO placed the desired object on a 5 by 8 arc minute chip only about 20 to 30% of the time. After applying TPoint this score improved to 40 to 50%. And, on another night the score improved to 68%. This is interesting data. But the mystery is that the 77 correction points fit in a circle of 1.7 arc minutes. Still only 70 % of the objects fell on the chip of size 5 by 8 arc minutes. It seems that with such a good PDF the objects should hit the chip every time.
There was some discussion of using TPoint with the LXD 650 and 750 mounts. It was not clear in these posts if TPoint helped much but pointing accuracy of about 10 arc minutes was mentioned for the mounts.
By the 16 November there was a flurry of posts about the LXD 650 and 750 mounts and several others. There was indication the repeatability was very good with these mounts though accuracy was still only about 10 arc minutes. If the repeatability was very good, then TPoint would be expected to correct the absolute pointing accuracy by a good amount. These reports, while short on data, are quite encouraging. There was some discussion of the lack of perfect orthogonality of the RA and DEC axes and flexing. Of course TPoint is designed to compensate for just exactly these mechanical defects. Again, if they are repeatable.
There was also some discussion of HPP which all LX200s have. In a way, HPP is a local mapping correction. It works by re-synchronizing the telescope for a small region of the sky. It is in no way a replacement for a full sky mapping such as that done by TPoint nor is it a mapping algorithm.
Several mounts with noted excellent stability were mentioned. These are:
It is interesting to note that most all of these are more than an entire 12" LX200. (which is now about $4400)
Summary
In summary, it is apparent that TPoint works but it cannot make a mechanically weak telescope into a perfect one. This was the conclusion in October 1997, April 1998 and again in November 1998. When the telescope is strong and mechanically sound, TPoint can do wonders to improve pointing accuracy.
I am looking forward to a more detailed set of comments from Patrick Wallace who has indicated that he will post to MAPUG-Astronomy in the near future. In the meantime here are his preliminary remarks from a November 13, 1998 post to the MAPUG-Astronomy group.
Continuing Topics and Advice
From Patrick Wallace:
I'm following the correspondence on TPoint and hope to be able to contribute something useful over the next couple of days. Here are a few preliminary remarks:
« As one subscriber said, you can't make a silk purse out of a sow's ear. The results can't be any better than the encoders and any hysteresis effects (for example mirror slop). What TPoint will do is get the best out of whatever telescope you've got.
« Poor results are often because something untoward happened during the test run - something shifted, or it was necessary to resync for example. The best you can do with such a test is to chop out the good bit and just use that.
« You should only use enough terms to match the quality of the data and the size of the run. Including more and more terms, especially powerful harmonics and polynomials, will reduce the RMS but make the model worse. If there's trouble, cut right back to the 6 geometric terms (IH ID NP CH ME MA for an equatorial) and look at the residuals for signs of two populations etc.
« When you've changed your setup, fix those terms which ought not to have changed and only fit the ones that are likely to be different. For example, if you've got a fixed mounting and no big changes of weight, fit only IH ID and CH. All the other terms in the model, such as the polar axis terms ME and MA and any flexure or runout terms, should be included but fixed at the values you got from a previous full-scale test. That way, the start of night procedure needs only to be 3-5 stars typically, to absorb the resynced zero points and any collimation changes.
« If your model is sensible (not too many terms) and you don't seem to get as good a result in practice as the PSD figure claims, suspect the implementation of the model in the telescope control system. There's an easy way to test this - do a "dummy pointing run". Do a normal TPoint run, but leave the telescope where it is each time: don't recenter the image. When you reduce the run, you should get a small PSD (as limited by the encoder resolution) and all the coefficients should come out to whatever you told your control system to use.
More in due course.
Patrick Wallace