Subject: Re: [sdss3-25mlog 1181] Re: 2.5m obslog 20130401 (MJD 56384) From: Dan Long Date: Fri, 5 Apr 2013 11:29:40 -0600 --Apple-Mail-201-328723680 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The rational for putting an upper limit on correction is to prevent = bogus readings (which do happen fairly frequently) from being applied as = a correction. 600 ticks was chosen as a value which was considered = about as large as a real error would get. Experience over the years has = shown that real errors do occur which are larger, though they are not = all that common. The best indicator of a real error is if it is confirmed by = subsequent fiducial crossings. I think it would be quite reasonable to = consider adding an additional layer to the existing fiducial logic. The = first layer would be as things are now: a single fiducial crossing with = error Not sure if there is another constraints on the system. =46rom = acquiring fields and guiding aspects, it would be nice to do so. >=20 > On Apr 4, 2013, at 3:49 PM, Mark Klaene wrote: >=20 >> can we/should we change the acceptable error margin for the rotator = so that a "too large to correct" won't happen unless it really is too = large that it will cause problems? >>=20 >> mk >>=20 >>=20 >> On Apr 4, 2013, at 3:30 PM, Dan Long wrote: >>=20 >>> Hi Dmitry, >>>=20 >>> It takes 38 arcseconds of rotator error or 1900 encoder ticks to = generate 1 arcsecond of error on the sky at the edge of the plate. A 15 = arcsecond error in rotator position would result in less than half an = arcsecond of error on the sky at the edge of the plate, and even less = towards the center . It would probably not have hindered acquisition. = While it is a little troubling to have fiducial errors too large to = correct, in the case of the rotator 600 ticks is only 12 arcseconds, and = it would take something on the order of several arcminutes of error ( = ~10,000 ticks of encoder error) to cause trouble acquiring. >>>=20 >>> Cheers, >>>=20 >>> Dan >>>=20 >>> On Apr 2, 2013, at 3:44 PM, dmbiz@apo.nmsu.edu wrote: >>>=20 >>>> Hi Kaike, >>>> thank you for the comments! >>>>=20 >>>>> If the rotator fiducial error when slew to a field is the ONLY >>>>> problem we have, I think that >>>>> we should be okay to continue. Most likely, fiducial errors on = the >>>>> rotator will not stop us from >>>>> finding guiding stars. After we get stars, no fiducial corrections = will be >>>>> applied, so we are okay >>>>> for that field except for observers have to tolerance multiple = verbal >>>>> warnings of "fiducials". >>>>=20 >>>> The rotators fiducial error suggested some 15" offset. Once it = happens >>>> with rotator, it is hard to predict where guide stars go, so I = recommended >>>> to >>>> fix the fiducials first. >>>>=20 >>>>> There is a bug on the "stop" of "goto Field". Clicking (applying) = the >>>>> "stop" >>>>> button puts sop into a confusion status although"sop ping" and = "sop >>>>> status" show >>>>> SOP is okay. One can get SOP back to its normal status by issue = two >>>>> commands >>>>> from STUI: >>>>>=20 >>>>> sop restart (this may not unnecessary, so you can try without it = first) >>>>> sop reinit >>>>=20 >>>> Can we put it to the observing notes that we cannot use the "stop" = button >>>> in STUI? >>>>=20 >>>> Dmitry >>>>=20 >>>>=20 >>>> _____________________________________________________ >>>> Message 1176 of sdss3-25mlog - Logs of nightly APO activities. >>>> = https://trac.sdss3.org/tracmailman/browser/private/sdss3-25mlog/all/1176.h= tml >>>> sdss3-25mlog@sdss3.org >>>> https://sdss3.org/mailman/listinfo/sdss3-25mlog >>>=20 >>> _____________________________________________________ >>> Message 1180 of sdss3-25mlog - Logs of nightly APO activities. >>> = https://trac.sdss3.org/tracmailman/browser/private/sdss3-25mlog/all/1180.h= tml >>> sdss3-25mlog@sdss3.org >>> https://sdss3.org/mailman/listinfo/sdss3-25mlog >>=20 >> Mark Klaene >> Site Operations Manager=20 >> Apache Point Observatory voice: 575 437 6822 >> PO Box 59 fax: 575 434 = 5555 >> 2001 Apache Point Rd cell: 575 430 0210 >> Sunspot NM 88349-0059 web: www.apo.nmsu.edu=20 >>=20 >>=20 >>=20 >>=20 >> _____________________________________________________ >> Message 1181 of sdss3-25mlog - Logs of nightly APO activities. >> = https://trac.sdss3.org/tracmailman/browser/private/sdss3-25mlog/all/1181.h= tml >> sdss3-25mlog@sdss3.org >> https://sdss3.org/mailman/listinfo/sdss3-25mlog >=20 --Apple-Mail-201-328723680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The rational for putting an upper limit on correction is to = prevent bogus readings (which do happen fairly frequently) from being = applied as a correction. 600 ticks was chosen as a value which was = considered about as large as a real error would get. Experience = over the years has shown that real errors do occur which are larger, = though they are not all that common. The = best indicator of a real error is if it is confirmed by subsequent = fiducial crossings. I think it would be quite reasonable to = consider adding an additional layer to the existing fiducial logic. = The first layer would be as things are now: a single fiducial = crossing with error <600 ticks gets corrected during a slew. = The second layer could be: if one sees two subsequent = fiducial crossing errors which are less than 6000 ticks and agree to = within 10%, apply the correction. This would cover nearly every = real error. I don't know how = difficult it would be to implement such a change (this is all in the mcp = I believe). I also don't know how much sky time is lost to dealing = with corrections manually, but I wouldn't think it is much. So = that would have to be weighed against the effort required to implement = the = change.-DanOn Apr 4, 2013, at 3:53 PM, Kaike Pan wrote:Not sure if there is another = constraints on the system. =46rom acquiring fields and guiding aspects, = it would be nice to do so.On Apr 4, 2013, at 3:49 PM, = Mark Klaene wrote:can we/should we change the = acceptable error margin for the rotator so that a "too large to = correct" won't happen unless it really is too large that it will cause = problems?mkOn = Apr 4, 2013, at 3:30 PM, Dan Long wrote:Hi = Dmitry, It takes 38 arcseconds of rotator = error or 1900 encoder ticks to generate 1 arcsecond of error on the sky = at the edge of the plate. A 15 arcsecond error in rotator position = would result in less than half an arcsecond of error on the sky at the = edge of the plate, and even less towards the center . It would = probably not have hindered acquisition. While it is a little = troubling to have fiducial errors too large to correct, in the case of = the rotator 600 ticks is only 12 arcseconds, and it would take something = on the order of several arcminutes of error ( ~10,000 ticks of encoder = error) to cause trouble acquiring. Cheers, = DanOn Apr 2, 2013, at 3:44 PM, dmbiz@apo.nmsu.edu = wrote:Hi = Kaike,thank you for the = comments! If the rotator fiducial error when slew = to a field is the ONLYproblem we have, I think = thatwe should be okay to continue. Most likely, fiducial = errors on therotator will not stop us = fromfinding guiding stars. After we get stars, no fiducial = corrections will beapplied, so we are = okayfor that field except for observers have to tolerance = multiple verbalwarnings of = "fiducials".The rotators = fiducial error suggested some 15" offset. Once it = happenswith rotator, it is = hard to predict where guide stars go, so I = recommendedtofix the = fiducials first. There is a bug on the "stop" of "goto Field". Clicking = (applying) the"stop"button puts sop into a confusion = status although"sop ping" and = "sopstatus" showSOP is okay. One can get SOP = back to its normal status by issue = twocommandsfrom = STUI:sop restart (this may not = unnecessary, so you can try without it = first)sop reinitCan we put it = to the observing notes that we cannot use the "stop" = buttonin = STUI?Dmitry_____________________________________________________Message 1176 of sdss3-25mlog - Logs = of nightly APO activities.https://trac.sdss3.org/tracmailman/browser/private/sdss3-25ml= og/all/1176.htmlsdss3-25mlog@sdss3.orghttps://sdss3.org= /mailman/listinfo/sdss3-25mlog___________________= __________________________________Message 1180 of sdss3-25mlog - = Logs of nightly APO activities.https://trac.sdss3.org/tracmailman/browser/private/sdss3-25ml= og/all/1180.htmlsdss3-25mlog@sdss3.orghttps://sdss3.org= /mailman/listinfo/sdss3-25mlog Mark KlaeneSite Operations Manager Apache Point Observatory = voice: 575 437 6822PO Box 59 = = fax: 575 = 434 55552001 Apache Point Rd = = cell: 575 430 0210Sunspot NM 88349-0059 = web: www.apo.nmsu.edu = ____________________________________________________= _Message 1181 of sdss3-25mlog - Logs of nightly APO = activities.https://trac.sdss3.org/tracmailman/browser/private/sdss3-25ml= og/all/1181.htmlsdss3-25mlog@sdss3.orghttps= ://sdss3.org/mailman/listinfo/sdss3-25mlog= --Apple-Mail-201-328723680--