an argo navis on a eq6 pro?

[h0ughy]

I am toying with the idea of installing My argo Navis onto the eq6 pro. I am thinking that i will still retain the goto to get to a rough area but also have to aqbility to utilise the argo to find anything - as the synscan isnt exactly what you can call accurate. Am i stupid for thinking about doing this, or is there merit in it?

my hope is to be able to either manually slew to what i want and use the argo, basically it has a better database and is more accurate. thought i could polar align then go and select a few stars to align off and then go to an area , use the agro to find the target to image. But the ability to align during the day also appeals to me.:help:

[peter_4059]

Try EQMOD - the pointing model lands objects in the middle of the DSI chip 9 out of ten times for me. If it isn't there you just sync on a nearby bright star then slew back to the target.

[toryglen-boy]

sounds a bit mental to me mate! why dont you clear the PAE data, and restart, trying to make the goto more accurate?

[h0ughy]

i might add here the whole point is not to have a laptop attached, but i can see the eqmod is an option

[rider]

I've got argo on an eq5. My opinion is that it is only as good as the synscan on my eqpro. I think this is a result of using it on portable eq mounts. It should be fine on a perminent pier though. If you use the error analysis program it is very accurate, but takes too long to set up for one session. I just do a one star calibration for the part of the sky I'm looking at. Then do it again when I move to a new constellation - much faster.

Rider

[h0ughy]

yes it does sound a tad mental:help:

[h0ughy]

Thanks for the feedback - so you use the synscan for the one star calibration after you polar align or the argo??

[acropolite]

Not at all to me, having seen how well Ponders AN worked with the G11, I think it would be an excellent option. Given that the encoders are the primary factor for accuracy I wouldn't expect it to be any more or less accurate than Pauls setup. That said, to get the sort of flexibility that Paul has you'd need to give up using the sysncan and declutch the EQ6 before moving.

[jjjnettie]

Chris (hotspur) encountered all sorts of trouble when he did this.
Maybe PM him for more details.

[h0ughy]

thanks JJJ

[gary]

Hi Jeanette,

Thanks for the post.

Chris's mount was a Vixen GP. Roger at Bintel in Victoria performed
some repairs on this mount. Both in a telephone conversation and later
in person at Border Stargaze, Roger confirmed that the problem was
not related to the encoder installation.

Best regards

Gary

[jjjnettie]

Thanks for clarifying Gary.:)
I wasn't sure of the details that's why I suggested the PM.

[rider]

Sorry H, I didnt make my self clear, they are on two different mounts - one is an eq5 (Argo) the other is a HEQ5pro (synscan goto)

The accuracy of the Argo is only comparable (at best) with the synscan unless you use the advanced pointing software - this is pretty useless on a portable mount, because you spend half your night training the mount. Its easier and quicker to just recalibrate it for the part of the sky you are looking at with a one star alignment.

That said, I find that if I accurately polar align either mount before switching them on, they both perform well.

(also, be aware of the significant extra drag the argo senders place on the motors)

rider

[h0ughy]

Thanks for that extra information. I am leaning more towards not doing it now. The whole idea was to try and make portability more viable to find the faint fuzzies and this option is moderately priced. Will be looking at other alternatives

[gary]

Hi Rider,

Thanks for the post.

You may not be using the pointing analysis system as is intended.
Specifically there is no need to spend that amount of time to re-synchronize
the pointing model. The following tip might be helpful.

What we recommend is a two-stage process.

On one night, say on some unfavorable observing night like on Full Moon,
we recommend you perform a long sampling run where you sample star
positions across the whole sky and fit a model. Any terms in the model
that are significant and whose nature is such that they are likely to be
persistent from session to session you should make the selection to
save into the non-volatile memory. Persistent terms are terms such as
non-perpendicularity between RA and Dec (NP), any flexure terms (TF & DAF)
and any eccentric bearing error terms (DCEC, DCES, HCEC, HCES).

Now - and this is the really neat part - on a subsequent night's observing you
simply need to re-synchronize the model by sampling four or five stars.
You would then fit the two non-persistent Index Error terms (ID & IH) and the
polar misalignment terms (MA & ME) and possibly the collimation in
hour angle term (CH), which comes about if there is any non-perpendicularity
between the declination and optical axis. This later short sampling run
should take you less than five minutes to perform but the beautiful part is that
your pointing performance will return to the same levels as it did as on the
night when you performed the long sampling run.

Whenever I use an equatorial mount, I use this same approach myself at the
beginning of the night as it is just getting dark and I wholeheartedly recommend it. :thumbsup:



Sorry, but that is not correct. The encoders produce negligible and insignificant
drag to the motors and gear train. The encoder shafts can be rotated with the
fingers and have as much torque as a volume control on a car radio. Compare
that to the huge moment of inertia of the OTA and the counterweight which the
motors and gear train are also driving and you can appreciate that the encoders
provide a minuscule loading. For example, If one were to measure the current
draw of the motors with and without the encoders in place, which is one way to
measure the loading, rest assured the difference would be incredibly tiny. :thumbsup:

