Page 1 of 3 123 LastLast
Results 1 to 10 of 22
  1. #1

    Default Comet trailing - 10 Micron RA Offset Not Working

    Hi Bob,

    I have tried imaging C/2017 T2 Panstarrs comet last week. I have uploaded comet data from the minorplanets website as advised in help files and used attached plan.
    ACP was centering the comet in the center of FOV, but, unfortunately, every time I got both star and comet trails on 600s exposure.
    Then, I did the same using direct pointing and tracking with the mount and imaging through MaximDL. No trails on the comet (I attached both images from the same night for comparison).

    Not sure what I may be doing wrong, is there any setting in ACP that I need to enable to be able to track the comet.

    Thanks

    Regards,

    Saulius
    Attached Images Attached Images
    Attached Files Attached Files

  2. #2
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    27,534

    Default

    That should have worked.

    18:25:17 (doing orbital tracking. RA -0.0263 "/sec, Dec 0.0037 "/sec)
    ...
    18:36:07 (doing orbital tracking. RA -0.0263 "/sec, Dec 0.0037 "/sec)

    What kind of mount is it? By "direct pointing and tracking with the mount" are you referring to the mount/telescope control software? APCC/PlaneWave PWI/TheSky? ??? Is it possible that the mount control software is not enabled for orbital tracking, and it is not reporting this to ACP (failing without an error message)? The above logged lines indicate that ACP called the mount control software to do the sidereal tracking offsets needed to follow the comet....
    -- Bob

  3. #3

    Default

    It is 10Micron GM2000 mount with ASCOM compliant driver. I uploaded comet data into the mount, selected C/2017 T2 from its menu and got the mount tracking


    Sent from my iPhone using Tapatalk

  4. #4
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    27,534

    Default

    Ahhhhh OK, Well ACP does not use the mount's internal orbit and tracking calculation (most mounts do not do this). Instead as you can see in ACP's log, it does the mount orbit calculations, including sidereal tracking offsets, and commands the mount to track at the offset rate theough the universal ASCOM functions for this. Apparently this feature is perhaps not enabled on your mount? Can you look in the mount instructions for ASCOM options and see if "offset tracking" is described. Apparently the mount is telling ACP that it can do offset tracking (ASCOM CanSetRightAscensionRate and CanSetDeclinationRate are coming b ack True to ACP), or ACP would give an error that it is not supported by the mount. Instead the mount is just not doing it, and not reporting an error. Check the settings for this.
    -- Bob

  5. #5
    Join Date
    Nov 2005
    Location
    Virgil, NY
    Posts
    4,858

    Default

    The ACP-driven telescope is tracking. The problem here is that the ACP enabled offset tracking has the telescope tracking at the wrong rate in the wrong direction.

    If you can imagine looking at the ACP image, and thinking about the comet trail as a vector, and then subtracting that vector from any/each/all of the star trails, you will get an image that looks just like the MaxIm image. I can't tell which way is north, so it's a bit hard to determine which offset track axis (or both) is not correct. In any case, it certainly didn't track the comet correctly.
    Last edited by Dick Berg; Jan 16, 2020 at 21:09.
    Dick
    www.VirgilObservatory.us
    Pier-mounted Meade 12-inch SCT "classic"
    w. focal reducer to f/5.3 ~ FL 1630mm
    Optec TCF-S focuser
    SBIG CFW-8A and ST7-XME
    FOV ~ 15' x 10'
    H-alpha, BVRI, RGB & Clear filters
    MaxIm and, of course, ACP!
    AAVSO Code: BRIC

  6. #6
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    27,534

    Default

    Correct... but if the mount reports that it tan accept offsets to the sidereal tracking, which his does, then ACP sends the commands to put the mount into an offset tracking mode, where it will follow the solar system object (Comet here). I can see in Saulius' log that it sent those commands

    18:25:17 (doing orbital tracking. RA -0.0263 "/sec, Dec 0.0037 "/sec)
    ...
    18:36:07 (doing orbital tracking. RA -0.0263 "/sec, Dec 0.0037 "/sec)

    Yet the mount silently failed to obey.
    -- Bob

  7. #7

    Default Comet trailing

    Quote Originally Posted by Bob Denny View Post
    Correct... but if the mount reports that it tan accept offsets to the sidereal tracking, which his does, then ACP sends the commands to put the mount into an offset tracking mode, where it will follow the solar system object (Comet here). I can see in Saulius' log that it sent those commands

    18:25:17 (doing orbital tracking. RA -0.0263 "/sec, Dec 0.0037 "/sec)
    ...
    18:36:07 (doing orbital tracking. RA -0.0263 "/sec, Dec 0.0037 "/sec)

    Yet the mount silently failed to obey.
    Thanks Dick, you gave me a good idea to validate the offsets. I compared offset that is being set by ACP (from the log) (A) to the one which appears in the mount during ACP initiated tracking (B) and offset after direct slew from the mount (C). Theoretically A should be equal to B, it is not the case. It seems that ACP tries to send correct offset (A is close to C, which is the correct one), but it gets adjusted at some point and becomes erroneous. Not sure how can I investigate further.

    From ACP log:
    doing orbital tracking. RA -0.0233 "/sec, Dec 0.0031 "/sec)
    A) RA -1.398"/m, Dec 0.186"/m (I converted to /min)
    From the Mount menu during ACP initiated tracking:
    B) RA -1.599 "/m, Dec 0.212 "/m
    From the Mount during direct (correct) tracking:
    C) RA -1.368 "/m, Dec 0.175 "/m


    Sent from my iPad using Tapatalk

  8. #8
    Join Date
    Nov 2005
    Location
    Virgil, NY
    Posts
    4,858

    Default

    Hi Saulius,

    I did a little math/graphic on the numbers you presented. Those were from a different day, so they're not quite identical to the pictures/data from the 12th, but notionally there is little difference because of the date difference.

    The comet is moving slightly north of west. The angles from your data above are
    A) 7.58 degrees, B) 7.55 degrees, and C) 7.29 degrees, and the lengths are
    A) 14.10 arcsec, B) 16.13 arcsec, and C) 13.79 arcsec (for a 10 minute exposure).

    comets002.png

    The graphic shows a scale view of the motion over ten minutes. The angles would be imperceptible differences in an image, but the incorrect, Mount-received ACP numbers would add a maybe-noticeable trail error in the image. The MaxIm-based image from the 12th shows the stars reflexively moving in just the right direction. The ACP image on the left should have star trails slightly shorter in the same direction.

    There wouldn't be much tracking in the north-south direction since the comet's motion is pretty much east-west. So why is the tracking wrong in the north-south direction? In ten minutes, the comet only moves about 2 arcsec in Dec and those star trails are much longer - perhaps even a couple arcmin long. Somehow a bum number got into the mount's tracking (A -> B in your data, but even more), so beyond that there's some other issue with the mount. Wouldn't you agree?
    Dick
    www.VirgilObservatory.us
    Pier-mounted Meade 12-inch SCT "classic"
    w. focal reducer to f/5.3 ~ FL 1630mm
    Optec TCF-S focuser
    SBIG CFW-8A and ST7-XME
    FOV ~ 15' x 10'
    H-alpha, BVRI, RGB & Clear filters
    MaxIm and, of course, ACP!
    AAVSO Code: BRIC

  9. #9
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    27,534

    Default

    Thanks Dick!!! I appreciate your pitching in here.

    doing orbital tracking. RA -0.0233 "/sec, Dec 0.0031 "/sec)
    A) RA -1.398"/m, Dec 0.186"/m (I converted to /min)
    From the Mount menu during ACP initiated tracking:
    B) RA -1.599 "/m, Dec 0.212 "/m
    From the Mount during direct (correct) tracking:
    C) RA -1.368 "/m, Dec 0.175 "/m

    ACP and the Mount are calculating very close offsets. Here is the code in ACP that logs and sends the offsets to the mount:



    Code:
        Elseif c_haveTrackOffset Then                               ' Starting
            If c_guiding Then AutoGuide False                       ' Safety Valve
            Util.Console.PrintLine "  (doing orbital tracking. RA " & _
                    Util.FormatVar(RightAscensionRate * 15.0, "0.0000") & " ""/sec, Dec " & _
                    Util.FormatVar(DeclinationRate, "0.0000") & " ""/sec)"
            Voice.Speak "Starting orbital tracking."
            c_trackOffset = True
        End If
        Util.ScriptTelescope.RightAscensionRate = RightAscensionRate * SIDRATE ' ASCOM needs sec/sidereal-sec
        Util.ScriptTelescope.DeclinationRate = DeclinationRate                 ' ASCOM declination rate
    and

    Const SIDRATE = 0.9972695677 ' UTC/clock seconds per sidereal second

    Why is that there? Because Right Ascension is a time, not an angle, and it is a sidereal time not a Civil/solar time. So from the ASCOM Specification:

    Snap1.png

    But that means the RARate that is getting sent to the mount is (in the example above) -1.398"/m * 0.99727 = -1.394 sidereal seconds / sidereal minute. And just taking the ratio of 1.394 (the raw number being sent by ACP) to 1.599 (the value that the mount "gets"), yields 1.1471, which doesn't give me any ideas. I can only conclude that the mount is interpreting the RightAscensionRate incorrectly.

    Dick check me on this...
    -- Bob

  10. #10
    Join Date
    Nov 2008
    Location
    ABQ (me) // Rincona NM (scope)
    Posts
    725

    Default

    It seems to me that this ASCOM specification is ambiguous. When working in Right Ascension, one should never refer to just "seconds", as this specification does in "(seconds per sidereal second)", but should always specify arcseconds, which here would make it read "(arcseconds per sidereal second)", or conceivably should specify "(RA seconds = 1/3600 of an RA hour)".

    RA seconds vs arcseconds is a very common confusion in programming sky coordinates. It's more than believable that the mount driver author got this wrong. I mess this up myself once in a while (but I test my code so it never slips through).

    And by the way, there's a second, hidden ambiguity in RA programming: is the RA rate in terms of sky coordinates, or in terms of RA coordinates? The difference is in inclusion or not of the cosine(declination) term. I know of no other way to keep this all straight than to tighten the descriptions until your teeth hurt. (In the service of which my variable names get absurdly long sometimes.)
    New Mexico Mira Project, Albuquerque NM

 

 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. (very) long wait for flip with 10 Micron Mount
    By Francois Regembal in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 10
    Last Post: Jan 15, 2020, 11:19
  2. PinPoint fails to solve from 10 Micron modelling software
    By David Taylor in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 9
    Last Post: May 5, 2018, 03:25
  3. 10 Micron GM2000HPS Flip Check Issues
    By Peter Hannah in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 5
    Last Post: Dec 14, 2017, 15:44

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •