AUTOSTAR INFORMATION Last updated: 14 December 2000

Autostar Command Set

Subject:	ETX-90 & personal computer
Sent:	Monday, June 14, 1999 14:47:33
From:	TD1964@aol.com
I recently purchased an ETX-90 and the Autostar controller.  This setup
is advertised in Astronomy and Sky & Telescope as being able to be
controlled by "programs of the user's own writing", so I thought I'd
give it a try.  Tech support at Meade told me that the command set for
the ETX-90 and the LX-200 is the same.  Meade mailed me an LX-200 manual
containing the command sets.  I can only get some of the commands to
work.  Things such as time, date, latitude, longitude, and north, south,
east, west scope movements work just fine, but I can not get my programs
to change the speed at which the telescope moves.  The command codes to
do this are listed in the book, but they just don't work.  Alt and Az
commands to get the Autostar to send the computer the Alt Az positions
don't work either.  This makes me wonder if the ETX-90 and the LX-200
really do have identical command sets. Meade techs continue to insist
that the command sets are the same.  Is there anyone familiar with
programming the ETX-90 through the RS-232 port that can help me solve my
problems?

Subject:	 Controlling ETX-90EC with computer
Sent:	Tuesday, June 29, 1999 13:38:30
From:	gmt@nebula.physics.uakron.edu (Greg Townsend)
I am interested in controlling the ETX-90EC with a computer ( a Mac !!)
and this means communicating with the Autostar using the RS-232 port. 
Do you know where I can obtain information on the commands that are sent
etc.

Thanks

Greg Townsend

I found some information at
        http://www.mailbag.com/users/ragreiner/

Subject:	 Autostar 2.0i
Sent:	Thursday, December 7, 2000 16:08:27
From:	weed@lexmark.com (Steve Weed)
I just bought a DS-114AT from Walmart and have been trying
to control the #495 Autostar azimuth and altitude from Unix.
I have found valuable help on your Autostar Information page.
Here are some things I have noted after downloading 2.0i code.

The command format is quite fussy.

Here are 3 working examples:

:Sz 348fl30#
   ^
   +- note one blank between 'z' and first digit

:Sa-01fl17#
   ^
   +- note NO blank

:Sa+04fl14#
   ^
   +- note the plus sign

The Autostar will respond with good status ("1")
for variations from these formats
(for example, no blank after Sz, blank after Sa,
 3 digits for Sa degrees, omitting "+" for non-negative Sa)
... but will generally slew to the wrong position.

One limitation is that position errors seem to accumulate
if the Autostar Mode is set to display AzAlt values while slewing.
I was using that to help debug, but it turned out to be counterproductive.

