EQ6 pointing accuracy

[lhansen]

I'm new to the EQ6. PE seems OK +- 7 arc secs and well managed by using PEC but the pointing accuracy appears very poor. Ive done a couple of TPoint models (88 and 48 points) and the best Ive got so far is around 1500 arc secs - thats 25 arc minutes :shrug:. My old EM200 did around 45 arc secs.

Polar alignmen is OK 1.5 arc min in azimouth and about 10 arc minutes on the elevation.
:question:

Ive fastened every nut and bolt on scope and mount.

Is there anything I should be looking out for?

:thanx:

[Astro_Bot]

Slipping gears? That's just a guess since I've yet to open mine up.

I've never achieved the advertised "up to 1 arc minute" GoTo accuracy, but if I pick decent alignment stars and take care with a 3-star alignment, I routinely get 5 to 10 arc minutes of pointing accuracy ... that's across the whole sky, so might be better using PAE in one specific region.

[lhansen]

Its pretty weird. Ive been syncing on Hadar and the pointing accuracy when on the east side of the pier looking west seems really good (around 40-50 arc secs). Do a pier flip an all hell breaks loose - the pointing accuracy goes REALLY bad.

[Tandum]

Hey Lars,
I've been running tpoint on my eq6 this week, mainly to ensure the dome is tracking the scope properly, I don't intend using it at all once I'm done.

I normally slew from park to a star, do a maxim pinpoint then sync and focus. Then slew to target and pinpoint/sync again. It is definitely a magical mystery tour after a flip but I find the pinpoint then sync method works for me there as well.

Also make sure eqmod is not creating it's own model and polluting the setup.

[lhansen]

I have a weakness for CCDAP and unattended operation so getting the pointing accuracy right is a priority. I'm getting 3-4 minute unguided subs (with PEC) so there must be some way of getting the pointing accuracy improved. Are there any TPoint afficionados out there who can look at a TPoint model and tell whan the problem might be?

I read about cone error? Im wondering if that might be at play.

[Astro_Bot]

Ah, well, there you go. I'm just using the SynScan firmware and the standard tripod, and don't usually fuss with setting up the tripod too carefully. Don't mind me. ;)

Cone error ought to be corrected for with 3-star alignment.

[Tandum]

Most of the eq6 guys I know are using ccd commander and maxim for unattended capture. No need for tpoint with that combo.

[lhansen]

Just had a first look at CCDCommander - it uses PinPoint for platesolving as does CCDAP, but you still have to be close for it to work as with CCDAP.

So I got one vote for slipping gears - i can check that out. Any other suggestions?

[Tandum]

Can't comment Lars, I don't use either but I know the guys use ccdc in the field without tpoint and it works fine.
Maybe one of them will chip in here.

[gary]

Hi Lars,

You can discount slipping gears. It is not that. Otherwise it would have betrayed itself
before the flip.

Have you been sampling stars on both sides of the meridian? Doing a meridian
flip and sampling on the "other" side is absolutely essential.

When you examine the pointing data in the spread sheet interface, you will
see a column for the star's RA and a column for its Dec as well as a column
for the scope's RA and a column for its Dec.

Examine the Dec pointing data for the scope.
Are the absolute values of the Dec data always in the range 0 to 90 or do
you see some that are in the range 90 to 180 as well?

Once you create a model, you should not be re-syncing on anything as you will
invalidate the model.



Alas, life would be simpler if this were true, but it is not.

By the way, "cone error" is a term Chinese mount makers coined in their instruction
manuals. On professional observatories, the preferred description for the Hour Angle
component of any Dec to Optical axes non-perpendicularity is usually Collimation
error in Hour Angle or CH for short. This is also the expression TPoint uses.

GEM's notoriously tend to suffer from CH and it is among the terms that
reverses its direction during a meridian flip. Hence my question to first check that the
pointing data being supplied to TPoint is correctly denoting when the mount
is flipped by the absolute range of Dec values going from 0 to 180 not just
0 to 90.

Once you can confirm that, there are several reasons why CH can commonly occur
but we can pick up the thread from there.

[lhansen]

Thanks Gary

I'll check those values when I fire up the observatory computers and get back.

I'm using eqmod with the mount in conjunction with thesky6 and aag tpoint mapper.

Regards

Lars

[troypiggo]

