Subject:	Autostar 497:  Multiple Sync
Sent:	Monday, July 4, 2011 04:45:35
From:	aws@mpe.mpg.de (aws@mpe.mpg.de)
I have a question about the Sync function in Autostar 494/497 The Meade
Autostar FAQ (http://www.meade.com/support/etxautofaq.html#a10) says:
------------------------------------------------------------
The "Sync" function looks like a great way to upgrade my alignment.
Should I use it often?
A: No, the "Sync" function is best used only if you intend to view many
objects within a small area of the sky. It provides a very localized
alignment so that when you move back across the sky you may not be as
accurate as you were with the standard alignment procedure.
-------------------------------------------------------------

I assume the method Autostar uses is just to compute Alt,Az offsets and
apply them, hence the local restriction.
One would then think that going to a new sky area it would be enough to
Sync again so that the offsets would be recomputed for that area.
Actually this seems not to be the case - a query to Meade replies that
it is necessary to align the scope from scratch before re-synching.
It would be interesting to know why this is the case, and if there is
any work-around. (Of course High Precision is great and I normally use
it but there are case where it is a problem e.g. due to the reference
objects being obscured). I searched your site and found some things on
sync but not the answer.

Andy Strong, Munich, Germany.

And:

From:	richard seymour (rseymour@wolfenet.com)
Andy wrote:

>> I assume the method Autostar uses is just to compute Alt,Az offsets and
>> apply them, hence the local restriction.

Actually, it adjusts the underlying coefficients of the matrix for the
RA/DEC to Alt/Az equations.

If you were running in Polar mode, it shifts the RA-to-HourAngle offset,
and the DEC effect depends upon how you aligned at the beginning of the
session (1 star or 2 star)

The SYNC programming is one of the "messiest" sections of the Autostar's
firmware.

>> One would then think that going to a new sky area it would be enough to
>> Sync again so that the offsets would be recomputed for that area. Actually
>> this seems not to be the case - a query to Meade replies that it is
>> necessary to align the scope from scratch before re-synching.

My arm-wave method of describing it (especially for Alt/Az) is: think of
the Autostar's map of the sky as a hemispherical rubber ball.
When you do a 2 star alignment, it "pins" that map to the sky at those
two points.
When you SYNC,  you are stretching the hemisphere to pin the SYNC point
to the sky.
That stretch is distortion.
It also (effectively) locates a point  (a virtual star?) where it can
add a 4th pin such that the first two can be removed with minimal
"relaxing" of that stretch.
So you've added distortion, and allowed the initial alignment points to
shift.
Further SYNCing keeps moving the "pins" and the resultant distortion.

>> It would be interesting to know why this is the case, and if there is any
>> work-around. (Of course High Precision is great and I normally use it but
>> there are case where it is a problem e.g. due to the reference objects
>> being obscured).

High Precision (HP) differs by *not* shifting the "original pins".
So the SYNC-like process does not add "error correction" to the original
alignment.

For obscured guide stars, simply tap the "scroll down" key, and HP will
select another one.

have fun
--dick

And:

Hi Dick,
many thanks!
Is there a description of the algorithms somewhere (reverse engineered
from the code ?)

how does HP do it then ? It is local too presumably.

(just now HP goes into a loop trying to find a star and hangs upon
pressing MODE or so. Hence the retrogression to Sync.
I hope RESET is going to help. Any advice welcome.)
4.2G9 (German language, purchased last year via Meade Germany)

thanks very useful

Andy

And more:

I'm including Andrew in this discussion  about SYNC and High Precision.
Andrew: this is firmware "4.2G9" in a German 497.
(i don't know if it's a true 497, or a 497EP .. it was purchased in 2010
in Germany)

There are only a few stars appropriate for SYNC (or HP), so it may "run
out" of choices.

But you may have found a bug... what are the circumstances of the loop?
What target are you trying to GoTo?
What is your location (nearest city, or Lat/Long)?
What time and date when it happens (so we can duplicate conditions)?
Polar or Alt/Az?

we're curious...
have fun
--dick

And:

> (i don't know if it's a true 497, or a 497EP .. it was purchased in 2010
in Germany)

how I can find out ? It actually says '42G9' when I hit
Telescope/Statistics

>
> On 7/4/2011 10:20 AM, aws@mpe.mpg.de wrote:
>> (just now HP goes into a loop trying to find a star and hangs upon
pressing MODE or so. Hence the retrogression to Sync.
>> I hope RESET is going to help. Any advice welcome.)
>
> There are only a few stars appropriate for SYNC (or HP), so it may "run
out" of choices.
happens in many places
and... it was working before
(only change was from batteries to mains adapter)
>
> But you may have found a bug... what are the circumstances of the loop?
What target are you trying to GoTo?
an example is M13, which was high in the sky.
the first problem was that it chose a star near the horizon obviously
wrong the next night it just started to loop

Same thing with a low object like M8

> What is your location (nearest city, or Lat/Long)?
Munich Germany (I live at 481330N 114030E which I use)

> What time and date when it happens (so we can duplicate conditions)?
11 pm June 30 (just an example)
> Polar or Alt/Az?
Alt/Az, set up so Goto works reasonably
>
> we're curious...
so am I
> have fun
will do

I would try a reset - but did not so far since did not want to lose my
settings: would you expect it to help ?

And this:

From:	Andrew Johansen (johansea@optusnet.com.au)
Gday All

This bug rings bells, but IIRC it was originally found in the ASII.
Funnily enough, i am just redoing the 497EP goto code
so can confirm if its the same thing later.
Going from memory, reset wont help.
If its the same bug, there is a special Hi precision algorithm
used to detect the nearest "named" star to target.
This star only has to be above the horizon.
The routine then returns this star to the main goto routine,
and treats it as a standard goto.
As such, the main routine then tests the star for being
above horizon ( by a set amount ) >> and also <<
below the upper slew limit and above the lower limit.
If the star fails this later test, the hi prec routine gets recalled.
( and keeps failing as it gets into a loop )
Again, i need to look if this is the same process in the 497.

Andrew

And:

Thanks, I see this has entered the world of the gurus, that's nice.

How can I tell 497 from 497EP (it's not written on the box of course)?

NB: HP was working before. At least before (a) the mount went back to
Meade to check since I had problems with power-loss using batteries (b)
replacing batteries with mains adapter. I mention that in case it's
relevant since you mention slewing.

Which prompts me to try my 494 which I still have, which would provide a
cross check on the mount aspect. Stay tuned.

Andy

And more:

NB with GOTO I *always* get the warning about 'danger of hit' (in
German: dont know what the english version is) and have to ENTER to
continue. Could this be related ? maybe all stars fail this test in the
search. Don't know why  this warning always comes and would like to
avoid it.

HP on 494 works fine, and no warning either.

And:

must be telepathy, I just came to the same idea, you're right.
max elevation  was 3 deg ! how could that occur I wonder.
Set it to 70 (the max it accepts for some reason)

Now all works normally.
This was obscure because the warning gives no idea of the origin of the
problem, nor does the handbook. Perhaps worth informing Meade.

Thanks for your help!
Andy

And this:

it's a bug though - a false setting of a user-defined parameter should
not lead to a hang up of HP. Maybe post it on your hints page.

one last thought: maybe that check can be switched off somehow when not
required (no equipmentment mounted).

And:

> must be telepathy, I just came to the same idea, you're right.
> max elevation  was 3 deg ! how could that occur I wonder.

Carbon based errors :-)
But it does line up with the way the code works when picking
Hi Prec stars.

> Set it to 70 (the max it accepts for some reason)

The max and min elevations are "normally" set to a default
value when you select a scope model. You can override
the max but not the min settings ( unless you run patched firmware )

> Now all works normally.
> This was obscure because the warning gives no idea of the origin of the
> problem, nor does the handbook.
...
>>> NB with GOTO I *always* get the warning about 'danger of hit' (in
>>> German:

Now i'm more confused.
The standard warning associated with exceeding the elevation limits
is something like "Target below slew level"
There is a specific warning re "Hitting the tripod" in the firmware
but this only applies to LXD75 GEM setups.

>>> Don't know why  this warning always comes and would like to avoid it.

Just to be sure, Double check what scope type is selected in the Hbx.

Andrew

And:

the German version of 497 says 'Anstossgefahr' which literally means
'danger of hitting'. Evidently something got lost in translation by the
coders of the German variant. But then follows a long explanation in
German saying that the tripod etc might get hit, so it's clear enough but
not clear that it relates to the altitude limit setting.

(NB 'Target below slew level' sounds even more off the mark if it wants
to warn about elevation!)

Andy

And this:

If you are getting that extra text after the initial warning, it's
assuming you have  GEM selected.
IIRC, your original post referenced you being AltAz
hence this is totally wrong for that setting.
Something else is really screwy here.
Andrew

And:

> If you are getting that extra text after the initial warning,
yes I am
   or  was getting it before resetting the elevation limit of course

> it's assuming you have  GEM selected.
what's GEM and where is it selected ?

> IIRC, your original post referenced you being AltAz
yes since this is the DS2090 mount I have

> hence this is totally wrong for that setting.
> Something else is really screwy here.
makes life interesting
Andy

And:

A GEM is a German Equatorial Mount
( ie your classical type scope mount )
You need to go into your handbox and find
the equivalent Menu of
Setup->Telescope->Model
and 
Setup->Telescope->Mount

If you select a GEM model, the second menu will
be disabled or missing.
Soooo, look at what model is currently selected.

>> IIRC, your original post referenced you being AltAz
> yes since this is the DS2090 mount I have
> 
>> hence this is totally wrong for that setting.
>> Something else is really screwy here.
> makes life interesting

I like "quiet" at present :-)

Andrew

And:

> Soooo, look at what model is currently selected.
no Mount Menu
DS2090

And further discussion:

The DS2090 (if i recall correctly) can hit the base if elevated too high.
So the travel limit message  (the English message is "Check Mount") is
appropriate, but not at an elevation of only 3 degrees.

If you SELECT the model (Setup->Telescope Model->DS2090  *ENTER* )
you will cause the Autostar to (re)set the Max Elevation setting
appropriate for that model telescope.
(you will also reset the Train Drive data to "default", which therefore
requires doing another setup->Telescope->Train Drive   process.)

have fun
--dick

And:

thanks, that explains it nicely, and also why it accepts a maximum of
70deg when I change Max Elevation by hand, obviously it checks against
the model and that must be the value for DS2090.
Andy

And:

The 70 deg limit will certainly prevent
the tube hitting when the scope is alt/az,
but the message re hitting tripod intrigues me
as ( IIRC ), it is only referenced for GEMs.
Thats whats still confusing me, but i'm not near my notes.
I'll look at the code in a few days to refresh the braincells.

Andrew