Release notes for the Astrometric Telescope Control System

Including details on SkyWalker firmware and Maestro software upgrades

Version: Beta 0.29.052
Date released: 12-May-2010

This Astrometric Telescope Control System (ATCS) upgrade comprises the upgrade of SkyWalker firmware and Maestro software. Maestro is the default SkyWalker client/user-interface software for Microsoft Windows based PCs.

Important notes

  1. Upgrading Maestro software will lead to SkyWalker firmware upgrade. When the new/upgraded Maestro is connected to the S-Box for the first time it will detect any older firmware version and ask if you wish to upgrade. Select yes. All SkyWalker firmware upgrade files are included in the latest Maestro release so there is no need to download them separately.

  2. To install Maestro download and run the MaestroSetup0_29_052.exe file which can be found on our support page.

  3. The following feature changes may require that previous settings be changed or re-instated:
    • Old Park positions will be invalid. The Park position (if used) MUST be re-marked.
    • SkyWalker's previous concept of Meridian, Down and Up limits have been changed to Soft limits and are defined as separate East/West/Up/Down limits. This is to provide consistency with SkyWalker's new Axial (Hard) limit features. If you use standard default settings (e.g. for Losmandy G-11) then no action is necessary however if you have a custom mount the Soft limits (on the Instrumental page) should be reviewed. Additional details are included in the "New Soft Limit features" section below.
    • After upgrading to version 0.29.052, the AlignFromLast feature is unavailable until a new celestial alignment is completed.

  4. Maestro does not work with SkyWalkers shipped prior to May 2010 unless that SkyWalker has been upgraded to a "smart" SkyWalker with the S-Box accessory.
<====================== This file best viewed with fixed-font at this screen width or greater =========================>

Note to beta testers

Several beta SkyWalker firmware and Maestro software upgrades were released since the June 2006 0.20.000 release.  We
would like to thank anybody who used these beta releases.  The release notes below do not distinguish with which beta
release various features were deployed.  The release notes below are a compilation of all changes since 0.20.000.

New features in this release

New SkyWalker features in 0.29.052 (i.e. new since the 0.20.000 release)

Note: many of these features are paired with Maestro features and the descriptions of how to use the new features are
  presented in the section titled "The following Maestro features are new since the 0.20.000 release".

Added support for Telescope Control System (TCS) peripherals
Telescope Control System peripherals are add-one hardware accessories that expand the capability of the SkyWalker
system.  Presently, the following new peripherals are available:

  - Automation Module which provides home-indexing, absolute Axial Hard Limits (Axial coordinate of limit can be set)
    and Hard Limit "back-out" capability.  These features upgrade SkyWalker to fully-remote and fully-autonomous
    capability.  More details on the Automation Module are provided below.

  - High Resolution Encoder Module (HREM).  The HREM provides interface to very high resolution and high bandwidth
    axial position encoders which allow high accuracy closed-loop pointing AND tracking.

  - SwitchPro "HighDrive" and digital/analog I/O module.  This provides high power "switched" device control and
    general purpose I/O.

  - New HP1 handpaddle that is functionally identical to the older model however it a) works with the S-Box and new
    SkyWalkers and b) has a replaceable cable.  Note: if a new HP1 is plugged into the S-Box while an old HP1 is plugged
    into an old SkyWalker then only the old HP1 will function (the new HP1 will be disabled and no damage will result!).

Dynamic Correction (DynaCorr) feature
### Note: in 0.29.052 DynaCorr is only qualified for use with Lower Meridian Avoidance.  This means it works for fork-
  type mounts but not German Equatorial mounts.
### Note: once DynaCorr is fully qualified it will become a reasonably-priced licensed option tied to the SkyWalker

SkyWalker now includes a dynamic error correction feature.  This feature, called DynaCorr, corrects for several errors
associated with pointing and tracking a telescope.  DynaCorr does not simply adjust GoTo targets (like other non-
integrated solutions); rather it continually (many times a second) adjusts telescope position to compensate for errors.