I am fooling with an algorithm to deduce when slew is complete.
The :D# command seems to always return only "#".
The best I have done so far is:
* Identical ack-to-back position readings (:GZ#  :GA)
  are a good indication that fast slew has ended,
* Then comparing the position readings to the requested position
  three times at 6 second intervals
* Then allow for an error of up to 5 minutes in the final AzAlt.

Then, there are puzzles that have baffled me:

My notion was to use the hand control to slew to a target of interest,
then have the computer process based on the current AzAlt.

For user interaction, it would be nice if some keypress,
such as [?] or [0], could be detected,
and if a serial host could make the Autostar simply beep.
I have been unable to imagine how to accomplish that
using the documented commands.

Printing over the serial to the Autostar display and
slewing to a requested position using only the fast speed would
also be handy tricks, but seemingly impossible without hacking the
Autostar code.

- regards,
  Steve Weed

Subject:	 hacking Autostar code? You called?
Sent:	Saturday, December 9, 2000 21:45:32
From:	rseymour@wolfenet.com (richard seymour)
To:	weed@lexmark.com
Hi...

I saw your note on Mike's site, and couldn't resist commenting...
(yes, there are bugs in the v2.0i LX200 command processing code)

> Here are some things I have noted after downloading 2.0i code.

>The command format is quite fussy.
Well, it IS a computer...

>Here are 3 working examples:
>:Sz 348fl30#
>    ^
>    +- note one blank between 'z' and first digit
>:Sa-01fl17#
>   ^
>   +- note NO blank
>:Sa+04fl14#
>   ^
>   +- note the plus sign

>The Autostar will respond with good status ("1")
>for variations from these formats
>(for example, no blank after Sz, blank after Sa,
> 3 digits for Sa degrees, omitting "+" for non-negative Sa)
>... but will generally slew to the wrong position.
Well, the "Sa" is incorrectly formatted in your example.
The specified format in the notes is "sDD*MM"
It is forgiving about the sign.

However, the Autostar's implementation of many commands is a bit
loose... the :Sa# command will *always* respond with "1".

The :Sz# command, on the other hand, does check format, and
will respond with "0" if unhappy.

>One limitation is that position errors seem to accumulate
>if the Autostar Mode is set to display AzAlt values while slewing.
>I was using that to help debug, but it turned out to be >counterproductive.
Actually, due to a bug in the firmware, if you send repetitive
coordinates and :MS# commands, you can blow the Autostar's stack.
(programmer's definition thereof).
When you push a key during [goto] slewing, it aborts the move and clears
the stack.  If you send LX200 commands... it doesn't.  And, if you send
commands which command motion (or change target coordinates), it'll just
push its operation stack deeper and deeper....

It also uses the same internal locations to store the target's RA/Dec or
Alt/Az... so if you switch modes it may use the values incorrectly.

A good bellweather is to have the -time of day- displaying on the
Autostar while you're commanding it.  Don't issue additional commands
until you see the time increment.  It can get a number of seconds
behind.. and can handle about a minute's worth of stacked commands
before it really loses it.

>I am fooling with an algorithm to deduce when slew is complete.
>The :D# command seems to always return only "#".
Nope... read the notes... it returns the (hex) character 7F.
Which is a non-printing character.  
If i tell Window's HyperTerm to display non-printables, it's there.

The LX200 returns many... the Autostar returns either one or zero.
You'll get the x7F character until the word "Slewing..." disappears
from the display... but it's not finished yet.
"Slewing..." disappears when it's within a few minutes of the target.
It then switches to the SYNC and backlash takeup subroutine for the
final home-in.  Figuring out when -they're- done is a problem.

>The best I have done so far is:
>* Identical ack-to-back position readings (:GZ#  :GA)
>  are a good indication that fast slew has ended,
>* Then comparing the position readings to the requested position
>  three times at 6 second intervals
>* Then allow for an error of up to 5 minutes in the final AzAlt.
The Autostar -tries- for arcminute accuracy.  The ETX has looser
tolerances.

>Then, there are puzzles that have baffled me:
>My notion was to use the hand control to slew to a target of interest,
>then have the computer process based on the current AzAlt.
nice.

>For user interaction, it would be nice if some keypress,
>such as [?] or [0], could be detected,
>and if a serial host could make the Autostar simply beep.
>I have been unable to imagine how to accomplish that
>using the documented commands.
The Autostar mimics the LX200 command set to operate under Meade's
various planetarium programs... and Meade apparently isn't too
interested in making it easier for -other- people nor to perform -other-
tricks.  I continuously send them notes about this.  Please join in.

You -can- gain more control by invoking the commands hidden in the
Download protocol... but they're not designed to operate with the
tracking system active.  There is, for example, a Jump command you could
give, which would trigger the beep, but you'd be displaying
"Downloading... do not turn off" while doing so.

My tack has been to co-opt one of the unimplemented LX200 commands and
have that lead to the code i want to execute.  That's how i now reach
the Autostar's internal debugger.  The :T# command gets
"In Debugger>" as a response on the rs232 line... (see below)

>Printing over the serial to the Autostar display and
>slewing to a requested position using only the fast speed would
>also be handy tricks, but seemingly impossible without hacking the
>Autostar code.
weeelll... funny you should ask that...
if you download my -entire- patch kit for v2.0i, it'll improve
your control results.  
It covers the stack-overflow, and it makes the :Q# command really -quit-
motions.

It's found in the zip file (and individually) at the bottom of the page
on Mike's site at URL:
http://www.weasner.com/etx/autostar/as_beep2.html

--regards
--dick seymour

From:	weed@lexmark.com (Steve Weed)
Hi Dick -

Thanks for your responses.

>> The command format is quite fussy.
>  Well, it IS a computer...

Fair enough; I SHOULD have reported that the formats are fussier
than the immediate responses would lead one to assume.  I had
thought that I had understood the public domain documentation
when I first coded those counterexamples...

> Well, the "Sa" is incorrectly formatted in your example.
> The specified format in the notes is "sDD*MM"

Whoops, thanks. I've fixed that in my code.

>> One limitation is that position errors seem to accumulate
>> if the Autostar Mode is set to display AzAlt values while slewing.
>> I was using that to help debug,
>> but it turned out to be counterproductive.
> Actually, due to a bug in the firmware, if you send repetitive
> coordinates and :MS# commands, you can blow the Autostar's stack.
> (programmer's definition thereof).

Thanks, the stack bug was one of the valuable hints
that I found on Mike's site.
I am pretty sure that the limitation is really there:
* park scope, zero mount ring settings, power up scope again.
* press MODE and scroll to get AzAlt display
* test serial program sets AzAlt coordinates,
  sends one :MS# command and immediately exits.
* wait for Autostar to beep, use utilities menu to park scope.
* note that ring settings are no longer 0 and 0

The same sequence without AzAlt display results in less park drift.

> A good bellweather is to have the -time of day- displaying on the
> Autostar while you're commanding it.

Hmm, I wonder if :Ga# results will imply the movement complete
feedback I'm looking for...

> >The :D# command seems to always return only "#".
> Nope... read the notes... it returns the (hex) character 7F.

Whoops again, you are correct;
I'd read the notes, but had not 'seen' the x7F.
Just checked my code again - doh! testing the wrong byte, sigh.
That now seems to work well enough that further tests are not needed,
just a delay (as you had suggested).

> You -can- gain more control by invoking the commands hidden in the
> Download protocol... but they're not designed to operate with the
> tracking system active.

I accidently got into the download protocol by sending Ctrl+D to 'tip',
the Solaris equivalent of hyperterm... messed up behavior for days
until I reloaded 2.0i.

> if you download my -entire- patch kit for v2.0i,
> it'll improve your control results.

Thanks, I will give it a try or two.

> in your wanderings on Mike's site, did you find:
>
> http://www.weasner.com/etx/autostar/as_lx200.html

I did.  In fact, I made a local copy of
"AUTOSTAR INFORMATION - LX200 Commands and Autostar",
printed it out and use it as my primary reference.
I did not find examples for Sa and Sz in it, nor in:
www.mailbag.com/users/ragreiner/LX200Commands.html
... so tried piecing them together from:
www.mailbag.com/users/ragreiner/lx200CmdSet.html

Thanks for helping me work thru these bugs;
my code is working much better now.

- Steve Weed

Subject:	 LX200 commands and stuff 
Sent:	Tuesday, December 12, 2000 22:31:08
From:	rseymour@wolfenet.com (richard seymour)
and here's two of two. (there's a thrid, where i just say that
:D# doesn't confuse my Parking)

-------- Original Message --------
(dick to Steve...)

>Well, there are
> :hS# "Start Home Position Search, Save Current Position"
> :hF# "Start Home Position Search, Set to Saved Values"
> :hP# "Slew to Home Position"
> ... but I've only tried the :hP#
> since I could not imagine what the first two would actually accomplish.
yes, it was :hP# that i was trying to remember.

>sending :D# after #:hP# screws up the park position
I forget what ":D#" does [added later (after reading your code
snippet) oh, yeah... i'm surprised it hiccoughs it... i'll look
into it tonight, if possible.  Otherwise tomorrow],
 but (on the keypad) (at least) [mode] and/or
(during normal GoTo's, so probably Park, too) **any** numeric
keypress (or slew key) -aborts- a slew, pops the stack, and returns
to the requesting routine as "done" ... irrespective of actual
aiming point of barrel.  Without testing (and from memory), i think
only [mode] kills a Park... 

I pause to ask/confirm: you are playing with a #495 Autostar?
(since you said you reloaded it, that means it's not a Starfinder)

> Does the Autostar use UCT internally?
> In other words, does :GG#         /* UCT */
> incur less processing than :Ga#   /* local time */
ummm... memory doesn't serve me well here (and it's confusing code,
too)... many things are done with delta time, not absolute.
The clock interrupt adds ticks to two incrementing variables,
so i wouldn't be surprised if it maintained -both-.
(and there's the Timer function, and the Alarm function, both
 downcounters skipped if they're not activated)
It also maintains local sidereal time.
I believe it doesn't maintain (or care) about any particular time,
unless you ask for one... so i'll have to look at the code and
see what happens between those two commands.  Most likely one of
them is the basic "get time" command, and the other tosses in 
a conversion... but it'd be mere microseconds compared to the rest
of the mess it goes through.
The "check for LX200 input" is done by synchronous in-line calls to
that subroutine set.  The actual individual characters are brought
in by interrupt routines, but the "anything to do?" is only checked
at specific points in the rest of the Autostar's non-interrupt 
code flow.  It's not multi-tasking in that respect.


>> How much drift is there (from the scales?)
>I can see 3 degrees of azimuth error from a single
>menu park, three handset moves, one program move, menu park sequence.

>> Ahhh... and the -final- value of Alt/Az may not be reliable
>> after a Park
>That sort of compromises its utility...
by that i meant the readback value of Alt/Az.
Park ends by a   " Here: goto Here "   instruction... 
which (again, my memory fails) may leave the interrupt processing 
active (conversely they MAY do a  block-interrupts in there... 
or the :D# may cause it to be skipped)

>> My scope always has a tiny bit of vertical drift when Parked
>The DS-114 tube is pretty balanced, which probably helps for that.
My "driift" is firmly driven by the motors, not a mechanical slop
(in this case)... 

>> My ETX has 3 degrees of mechanical slop in the Alt axis... 
>The DS worms have readily accessible brass nuts to reduce lash.
it's a characteristic of the ETX models that the final connection
between the Dec-axis-clamp and the barrel is a small brass insert
(poorly) held in plastic... -any- play there is magnified.

>> The full belts-and-suspenders is :S to set, :G to verify that
>> the -target- got set correctly, THEN the :MA,
>Bingo! I should have thought of that...
>Would you believe, simply sending a :GZ# :GA# sequence
>after setting :Sz and before :Sa :MA# eliminated the up to 6 minutes
>of subsequent reported position error?
I wonder... you might try waiting one full second between setting
and using coordinates... 
There are lots of places in the code where they'll accept commands
(be they keypad or LX200), then they'll -wait- a little bit
(they call the clock routine with an elapsed-time value specified)
before they act upon it.  And i have no idea -why- they do that.
And it's a humanly-noticeable time lag (frantic button pushing sees it).

> sending :D# after #:hP# screws up the park position
yeah... i'll see if i can find out why...

--dick

And a response:

dick -

> :MS# is for Sidereal objects, MA is for Alt/Az (terrestriual) objects.

Right; sorry, the code really uses :MA instead of :MS

    else {
      ScopeSendData(s.id = ":MA#");
      s.ptr = getfrag(2);
      if(s.ptr[0] != '0' ) {
        status = Interactive = 1;
        qpage_log(LOG_NOTICE, "AutoStar slew AltAz returned %c",
*s.ptr);
      }  
      else do {
        ScopeSendData(s.id = ":D#");
        s.ptr = getpacket(5);
        sleep(3);
      } while(0x7F == s.ptr[0]);

> But, when testing, be sure to tape the
> RA circle to the moving portion of the base... the paper band
> can (and will) slip at times. (mine sure does).

Yup, there too much excitement before I figured that out...

> How much drift is there (from the scales?)

I can see 3 degrees of azimuth error from a single
menu park, three handset moves, one program move, menu park sequence.

> Does the Alt/Az display think you're getting back to 000/000?

Cannot get to the Alt/Az display (or response to serial commands)
after park without first power off/on.

> Ahhh... and the -final- value of Alt/Az may not be reliable
> after a Park

That sort of compromises its utility...

> [you could try the :(i forget... there's a :Sh or something which
> is the LX200 command for "Park ... "go home")

Well, there are
:hS# "Start Home Position Search, Save Current Position"
:hF# "Start Home Position Search, Set to Saved Values"
:hP# "Slew to Home Position"

... but I've only tried the :hP#
since I could not imagine what the first two would actually accomplish.

> **none** of the LX200 commands turn ON the Sidereal drive!!

So far, I have only been testing against terrestial targets.

> My scope always has a tiny bit of vertical drift when Parked

The DS-114 tube is pretty balanced, which probably helps for that.

> My ETX has 3 degrees of mechanical slop in the Alt axis... 

The DS worms have readily accessible brass nuts to reduce lash.

> The full belts-and-suspenders is :S to set, :G to verify that
> the -target- got set correctly, THEN the :MA,

Bingo! I should have thought of that...
Would you believe, simply sending a :GZ# :GA# sequence
after setting :Sz and before :Sa :MA# eliminated the up to 6 minutes
of subsequent reported position error?
I'll need to check this code to make sure it's not doing something
unintended...

> then monitor :G to test arrival (to your criteria)

Does the Autostar use UCT internally?
In other words, does :GG#         /* UCT */
incur less processing than :Ga#   /* local time */

> It was (initially) meant to merely clarify what works,

Believe me, it is much appreciated.
I was intending to provide update to that.

... and another limitation:

sending :D# after #:hP# screws up the park position

Thanks again,

- Steve Weed

Return to the top of this page.

Go back to the Autostar Information page.

Go back to the ETX Home Page.