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 CmdrJaycee@aol.com wrote: >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 ******************************************* Paul Gabriel 26.24310N 098.21635W 33m (the stars at night are big & bright......) gabriel305@earthlink.net titan / win95C / Calypso ----------------------------------------------------------------- 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 - 06:38:56 PDT