Re: Another ISS reboost this morning ...

From: CmdrJaycee@aol.com
Date: Sun Sep 17 2000 - 05:52:33 PDT

  • Next message: Paul Gabriel: "Re: Another ISS reboost this morning ..."

    In a message dated Sun, 17 Sep 2000 02:38:04 -0400, JAY RESPLER 
    <jrespler@superlink.net> writes:
    
         >> Jim Cook wrote:
         >> Unfortunately, I'm all thumbs with UTC conversions.
         >
         >Seems pretty simple. 
    
    Not if you're right-brained. ;-)
    
    No, seriously, it's not quite that simple, especially if you are not used to 
    working with UTC decimals in the format NASA uses, which I rarely do beyond 
    copying and pasting.  You are looking, say, four or five days ahead.  You see 
    Heavens-above shows a decent STS-106 pass, say, around 5:30 AM local time.  
    You know NASA is going to make a few orbit changes before then.  You have to 
    figure out which UTC number date (259, 262, etc.) applies to the date of the 
    pass, as predicted by H-A, then figure out what the decimal should be.  (And 
    then go to the Real Time Data page(s) to see which TLE to use.)
    
         >The fraction of a day is constant no matter how many days
         >there are in a month. They are completely independent of each other.
         > You usually don't need the exact conversion. Roughly, .1 would be 
         >2.4 hours.  .25 (1/4 day) is 6 hours. .5 is 12 hours. 
    
    That's true, but I, for one, still need to work with them a lot more than I 
    do before the fractions and decimals sink in.  And the process is backwards; 
    H-A gives you the rough time, x-days from now, and you have to convert that 
    into NASA's UTC decimal format.  
    
         >Sue Worden wrote:
         >
         >>A "trick" I've used
         >> for that is to mark up my calendar at the beginning of each year.
         >> At the top of January goes a "0"; at the top of February goes a
         >> "31"; at the top of March goes either a "59" or "60".  You get
         >> the idea.  The "day" value is then the date in the month plus
         >> the number at the top of the month, e.g., February 17 is day
         >> 17+31. 
         >
         >Ok, here we're talking about day #. I have a little chart that shows #
         >of each day of year. I can post it on my Sky Views web site (below) if 
         >there's enough interest. Mailed photo copies can be arranged too.
    
    Sue, Jay, before anyone goes to any trouble here -- a few things to keep in 
    mind.  One is that the, once the final separation burn is completed later 
    today (or early tomorrow), we won't really need to use the Real Time Data 
    TLE's much for the remainder of the STS-106 mission (except perhaps those 
    along the reentry path), so there's no hurry.
    
    But I also discovered yesterday that Chris Peat's H-A page -- under the "What 
    Time is It?" link, there's the current date and time, in precisely NASA UTC 
    decimal format (or, as I type this: "Time in two-line element format:   
    00261.51090278").
    
    Knowing this, it should be much easier to figure out the NASA UTC decimal for 
    a pass a few days into the future.   People may still have to do a little 
    figuring, but this gives us a head start.  [You would simply add the number 
    of days remaining until the pass to the H-A NASA UTC date.  For the decimal, 
    if 1 hour is .04166666667 days (1/24) , then you would round the number of 
    hours of difference between the current hour and the hour of the predicted 
    pass, and multiply that by .04166666667, and then add or subtrack that to the 
    decimal portion of the H-A NASA UTC time.  I think ... ;-)]
    
    Plus, maybe the best answer to simply approach NASA about the problems many 
    are having using their Real Time Data pages.  Perhaps they can add an FAQ 
    (let THEM write this one ;-), or perhaps they could add another JAVA applet 
    to let visitors to their Real Time Data pages enter the Date and Time of an 
    expected pass, (specifying their time zone), and have it compute the 
    corresponding NASA UTC decimal.  I think if they knew how confusing those 
    pages can be for a lot of people, they might be amenable to looking into ways 
    to make it easier to use.
    
    In a message dated Sat, 16 Sep 2000 18:17:55 -0500, Ed Cannon 
    <ecannon@mail.utexas.edu> writes:
    
        >For Jim Cook, here's a page that may include a useful Mac calendar
        >conversion program:
        >
        >http://allmacintosh.xs4all.be/tangerine/calclokmac.html
    
    Thanks, Ed.  I'll go through those (there must be two dozen or more) and see 
    which look promising.  Maybe there's a perfect answer among them.
    
    In a message dated Fri, 15 Sep 2000 21:35:33 +0000, Jonathan T Wojack 
    <tlj18@juno.com> writes:
    
        >>But then the Real Time Data page, oddly, had replaced the shuttle 
        >>orbit numbers with ISS orbit numbers, confusing the hell out of me.  
        >
        >ISS orbit numbers?  You mean numbers like 13000 (ISS has made 
        >around that many orbits)?
    
    No, what I meant was, where the "Real Time Data Orbital Elements - Shuttle" 
    page had been referencing headings such as "Coasting Arc #11 (begining on 
    orbit 152),"
    it suddenly began showing the orbit numbers as 2367, 2454, etc., which I 
    eventually confirmed were the corresponding ISS orbit numbers.  It was a 
    curve ball I wasn't expecting.  But as I said, NASA was back using shuttle 
    orbit numbers the next day.
    
    Well, that's it.   This note's gone on long enough. 
    
    Jim Cook
    Germantown, MD
    39.2N, 77.3W
    
    -----------------------------------------------------------------
    Unsubscribe from SeeSat-L by sending a message with 'unsubscribe'
    in the SUBJECT to SeeSat-L-request@lists.satellite.eu.org
    http://www2.satellite.eu.org/seesat/seesatindex.html
    



    This archive was generated by hypermail 2b29 : Sun Sep 17 2000 - 05:53:14 PDT