How good is your balance? I've had similar problems if things were s bit out of balance. And how much weight do you have on it? I noticed it more with 10in newt than little 500mm refractor.

[lhansen]

Balance I thought was ok, but I will double check.

Weight - it's carrying a fairly heavy 6inch newt plus cameras auto guiders etc. Certainly not near the supposed (I don't know for sure) 25 kg weight limit of the mount.

Thanks for that

[lhansen]

Just checked out the various things suggested:

Balance is good in RA, could be better in DEC

I checked the tpoint model numbers and the dec values range from 0 to 90 + and -.

I also looked at the error vectors and there is a strange pattern - Measurements made with the scope on the east side of the pier, looking west have error vectors that point due west, with the reverse pattern being evident on the west side of the pier. I interpret that as either, my pier could be rocking? I can check that - or the mount is not properly attached to forks of the mount base.

Any thoughts?

[Terry B]

I only used EQMOD to run mine but could usually position a star within a 20arcmin wide frame anywhere in the sky from anywhere else.
Backash makes a bit of difference but it still should point better than you are getting.

[gary]

Lars, this is key and I would need you to clarify it further.

When you examine the column for the Dec values of where the scope
appears to be pointing, do any values appear whose absolute values (i.e.
ignore the +/- sign) are in the range 90 to 180?

The column for the Dec values of the star that you sampled will
always have absolute values in the range 0 to 90 but those for the mount
need to also supply information to TPoint that the OTA was flipped.

If you can attach the data I can have a quick look.



As mentioned in my previous post, some classical error terms such as CH
reverse their vector direction when the mount is flipped, so the pattern
you saw is not strange but in fact normal.

It is typical to achieve a small RMS when you begin sampling just on
one side of the meridian, but as soon as you do a flip see the RMS values
go out the door until you sample some more.

But it is key that whatever automation you have in place that is
conveying the mount's position to TPoint is also able to denote
which side of the meridian the data was sampled on.

If not, you can be chasing your tail.

[Barrykgerdes]

Polar alignment sounds like the trouble. 10 arc mins in elevation is much too much. This will give quite large goto errors in some parts of the sky. particularly at high declinations.

Elevation is far more important for accuracy than most people think and the error will not show up on a simple drift alignment at the zenith. You need to do a drift at the horizons as well.

Barry

[gary]

The high fitted RMS won't be due to polar misalignment as
the MA and ME terms will mop that up very nicely.

The polar misalignment terms have very distinctive mathematical signatures
and so the analysis typically has no problem characterizing them.

[gary]

Hi Lars,

Within TPoint, select File->Export Text File and type in a suitable name.
That will produce a .dat file which you can then attach here so we can have a quick
look for you.

[Merlin66]

Just a comment:
I can get good GOTO results with the NEQ6pro.
The weight limit for "serious" work is more like 18Kg.
Have you double checked that cone error isn't one of the problems - re your earlier post.
Meridian flip would certainly aggrevate the accuracy...

[The_bluester]

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]

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]

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]

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]

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]

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

[Marke]

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]

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]

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]

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]

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 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]

Thanks Gary

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

I'll have a bash

Cheers

Lars

[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]

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. :thumbsup:

[lhansen]

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?:P

[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.

[lhansen]

:D 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. :sadeyes:

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

All the very best and thanks again :thumbsup:

Lars

[gary]

Hi Lars,

Good stuff. One tell-tale sign that side of pier information is coming through is to
look for scope Dec values that have absolute values greater than 90 when the
OTA is flipped.

if you get a chance to post your raw data and model when you are done, I would
be interested to have a quick look.

Anyway, glad that the insight I provided on the lack of side of pier information as being the
core problem was helpful and so hopefully you can keep moving forward with your observing.

Enjoy!

[jjjnettie]

I don't understand why we should have to go through all this rigmarole. One would assume that the mount would work properly out of the box.
My HEQ5Pro works supremely better than the EQ6 in regards to accurate pointing.

[coldknights]

Yes 1 would think straight out the box it should work well! So what happened to quality control or the lack of it.

[Astro_Bot]

It's variable. ;)

[RobF]

For those using EQMOD, remember there is a "side of pier" option for alignments. I find this drastically improves my modelling and pointing accuracy. With this off you can often see the first sync'd point on the other side of the meridian has signficantly more error than all the others, instantly messing with your pointing model.