Creating a TPoint Model

[roughy]

If you are intending to use two scopes on a mount with TPoint, whether piggybacked, side by side or interchanged, is it necessary to create a model for each or just one for the longer focal length?

There is quite a difference in FL, 770mm and 1600mm. Neither scope will be used to guide and they would not be imaging simultaneously.

Mark

[PRejto]

I'm probably not qualified to answer this because I've never tried. But, I can say that it is recommended that even changing the camera rotation a bit, or removing the scope and just putting it back in the same position can corrupt a T-Point model enough to require a re-synch into the model, or a new T-Point model. It's hard to imagine a SBS arrangement where flex issues due to the focuser, or mirror, or mounting wouldn't be different enough on each side to require different models especially considering the degree of accuracy obtainable. Maybe a model would be usable for both scopes if a high degree of accuracy is not required. I guess one scope would be very accurate, and the other not so. Certainly use the longer focal length scope to get the model...

Furthermore, I think there is a current related post in the imaging equip forum where a user has an SBS system and is unable to guide both scopes simultaneously. If I understand the reasons why this fails it isn't just difference in flex, but also the fact that both scopes may not be exactly parallel to the RA axis, and the fact that both scopes do not have the same radius during rotation around RA. I guess those latter two facts might also influence pointing accuracy.

Try it and tell us what happens!

Peter

[CDKPhil]

Hi Mark,
I would make a model for each scope. The scopes will be aligned slightly different, they will have different flexure issues etc. All you would need to do is load the appropriate model for what ever OTA you were using.


Cheers

Phil

[roughy]

Thanks Gents. I've perused the suggested thread and it appears that the best philosophy is to "keep it simple stupid."
The most convenient way is to just have a model for each OTA and interchange them as required. Onlt a five minute job to vchange them over anyway.

[frolinmod]

The act of changing OTAs has major implications for your Tpoint model. You might be able to get away with a saved model and a sync. I doubt you can do it exactly the same way every single time to the most minute detail, so a saved Tpoint model probably won't be as useful as a fresh one. If not, then maybe the sync with a short re-calibration run off the saved model as the base might be good enough. I myself have never had much success with re-calibration runs. They never give me results anywhere near as good as a fresh full calibration run and don't save me that much time either. So I just sync for minor changes and when the change is more than minor, I bite the bullet and do a full calibration. If anyone here is having great success with doing a short re-calibration run to an existing model instead of full calibration to create a new model, please pipe up!

[rogerg]

I think you are talking about switching out one OTA for the other (a physical change to the setup) where as the original poster is talking about having two OTA's permanently mounted at the one time. I could have interpreted wrong.

Two models sounds legit but is beyond what I'd do, I just use the one model. I build the model for the long FL scope (2900mm) and the short FL scope (600mm) is sufficiently short (perhaps) and sufficiently rigid that I don't notice any problems with using the short FL scope from time to time. Pointing appears accurate and unguided exposures still track well in both scopes.

Roger.

[gary]

Hi Mark,

If you are going to the trouble of creating a TPoint model, then that means you
are interested in refining your whole-sky pointing performance, in which case,
those that responded to you with the suggestion that you would require two models
are absolutely correct.

Technically more specific, some pointing terms are a function of the optical axis
of the scope. A classic example of this is CH, which is a measure of the amount
of non-orthogonality between the optical and Dec axes. CH can even change from
session to session should you do something as simple as re-attaching a camera.

[Terry B]

I have 2 scopes side by side but only use the one pionting model. Whilst there might be a very small difference between the models, I don't see how it matters much. I point my scopes using the smaller scope and it's T point model. This will place my target pretty close to the centre of a frame anywhere in the sky. I have my spectrograph on the larger scope (C11) and the target slit always corresponds to just above the image centre of the camera on the smaller scope. This is perfectly adequate.
Doing a T point model takes at least an hour for 60 points. Why would I waste more time on this than needed?

[Paul Haese]

I have two scope mounted piggy back style. I was using a Tpoint model for my TSA OTA to point with the gso 12, but found it was too inaccurate. I have done a subsequent run with the gso 12 and that model is pretty good for the TSA. I think the longer focal length makes for a more accurate model. Just some minor jiggling to center the object in the TSA. However, two models would be best.

[Terry B]

Paul
I can't see how the focal length should make any difference. If you are taking an image and plate solving it to sync to then the accuracy of this should be to sub arcsec regardless of the focal length (unless the images are very wide like from a camera lens).
There must be another reason for the difference on T point models.

Terry

[gary]