Presently, SkyWalker includes dynamic correction for the following errors:
  - Atmospheric refraction: this correction was included in previous SkyWalker firmware versions.
  - Axial misalignment: either polar misalignment (for polar mounts) or misalignment of the Scope Pole from the
    zenith for Alt/Az telescopes.
  - Non-perpendicularity errors: corrects for Dec/Alt not perpendicular to RA/Az and optical axis not perpendicular to
  - Index (zero-point) errors: corrects for fixed offset errors in Axial coordinates.
  - Harmonic errors which for gearing eccentricities or out-of-round (supporting periods of from once-per-rev to
  - Flexure errors including tube flexure, fork flexure and dynamic change in axis perpendicularity with change in
    telescope position.
  - Scale error in each axis to correct for non-precise determination of motor steps or encoder counts per revolution.
  - Optical "flop" error for Alt/Az telescopes where primary mirror shifts offset the image.

SkyWalker's DynaCorr feature only CORRECTS for telescope errors.  DynaCorr does not derive telescope errors from
measured data however there are a few options for characterizing a telescope to derive errors.  These include:
  1.	Patrick Wallace's ProTPOINT is licensed for telescopes or 0.5m or larger.
  2.	TPoint from Software Bisque which is the TPoint version licensed for telescopes smaller than 0.5m.
  3.	MaxPoint from Diffraction Limited.

Additional details on the DynaCorr coefficients included in 0.29.052:
  - IX: Offset error on the Axial X axis: positive if a positive correction needs to be added to all AxialX values (i.e.
    observations are errored negative).
  - IY: Offset error on the Axial Y axis: positive if a positive correction needs to be added to all AxialY values (i.e.
    observations are errored negative).
  - SA: the error in the Scope Pole Angle, which is the vertical angle of the Scope pole with respect to the zenith.
    SA is positive if the Scope Pole is high for equatorial instruments, in which case the Scope Pole Angle needs to be
  - SH is the horizontal error in the nominal Scope Pole position.  SH causes rotation on the plane including the
    ScopePole and AxialX +/-90deg.
  - YX is the deviation from 90 degrees of the angle between the telescope's Axial Y and X axes.  A positive YX value
    means the scope is biased towards the right when the scope is pointed towards the Scope Pole.
  - OY is the deviation from 90 degrees of the angle between the telescope's optical and Y axes.  A positive OY value
    means the scope is biased towards the left when Axial X is 0.0.
  - YXD coefficient: Dynamic non-perpendicularity between AxialX and AxialY.
  - SX: Scale error in Axial X
  - SY: Scale error in Axial Y
  - FF: Fork flexure
  - FS: Tube flexure sin-law
  - FT: Tube flexure tan-law
  - FL: Optical "flop"
  - Harmonic coefficients
    X1F: Axial X harmonic1 frequency (cycles/rev -- a real # <=20)
    X1M: Axial X harmonic1 magnitude (arcseconds)
    X1P: Axial X harmonic1 phase (degrees)
    X2F: Axial X harmonic2 frequency
    X2M: Axial X harmonic2 magnitude
    X2P: Axial X harmonic2 phase
    Y1F: Axial Y harmonic1 frequency
    Y1M: Axial Y harmonic1 magnitude
    Y1P: Axial Y harmonic1 phase
    Y2F: Axial Y harmonic2 frequency
    Y2M: Axial Y harmonic2 magnitude
    Y2P: Axial Y harmonic2 phase

The correspondence between DynaCorr coefficients and TPoint terms is provided in an Excel spreadsheet available from
Astrometric Instruments.

Notes related to Dynamic Correction
  - Stability near the Scope Pole is not assured when Dynamic Correction is used.  A low-velocity "run-away" is
    possible for targets at very high Axial Y.  Stability is assured, even for maximum corrections to 88deg in Axial Y
    (88deg Dec for Polar or 88deg Alt for Alt/Az).
  - Dynamic Correction is not yet qualified for use in Secondary Scope orientation like would get after GEM meridian

Improvement to Park position
SkyWalker now defines the Park position in Axial coordinates rather than Alt/Az coordinates.  This resolves the problem
with previous SkyWalker firmware versions where Park position would become non-deterministic if it were "marked" in the
Meridian "overlap" zone (i.e. it could be reached from either side of the Meridian).  Additionally, since Park position
is now expressed in Axial coordinates, it is no longer necessary to be aligned to park the telescope.

Note: if the Park position was marked when running a previous version of firmware it will have to be "remarked" with
version 0.29.052.

Support for Alt/Az telescopes
Version 0.29.052 ports SkyGuide's Alt/Az capabilities to SkyWalker and provides support for "level" Alt/Az telescopes.
These are Alt/Az instruments for which the azimuth axis aligns on the celestial zenith (as determined from site latitude
settings).  The Alignment->AlignmentType setting on Maestro's Settings tab now includes "AltAz" in addition to the
"Polar" option included in pre 0.29.052 versions.

Added support for Homing.  This includes all functionality necessary to use home position switches (one on each axis)
with the Automation Modules to provide the "Align from Home Seek" feature.  Specifically, this includes:
  - Features for setting up Homing support
    - Settable direction from which the Home Index is to be "discovered" for each axis.
    - A HomeDiscover feature instructing SkyWalker to find ("discover") the Home Index on each axis and record the index
      coordinates for use later with the HomeSeek and AlignFromHome features.
  - Features providing "Align from Home Seek" functionality
    - HomeSeek feature which initiates a sequence to find the Home Index in each telescope axis.  Once the indexes are
      found SkyWalker's Axial coordinates are set to the coordinates found with the HomeDiscover command.
    - AlignFromHome command which completes the alignment after the HomeSeek has put the telescope at its home position.

  - Homing functionality requires that Automation Modules (TCS peripherals) are installed in the SkyWalker system.
  - A "Home Seek" timeout is included.  If the home index "seek" operation exceeds this timeout value the homing is
    canceled and a warning with the following text is issued: "Home Seek timed-out prior to finding both home index
  - Further information is provided in the "Automation Module User's Manual" (part number DOC-14).
  - The HomeSeek command checks that a "last" position is available.  If not, the message "Cannot Home Seek since no
    previous last alignment established." is issued.  This assures that the initial GoTo of the HomeSeek, which is to
    the starting position for searching for the home index switch, is based on Axial coordinates that are properly

Intelligent Axial Hard Limits
Added support for intelligent Axial "hard" Limits of motion when using our new Automation Module TCS peripheral.  New
functionality includes:
  - Support for East/West Axial Limit switches in RA/Az and Up/Down Axial Limit switches in Dec/Alt.  The definition of
    Axial Limit angles are the same as for the new Soft Limit definitions (see next item).
  - Action when Automation Module detects that an Axial limit is hit:
    - All motion terminated
    - Alignment voided
    - Axial coordinates set to the pre-set coordinate of the limit.
    - Automation Module Hard Limit output (which is feed into SkyWalker's HardLimit input) asserts.

Axial Hard Limit act regardless if SkyWalker is aligned or not.

The SkyWalker and the Automation Module provide a Hard Limit "backout" feature that utilizes the Automation Module's
fixed Hard Limit disable timer.

  - Axial Limit functionality requires that Automation Modules (TCS peripherals) are installed in the SkyWalker system.
    See our "Automation Module User's Manual" (part number DOC-14) for more information.
  - Further information is provided in the "Automation Module User's Manual" (part number DOC-14).
  - For any Axial Limit to be enabled its corresponding Soft Limit (see next item) must also be enabled.  The Down Soft
    Limit is always enabled (it cannot be disabled).
  - For Full(GEM) Meridian Avoidance, there is no Up Axial Limit.  Dec/Alt Automation switch input connections are as
    - Negative switch input hooks to the Down Limit which is used for Primary Scope Orientation
    - Positive switch input hooks to the Down Limit which is used for Secondary Scope Orientation.
    Primary Scope Orientation is defined as the side of the Scope Pole that the telescope is on when the Dec/Alt motor
    polarity is valid.

New Soft Limit features
Overhauled "soft" limits (e.g. Meridian, Up and Down limits) to be consistent with the new Axial Limit capability.
Specifically; East, West, Down and Up limits are now provided as Soft Limits and, separately, as Axial (hard) Limits.
New limit angle definitions and restrictions (apply to both Soft and Axial limits):
  - East/West limits are measured from the Celestial Meridian.
    - The East limit defines the limit of motion when the telescope is pointing into the East.
    - The West limit defines the limit of motion when the telescope is pointing into the West.
    - For Full(GEM) Meridian Avoidance:
      - A positive limit value means the telescope avoids the Celestial Meridian by the limit value.  A negative limit
        value means the telescope is allowed to move through the Celestial Meridian by the limit value.  Note: if the
	sum of the East and West limits is < 0 then there is an overlap zone, near the Celestial Meridian, that can be
	reached from either the East or the West.
      - Each limit is restricted to the range <= +45.0deg, >= -45.0deg.
    - For Lower Meridian Avoidance:
      - The limit value defines how far from the Celestial Meridian the telescope is allowed to move.  Note: if the sum
        of the East and West limits is > 360 then there is an overlap zone, under the Celestial Pole, that can be
        reached from either the East or the West.
      - Each limit is restricted to the range <= +225.0, >= +45.0
  - Down Limits express the minimum allowed angle downwards from the Scope Equator and are restricted to the range
    <= 90.0deg, >= -45.0deg.  A negative value places the limit above the Scope Equator.
  - Up Limits express the minimum allowed angle upwards from the Scope Equator and are restricted to the range
    <= 135.0deg, >= 45.0deg.  Note: any value larger than +90.0deg allows for passage through the Scope Pole.
    Note: the Up Limit is not used for Full(GEM) Meridian Avoidance.
  - There are no restrictions on the position of any Axial Hard Limit with respect to the corresponding Soft Limit
     however it is strongly recommended that Soft Limits are made a comfortable amount more restrictive than the Axial
     Limits to prevent hitting the Axial Limits under normal operating conditions.

Soft Limits act only if SkyWalker is aligned.

IMPORTANT NOTE: Due to the above overhaul of Soft Limits, users of Lower Meridian Avoidance (i.e.  Fork mounts) should
be aware that the East/West Soft Limit settings are defined differently than the old East/West Meridian Limits.
Specifically, the limits are measured from the "upper" Celestial Meridian (portion of meridian from pole through zenith)
rather than "lower" Celestial Meridian (portion of meridian from pole down to horizon *not* passing through zenith). For
Full(GEM) Meridian Avoidance, SkyWalker will read old/existing Meridian Limit settings and apply them as new Soft Limit

Here is the change in definition between the old and new Soft Limits...

   Old								New
   ---								---
   East/West Meridian Limits					East/West Soft Limits: in deg off the Celestial Meridian
     For Full(GEM): degrees off the upper Celestial Meridian		   
     For Lower: degrees off the lower Celestial Meridian
   Scope Pole Limit (degrees down from Scope Pole)		Up Soft Limit: in degrees ABOVE the Scope Equator
   Down Limit (degrees down from Scope Pole)			Down Soft Limit: in degrees BELOW the Scope Equator
   Note: when Meridian Avoidance is Full(GEM) the following applies:
    - The Up Soft Limit is disabled to allow for Meridian flips
    - The Down Soft Limit is symmetric and applies on either side of the Meridian

Additional notes on limits:

- SkyWalker now allows the Up Soft (and Axial) Limit to be set "through" the Scope Pole into the Secondary Scope
  Orientation.  The Up Limit is measured off the Scope Equator and can be up to 135 degrees (which is 45 degrees past
  the Scope Pole).  Note: when using Full(GEM) Meridian Avoidance, Up Limits are disallowed and the Down Limit is
  applied in both Scope Orientations (i.e. on both sides of the meridian flip).

- The East/West Soft limits, for Lower Meridian Avoidance, can be more restrictive than in previous firmware versions.
  Previously, East/West limits could not be set further than 45 degrees from the LOWER Celestial Meridian.  Now they
  can be set as close as 45 degrees to the UPPER Celestial Meridian (i.e. 135 degrees from the LOWER Celestial

- Full Meridian Avoidance is now specified as "Full(GEM)" (used to be just "Full") to indicate its use on German
  Equatorial mounts.

Axial Coordinate System
SkyWalker's Axial coordinate system has been exposed (as status on Maestro's Diagnostics tab).  Axial coordinates are
the nominal coordinates that SkyWalker calculates for the telescope axes.  Axial coordinates are the output of
SkyWalker's pointing model.  Axial coordinates are further modified by PEC, Backlash Correction and Axial Encoder
Track Lock corrections into Motor coordinates.  Motor coordinates represent the position of the motor shafts and are
expressed in number of steps.

Axial coordinates are defined as follows:
  - X-axis (e.g. RA axis on equatorial telescopes or Az axis on Alt/Az telescopes):
    - 0.0 at the Celestial Meridian
    - Increasing to the left (i.e. Eastwards in the Northern hemisphere).  Or, alternatively, increasing CCW looking
      down from the Scope Pole.
    - Decreasing to the right (i.e. Westwards in the Northern hemisphere).  Or, alternatively, decreasing CW looking
      down from the Scope Pole.
    X-axis coordinates do not "wrap"... that is to say that they continue to increase/decrease as the telescope
    rotates through multiple turns.
  - Y-axis (e.g. Dec axis on equatorial telescopes and Alt axis on Alt/Az telescopes):
    - 0.0 at the Scope Equator (i.e. Celestial Equator for equatorial telescopes or horizon on Alt/Az telescopes).
    - Increasing upwards towards the Scope Pole
    - Decreasing away from the Scope Pole
    - Analogous to declination for equatorial telescopes in the Northern hemisphere and analogous to altitude on Alt/Az

High Resolution Encoder Module (HREM)
Added support for RA/Az and Dec/Alt High Resolution Encoder Modules.  The HREMs are SkyWalker TCS peripherals that
provide 2Mhz sampling of high resolution optical encoders used on the telescope axes (this is a 100X increase in sample
rate over SkyWalker's standard encoder port which samples at 20kHz).

The HREM modules also enable SkyWalker's new closed-loop tracking feature: see next item.

Axial Encoder Track Lock (AETL) feature
When enabled, Axial Encoder Track Lock (AETL) adjusts the motor velocities such that the telescope position follows the
axial encoders in a closed-loop manner.  Without AETL the motor position is applied open-loop and the Calibrate From
Encoder feature provides the only means to close the loop with axial encoders.

The way that AETL works is that SkyWalker samples axial encoder position very 75 milliseconds and if it differs from the
motor position by more than +/- 1 encoder count then the motor is issued +/-X motor steps where X is the correction that
is applied each Tick (see below).  If the difference between axial encoder and motor position differs by more than 100
encoder counts then AETL is disabled and a warning is issued.

The correction that is applied each Tick, when an encoder-to-motor discrepancy is detected, can be set using the
following options:
  - Number of motor steps to correct X motor position when a discrepancy with encoder position is detected. Default
    value is 1 and max is 10.
  - Number of motor steps to correct Y motor position when a discrepancy with encoder position is detected. Default
    value is 1 and max is 10.
  Note: the above values can be set to 0 and then the GetAxialEncoderTrackLockErrorX/Y ATCL command can be used to
  view un-corrected motor/encoder error.

A "cadence" value can be set that specifies how often (in number of 75ms Ticks) the application of corrections to motor
position occurs.

AETL only works well on telescopes where the correlation between encoder and motor position is quite accurate and there
are at least no large discontinuities between encoder and motor position.  Additionally, encoder position needs to be
fine enough to assure smooth tracking.  Encoder resolution of at least 0.5 arcseconds is recommended as a minimum.

To enable AETL, issue the SetAxialEncoderTrackLockEnabled ATCL command (e.g. from a script via the ASCOM CommandString()
method).  Once issued, SkyWalker will calibrate from encoder position (to assure 0 initial error) and then lock motor
position to encoder position so long as the Move Mode continues as Track.  If the Move Mode changes out of Track (e.g.
to Slew, GoTo) then AETL is disabled.  Hence, AETL must be re-enabled after a GoTo.  The GetAxialEncoderTrackLockEnabled
ATCL command can be used to poll and determine if AETL is still enabled.  Axial Encoder Track Lock will also be disabled
if alignment is voided or any fault occurs.

SkyWalker will not allow AETL to be used when:
  - High Resolution Encoder Modules (HREMs) are not installed on both axes.  HREM modules are necessary to support the
    encoder sampling bandwidth necessary for AETL.
  - A given Axial encoder is disabled then AETL will not function in that axis.
  - The Axial encoder resolution, on both axes, is not at least 1/4 the motor step resolution.  For example, if the
    motor steps per rev is 4,000,000 then the encoder counts per rev must be at least 1,000,000.
  - Alignment is not complete
  - The Move Mode is not Track
  - SkyWalker has not be Tracking for at least 0.5 seconds

Encoder feedback change
Encoder feedback is no longer selectable between "OnDemand" and "Continuous".  Rather, encoders are either enabled or
disabled individually for each axis.  When an encoder is disabled then CalFromEncoders and AETL does nothing for that
axis.  Encoder diagnostic position is still available.

Maximum disparity allow for CalFromEncoders
Added a setting to bound the maximum disparity allowed between encoder and motor position during CalFromEncoders.
Specifically, for each axis, if encoder position differs from motor position by more than the
CalFromEncoderDisparityAllowed value then CalFromEncoders in that axis is disallowed and the warning "CalFromEncoders
in  disallowed since motor -to- encoder disparity too large" is issued.

Functionality added in support of SwitchPro
SwitchPro is a SkyWalker TCS accessory that provides HighDrive and analog/digital I/O support.  SwitchPro support
provided in SkyWalker 0.29.052 includes support for "High Drive" outputs (BiDriveA&B and UniDriveA,B,C,D).  This
functionality is identical to that provided by old SkyWalker1 and SkyWalker2 products.  Future SkyWalker firmware
releases will also provide support for SwithPro's 4 digital/analog inputs and 2 digital outputs.

When a SwitchPro TCS accessory is attached to SkyWalker, all BiDrive and UniDrive functionality (configurable from the
"Output Assignments" group on Maestro's Peripherals tab) is provided through SwitchPro.

Added Custom Track Rate
Version 0.29.052 ports SkyGuide's Custom Track Rate feature to SkyWalker.  The Custom Track Rate offset rate in RA or
Dec in arcseconds (sD.DD) per hour (max of +/-1,000,000 arcseconds/hour which is +/- 277.77 degrees/hour) is provided
by the client (e.g. Maestro).  The Custom Track Rate is applied on top of (i.e. relative to) Sidereal tracking.

  - If not celestial aligned, the Custom track rate is not applied (even if Track Rate is set to Custom)
  - At the completion of celestial alignment, or a GoTo, the Track Rate defaults to Sidereal or Drift depending on
    which is appropriate for the alignment or GoTo target.  Regardless, a GoTo always terminates with Track Rate NOT in
  - In ASCOM the +/-1,000,000 arcseconds/hour limit translates to:
    - RA: +/-18.4679549574 seconds per sidereal second
    - Dec: +/-277.77 arcseconds per second

Added support for UT1 offset from UTC
UTC (Coordinated Universal Time) is the standard timebase used for civil purposes the world over.  UTC is maintained by
atomic clock with occasional leap seconds added to compensate for the gradual slowing of Earth's rotation.  These leap
seconds keep the solar time (which is related to the mean hour angle of the sun) and civil time from drifting apart over

For astronomical position calculations a different flavor of universal time called UT1 is used.  UT1 represents the
rotation of the Earth in a smooth and continuous way and because of this UT1 is used as the most-accurate basis for
celestial coordinate system standards .  UT1 can differ from UTC by up +/-0.9 seconds.

When using non-celestial referenced alignment (e.g. Align From Last or Align From Home Seek) very accurate time is
necessary to calculate the present celestial position for the alignment.  The most accurate time for non-celestial
alignment is UT1.  Since SkyWalker's timebase is set from a PC, and the PC should be set from a civil standard time
source (i.e. UTC-based, see section xxxx for details on accomplishing this), then to provide the most accurate time the
difference between UT1 and UTC for the time of observation should be specified.  As mentioned above, the magnitude of
UT1-UTC can be as large as +/-0.9 seconds which results in ~+/-13.5 arcseconds of pointing error in RA for non-celestial
referenced alignments.

In general, this UT1-UTC difference is not predictable since, other than some seasonal periodic changes, the slowing of
the Earth's rotation is difficult to calculate.  Therefore, the UT1-UTC difference should be acquired from published
ephemeris.  A useful UT1-UTC ephemeris is available at  For example, on
28-Sep-2008, UT1-UTC = -0.48826 seconds however after the inclusion of a leap second on 1-Jan-2009 it becomes

Note: UT1_UTC_Offset is only used in the calculation of Local Apparent Sidereal time.  Standard time, UTC, local time
and Julian Date calculations do not use this offset.

Changes to forms of time
All SkyWalker status/reporting of universal time is now clearly labeled as UTC (Coordinated Universal Time).

The abbreviation "LST" to represent Local Standard Time has been eliminated due to possible interpretation as Local
Sidereal Time.

Local time (not Local Standard Time) has been removed from SkyWalker... it is of little use and was causing confusion.

Miscellaneous new features and/or changes
- Added support for GoTo "axial" position.  Previously, support was only provided to GoTo catalog/apparent celestial and
  Topocentric position.

- Added a Timer and Alarm function to SkyWalker firmware consistent with SkyGuide's capabilities.

- Added a TimeStamp function to SkyWalker firmware consistent with SkyGuide's capabilities.  Possible display formats
  are "UTC" of "Local".

- Now disallow ScopePole Avoidance if in Secondary Scope Orientation.

- Changed "Mount Assumption" to "Alignment Type" and the choices are "Polar" or "Alt/Az".

- When completing alignment the tracking rate is set depending on the type of alignment:
  - If the reference positions are celestial: Sidereal
  - If the reference positions are not celestial (e.g. Topocentric or Axial): Drift
  - If it is an align-from-last: no change to Track Rate
  - If align-from-home: Drift (so AtHome stays valid)
  Note: regardless of the Track Rate entered after alignment, after any subsequent GoTo SkyWalker will enter a Track
  Rate appropriate for the target type (e.g. Sidereal for celestial targets).

- New behavior when enter fault condition (e.g. Hard Limit, Over Current, Motor Stall):
  - Move Mode is set to Tracking
  - Track Rate set to Drift
  - All motion is terminated
  - Alignment is voided
  Previous firmware versions terminated motion at SkyWalker hardware however internally (in SkyWalker's "Pointing
  Model") motion ramped down per deceleration limits.  This let to the situation where if the telescope "bounced off"
  the Hard Limit then motion would stop/start/stop/start, etc.  Additionally, previous firmware versions would not void

- Some changes and clarification around Backlash compensation:
  - To the question of "why doesn't the backlash Applied X/Y (as seen on Maestro Diagnostics tab) change when the
    backlash Burst value is changed on the Instrumental tab?"... the answer is because the backlash value applied is
    only calculated when the motor direction changes.  So, if the Burst magnitude setting is changed then the motor
    direction has to be reversed for the Applied value to reflect that change.
  - Changed approach to backlash correction so that backlash correction is "de-applied" when backlash is turned off.
    This is per user request.

- For Site settings, the use of "GMT Offset" has been changed to Timezone.

- The standard definition for Hour Angle is defined as positive West of the Meridian.  SkyWalker now reports Hour Angle
  per that convention (previous versions where opposite of this).

- In previous versions of firmware, alignment below the Down Soft Limit or above the Up Soft Limit was allowed.  It is
  disallowed in version 0.29.052.

- Reverse refraction (used in the Reverse Pointing Model) is now calculated as the exact reciprocal of forward
  refraction.  This prevents low-velocity "run-away" as sometimes experienced near the horizon in previous
  firmware versions.

- Added a check to be sure that SkyWalker's firmware, when running on an S-Box connected to an old SkyWalker, does not
  exceed the calculation time limits imposed by the old hardware.  If all telescope control functions (e.g. several TCS
  devices, all Dynamic Corrections and refraction correction) are enabled then there is a risk of this happening.  If it
  does happen the error "InternalError: Too many calculations for old SkyWalker" will be issued (in Maestro) and
  S-Box/SkyWalker will have to be power cycled and some TCS devices disconnected, some Dynamic Corrections disabled
  (0-coefficents used) or refraction correction turned of.  This is NOT a problem for new SkyWalker models that do not
  require an S-Box to operate.

- Fixed a bug where align-from-last was available after a Latitude change.  This lead to an improper alignment for the
  new Latitude/site.

- Display of Refraction Correction Mag previously reported 0.00amin when in Drift Track Rate.  Now it reports "N/A".

- Changed the minimum allowable "Max acceleration" value to 0.5deg/sec2 min.  This is consistent with the same
  (preexisting) restriction on ViewAcceleration.

New Maestro features in 0.29.052 (i.e. new since the 0.20.000 release)

ASCOM enhancements

Maestro is now a multi-client ASCOM Telescope hub.  The number of simultaneous clients supported is limited only by
available system resources (memory, etc.).

All status that ASCOM clients can poll (e.g. .RightAscension, .Slewing, etc.) is now cached within Maestro.  This
significantly reduces the latency that an ASCOM client experiences in polling status.  Latency-sensitivity clients
(e.g. ACP!) benefit enormously from this change.

To provide high accuracy PC -to- SkyWalker time synchronization, Maestro has added a "TSync" option to the
ASCOM Telescope CommandBool() method.  This signals Maestro to update SkyWalker time and date to the PC's time/date in
a low latency manner.  Note: this will also void alignment.  Additionally, an "At Home" indicator is provided.

Provided ASCOM support for Custom track rate through the RightAscensionRate and DeclinationRate properties.

Added bounds-checking to setting the target coordinates.

Completed extensive testing/validation of Maestro's ASCOM Telescope object for compliance with the ASCOM Telescope 2.0
specification under the ASCOM 5.5 platform.

New Maestro ASCOM Telescope object documentation and a complete library of VBS scripts for set-up, start-up, operation
and shut-down is now available from here.

Accommodating ACP Park issue:
- ASCOM's RightAscensionRate and DeclinationRate are (per ASCOM documentation): "used primarily for tracking objects
  that move relatively slowly against the equatorial coordinate system".  From this definition, if they are both set to
  zero then one would expect that Sidereal tracking is required so that there is no telescope movement w.r.t. the
  equatorial coordinate system.  The problem when using ACP is that at the completion of a script (and hence after a
  Park()), ACP sets RightAscensionRate and DeclinationRate to 0 and Maestro 0.29.042 then sets SkyWalker's tracking
  rate to Sidereal to be consistent with the spec interpretation EVEN IF SkyWalker was previously in Drift thus leading
  to the scope continuing to track after the ACP script.
- New Maestro behavior in 0.29.052: when either RightAscensionRate or DeclinationRate are set then if both
  ASCOM_RightAscensionRate and ASCOM_DeclinationRate are 0.0 then:
    - If SkyWalker is in Custom rate then change to Sidereal.
    - If SkyWalker is NOT in Custom rate then DO NOTHING <-- this is key to fixing the ASCOM/ACP problem.
    - Else, if either are non-0.0 then set SkyWalker's custom rate values and set SkyWalker's track rate to custom.

Automation Module support
Added an "Automation Module" group to the Peripherals tab providing access to several new features:

- Status of Axial Limits (active/inactive, etc.).

- Access to SkyWalker's Hard Limit "back-out" feature.

- An area where the Home Index seeking/alignment capability of SkyWalker can be set-up.  This area provides the ability
  to "discover" the home index switches in each axis.  See the "Automation Module User's Manual" (part number DOC-14)
  for complete details.

- Status for the Automation Module's Auxiliary inputs and means to toggle Auxiliary outputs.

Added support for SkyWalker's new feature to align from home position feature.  From the Settings tab, an "Align from
Home Seek" button has been added.  So long as the home position has been "discovered" (from the Peripheral's tab
"Automation Module" group) SkyWalker will seek the home switches in each axis and complete an alignment.

Axial Hard Limit support
In support of the Automation Module's Axial Hard Limits, Maestro has added an area to the Instrumental tab allowing
East, West, Up and Down hard limit angles to be set.  Additionally, each Axial Hard Limit can be individually enabled or

Axial Limit functionality requires that Automation Modules (TCS peripherals) are installed in the SkyWalker system.
See our "Automation Module User's Manual" (part number DOC-14) for more information.

Soft Limits consistent with Axial Hard Limits
In support of SkyWalker's change to soft limits which are consistent with hard limits Maestro now includes an area on
the Instrumental tab allowing East, West, Up and Down soft limit angles to be set.  Additionally, each soft limit can be
individually enabled or disabled with the exception of the Down Limit which is always enabled.

Ability for GoTos from clients to always assume "EpochNow"
TheSky and several ASCOM planetarium software packages output celestial coordinates that are already corrected into the
present epoch (i.e. "Epoch Now").  Maestro now provides a new feature that allows celestial coordinates from clients to
be assumed as Epoch Now regardless of "Epoch of Entry" set for SkyWalker (on the Settings tab).

To enable this, the following check-box options are provided on the Windows tab (under new group called "Client
  - EpochNow from ASCOM
  - EpochNow from TheSky

On the Settings tab, for the "Epoch of Entry" box, the follow status is displayed if SkyWalker's Epoch of Entry is NOT 
  - If "EpochNow from ASCOM" is selected then "!ASCOM" is shown next to the epoch on the Epoch of Entry display (e.g.
    "2000 !ASCOM") when Epoch of Entry is NOT "Now".
  - If "EpochNow from TheSky" is selected then "!TheSky" is shown next to the epoch on the Epoch of Entry display (e.g.
    "2000 !TheSky") when Epoch of Entry is NOT "Now".

Save/Restore SkyWalker settings
Added a feature to the Windows tab that allows the user to save/restore SkyWalker's settings to/from a file.  These
buttons in the "SkyWalker Configuration" group on the Windows tab work as follows:
  - Save to File: saves all of SkyWalker's internal settings to the file named maestroSavedSWsettings.txt
  - Load from File: restores all of SkyWalker's internal settings from the file named maestroSavedSWsettings.txt
This feature is useful in transferring settings from one SkyWalker to another and useful as a "backup" of known-good

Installation support
Maestro is now installed from one self-contained executable file available on our support website.  No longer is
it necessary to install the first version of Maestro and then a "patch" install on top of that.  This new
installation works for all versions of Microsoft Windows from XP forwards.

Runs on 64-bit versions of Windows
A few changes were made to Maestro so that it will run on 64-bit versions of Windows.  Maestro now runs on all versions
of Windows from XP forwards.

Miscellaneous new features and/or changes
- On the Settings tab, in the Alignment group, made the following changes:
  - Changed "Mount Assumption" to "Alignment Type" to avoid confusion.  The choices remain "Polar", "AltAz",
    "NearlyPolar", "NearlyAltAz", "Permanent", and "Arbitrary".

- Alignment status added to the top of the Alignment group on the Settings tab.

- Add ability to enable/disable each Axial encoder (RA/Az and Dec/Alt) separately from the Instrumental tab.

- The maximum disparity between present position and encoder position that is allowed for CalFromEncoder can now be
  specified from the Settings tab.

- On the Settings tab under Site settings, the use of "GMT Offset" has been changed to Timezone.

- The System group on the Status tab has been expanded to indicate the presence/absence of SkyWalker's new peripherals.

- The Actions tab now provides support for SkyWalker's new Timer and Alarm tools.

- Increased the available communications ports from 8 to 16.

- Removed the following option from the firmware upgrade confirmation pop-up: "Don't ask me again - always update when
  newer version available".  Also removed the "Force F/W Update" option from the Windows tab.  Both of these have been
  superseded by Maestro's new features where it checks that SkyWalker meets the necessary minimum and maximum versions
  prior to proceeding beyond initialization.

Note: the Instrument Display in Maestro is NOT up-to-date with all SkyWalker functionality.  The other Maestro tabs are
however with the exception that Dynamic Correction settings will be provided in a separate Maestro tab in a near-term
Maestro release (in 0.29.052 Dynamic Correction settings/status must be made through ASCOM/VBS script as exemplified in
the Script Library).

Bug fixes in this release

The following SkyWalker bugs have been fixed since the 0.20.000 release

- Fixed a but where occasionally there would be a "Client Syntax error" with an unknown command that is shown as 3
  characters rather than the standard 4 characters for all ATCL commands.  SkyWalker firmware was loosing a
  communications character from time to time.
- In 0.20.000, if SkyWalker was powered-down with a TrackRate of Drift (either because the user had selected a TrackRate
  of Drift or because there was an active fault) then when powered back up SkyWalker could not be "toggled" out of Drift
  with the DriftToggle assignable key.
- Fixed a bug where the assignment of a QuickKey to Hunt or Wobble caused a settings corruption that was irrecoverable
  without return-to-factory and reprogramming.
- Fixed a bug where SkyWalker would not always save the former Track Rate when switched into Drift.  This led to
  toggling out of Drift not always restoring the correct "former" Track Rate.
- If SkyWalker produces an integer that is too large to display (absolute value > 100,000,000) it will display
  "###,###,###" (previously would cause InternalError).
- In SkyWalker firmware 0.20.000, Sidereal time was "calibrated" to the high accuracy internal temperature-compensated
  clock only at power-up or when site settings changed (since time would change as a result).  In SkyWalker firmware
  0.29.052, Sidereal time is additionally calibrated:
  1) When local standard time is changed.  It was a bug in 0.20.000 to not adjust Sidereal time when local standard time
   2) At every alignment.  This provides better accuracy in applications where SkyWalker is left powered-up for extended
     periods of time.   It is assumed that SkyWalker is aligned at the beginning of every night (e.g. AlignFromLast,
     AlignFromHome or align-from-star(s)).
- Fixed a bug where Nutation corrections were not factored into sidereal time calculations at power-up prior to
  alignment (lead to ~1sec error).

The following Maestro bugs have been fixed since the 0.20.000 release

- Bug fixes in the ASCOM interfaces:
  - In 0.20.000, SideOfPier was reporting the side of the sky the telescope was pointing into (SkyWalker convention)
    rather than the side of the pier the telescope is hanging on (ASCOM convention).
  - For asynchronous slew methods (those that return immediately) the slewing property was not being extended by the
    SlewSettleTime property in accordance with the ASCOM specification.
  - Fixed various problems with methods (e.g. FindHome) returning prior to all actions (e.g. alignment) being complete.
  - Fixed a bug were the PulseGuide() was synchronous and would not return until the pulse guiding motion was complete.
    PulseGuide() is now asynchronous and returns immediately.
- Fixed a bug where the constellation would not be properly reported for Bayer stars from the Objects tab.

Known problems with this ATCS release

The following are known problems with the present version of SkyWalker firmware

- If you calibrate too close to the celestial pole (say within 1/2 degree) then SkyWalker can "run away" in tracking at
  up to 1/4 degree/second.
- If an illegal value is entered in Maestro then SkyWalker will reply with an unfriendly "Client Syntax Error" rather
  than reporting a more friendly error describing the illegality of the value entered.
- Some SkyWalker messages are reported multiple times rather than just once.  For example, when alignment is voided it
  is reported 3 times.

The following are known problems with the present version of Maestro software

No known Maestro problems in this version.

Copyright 2004-2010 Astrometric Instruments, Inc.