EQ6 pointing accuracy

[The_bluester (Paul)]

Was just reading up on NEQ6 stuff today as a potential remount for my CPC925. One issue that was mentioned was movement between the head and the wedge section. That would allow some lateral movement during a flip as the weight distribution changed and would whack pointing accuracy if it were happening. The fix showed removing the altitude scale and tightening three grub screw underneath.

[Merlin66 (Ken)]

Paul,
Interesting....(could you post a link?)
I have the C9.25 merrily working on the HEQ5pro and the C11 on the NEQ6pro and haven't come across that issue ...yet...

[lhansen (Lars)]

eq6.txt renamed from eq6.dat

going through the drift align as we speak. have implemeted all suggestions - after that I will do another tpoint

Many thanks to all who have made suggestions

[The_bluester (Paul)]

Actually, I just worked out I had wandered onto another section of the same site and the altitude play adjustment was referring to the EQ5, but the principle would be the same and any play there would affect an EQ6 in the same way.

http://www.astro-baby.com/heq5-rebuild/heq5-alt.htm

[lhansen (Lars)]

Pempro polar alignment wizard is now registering < 1 arc min in azimouth and < 1 arc min in elevation

That should be good enough

There is some small amount of backlash in DEC

Il start another tpoint run

[Merlin66 (Ken)]

Paul,
I honestly haven't struck that particular issue with either the HEQ5pro or the NEQ6pro mounts.

[Marke (Mark)]

Just a wild guess but what about orthogonality ie is the tube perfectly aligned with the mount axis . This is one cause for good pointing untill you do a meridian flip . It can be fixed by shimming the OTA a little to get it closer to axis .
Just a thought .

[lhansen (Lars)]

TPoint is able to cope with almost all of those common mount misalignments, the non perpendicularity is part of the standard tpoint model parameters.

Interestingly, with the new tpoint model thats currently running based on the measurements of points before the meridian flip (24 points) I got pointing accuracy of 19.6 arc secs, after the meridian flip.... time will tell

[gary]

Hi Lars,

Stars 2 and 5 are most likely outliers. Mask them.

I would assume you may have performed a meridian flip at star 26 onwards.

Whatever tool chain you are using is not conveying to TPoint that the observation
is from the flipped position.

For example, take star 26 itself. The scope RA/Dec position is 22:31:50.8 -57:02:32.1.
The angular separation on this star is 6641 arc seconds.
Would I be right in assuming this is where you first performed a flip?
If so, the scope RA/Dec position should be "flipped" to 10:31:50 -122:57:28.

Likewise the scope position for star 27 should be "flipped" to 08:44:53 -140:35:05.

I only converted 26 and 27 by hand to verify this but when you mask 28 to 45,
the results are excellent, with an RMS of 25 arc seconds using only 7 terms,
namely IH, ID, CH, ME, MA, HDCH1, HHCH3.

* fit

       coeff       change     value    sigma

  1     IH         -5.899  -6439.18   14.304
  2     ID        -64.536    -21.79   10.861
  3     CH         +2.153  +3066.14   13.963
  4     ME         +3.271    -22.63   21.493
  5     MA        +14.153    -48.96   12.070
  6     HDCH1     +53.635    +91.58   23.079
  7     HHCH3      -2.473    -27.28   10.134

Sky RMS =  25.26
Popn SD =  29.77

The mount has virtually no discernible NP, so I did not include it. You can see in
the fit above that the CH value of 3066 arc seconds is the most significant, so
it may simply be that the OTA is not "square" to the mount.

I would not be surprised that if the remaining samples, that is 28 to 45, had
their scope positions "flipped", that the results may continue to stay good.

So in a nutshell, you should first do the following -

Take care to avoid outliers.

Review how your tool chain conveys "flipped" mount positions to TPoint and
correct it. That appears to be the major source of your problems.

As you can appreciate, GEM's have the ability to view the same place in the
sky from two distinct mechanical orientations. The mount co-ordinates sent
to TPoint need to convey when the OTA is observing from the flipped position.

One could post convert the positions by hand, which is tedious, or by way
of a script, or better still, determine a tool chain flow that might allow the
flipped co-ordinates to be embedded in the data.

[lhansen (Lars)]

Gary - im grateful for your help. It will me a little time to digest your analysis but as I understand it:

Remove the obvious outliers and
Identify the issue around the incorrect recording the location

Im new to eqmod, but I have used all the other components many times on previous mounts and never with too much issue.

I'll keep pushing

[lhansen (Lars)]

sorry Gary

I didnt complete answer your last email. Yes the mount flipped @ 26, before that the numbers were excellent.

How did you do the hand calculation - my trig is very rusty

[gary]

Originally Posted by lhansen

Gary - im grateful for your help.

Lars, you are most welcome.

sorry Gary

I didnt complete answer your last email. Yes the mount flipped @ 26, before that the numbers were excellent.

How did you do the hand calculation - my trig is very rusty