Since the mathematics are rigorous, that is, they work both in theory and in
practice, it means that some of the terms in the model that you obtained from
the long sampling run should not be held fixed for the short sampling run.

For a fixed observatory, you will need to re-compute at least ID and IH and should
possibly consider CH as well if you have changed anything, such as re-attaching
a camera or rotating it in the holder.

A converse way of saying this is that something in your setup is likely to have
changed between sessions or you have an unsystematic random error somewhere.
A sudden mirror flop is a good example of an unsystematic error and no pointing
analysis system can model a random error.

If you do multiple long sampling runs of approximately the same number of stars distributed
across the entire sky and compare the magnitude and sign of each of the terms along with
their associated standard deviations, with the exception of ID and IH, they should all be very nearly the
same.

Few things throw out a pointing model more than a single outlier. Automated sampling can easily
misidentify a star particularly if not guided by an existing reasonable model.

[frolinmod]

Gary, if that is a direct quote from Patrick Wallace, then it should be given an attribution as such, don't you think?

[gary]

Hi Ernie,

That is a direct quote from Gary Kopff, so you should weight any advice it may
contain accordingly.

With regards to TPOINT, you should always defer to its author, Pat Wallace,
who is the utmost authority on the subject of telescope pointing in general.

However, I know TPOINT works as we used it in regression testing during the
development of our own pointing analysis system and pointing kernel, TPAS,
for the Argo Navis Digital Telescope Computer.

In a professional engineering capacity, I had thought about pointing analysis
on and off, firstly as a geometric problem and later as a mathematical problem,
initially over a seven year period.

It is a non-trivial problem.

Sometimes the problem would come to the foreground of my attention and I would
write notes that I accumulated in a dedicated ring binder folder.

Once the folder became full, I was confident enough to implement a solution, which
took approximately a futher full year to code and test and consumed all of my working
hours and many of what should have been my sleeping hours as well.

Sometimes we would code all day, drive to a dark sky site in the afternoon,
test until dawn, drive back and repeat the process the following day.

The resultant text portion of the TPAS code was a significant fraction of the
entire Argo Navis software, nearly as large as all the other code we had written
combined.

One significant milestone was when TPAS began to provide results which
were in close agreement with other analysis systems, such as TPOINT.

As an example, below are the analyses made by TPOINT on the left and
TPAS on the right of pointing data consisting of 39 observations for the
Hale 200-inch Palomar telescope.


TPOINT ANALYSIS ARGO NAVIS TPAS
coeff value sigma value sigma

1 CH +45.82" +- 3.357 +45.77" +- 3.347
2 ID -128.41" +- 1.383 -128.38" +- 1.379
3 HCEC -7.28" +- 4.344 -7.27" +- 4.332
4 HCES +18.49" +- 1.606 +18.48" +- 1.601
5 IH -87.55" +- 4.749 -87.50" +- 4.736
6 NP -2.01" +- 2.101 -1.99" +- 2.095
7 MA -3.58" +- 1.020 -3.58" +- 1.017
8 ME +64.99" +- 1.587 +64.94" +- 1.583

Sky RMS = 3.81" Sky RMS = 3.80"
Popn SD = 4.27" Popn SD = 4.26"



The results are pretty nearly, as would be expected.

Through both field testing and through in-house simulation, we are extremely
confident of the analysis and pointing corrections the Argo Navis TPAS
system provides.

Through comparing our test results against TPOINT, we are therefore
also extremely confident that the analysis TPOINT provides is valid as well.

Many thousands of Argo Navis units are deployed around the world and we
have a large customer base using TPAS as a routine part of their observing.
In my capacity of providing support for our customers and by way of
further ongoing development and testing, I have accumulated considerable
experience in the topic of pointing.

The specific advice I provided you in this instance is exactly the same advice I
would provide one of our own Argo Navis TPAS users. Hopefully it proves helpful.

Best Regards

Gary Kopff
Managing Director
Wildcard Innovations Pty. Ltd.
20 Kilmory Place, Mount Kuring-Gai
NSW. 2080. Australia
Phone +61-2-9457-9049
Fax +61-2-9457-9593
sales@wildcard-innovations.com.au
http://www.wildcard-innovations.com.au


Footnote:
The use of the Argo Navis TPAS system is detailed in the Argo Navis User's Manual pp 115-142, under the section SETUP MNT ERRORS.
http://www.wildcard-innovations.com.au/downloads/documentation/argoman10.pdf

[Paul Haese]

Yes that makes sense. Clearly I have some orthagonality issues going on. Thanks for pointing that out.

[frolinmod]

Thank you Gary. My brain is turning to mush these days.