Subject: Questions about rotator angles for drift-scanning. Forward comments directly to


Submitted: Fri, 20 Oct 1995 09:56:22 -0600

Message number: 21 (previous: 20, next: 22 up: Index)

>Mime-Version: 1.0
>Date: Mon, 16 Oct 1995 17:40:05 -0700
>To: Bruce Gillespie <>
>From: (Russell E Owen)
>Subject: Questions about rotator angles for drift-scanning TCC code
>Cc: Pat Waddell <>,
>        Brian Yanny <>,
>        Bob Loewenstein <>,
>        Steve Kent <>
>In the process of implementing drift scanning I have run into a problem
>that should be answered by the user community and programmers of the
>interfaces to the TCC:
>To implement drift-scanning, I am adding a new "arc" offset (in addition to
>all existing offsets). This offset moves a specified distance across the
>sky in a specified direction (which is specified in the object's coordinate
>system -- typically FK5 RA/Dec). Specifying a velocity in the arc offset is
>the basic mechanism behind drift-scanning. This offset will also probably
>become the basic offset used for "nudging" and for graphical offsetting.
>To keep the instrument oriented correctly for drift-scanning, the rotator
>maintains a constant angle of the "user" coordinate system with respect to
>the instrument at the non-arc-offset position (rather than at the object).
>If there were no arc offsets, this would be the usual "object" rotation
>So the first question is: do we also want the more obvious form of "object"
>rotation: maintaining the angle at the object, rather than at the
>non-arc-offset position? I suspect everybody's first impulse will be a firm
>"yes", but please consider:
>Some arguments against a 2nd object rotation mode:
>- The non-arc-offset mode is often what users will want:
>  - Suppose you are using the nudger to move around in a dense field of
>stars near the pole (there is no such field, but it illustrates the point):
>using the present object rotation, the field's orientation on the CCD would
>remain constant. Using rotate-at-object instead, the field would rotate by
>quite a bit every time you nudged the telescope. This problem remains on a
>smaller scale as you move away from the pole.
>  - Similarly, if you have chosen a rotation angle with a particular guide
>star in mind, the non-arc-offset rotation mode is more likely to keep that
>guide star on the guide camera as you nudge around on the field.
>- Having two flavors of object rotation is a recipe for endless confusion
>and mistakes. One mode is easier to document than two, and there's no
>danger of users picking the wrong mode and wondering what the heck is going
>Some arguments for a 2nd object rotation mode:
>- Specifying the angle at the object is what naive users may expect (until
>they start nudging or graphically offsetting and run into the problem
>listed above).
>- If users start applying huge arc offsets they will get confused by the
>resulting orientation of the CCD. But large fixed arc offsets are probably
>not a good idea in any case, and small offsets favor the non-arc-offset
>Note that the rotation angle at the object will be part of status, so
>Remark and the instrument headers and etc. will have enough info to figure
>out what is going on in either case.
>I personally feel that two nearly identical rotation modes would be
>terrible, but I would like to hear what others think.
>Bob L: this is the same issue that caused confusion for your star finding
>chart offsetter (going x degrees E and then x degrees W didn't get you
>where you started). The orientation was set at the offset object (rather
>than the non-offset object), so the W offset was at a different orientation
>than the initial E offset.
>The TCC also supports a "horizon" mode of rotation, which I propose will
>maintain the angle of the horizon with respect to the instrument at the
>object (rather than the non-arc-offset position). What do you think?
>Arguments for horizon rotates with object:
>- It is much easier to implement.
>- It may be what users expect, arguments about moving around in a crowded
>field to the contrary. I'm on thin ice here, but still..if you are trying
>to maintain a slit in a particular orientation, you really don't want the
>user shafting you.
>Arguments for horizon rotates with non-arc-offset position:
>- It is consistent with the proposed object rotation mode.
>Another possibility: dump the horizon mode altogether. Are folks using it?
>Its purpose was to allow the slit to remain upright w.r.t. the horizon. If
>it's not useful I'd love to dump it, but if it's useful let's keep it.
>Your comments welcome. Please feel free to call me if you have any
>questions. Also please feel free to forward this to others (even mailing
>lists) if you want to solicit wider feedback. But please get your feedback
>to me this week if possible (or tell me why you need a delay). I wish to
>finish coding this stuff so I can get it ready for the engineering down
>My default solution will be to only implement the one object rotation mode
>and the non-consistent-with-that horizon rotation mode.
>-- Russell
>Russell E. Owen
>               University of Washington
>phone: 206-543-2859                     Astronomy
>fax:   206-543-9850                     Box 351580
>                                        C321 Physics/Astronomy Bldg (non USPS)
>      Seattle, WA 98195-1580

APO APO APO APO APO  Apache Point Observatory 3.5m  APO APO APO
APO  This is message 21 in the apo35-general archive. You can find
APO  the archive on
APO  To join/leave the list, send mail to
APO  To post a message, mail it to