Re: Another ISS reboost this morning ...

From: Paul Gabriel (
Date: Sun Sep 17 2000 - 06:26:15 PDT

  • Next message: Ted Molczan: "91082a elements"

    it is relatively easy if you have a spreadsheet, eg, 
    excel or quattro (lotus) to set it up to spit out these
    conversions, UTC, date and time decimal conversions -- I did it,
    so ...
    *********** REPLY SEPARATOR  ***********
    On 09/17/00 at 08:52 wrote:
    >In a message dated Sun, 17 Sep 2000 02:38:04 -0400, JAY RESPLER 
    ><> 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:   
    >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 
    ><> writes:
    >    >For Jim Cook, here's a page that may include a useful Mac calendar
    >    >conversion program:
    >    >
    >    >
    >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 
    ><> 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
    Paul Gabriel
    26.24310N 098.21635W 33m (the stars at night are big & bright......)
    titan / win95C / Calypso
    Unsubscribe from SeeSat-L by sending a message with 'unsubscribe'
    in the SUBJECT to

    This archive was generated by hypermail 2b29 : Sun Sep 17 2000 - 06:38:56 PDT