on-board computers and precession

[Demonperformer]

This is one of those problems that niggle away at the back of my mind until I get it worked through:

Does anyone know if the on-board computers in mounts take into account precession?

I have been playing around with precessing some objects recently, and (for example) Arcturus has moved about 10' since J2000, but Deneb has barely moved 6' since J2000. Now, if you have a CCD chip that has a height of 11' (a) a distance of 10' out is a problem, and ( if different stars have moved different amounts, this could be an issue.

If they don't take precession into account, then the accuracy of alignment would surely get worse as time goes on, because even if you get the alignment star precisely in the middle of the frame, it would have to guess where the real positions were when objects have moved different distances (eg Arcturus and Deneb).

But if it does take precession into account, then any object for which you entered the RA/DEC because it wasn't in the on-board database, would not arrive at the correct position unless you precessed the inputs first.

So when a mount says it GOTOs with an accuracy of <1', what does this actually mean in these circumstances?

Any thoughts?

Thanks.

[i know ... I need to get a life!]

[Jessun]

Aren't RA/Dec fixed? Meaning that only Alt/Az really change depending on the day/year/century. The coordinates as such remain fixed, and by allowing for precession in the polar scope - they last some 30 years or so I think judgeing by the etched reticule patterns - the problem is effectively solved.

I like the question, and I'm not too sure I've got it right either.

/Jesper

[Demonperformer]

Objects nearer the poles move a greater amount in RA compared to objects at the equator, so their RA/DEC coordinates change relative to each other.

Example:

J 2000 00h00m00.0s+00 00 00 in 2100 will have an RA of 00h05m07.6s (and a DEC of +00 33 24)

J 2000 00h00m00.0s+80 00 00 in 2100 will have an RA of 00h05m16.6s (and a DEC of +80 33 24)

Therefore, the +80 object has moved 9s of RA further than the equatorial object. I think this has something to do with the DEC circles being smaller in absolute terms near the poles [length of the circle at declination D, compared to the length of the circle at the equator (E) is E*cos(D)]

So if you used the same RA figure for the +80 object as for the equatorial object, you would end up just under 13' away from the intended position.

At least, I think that is the way the math works!

[Daddystu]

Is it necessary for the mounts to take into account precession? I would think that would be best solved by mount control/planetarium software either in the handset or on the laptop (ie JNOW).

[wxsatuser]

According to the Nexstar resource site CGEM hand controllers do use precession.

Look down at the Version 4 hand controller.......section 4.15.

[wxsatuser]

According to the Nexstar resource site CGEM hand controllers do use precession.

Look down at the Version 4 hand controller.......section 4.15.

Forgot the link

http://www.nexstarsite.com/Firmware/ASGTFirmware.htm

[Demonperformer]

Thanks for that, Mike.

I would guess that other similar mounts (eg EQ5/6) would do similar.

So presumably, if one was looking for an object that is not in the handset's database, thus requiring the entering of RA/Dec, it would be necessary to use coordinates that were precessed to today's date, rather than the J2000 figures.

[wxsatuser]

Astro Baby has a bit on NEQ6 etc.

Scroll down to the section....Version 3.22 5th June 2008.

It mentions Precession compensation.

http://www.astro-baby.com/EQ6%20rebuild%20guide/EQ6%20Development%20and%20Software%20Releases.htm

[knightware2]

You are wise to question this. The difference between precessed and unprecessed positions can be several arcminutes as you stated.

I certainly can't answer for every mount or its driver, but the ASCOM interface that so many external programs use to talk to mounts includes an attribute that specifies whether GoTo commands are referred to the epoch of date (JNow) or J2000. The ASCOM documentation states that mounts either accept position information precessed to the epoch of date (JNow), or precess J2000 positions internally. A well-behaved program should interrogate this setting and supply GoTo commands that suit the mount's capabilities.

I don't think mounts adjust for proper motions of stars. That would be another source of position error when slewing to a star. Proper motions is generally measured in milliarcseconds per year, so this is a small source of error for most stars.

Bottom line: I suspect your mount does precess to the epoch of date. ASCOM drivers are built to handle this.

[Demonperformer]

Thanks for the replies.

I'm not too worried about proper motion. Most of the objects that I will be trying to find like this are faint galaxies from PGC and I'm not sure what the NEQ6 database holds as regards those (due to get one next month). But they don't suffer too much from PM errors. I'm planning on using EQDIR, which uses ascom, so hopefully I won't have any problems.

Thanks.

[Cath]

Although not bothered to calculate it myself ..

I've heard that the precession (and thus the seasons, summer/winter solstice) moves about a day during a persons average life time.

[FraserClarke]

I don't think mounts adjust for proper motions of stars. That would be another source of position error when slewing to a star. Proper motions is generally measured in milliarcseconds per year, so this is a small source of error for most stars.

Bigger issue would be refraction; objects on the horizon are refracted by something like half a degree... At 10 degrees altitude, an object's position will be refracted by about 5 arcminutes. Not sure if mounts account for this or not?

[knightware2]

I definitely don't think mounts account for atmospheric refraction. I suspect there are 2 reasons...

1) You need air temperature and pressure to calculate refraction. I've never seen this in the ASCOM interface.

2) While the amount of refraction approaches zero at the zenith where we are supposed to observe, many of us observe at lower altitudes where the effect grows to > 1 arcminute. To get a very noticable effect (1.67 arminutes), altitude needs to get below 30 degrees (2 airmasses), but most of us probably don't observe there anyway. These values are illustrative only, I don't mean to imply and absolute rules here.

FraserClark is right that refraction is a significant effect nearer the horizon, and I don't think mount manufacturers account for it. Hopefully we observe at a higher altitude where the error is within the field of view of our eyepiece or camera, etc. To the original poster's statement about a mount being accurate within 1 arcminute - I would think that statement should include the caveat 'without taking atmospheric refraction into account'.

[perfrej]

The high end ones may do refraction. At least 10micron mounts do, and it works!

/p

[knightware2]

The high end ones may do refraction. At least 10micron mounts do, and it works!

/p

Cool! Is there a way to input temperature and pressure, or are there sensors in the mount?

[perfrej]

You input it or let the mount calculate it from ISA corrected by site altitude, which in turn is input or read from a connected GPS receiver. I wrote an ASCOM driver and some utilities that update it periodically from a weather station. Works like a dream!

/per

[perfrej]

... And ASCOM has a flag in the iTelescope interface for mount does/doesn't do refraction.