Date
1 - 6 of 6
AP 1200 and Tpoint
Barbara Harris <barbharris1@...>
Since I have a permanent setup I decided to use T point to do some
mapping and improve my pointing. I did mapping rung for the entire sky. I got pretty good pointing accuracy on one side of the mount (within 10 arcsecs) but when I would go to the other side of the meridian the pointing accuracy would be several arcmins off the target. I have been communicating with Patrick Wallace (the person who wrote the T point program) and he used my model to try to make a model that would have accurate pointing on both sides of the mount. His model improved the pointing but I still had targets that were almost on the crosshairs on one side of the meridian but would still be off when crossing the meridian. Is this behavior that everyone else is experiencing with Tpoint? Also, if I park and then start up the next night, even though my time is set very accurately, my pointing is off when I slew to a star compared to how accurate the pointing was the night before. I have also just trie powering the mount down without parking and starting up from that poisition but still the pointing is several arc mins off. I am using the no beta ver of the keypad. I will also post there.
|
|
jiprovi
I had a similar problem using TPoint with my AP1200. In my case it
toggle quoted messageShow quoted text
turned out that I was using the ASCOM AP driver in the Sky6 and it was not effective in working with TPoint. When I turned to using the AP driver built into Sky6, I saw dramatic improvements in pointing accuracy when using TPoint. In fact my pointing errors across the sky went down from many minutes to less than 15 arcsec (crossing meridian) James
--- In ap-gto@..., "Barbara Harris" <barbharris1@...> wrote:
|
|
mogulskier_groups
I few questions...
1) exactly how far off is it? 2) is it the same displacement no matter where you are on the other side of the meridian? 3) When you go back to the good side of the meridian, are you still pointing well? 4) Here is an important one - what method did you use to align? 5) I had similar problems. I lived with it for months. Finally, I broke down and shimmed one end of my parallax rings with 4 thin pieces of soda can and now I have no more pointing problems, with or without a pointing corrector. 6) Which rings/mounting are you using? Does TPoint analysis describe what is wrong? How much flexure is it reporting? My thinking on my system was that, during a drift align, I could get it smack on for a good hour long drift. However, if I went to another part of the sky, it wasn't right. I'm not sure of the math on this and I'm absolutely sure that someone will argue this point, but my theory was that the mis-orthogonality was skewing my alignment, this my pointing and tracking was messed up elsewhere in the sky. If you havn't already, I'd start looking at: 1) Orthogonality, since this is a one-time fix 2) Flexure - this plagues many owners of high-end mounts 3) Alignment - be sure that the "mount" is aligned, no matter what the scope is telling you. I suggest turning off TPoint pointing correction until you get these 3 resolved. Good luck Dave 2) Alignment --- In ap-gto@..., "Barbara Harris" <barbharris1@...> wrote: a model that would have accurate pointing on both sides of themount. His model improved the pointing but I still had targets that werestill be off when crossing the meridian. Is this behavior that everyone
|
|
Dr. David Toth
At 12:36 AM 10/8/2006, mogulskier_groups wrote:
If you havn't already, I'd start looking at:Dave: the whole point of using TPoint is that it fixes repeatable error. It will guide you in getting polar aligned, and will compensate for non-orthogonality, etc. There is no reason to "turn it off". Dave
|
|
observe_m13
Yes, but in this case there is NON-repeatable error on top of the
toggle quoted messageShow quoted text
uncorrected repeatable error. This is the crux of the problem. So, one has to discover the source of the non-repeatable error and the best way to do that in my opinion is to bite the bullet and manually get rid of the repeatable errors first. Then one can try and figure out what is really going wrong and the source of the non-repeatable errors. This may not be the easiest method to use, nor is it the only method to use, but it sure works a heck of a lot better than the shotgun or guess and by golly approach in my mind.
--- In ap-gto@..., "David B. Toth" <ve3gyq@...> wrote:
|
|
Dr. David Toth
At 03:50 PM 10/8/2006, Rick K wrote:
Yes, but in this case there is NON-repeatable error on top of theWell, since non-orthogonality is corrected by TPoint you can skip that. Likewise, repeatable errors need not be corrected mechanically since TPoint will model them out. You are under-estimating the difficulty in correcting non-orthogonality, etc. More power to you if you enjoy doing that though. You need to look for loose parts that are shifting, things that flop, like mirrors or lenses loose in their cells, and if portable, assure that the pier is not shifting. Dave
|
|