I stand corrected ... I thought others had said (in the past) that if you powered off in a position that was not previously set (like park) that there could be ambiguity. Thanks, Dave

For your personal use, you can use whatever you want to control a telescope. For example, you could connect with pcAnywhere remotely. To run a paramount, you need to run TheSky6 by default. Where the

Bob: I'd add that it'd be a good idea to run the mount on a UPS - if you LOSE power, and don't have a way to home the mount, then it would be lost. The UPS might obviate that. The advantage of the ME

I think that you may have missed some of the features of TheSky6 and some of the other Windows-based planetarium programs. The databases in KStars seem rather limited in comparison, as least from what

This isn't quite correct. Both programs can calibrate/guide irrespective of the camera angle. If you change the angle, you simply recalibrate. Dave

<much deleted> No it doesn't Bob. To create a TPoint model, you want to get a set of points evenly distributed across the sky - or less of an area if you do not plan to image across the whole sky. Gat

I think it is pretty self-evident. Fork flexure does not apply, because a GEM is not a fork mount. The terms that say: Apply to AAT only don't apply, because they apply only to the Anglo-Australian Te

What I am saying is that it does not make sense to use ACP to acquire points for TPoint. Dave

This is not correct. Yves, I'm not sure that you understand what TPoint does with a point, when used with something like Automapper II. You take a list of Alt-Az points spread out over the sky, in as

Gary: this is exactly what I am not going to do .... I am not going to get into an argument about any of this. I am not questioning anything about methodology. What I AM saying is that there is ABSOLU

Ray, not to be confrontational on this, but you apparently have not read enough about TPoint ... the above statement is absolutely not correct. Again, I think there is a bias clouding the analysis, if

You are welcome .... I don't use all of the various packages, but I am pleased with what I use ... I think people tend to get comfortable with what they are used to using, and how they use it. I never

Mark: there are various ways to improve mount pointing accuracy, and there are trade-offs in some. I think most of this has already been pointed out, but they may not be clear to you .... First, you s

From a statistical viewpoint, there really is no way that MaxPoint can improve pointing as well as TPoint, no matter what mount you use. MaxPoint uses only the first 6 "equatorial" terms used in TPoin

Jim: it would not matter. It is an individual command, not part of a string, and nothing follows it, so it isn't clear why inserting a delay after would help anyway. Dave

I know what you meant Ray, but the data is sent at a slow rate and is packetized, so it is surprising that we'd see this happening, and only on one mount and computer. In addition, we're not talking a

I wouldn't call 9600 baud blasting ... and Mark is the only one that reported a problem with his 1200 ...Marj reported that all was well ... We'll see if it happens more with faster processors. Dave

Just to supply some more info, Mark tells me that Daniel was able to help him by introducing a 100 msec delay in TheSky6 when the Park command is sent. Mark's hypothesis is that the problem was caused

Thanks Marj, that is a big help already to know that. This is quite confusing. Dave

So, what version of TheSky(6) are you running? Dave