New_Scope_RA = normalized(Old_Scope_RA + 180 degrees)
New_Scope_Dec = normalized(180 - Old_Scope_Dec)

Since the RA positions are in hh:mm:ss format, you first need to convert them to
decimal hour format (i.e. hh.d ....).

To do that,
decimal_hours = h + m/60 + s/3600

So for example, star 26's scope RA was 22:31:50.
Therefore in decimal hours, 22 + 31/60 + 50/3600 = 22.5306.
You can also perform that conversion conveniently online here -
http://www.springfrog.com/converter/decimal-time.htm

We then need to convert this to degrees by multiplying by 15.
Therefore 22.5306 * 15 = 337.9583 degrees.
We add 180 degrees to this, so that 337.9593 + 180 = 517.9593.
By "normalize" we mean here to keep it in the range of 0 to 360 degrees.
Since our number is greater than 360 degrees, we can subtract an entire 360 degrees
to get 517.9583 - 360 = 157.9583.
We now need to convert this back to decimal hours, so we divide by 15.
157.9583/15 = 10.5306
We now want to convert this to hh:mm:ss format
Using http://www.springfrog.com/converter/decimal-time.htm to convert back -
the result is 10:31:50

For Dec, we need to convert -57:02:32 to decimal degrees, being mindful of
the minus sign. Conveniently, you can use this web site -
http://data.aad.gov.au/aadc/calc/dms_decimal.cfm
The result is -57.0422.
We now compute the New_Scope_Dec = 180 - -57.0422 = 237.0422.
In the case of Dec, to normalize, if the value is greater than 180, we
will subtract 360 degrees. If it is less than -180, we will add 360 degrees.
Therefore 237.0422 - 360 = -122.9578.
We then need to convert that back to dd:mm:ss format.
Conveniently, you can use this web site -
http://data.aad.gov.au/aadc/calc/decimal_dms.cfm
the result is -122:57:28

So you then hand edit the Scope RA and Scope Dec fields for star 26
and enter the values 10 31 50 and -122 57:28

[White Rabbit]

Not sure if it has been mentioned above, I havnt read all the posts, but have done a three star aligne with the synscan alone, no computer in the mix. If your polar align is as good as you say then pointing should be consistently good either side. If it is good on both sides, you know you have a software issue, if it's not, you have a mechanical issue.


Sandy

[lhansen (Lars)]

Thanks Gary

I should be able to turn this into a spreadsheet and import the export file.

I'll have a bash

Cheers

Lars

Originally Posted by gary

Lars, you are most welcome.



New_Scope_RA = normalized(Old_Scope_RA + 180 degrees)
New_Scope_Dec = normalized(180 - Old_Scope_Dec)

Since the RA positions are in hh:mm:ss format, you first need to convert them to
decimal hour format (i.e. hh.d ....).

To do that,
decimal_hours = h + m/60 + s/3600

So for example, star 26's scope RA was 22:31:50.
Therefore in decimal hours, 22 + 31/60 + 50/3600 = 22.5306.
You can also perform that conversion conveniently online here -
http://www.springfrog.com/converter/decimal-time.htm

We then need to convert this to degrees by multiplying by 15.
Therefore 22.5306 * 15 = 337.9583 degrees.
We add 180 degrees to this, so that 337.9593 + 180 = 517.9593.
By "normalize" we mean here to keep it in the range of 0 to 360 degrees.
Since our number is greater than 180 degrees, we can subtract an entire 360 degrees
to get 517.9583 - 360 = 157.9583.
We now need to convert this back to decimal hours, so we divide by 15.
157.9583/15 = 10.5306
We now want to convert this to hh:mm:ss format
Using http://www.springfrog.com/converter/decimal-time.htm to convert back -
the result is 10:31:50

For Dec, we need to convert -57:02:32 to decimal degrees, being mindful of
the minus sign. Conveniently, you can use this web site -
http://data.aad.gov.au/aadc/calc/dms_decimal.cfm
The result is -57.0422.
We now compute the New_Scope_Dec = 180 - -57.0422 = 237.0422.
In the case of Dec, to normalize, if the value is greater than 180, we
will subtract 360 degrees. If it is less than -180, we will add 360 degrees.
Therefore 237.0422 - 360 = -122.9578.
We then need to convert that back to dd:mm:ss format.
Conveniently, you can use this web site -
http://data.aad.gov.au/aadc/calc/decimal_dms.cfm
the result is -122:57:28

So you then hand edit the Scope RA and Scope Dec fields for star 26
and enter the values 10 31 50 and -122 57:28

[Astro_Bot]

Having a quick look at the maths above, for RA, you could just add 12 hours and check the resulting hour component (if >=24, subtract 24). It would save a lot of conversion.

[Terry B]

Lars
Are you using EQMOD?
If you synch into EQMOD it works out its own pointing algorithm and corrects the pointings. This would work against TPoint. The 2 methods can't really be used together.

[gary]

Originally Posted by Astro_Bot

