Satgen251  Satellites and Calendars Part 2    by GM4IHJ       15 Jan 94
BID of this msg is SGEN251   Please use this BID if you retransmit the msg

Part 1 of this bulletin described how an accurate Earth calendar was
obtained, and mentioned that observers of objects in space must use a
different calendar with one extra rotation ( day ) , to allow for the
Earth's annual orbit around the Sun. This Space or Star time is called
Sidereal time. If you want to point your telescope at a star or your
antenna at a satellite, you tell your computer the Earth date and time
Greenwich ( UTC) and it works out the sidereal time for you before
indicating the position of the star or satellite. This is not an easy
calculation particularly if your satellite Keplerian elements are say 1992
and you wish to calculate the satellites position in 1993. You have to
allow for the fact that 1992 is a leap year so it has 366 days. Or if you
have 1995 elements and you wish to use them in March 96 you have to allow
for the February 29th. But it is much worse when you track deep space
satellites or the planets and moons. Their Ephemeris data is usual given
as either 1950 or more recently year 2000. To cope with all the leap years
and leap days , a special system called the Julian day system is used.
PLEASE NOTE this is not the old calendar of Julius Caesar which was
abandonned in the 17th century, NOR IS IT, the Day of the year used in
NASA KEPLERIAN ELEMENTS and sometimes mistakenly refered to as Julian Day.
The true JULIAN DAY system counts days since Noon ut on January 1st 4713
BC. Note 4713 years before the start of the Christian era. A method which
allows correlation of modern and ancient Eg Babylonian or Chinese
astronomical reports. Your computer software should know how to calculate
sidereal time for any date using the Julian day count , so unless you use
a copy of the old W3IWI software you will be OK. W3IWI of 1982 needs the
insertion of a new sidereal time correction variable on Jan 1 each year.
So most Radio Amateur software does it all for you. But if you get
software you are unsure about , how can you test it ?
Run the software for 2356 ut 31 Dec 1966 to get an example for 0000 and
0002 utc as it runs on into Jan 1st 97 Eg
0000ut 9Az 1El 82N 321W  and 0002ut 18Az -4El 79N 280W
Then restart your software at 0000 ut 1 Jan 97 you should get exactly same
Do the same for a non leap year change Eg 1994 to 1995 to get say example
0000ut 168Az -70El -83 298W and 0002 157Az -72El -78 269W
Then restart your software at 0000ut 1 Jan 95 you should get the same .
If both these checks give results which agree your calendar is working OK.
 However if you write software please remember the following story :- Some
years ago a Texan pirated IHJ software . HE "decided" the calendar it used
was too elaborate so he rewrote it and sold it widely as "improved IHJ" .
Came the 1st Jan 89 and his 300 or so customers found that his calendar
did not allow for the 366 days in leap year 1988. So Epoch 88 keps
produced data a day out. He did not know what was wrong. So his customers
asked for their money back. But he had spent it. In the ensuing agrovation
. He sold his home , bought a trailer caravan and disappeared into the
wild blue yonder. So be aware the calendar in your software needs to be
complex. Please also note that if you want accurate tracking of the Moon
or Planets you must use Ephemeris based on the Sun , not the Earth. This
allows you to used ephemeris based on standard dates Eg 1 Jan 2000 or 1
Jan 1950. For the way out planets which take several leap years for an
orbit , and even for the Moon ,Julian Day and Solar centred ephemeris is
the only way to work accurately. 73 de GM4IHJ @ GB7SAN