Thanks again for the post and I hope the tip on using TPAS is helpful
as well as the clarification on the tiny moment that the encoders present to
the motors.

Best Regards

Gary Kopff
Wildcard Innovations Pty Ltd

[rider]

Thanks Gary,
I'll try your method to see if I like it.
In most sessions, I tend to concentrate on a particular part of the sky and if I don't stray too far from the selected (1 star) alignment star, I get good accuracy. if I do switch to a new part of the sky, it only a matter of selecting a new alignment star. -very quick.
Brisbane's sky has not been cooperating this year, and if I do get a good night, I don't want to waste any of that short window between dark and dew adjusting equipment.

I'll take on board your comments about the negligible nature of sender drag, however I did some experimenting last night, and the result was that if I un-balance my scope without the Dec sender belt on, it will pivot on the axis under its own weight, but with the belt attached it stays (firmly) where it is. The same happens with the RA axis cog disengaged, so there must be some drag. Static load only perhaps?

Regarding accuracy of any type of goto or push to device, my opinion is that if the object is in the ep field then the unit has acheived its function. Realistically its a bit too much to expect ultimate levels of accuracy out of portable mass-produced amateur equipment (such as Eq mounts). With an accurate polar alignment prior to starting, both Argo and Synscan acheive this. I recon they both do a good job.

regards Rider

[gary]

Hi Rider,

Thanks for the follow-up which is appreciated.



This is also a good strategy and one we also recommend.

What is happening here is that in the face of polar misalignment and
mount errors, the pointing residual will be smallest in the neighborhood
of the alignment star. So re-aligning on some star when you move to a new
part of the sky exploits this fact.

Once you get more familiar with TPAS, you can use it in a similar quick way
but with the added benefit that the system can help refine the pointing model
so that the pointing improves across the whole sky. Rather than align on
a new star, SAMPLE the position of the star, DIAL up SETUP MNT ERRORS,
COMPUTE ERRORS and accept them all in the model. This is all easy in practice.
You simply find yourself hitting the ENTER button a few times in rapid succession. :)
What is neat about this approach is that after you SAMPLE and COMPUTE
on each new star, after a while you will often find that when you move to some
other part of the sky, you don't need to do it again for the rest of the night as
the pointing improves across the whole sky.



You have got your priorities right. Never let aligning the system get in the way
of observing. :thumbsup:



OK. However, it is not really a good experiment when it comes to demonstrating
the load a motor 'sees' on a telescope when it comes to determining the motor's
torque requirements.

You might be familiar with or heard of a concept known as "moment of inertia".
It is a measurement of how hard it is to change the rotational motion of a body around
a given axis. On a scope, the further out the OTA and counterweight from the axis
of rotation, the larger is the moment of inertia and hence the larger the effort
required for the motor to initially move it.

Rather than think in terms of pushing on the OTA or counterweight, which is what we
tend to do as humans so we have some mechanical advantage, think in terms
of the motor attempting to rotate these two masses at the very axis itself.

It is like when one pushes open a door. Normally we push the door near the handle
and it opens easily. However, if one pushes it close to the hinges, it can take
considerable effort to push it open. Much of the mass of the door is some distance
away from the axis of rotation (which runs up through the hinges). This mass
distributed some distance away from the axis increases the doors moment of
inertia.

The moment of inertia the motors "see" when they rotate the OTA and counterweight
will be orders of magnitude larger than the moment of inertia that would be required
to rotate the encoder shaft. Indeed, once in motion, the encoder also provides a
constant light static drag (torque) as do the bearings in the mount, but compared to the
initial effort required for the motor to spin the scope from a point close to the axis, it
is an absolutely tiny amount. ;)



Absolutely and in the Manual and whenever I give talks on pointing
analysis, we talk in terms of an individuals "pointing goal".
For example, landing the object in the FOV of an eyepiece of choice is
a commonly articulated pointing goal. Others have more demanding goals,
such as blind pointing to land an object onto a small CCD array.



The good news is that often the primary source of pointing errors in some
GEM's is not entirely the fault of the manufacturer at all but Dec to optical
axis non-perpendicularity that was in play by the user. Sometimes something
as simple as not having collimated the scope or not mounting a dovetail squarely.

What is surprising is how a handful of terms in a pointing model can
so often dramatically improve, in a very real quantitative sense, the pointing
performance of scopes such as these. As long as the source of the errors
is systematic rather than random (no system can compensate for random errors)
a good pointing analysis system can transform commodity mounts into even
greater value performers. :thumbsup:

Thanks again for the post and I hope your weather in Brisbane is better than
the weather here in Sydney tonight.

Best Regards

Gary Kopff
Wildcard Innovations Pty Ltd.

[rider]

Thanks Gary, your replies are always good value.

I will spend a bit more quality time with the TPAS. (Sometimes I think that successfully mastering the fine details of astro equipment is half the fun.)

Rider