Having a quick look at the maths above, for RA, you could just add 12 hours and check the resulting hour component (if >=24, subtract 24). It would save a lot of conversion.

Thanks Astro_Bot. Since the RA values will always be positive, adding the 12
and keeping in the range within 0 to 24 will do the trick.

Lars, you have to however take care with the Dec calculations, particularly
when negative values are involved. It is important to remember that if you
have a Dec such as -57:02:32.1 it is really -57 degrees, -2 minutes, -32.1 seconds.
Particularly be mindful of the case where the degree field is negative 0.
For example, -0:12:34. You need to apply the sign to all fields. Your Scope Dec
values will end up being in the range -180 degrees to +180 degrees.
Your star Dec values however will only ever be in the range -90 degrees to +90 degrees.
In other words, don't touch the star RA and Dec fields, only the scope RA and Dec fields.

By the way, when I mentioned that NP was virtually non-discernible, I was
looking at its value compared to its own standard deviation (reported as sigma).
The standard deviation was close to the size of the term's value, so it really
was down in the noise on the limited number of points fitted.

Physically, Dec to optical axes non-perpendicularity was the dominant term,
which is common on GEM's. As I mentioned, if the OTA is not "square" to
a dovetail plate or the plate not "square" to a mount head, CH will come about.
There are a variety of other potential reasons, including the optical path
not being parallel to the tube (collimation) or a camera coupling that is skewed.

When you perform the spreadsheet conversion, you might like to post
an updated .dat file and we can have another quick look.

But I am hoping it will be all over bar the shouting.

[lhansen (Lars)]

Hi Terry

Figured that one out this afternoon and disabled the EQMOD pointing capability. Did not make any difference. Interestingly when I chopped out half the model (the evil part), the model cleaned up and my actual gotos improved. I believe it has to be software related:

my software chain is



aag_tpoint -> theSky6->tpoint
| ...................|
| ....................-> teleapi -> eqmod->eq6
|
------>maxim->dssi pro
|
|------>pinpoint

i make that 8 cooperating components, now where in that chain could the problem be?

Originally Posted by Terry B

Lars
Are you using EQMOD?
If you synch into EQMOD it works out its own pointing algorithm and corrects the pointings. This would work against TPoint. The 2 methods can't really be used together.

[gary]

Originally Posted by lhansen

Interestingly when I chopped out half the model (the evil part), the model cleaned up and my actual gotos improved.

Hi Lars,

This is what I pointed out yesterday. By masking the sampling data
when the OTA was on the "other side" of the meridian, you are masking out
data that has incorrect "side of pier" information.

By way of background, some telescope control systems have the ability
to keep track of which side of the meridian the OTA is on.

I refer you to pp 15-16 of the TPoint manual of specific restrictions
if your telescope controller does not have the capability to convey
what they refer to as "side of pier" information.
See http://www.bisque.com/sc/media/p/28065.aspx

So the data you collected from the "flipped position" is in one sense
"good" rather than "evil" but you would need to manually convert the
scope RA and scope Dec positions as per my previous post.

Whether your controller provides support for supplying side of pier
information by way of a protocol that TheSky supports, I do not know
and you will need to independently determine that.

Otherwise when you sample stars, you should stick to the restriction
as outlined in the TPoint manual.

I hope this helps.

[lhansen (Lars)]

Thanks Gary

And thanks to all for the suggestions made in this thread - it is very much appreciated. In the end I took another path. On the assumption that the problem related to software, I installed theSkyX and the ASCOM/X2 connectors. Set the mount up as an ASCOM mount and set camera control as a MaxIm connected camera then used the integrated TPoint modelling capability of theSkyX.

I'm just doing a quickie 32 point model, but the scope has already flipped and the unimproved SkyRMS us approximatey 52.3 arc secs. Should be better when (if?) I run the super model.

So it appear the problem was that one of the software components was not correctly returning the scope RA/DEC as suggested by you. I'm not going to try to sort it out now that I have it working, it has consumed enough nights already.

Ill do an export of the finished model if you are interested

All the very best and thanks again

Lars

Originally Posted by gary

Hi Lars,

This is what I pointed out yesterday. By masking the sampling data
when the OTA was on the "other side" of the meridian, you are masking out
data that has incorrect "side of pier" information.

By way of background, some telescope control systems have the ability
to keep track of which side of the meridian the OTA is on.

I refer you to pp 15-16 of the TPoint manual of specific restrictions
if your telescope controller does not have the capability to convey
what they refer to as "side of pier" information.
See http://www.bisque.com/sc/media/p/28065.aspx

So the data you collected from the "flipped position" is in one sense
"good" rather than "evil" but you would need to manually convert the
scope RA and scope Dec positions as per my previous post.

Whether your controller provides support for supplying side of pier
information by way of a protocol that TheSky supports, I do not know
and you will need to independently determine that.

Otherwise when you sample stars, you should stick to the restriction
as outlined in the TPoint manual.

I hope this helps.