[time-nuts] Sidereal time

Bill Hawkins bill at iaxs.net
Sat Jan 16 03:48:07 UTC 2010


Magnus,

I learned a technique for adjusting time that doesn't require floating
point calculations, back when a FP Package significantly slowed micro
processing, circa 1980.

Use a preset counter to count incoming pulses, perhaps 1 PPS. Set it
for the number of pulses that will make a one pulse adjustment, up
or down. When it rolls over, double or cancel the next pulse on its
way to the clock  counter. The maximum clock display error is one pulse.

To carry it out to several decimal places, you need successively larger
counters to add or subtract a pulse.

I know this is heresy, but you don't need any programming skills, or
micros and compiler packages and endian calculations and debug tools
and training time to do this simple pulse manipulation in hardware.

If a person has programming skills, it is possible to implement the
counters and adjustments in a micro that doesn't have FP math.

Ah, I don't think "or -1,211 arcmin per day or -0,44 arcmin per year"
is correct. More change per day than per year? What have I missed?

FWIW,
Bill Hawkins
 

-----Original Message-----
From: Magnus Danielson
Sent: Friday, January 15, 2010 8:48 PM

While displaying Hour Minutes and Seconds of apparent local sidereal 
time may be fun, the actual need is to calculate an angle in degrees and 
minutes for which the object of interest position can be converted into 
suitable pointing angle.

The simplest approximation can make use of the fact that on 365,25 
normal days, there is 366,25 sidreal days. The error of that 
approximation is 366,25/366,2425/365,25*365,2425 - 1 = -5,6E-8 days/day 
or -1,211 arcmin per day or -0,44 arcmin per year. The Gregorian 
correction was used for comparision value rather than a tabulated value, 
but I was lazy to get a quick back-off-envelope type of result.

My point being that fairly simple approximate "gears" could be used to 
give a good-enought result such that remaining drift can be compensated 
using regular observation. Pointing towards known fix-stars for 
calibration of local position, local pointing error and clock offset 
would end up as a single correction factor of pointing angle correction.

The only thing one wants is that date, time and position sets the local 
sidreal time close enought for manual correction to be a matter of minor 
adjustments.

To convert the day (D) of a year into a sidreal day (DS) one gets
DS = D*366,25/365,25 = D + D/365,25

For hours we would use the relation HS = 24*DS, D = DI + H/24 and used 
modulo 24

HS = 24*D + 24*D/365,25 = 24*DI + H + 24*D/365,25 = H + 24*D/365,25

Thus, the time of day is adjusted with the date, but there is no need to 
calculate the full number of seconds. Similarly may the time of day be 
converted to degrees.

AS = 360*DS mod 360 = 360*D + D*360/365,25 mod 360
    = 360*DI + 15*H + DI*360/365,25 + H*15/365,25 mod 360
    = 15*H + H*15/365,25 + DI*360/365,25 mod 360

H is then broken into HI, MI and SI for normal wall-clock 
representation. This approximate convertion on the back-of-envelope 
level has silently ignored the phase error, but retracing to the USNO 
webpage should allow a more thorough calculation of a suitable offset.

The remaining mod 360 operation needs to handle the addition of three 
0-360 degree ranges, so the range only needs to extend over 1080 degrees.

 From the above formula it becomes apparent that the pointing needs an 
adjustment of about a degree every day and about 2,464 arcmin every hour.

So, a very coarse calculation could be good enought. A fairly trivial 
calculation with a correction from date and fine-correction for hour and 
minute may provide enought pointing precission. It is trivial to correct 
for local offset from the UTC time using the GPS position.

Should be doable even for a tiny processor. Should be not too hard to 
include into a motor control to keep the scope pointed to the right point.

Cheers,
Magnus






More information about the Time-nuts_lists.febo.com mailing list