EasyManua.ls Logo

ASTRO-PHYSICS GTO - Incorrect GMT Offsets When Polling the Mount from the Keypad; Western Longitudes at Time Zone Zero; Eastern Longitudes and Time Zone 12; Eastern Longitude Limit

ASTRO-PHYSICS GTO
95 pages
Print Icon
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
71
therefore affects proper operation of the mount from the very beginning. It is important if you are in a western longitude
with an eastern time zone that you make the adjustments outlined above to ensure correct and safe operation. Both the
servo and the keypad use the “equations of time” to calculate the meridian and the horizons. The equations of time start
from GMT, and then incorporate your longitude. The important thing to remember is that both the keypad and the servo
must be able to determine the correct GMT in order to know where the meridian and the horizons are in terms of right
ascension values. From the main menu, you can always check the 4=Time/LST button to verify that GMT is correct.
Incorrect GMT Offsets When Polling the Mount from the Keypad
(see p. 44) Keypad v.4.17 addresses a bug with the 3=Get Time/Loc FrMnt command in the 2=Setup => 1=Locations
& Time menu. Earlier versions of the keypad rmware did not return the correct value for the GMT offset from the mount
when polled from the keypad in eastern time zones. This problem only occurred with GTOCP3 control boxes because
they return negative numbers for eastern offsets whereas the older GTOCP1 & 2 returned text for the negative values. In
all cases, the correct values were being sent to the mount’s servo, and all other mount functions relating to the GMT offset
were handled correctly. Version 4.17 will now return the correct values for all time zones except for the special cases
below.
Western Longitudes at Time Zone Zero
(see p. 44) There is one major issue that remains when using the 3=Get Time/Loc FrMnt command: Customers in
western longitudes who are in time zone 0 cannot poll the mount and get the correct offset when daylight savings time is in
effect. This will affect customers in Great Britain, Portugal and West Africa. The keypad sends the correct information to
the mount servo, but it cannot retrieve it correctly at this juncture, because it wants to apply the “west” standard to the “01”
that is returned from the mount. This erroneously puts the offset as one hour behind GMT instead of one hour ahead of
GMT. Customers affected by this bug have two options until version 4.20 is released: 1. Do not use the 3=Get Time/Loc
FrMnt command when daylight savings is in effect, or 2. Keep your keypad, computer etc. on standard time so that the
system’s time always equals GMT.
Eastern Longitudes and Time Zone 12
There is an additional minor remaining issue with the 3=Get Time/Loc FrMnt command, but it should be of no consequence
to anyone that we are aware of. If you happen to be in time zone 12 east and observe daylight savings time giving an
offset to GMT of local time – 13 hours, AND you are using a GTOCP1 or 2, you cannot use this command. Again, all data
sent to the mount is ne; you just can’t have the keypad poll the mount for your time and location data.
Eastern Longitude Limit
(see pp. 14-16) The last issue will only affect people in the Fiji Islands and in far north-eastern Siberia. Because of the
longitude issue outlined above, an eastern longitude above 178° 59’ 00” should not be used. At this time, we know of no
one who is affected.
The International Date Line
The region on either side of the International Date Line (IDL) has the potential to pose some problems. First of all, the
IDL is not a straight line at exactly 180° from the Prime Meridian. There are Pacic Islands (Tonga, parts of Fiji, Chatham
etc.) whose longitudes would be measured as West, but who are in an eastern time zone. Likewise, many of the western
Aleutians are actually in eastern longitudes, but have western time zones. The keypad will not allow a time zone greater
than 12 or a longitude higher than 180° either east or west. Fortunately, we again know of no customers in these locations,
but you never know… This is where we would have to trick the system.
Let’s say you have taken your Mach1GTO on a South Pacic Dream Vacation in Tonga at 175° 08’ West Longitude, but at
13 hours east time zone. (Thank goodness there’s no DST in Tonga!) Since you want to begin with some solar observing
you decide to use the Daytime Polar Alignment Routine which requires accurate time, date and location information to be
successful. (The mount must know the exact LST to know the RA and Dec values for the Park Positions. (See pp. 23-28)
The key to successfully tricking your mount is to remember that your DATE must be backed up by one day if in a western
longitude with an eastern time zone, and it must advance by one day if in an eastern longitude with a western time zone.
For my Tonga example, let’s assume it is Feb. 15th, and local time is 3:15pm (15:15:00). You already entered the correct
longitude of 175° 08’ 15” W and the correct latitude of 21° 10’ 47” S and then entered the time zone as 24 – 13 = 11 hours
west. (The keypad will assign the west time zone because the longitude is west.) You check the GMT by pressing the
4=Time/LST button and see that it correctly reads 02:15:00. The problem is that your mount will be calculating LST one
day off amounting to about +4 minutes of LST error or about 1° off (west) in your Daytime Polar Alignment Routine. To

Table of Contents

Related product manuals