AUTOSTAR FEEDBACK
[Home!]
Last updated: 31 October 2008

Welcome to the AutoStar feedback page. This page is intended to provide user comments on using the Meade Autostar #494, #495, #497, cables, and the AutoStar updater software. See the AutoStar Info page for information from Meade and other users on the AutoStar, cables, and software. Send your comments and tips to etx@me.com. Remember, tips described on this site may invalidate the warranties on your ETX and accessories. Neither the submitter nor myself are responsible for any damage caused by using any contributed tips.


Subject:	ETX90 Model?
Sent:	Thursday, October 30, 2008 19:42:12
From:	CatWhiskR@aol.com (CatWhiskR@aol.com)
I just picked up a ETX90 used. Been looking through your site. How can I
tell which model Autostar I have? I have not plugged anything in yet.
Just reading basics now. Does it say on the screen the model # when it
is fired up?
 
Thanks,
 
Terry
Mike here: There are several possibilities. You have just the standard EC handcontroller. There is no display, just buttons and 4 LEDs. You have the #494 AutoStar (which won't work with the ETX-90). There is a display but there are no number keys on the keypad. You have the #497 AutoStar, which has a display and it has number keys on the keypad. To see what version of the AutoStar software is loaded on the AutoStar, connect the AutoStar to the telescope and power on the telescope. Select Setup --> Statistics and then scroll up or down until you see the version number. The current version for the AutoStar #497 is 4.3Eg.
Subject:	Autostar #494 blank screen after download
Sent:	Saturday, October 25, 2008 16:05:36
From:	greg Williams (greg95111@gmail.com)
First off, thanks for the fantastic site.

I just finished downloading and updating my 494 Autostar but now the LCD
screen is completely blank.  I have the back lit buttons as well as the
back lit screen but no text is visible.  I've replaced the batteries
thinking that that may have been an issue and have tried the reset
(Enter+Scroll Down) but no luck.  Any ideas?

Thanks,
Greg 
Mike here: There is NO user-installable update for the AutoStar #494. It you tried to install one you likely have corrupted it. You only choice would be to return it to Meade for a repair or replace it with a new AutoStar. If you do decide to get a replacement, I suggest getting a #497, which is user-updateable or a used #495, which you can update to a #497 with software from Meade's web site.

And:

I was afraid that was going to be the answer.  I've ordered the Meade
USB-Parallel cable on the off chance that the Autostar lost it's
connection during the update and that's causing the problem.

Thanks again,

Greg
Mike here: Since there is no update for the #494, you can't reload the ROM, with or without a USB-serial adapter.
Subject:	#494 hand box
Sent:	Friday, October 24, 2008 21:45:07
From:	WHEATHAULER@aol.com (WHEATHAULER@aol.com)
I have a etx-80AT-TC the hand box is a #494 when i turn on the handbox
it comes up with a code that say,s  (Proc. TRAP 2 )BUT NOTHING else
happens the hand box will not do any thing eles. what can i do to get it
to work, or do i need to get another box? thank ernie
Mike here: If you search the Site for "Proc Trap 2" you will see a few similar reports. If you read the article "AutoStar Proc Traps" on the Helpful Information: AutoStar Info page you will learn about them. Unfortunately, for the AutoStar #494 there is not a lot you can do. But check the batteries and that they are inserted correctly. Check the condition of the cable pins and the HBX jack. If those don't help you will likely need to get a new AutoStar. If you do get one I recommend getting a #497 (which is user upgradeable) or a #495 (if you can find one) as the #495 can be upgraded to a #497 via the software on Meade's site using a #505 serial cable.

And:

thank.s mike i,ll look up what you have rec. and get back to you. thanks
for your help . ernie

Subject:	Meade LX-90acf and autostar and vista
Sent:	Wednesday, October 22, 2008 22:15:32
From:	GRAHAM STEVENS (graham.hobart@bigpond.com)
I have one of the new meade lx 90 8" ACF with gps. The autostar version
is 5, handbox #497, I used a belkin pda USB to serial adapter and the
meade 505 adapter kit, downloading both drivers to brand new sony laptop
running windows vista with the autostar. I connected it all up and it
has now fried my autostar completely. There is no response. I did not
attach it to the aux port and all the cables were meade. I have read
this happening with ETX's and your replies. Any experience with the LX
90?
Graham Stevens
Mike here: The AutoStar ROM (handset) is version 5? Or the AutoStar Suite (software) is version 5? The last I knew, the AutoStar that shipped with new LX90-ACF telescopes was 4.4.Ea. I never needed to update my LX90 AutoStar (before it was sent back). However, loading an old version ROM onto the LX90 AutoStar is not a good idea if it shipped with 4.4Ea. As to the USB adapter, see the article "AutoStar and USB" on the Helpful Information: AutoStar Info page. Not all USB adapters work well with the AutoStar. I've used a Keyspan one successfully on my Macs with the AutoStar. As to "frying" your AutoStar, do you mean that smoke came out of it? If so, that indicates a power problem, likely caused by a bad cable. If you mean that the AutoStar went blank during the update, you may be able to use the SAFE MODE (see the FAQ page) to restore the AutoStar. However, Meade has not yet made the LX90 4.4Ea version available on their web site.
Subject:	Re: Autostar 497, ETX 90C, No Dec motion in Guide mode when N/S pushed.
Sent:	Tuesday, October 21, 2008 12:32:32
From:	Howard C. Anderson (support@azcendant.com)
Just an update.  Bought a second Autostar just to make sure it was not
the source of the problem.  It was not.

Motor boards in the ETX-90 scope I have are 1998 Rev D.

I have carefully checked gear trains, etc., etc.  The only remaining
item is the motor boards (probably their PIC controller programs)
themselves.

Called Meade this morning.  Just now got back from shipping scope to
Meade UPS to see if they can improve Dec response.  (Person I talked
with at Meade indicated that 1998 Rev D was pretty old and maybe some of
the first ever shipped!)

I think there are two possibilities:
	1.	Meade replaces the motor boards or the PIC processors.
	2.	<>Meade pretends there is no problem and ships it back with no changes.  :-)
	3.	<>
Costs $150 plus $50 shipping-back charge from Meade.  Somehow I just
shipped UPS for just $28.70 so maybe Meade is going to use gold-plated
shipping boxes?  :-)

Will let you know how this all turns out.  

Its been driving me nuts so I just have to know...
-- 

Thanks,

Howard
Support@AZcendant.com
http://www.AZcendant.com

And:

From:	Andrew Johansen (johansea@optusnet.com.au)
Gday Howard
 
> Just an update.  Bought a second Autostar just to make sure it was
> not the source of the problem.  It was not.
 
 Based on yr train numbers, its 99% sure to be a sloppy
 geartrain/support structure
 
> I think there are two possibilities:
 
I vote for 2, I dont think 1) will help given the total slop
 
> 1) Meade replaces the motor boards or the PIC processors.
> 2) <>Meade pretends there is no problem and ships it back with no changes.  :-) <>
 
> Costs $150 plus $50 shipping-back charge from Meade.  Somehow I just shipped UPS
> for just $28.70 so maybe Meade is going to use gold-plated shipping boxes?  :-)
 
But you only have to ship it to them :-)
They have to send it to Mexico, get it back from Mexico, then send it
back to you
 
Andrew

Subject:	Update on Alignment
Sent:	Monday, October 20, 2008 14:01:20
From:	Jonathan B. Crew (jcrew@hanover.k12.va.us)
Well, I went out last night and I somewhat sucessfully aligned the scope
and sort of got the gotos working. Your tutorial/advice really helped. I
am using the 494 controller and my guess is that it is limited in
accuracy since I can only enter my zip-code or city. It was off some...I
was hoping the stuff would show up in the FOV. It was close though (I
think). Any tips to get the 494 pointing the scope more accurately? I
will keep trying and learning the sky...that seems to always help.
 
Thanks,
Brad
Mike here: You can ADD or EDIT a location in the #494 but as long as you are within 60 miles (or less) of a CITY in the AutoStar, you should be OK. If you do want to add your location, it is usually best to EDIT an existing one; that way you get the ZONE ZONE set correctly. As to improving accuracy, be certain you have done a CALIBRATE MOTOR and TRAIN DRIVES. Using a high power eyepiece for training and the star alignments will improve the accuracy.
Subject:	Alignment Question
Sent:	Sunday, October 19, 2008 08:25:57
From:	Jonathan B. Crew (jcrew@hanover.k12.va.us)
How is it going? I emailed you a while back; thanks for the quick and
excellent response! My question is: Is the home position when you turn
the scope and mount to north (guessing magnetic north) and level the
scope and mount? This is what they show in the videos as the "home
position". It is then that they say to do the star alignment (I have the
494 controller). I am just confused as to whether I set it to the home
position and then do the star alignment or do I align the scope pointing
at polaris and then do the star alignment with the autostar? I have read
some of the sections on the website...but no luck fully clearing up my
confusion. :)
 
Thanks,
Brad
 
PS...I'm using an ETX mounted on a DS-2080 mount (thanks for the
modification and bringing new life back into my ETX90RA)!!!
Mike here: First, the Home position is based on True North, not Magnetic North. So using Polaris instead of a compass will get you closer to True North in many locations. Now has to the DS mount, in looking at the DS manual on Meade's web site, it appears that the OTA should be pointed to True North and the OTA level.

And:

Thanks mike....you wrote...."it appears that the OTA should be pointed
to True North and the OTA level." Did you mean the mount should be
level? If so, let me see if I understand this...
1. Level the mount.
2. Point the tripod and the OTA at Polaris (im guessing this is true north)?
3. Do the autostar star alignment.
 
Does this sound about right? Do I have to necessarily worry about the
setting circle positions or is it all done with the computer?
 
A tremendous thank you (again) :)
Brad
Mike here: You can ignore the setting circles. Just level the telescope tube and point the telescope tube towards True North on the horizon. Don't point the telescope AT Polaris; just draw a line (in your mind) straight down from Polaris to the horizon and point the telescope at that point.

And:

10-4...Roger that! Looks like it might be a clear night here in
Virginia. Gonna give it a shot tonight. Thanks again for your help.

Subject:	Autostar [44E] Utility menu
Sent:	Friday, October 17, 2008 08:35:51
From:	John Batiste
I am trying to find a definition of the "Brightest Star" option on the
Utilities menu of the Autostar [44E].

I have received two answers from Meade Customer Service, both of which
are incorrect.

1. Toggling "Brightest Star" between OFF and ON turns OFF/ON the
Smartfinder red dot.  Wrong, the red dot is turned off and on by using
the 0 (light bulb) key on the hand box.

2. Toggling Brightest Star between OFF and ON determines whether the
alignment process displays "Center Brightest Star" or "Center "Star
Name"".  Wrong, toggling has no effect on the alignment displays.

There is no mention of a "Brightest Star" menu option in the owners'
manual or in documentation found on the Meade online site.

Note: The Display menu option to turn ON/OFF the Sun Warning and Getting
Started messages no longer appears on the handbox.

Am basically frustrated with what Meade documentation says versus what
the scope or hand box displays.

Any help?
Mike here: The LX90-GPS manual on Meade's site has this description:
	Brightest Star: If turned on, displays the phrase "Center Brightest Star"
	instead of the name of the alignment star during the alignment
	procedure.If turned off, will display the actual name of the alignment
	star (e.g., "Sirius").

This was added in some earlier version of the AutoStar ROM. The Sun Warning and Getting Started screens were deleted some versions back as well.

And:

Thank you very much!
 
I find it interesting that I need to refer to a LX90-GPS manual for
information relating to an ETX.
 
Appreciate it ...
Mike here: Or you can refer to the Helpful Information: AutoStar Info page on my ETX Site for TONS of AutoStar information.
Subject:	Re: Autostar 497, ETX 90C, No Dec motion in Guide mode when N/S pushed.
Sent:	Thursday, October 16, 2008 15:06:46
From:	Howard C. Anderson (support@azcendant.com)
Richard Seymour wrote:

>>I also just noticed that I can issue GD commands during a slew so
>>perhaps I can monitor declination readout for small changes
>>and see if there was sufficient motion and save the time values
>>for various motions as an alternative.  (Then I saw that this is
>>similar to what you were suggesting except I need to read GD
>>DURING the move.)
>>    
>
>There is dither and delay in the production of the GD numbers.
>In fact, you can -really- be misled if you try that on an LX200gps.
>(in all autostars, do not interrogate it for position more than twice
>per second, if that).  At least in the LX200gps, the function which
>reads and translates the encoders operates asynchronously from the
>:GD# routine... and they're not "thread safe" so you can get mixed
>partial results sent back up the wire (see it shift 90 degrees for 1/4 second!).
>
OK, sounds like a problem if I try to do that. 

>>Now that I understand things a little better, I think I might be able to 
>>write something that will always work and automatically take a particular
>>scope's peculiarities into account in "Centering" mode for Dec motion. 
>> 
>
>It was hitting the word "always" which caused ROTFL action...
>(wiping tears from my eyes...)
>
Sorry.  Did not mean to provide comic relief...  :-)  I'm finding much
of the Autostar/ETX behavior rather unfunny.  :-)  In a morbidly funny
way...  :-)

>>Not positive I can do it though.  The acceleration scheme
>>programmed in to the motor PICs is really disgusting...
>>
>
>I'm still not completely convinced it's not in the Autostar programming
>instead of the PIC, but Andrew's studied it harder and more recently
>than i have.  A test would be to command a guide motion, then *disconnect
>the Autostar* and see if the PIC still ramps up after 6 seconds.
>If it does, it's PIC and all hope is lost.  If it doesn't, then...
>
>>As is the automatic switching to Guide mode for Mg commands.
>>I mean, couldn't they have trusted us to set the speed
>>the way we wanted it for Mg commands.  :-) 
>>
>
>Meade's reasonable stance:  If you're guiding, you're not slewing.
>Hence once you start sending Guide commands, you -want- to run
>at Guide speed.
>
That would be fine if it would "Guide".  :-)  6 minutes to change
direction in Dec is a bit much.

>If you want to slew, or GoTo, then prepare the turf to a known
>state by sending a speed command before sending the :Motion command.
>  
>>I used to work in the Multics system 
>>
>
>... what is it about Meade scopes that attracts the Multics crowd?
>You are perhaps the 5th or 6th whom i've "met" dealing with Autostar issues.
>
>>where the philosophy was "If it won't
>>HURT the user to be able to do something, don't restrict him
>>
>>from doing it...  He might be smarter than you..."
>
>..and from that crowd we got Unix, whose view is: "ignore the user,
>kernel mode is holy" ... so much for "trust".  
>
Actually, Unix came from a break-away group.  Bell labs bailed out of
Multics (which had been a government sponsored joint venture between (if
I recall correctly) IBM, Honeywell, Bell Labs, and of course MIT where I
believe most of the software work was done.  When Bell Labs bailed out,
two of the Multics guys, Thompson and Ritchie, missed Multics so much
that they wrote an "enucleated" version, UNIX, for a "cast-off" PDP-8
computer. (Bell System Journal Jul/Aug 1978 p1899.  UNIX was started in
1969.)

Multics was a much richer and far more impressive system.  Where I was
in the Pentagon (mid 1970s), it was running on a Honeywell 6180
mainframe computer.  Among other things, while it was running, you could
actually power down one of the memory banks it was using and it would
immediately recover without anyone losing anything. It was certified C2
secure so we ran Top Secret and Secret users within the same system with
lots of assurance that the Secret guys could not see the Top Secret
stuff.  It had true dynamic linking and you could run FORTRAN and PL/1
(or any other compiler's output) subroutines and have them call each
other and link at run-time without having to run a linker or do anything
special.  We once were running a 72 hour simulation model (like of World
War III) that  blew out in hour 70.  We found the subroutine that blew
out, fixed it, recompiled it,  backed up one stack frame and continued
to completion at hour 72 without having to rerun the 72 hour simulation.
 Don't know of any other system that could do that now or in the past.

>Gimme DEC's VMS any day....  (12 microseconds after putting a signal on an
>external wire, you could be inside a user's program dealing with it... 
>even if the program was written in Fortran).  _That's_ trust.
>  
I never worked on a VAX machine.  Did work on Philco 2000, Philco 1000,
IBM 1130, IBM 360/85, Univac 1108, Honeywell GCOS, Multics, etc.  They
were all great fun...

>>I am visualizing a two-stage approach where I use Guide mode
>>first.  If the scope can handle it, then I go with it.  If not,
>>I switch Dec to Centering mode and gradually increment
>>Mn and Ms times to see how long is required to cause
>>sufficient motion without overshooting too much.
>>
>
>You have additional speed control... you can set a "maximum slew
>speed limit" (:W? I'm not near the docs)... and that's in degrees
>per second (floating point allowed, 8 maximum).  Then just command
>a max-speed slew (:Mn#).  This gives you far finer control than
>just the four :Rate commands.   The 497 (again, i'm not near my notes)
>may also support the :R1# :R2# :R3# ...:R9#  commands, which are equivalent
>to selecting handbox speed keys 1 thru 9. 
>
I tried the R commands.  No effect at all so my hand controller is not
paying attention to them. Would be really handy if I could issue R2.  I
could probably work there pretty well. Could not find anything on
"maximum slew speed limit". Found some set slew rate commands that apply
only to GPS and RCX scopes.

>>The acceleration
>>is the worst part of this scheme though.  I might not be able to
>>properly take it into account.  I might have to remember which direction
>>was last issued and have different time values depending on whether
>>a reversal is called for.  Pretty complicated but only testing
>>will show whether I can make it reliable.  I have already separated
>>the code into two different calibration schemes, one for the LX-200s
>>and one for Autostar-controlled scopes.  This is so I don't break
>>one while trying to fix the other...  :-)
>>
>
>If it's a "six second" error, you could do :Mn# (or Mg5000#) and then send a
>:Qn#  before the six seconds are up.  Then another :Mn#.  Perhaps you could
>-avoid- triggering the acceleration.
>
Unfortunately, its six MINUTES.  (Did I accidentally say six seconds
reversal somewhere?
If I did, I meant six MINUTES.)

>>Enough possibilities to keep me busy for a couple of days anyway.  :-)
>>
>
>Pick a soft wall for head-bashing.
>
Yes, that part I definitely understand...  :-)

>>I hate giving up on things...  Getting close to that point though...
>>
>>There must be something funny about this scope...  But I have
>>tried everything I know and everything you guys have taught me
>>so far...  I even shimmed the Dec motor so it is FOR SURE pushing
>>against the main Dec gear.  No effect...  Almost has to be something
>>in the electronics.  I suspect the motor PICs are misprogrammed somehow
>>but have no proof...
>>    
>
>For chuckles, you could load an *ancient* version of the Autostar firmware.
>On the order of 22Eb or even earlier.  See if that exhibits the
>same problems.  They're archived on Mile's "Autostar Info" page, left column.
>
Thanks!  I was thinking about doing that just in case...  But I didn't
see them on Meade's site.  I now see them on Mike's site.    I will
check them out...

I see that the "percent" commands are supposed to be the percent of the
Training value that gets applied at high speed.  I'm getting training
values for Dec in the vicinity of 4000.  If I force the value to 5000
then apply 99%, I hear the motor move at high speed on a reversal in
Guide mode but then it takes a LONG time for the Dec readout to change. 
It seems like it should change every 10 seconds or so and it does if I
use speed 3 and force the gear to move more so it is fully engaged. 
However the 5000 and 99% should have pushed it to fully engaged. 
Peculiar.  Not right...

Thanks for all your assistance everyone!

>good luck
>--dick
>
-- 

Thanks,

Howard
Support@AZcendant.com
http://www.AZcendant.com

And:

I am guessing that a "patch kit" is essentially the Meade release with
patches added to it instead of just patches to a Meade release that is
not available...

-- 

Thanks,

Howard

And:

From:	richard seymour (rseymour@wolfenet.com)
A patch kit is a script of bytes to change in the Meade file.
The kit includes an app which does the byte-tweaking.
Then you can use Meade's ASU to upload the result to the Autostar

*or*

You can use StarPAtch, which turns the (newer) patch kits into
"checklists", and which squirts the data to the Autostar much
faster (and more securely).

have fun
--dick
Ok,
Thanks. They are actual patches then.

Did anyone archive the Meade files that the patches apply to? If I want
to test earlier incarnations of the Meade software I need to be able to
retrieve some of those.

Thanks,

Howard
Mike here: I have all (or most all) the older AutoStar #497 ROM files on my AutoStar Software Archive page.

And:

Mike did... left column of Autostar Info page,
the last (or next to last) item in the first section at the
top of the column.

have fun
---dick (whose history of systems was: IBM 1620, IBM 1130 (yes, even A/PL),
IBM 1409, IBM 360 and then into the happy world of small DEC systems
(i -think- Unix started on PDP-9's, not -8's.))

And:

Absolutely wonderful!   Thank you Mike!

Thanks,

Howard

Subject:	Meade Customer Service re Autostar & cable for my new ETX-125PE
Sent:	Wednesday, October 15, 2008 12:42:00
From:	Sharon Stanfield (sharonstanfield7@charter.net)
I returned an Autostar and Autostar Cable to Meade for my new ETX-125 PE
on or about the 2nd. of October.  Every time I talk to someone at Meade,
I get a different story.  My scope was received new during the second
week of September.  I made a call to discuss the problems I was having
on my scope that was purchased on-line from one of their dealers on the
1st. of September.

Last Wednesday I was told by Anais Gamez (cutomer service) the replacemt
would ship on Friday.  I called on that day  and was told it had not
been shipped and was to late to get out on that day and would ship on
Monday.

I was not aware at the time that Moday was Columbus day, but I did call
on Tuesday around noon and spoke to a customer service rep (David) that
checked and found that the item had been blocked and that he would
un-block the item and said it would ship on Wednesday and they had a
number of the Autostars and cables in stock.

I called again today to check status, and was told that the Autostar
could not ship, and that the unit to be reprogrammed and it would take
several weeks. I told him reprogramming does not take that long and it
should not take a week to reprogram.  He then advised that they need
chips that are on backorder and awaiting for units from China and do not
have a date as to when they would arrive.

John T. Stanfield
(former physicist, engineer & retired as Director of Military Programs and Sales in Oct. 2005)
Mike here: Bummer. It could be that they are out of stock and waiting "chips". It could also be that they are reprogramming them to version 4.4Ea (which is not yet available on their web site). I don't know what their process is for that.
Subject:	Autostar 497 does not list the LX90
Sent:	Tuesday, October 14, 2008 16:32:04
From:	Sam Selig (bigdob1400@gmail.com)
Just received a new LX90-ACF and Autostar #497. The Autostar came loaded
with version 44e but when turning on the scope for the first time, the
Autostar can not slew the scope and the auto align does not move the
scope. The motors just do not engage. Ran through setup and noticed that
the LX90 is not listed under the telescope types. Only the DS, ETX and
LXD series are there. I tried upgrading the Autostar and much to my
surprise, the upgrade actually downgraded the handbox to version 43g. So
here I am with a new scope that does not move and has no guide function
at all. Is there a way to clear the handbox and reload all data
including the drive motor details? Any way to test the drive motors? I
am not getting any response from Meade and am hoping I do not need to
ship it back for service as it is a brand new scope just off the line.
After waiting almost three month you would think it would arrive in
working order. Any ideas  or suggestions will be greatly appreciated.

-- 
Sam Selig
Keep Looking UP
20 f/5 #1400
WO 80 APO
10 LX90-ACF
Mike here: Actually, for a new LX90 you WANT AutoStar 4.4Ea. But since Meade hasn't yet posted it you are sort of out of luck for the gear fixes. But even 4.4Eg should work with the LX90-ACF. Try doing a RESET and CALIBRATE MOTOR. See if it responds.

And:

Thanks for the quick reply. Running a REST and CALIBRATE does not help.
Still have the issue of there not being an LX90 to pick from the list of
available telescopes. I would also love to reload 4.4Ea or 4.4Eg but
they do not exist in my tables or out with Meade. It only existed on the
AutoStar when I first turned it on. Performing an update dropped it to
4.3g and there does not seem to be a 4.4 available anywhere.  Any other
ideas?

Sam
Mike here: Odd. Perhaps something has changed that requires the 4.4Ea version. Hopefully Meade will post it soon. You could contact them; perhaps they will send you the ROM file. One other thought: try reversing the AutoStar coiled cable.

And:

No luck... I have calls in with OPT and am still waiting to hear from
Meade.
Once we find a solution I will be sure to let you know.

Subject:	Re: Autostar 497, ETX 90C, No Dec motion in Guide mode when N/S pushed.
Sent:	Monday, October 13, 2008 00:00:25
From:	Howard C. Anderson (support@azcendant.com)
OK,

Thanks Richard.  Very helpful!

During my tests this morning, I was in Guide mode.  Pressed the N key
and the Dec ran away in high speed for about 10 degrees! It then paused
for 3 or 4 seconds then moved another 10 degrees! It continued to do
that until I pressed the S key several times.

After that, the Dec readout did not change no matter how much I moved
the scope even at the highest slew rate.  The scope moved but the
readout did not change.  There is something else wrong with this scope
or the autostar I think. 

Other symptoms:  While stuck in the above situation, when I changed the
slew rate to 2, the RA moved slowly at slew rate  and the RA readout
showed the changes.  However pressing N or S caused the scope to move at
the highest slew rate and the Dec readout remained constant at 33:44!

So now I need to figure out how such a thing can happen and what to do
about it.  This is probably related somehow to the original problem
where I do not see Dec motion even though, presumably, the scope thinks
it is moving. 

To restore the Dec to "normal", I will have to redo the alignment.

Think I need to locate the circuit diagrams of the scope itself and the
Autostar and see how run-away motion could be possible.  I have seen
this occur in the past with this scope and the run-away motion was in
both Dec and RA.  I replaced the connectors between the Autostar and the
scope and thought I had this fixed.  Apparently not.  I cannot imagine
that the Autostar is issuing rogue commands.  Or could it be?  

On a hunch, I decided to hot-unplug the Autostar.  (VERY DANGEROUS for
an LX-200 - almost guaranteed to cause a serious electrical problem,
i.e., blows out a chip I think...  Once, when irrigation system pipe
broke and sprayed my scope I unthinkingly caused this problem while in
panic mode: http://www.astroshow.com/astrotip/saga.html ) 

I have not seen any warnings about plugging/unplugging the Autostar so I
was guessing that Meade corrected this problem for newer scopes.  After
unplugging, all motor noise stopped.  So the Autostar is apparently
doing all of the control of the motors?  So there is probably nothing in
the ETX-90 that could be the source of the problem? 

Hot-plugged it back in and it seems to be OK.  Wants me to redo the
alignment.

So maybe I should purchase another Autostar controller?  I need to solve
these problems so my software works correctly with these scopes.   It is
now a matter of irrepressible intellectual curiosity in addition to
wanting my software to handle these scopes.  :-)

Is there any chance that what I am observing could originate in the
scope's board(s)?

WHOA!

On suspicion, I took the Autostar apart to look for circuit board
problems. Found some!  Surprised me!  I really didn't expect to find
anything.  Found poor solder connections at the leads of BOTH large
capacitors!  (What we used to call "cold-solder joints" in Ham radio.) 
Here is the board:

photo

The two capacitors are the relatively large blue objects.

Here is the one nearest the 68HC11 computer chip:

photo

Not as easy to see in the photo but the two capacitor leads are very
poorly soldered.  Should be shiny, smooth and slightly raised.  These
are not. 

I resoldered these connections!  Also the ones at the other capacitor Am
now getting changing readings when I press N or S in Guide mode. About
one minute of Dec every 60 seconds.  Before, I was getting nothing. 

I think this capacitor was only intermittently connected and when I
moved the control box to certain angles it connected or disconnected
causing a severe voltage spike which probably caused the random
telescope motion effects I was seeing earlier.  The microprocessor
probably didn't know what hit it!  :-)

I'm waiting for it to get dark now to be absolutely sure that I see Dec
motion at Guide speed.

Yes but it is extremely slow.  It moves Dec at 1 ArcSecond per second,
approximately the Sidereal rate.  That is MUCH too slow.  The diameter
of Jupiter at the moment is 38 Arc Seconds. it would take 38 seconds for
Jupiter to move one diameter!

Noticing something else I will have to take into account.  The RA
percentage Backlash corrections are applied in only one direction in
every mode but guide mode.  When the RA is reversed in one of the
directions, the correction is applied, the movement order is carried
out, then the correction is DE-APPLIED!  Takes time.  Must take time
into account somehow to effect correct calibration.

Sorry to bore you with details.  Appreciate your help.  I've been
working on this all day and am getting tired. 

My last thought is that I might be able to do the calibration and
centering by doing RA in Guide mode and Dec in "Centering" mode.  Will
try that tomorrow.

Have been working on this from 6:00 AM to Midnight...  Normal for me but
I am tired...

Thanks,

Howard

And:

Thanks.

Yes, the Autostar does seem to have some peculiar software. I notice if
I center Jupiter for example, SYNC on it then go someplace else, when I
select Jupiter and go to it, it is NOT centered.  Not even close.  The
scope doesn't seem to have anywhere near the precision of the LX-200...

Not sure what you mean by Drive Train Numbers.  Unless you are talking
about the RA and Dec Percentage settings RA is 80% and Dec is 10 or 15 I
think.

Lots of slop in the two axes...  LX-200 does not have those problems...

Thanks,

Howard
Mike here: SYNCing on moving objects like planets is not normally a good idea. It can introduce pointing errors. Use a fixed object. And then, the alignment is only improved in that area of sky.

And:

That was not the point.  The point was whether the scope can return to
the same place.  The same problems occurs if I do the same thing with a
star instead of a planet.
Mike here: That I haven't seen before.

And:

Thanks, that is useful information that continues to tell me that maybe
this scope and its subsystems are not working properly.  So I should
expect the scope to return pretty much accurately to a location that I
Sync'ed to.

I did grease the Dec axes.  They were pretty bad.  Previous grease was
more like glue.  That might account for some other symptoms I was
seeing.  Seizing up a bit wouldn't help I'm sure.

Thanks,

Howard

And more:

From:	richard seymour (rseymour@wolfenet.com)
As i read your note, i was screaming "open circuit!"
(until the neighbors called)
Runaways can occur if the data lines between the Autostar
and the subsidiary computer cards at the motors break.
If the clock line is solid, but the data line is erratic,
runaways can happen.

There's somewhat of an overview of "how it all works" at:
http://www.weasner.com/etx/autostar/as_schematic.html

The full story is in Meade's patent: 6,304,376
...which you can download as a PDF (hence all images) from
http://www.pat2pdf.org/
(it's 3.1 megabytes that way)

Your photos show that you have what i call the "old" 497.
(the broad centered display cable is the big giveaway).
Your capacitor photo shows that my "old" photo has the
near-68hc11 capacitor standing up from the board... i probably
did that to access the traces beneath it, and i didn't lay it
flat (again) for the photo.   (the "old" one has a more-capable
display module).

As Andrew said, you should be seeing 8 arcsec/sec at guide rate
(actually, i would've guessed 12 arcsec/sec ... there are some
guide rates of 50% of sidereal, others at 67%)

Andrew asked what Training values you got... Meade doesn't tell
you the results of Drive Training, so that inspired me to get into
the (unpaid) business of "patching" the Autostar firmware.  For
each firmware version, i create a list of tweaks which modify the
ROM file on your PC, then you download that updated file to gain
additional features and/or to fix some of the bugs.
One of the patches displays the Training results on the handbox,
and lets you edit them from the keypad.
Another portion of the kit changes the fundamental guide rate.
Each tweak of the kit is individually selectable.
Patch kits are available from Mike's "Autostar Info" page, or are
automatically available if you use StarPatch to perform the update
(it provides a tick-list of the subsections).
http://www.weasner.com/etx/autostar_info.html
http://www.weasner.com/etx/autostar/patches/patch43eg.html  <--43Eg
http://www.stargps.ca/starpatch.htm

Andrew has written a "PEC Editor" which has many many more features,
including the ability to show (as its startup screen) many of the
internal parameters of the Autostar.  If you have my patch kit loaded,
it adds byte-level "peek" and "poke" functions which give Andrew's
program even more access and control.
Pick up the beta version from the bottom of:
http://members.optusnet.com.au/johansea

have fun
--dick

And:

Thanks VERY MUCH Dick and everyone.

I am quite sure the runaway problem was the poorly soldered capacitors.
It has not happened since I resoldered the connections.  So that is the
one bright spot...

I still am not able to get consistent Guide results.  I have noticed
that if I set to "5" then push N then set to 1 and push N, I get about 1
Arc minute every 10 seconds according to the readout.  If I do the
similar thing for S,  I get similar results.  However if I have done
that for N and am in Guide mode, then press S, the Dec motor seems to
run OK but the screen shows no change in Dec for a LONG time.  REALLY
LONG TIME. When set for Slew Rate 3 or so, if I press N, Dec Display
shows Dec slowly moving for about  2 or 3 seconds then the speed greatly
increases.  The motor SEEMS to maintain constant speed through all this
but I can't be sure.  When I view this with a webcam centered on a
planet, it move slowly for about 2 seconds then suddenly zips out of the
field.

So far, I have not been able to see any discernable movement when set to
Guide Slew Rate.  Someone I have been working with related to HandyAvi
has an ETX-125 and reports that in Guide speed, with Dec held down, an
object crosses the entire view field of a webcam chip in 30 seconds.  I
could live with that almost...  Its still awfully slow.  (On the LX-200,
the reason it is called "guide" mode is because you can keep an off-axis
guide star centered using the hand controller.  If the motion is too
fast you would ruin your photo.  If the motion was too slow, you would
not be able to keep up over time.  The LX-200 got it just about right.)

So, something seems wrong but I am unable to determine what.  I had the
entire thing apart with the OTA removed and watched the Dec motor run
while I put it through its paces.  It sounded like it was stuttering a
bit rather than running really smooth but I assume that is a function of
the stepping algorithm.  I checked the encoder for excess grease (wasn't
any) and wiped it down.

Also wiped down the transmitter/receiver chips that look through the
tabbed wheel.  I inserted a piece of paper to interrupt the light beam
while holding N or S and the motor sped up to full speed. So it looks
like the encoders act more like brakes than go-ahead signals.

So I was unable to find anything "not working" but if it is working to
spec, those must be pretty weird specs!

Thanks for info on "training.  Sorry for the confusion Andrew.  I was
unaware of the software additions until now.

Would like to make this work using "vanilla" version so users of
HandyAvi can operate ETX scopes without having to do anything extra.
Will experiment more tonight with alternative calibration schemes.

And more:

Ohhh.... so many questions...

Let's try explaining, and maybe that'll answer some (or point to how
to do so).

When you reverse the motor, the DEC display will stay steady until
the previously measured backlash has been (theoretically) overcome.
So if the Autostar -thinks- that it requires spinning the motor
enough to move 2500 arcseconds *before the scope really moves*,
then it won't change the DEC display until that much motor motion
has occurred.
This might be why you have to wait a REALLY LONG TIME for any change.
(how about some quantification: how long -is- that?)

If you -have- performed a Setup/Telescope/Train Drives for the Alt/DEC Axis,
then it's using your numbers.  IF you're never done a Train, or have RESET
or selected your telescope model since then, then it's working with a "factory
default" of about 2500.
If your DEC bearings are loose in the forks, that can greatly increase the
Training result.
As an example, my plastic-bearinged 9-year-old (and bought used) ETX90
Trains to 1100 in the Az axis, and about 3200 in Alt  (yes, thirty-two hundred).

We don't expect that you'll need patching for HandyAvi to work,
but we -do- suggest that you patch -your- firmware to have more information
available about why it's not working (As you expect).
At least download Andrew's PEC editor so that you can see your Training Results.
No patching needed for that function.

You were watching the DEC motor stutter along ... well, the optical encoder
is quite likely being confused by the ambient lighting.
Did you do a "Calibrate Motors"  with the forks open?
If not, you undoubtedly shifted the waveforms from the
expected 50% square wave to something unexpected.
(LXD55's -really- go weird if there's ambient light)

The Autostar sends a -speed- command to the motor cards.
The PIC on the motor cards watches the encoder disk to maintain that
-speed-.  It is -not- a "stepper" system, it's an "encoder transitions
per 6 milliseconds" feedback loop... if it doesn't see enough go by,
it speeds up (as you saw when you blocked it).

It's certainly possible that one of the DEC motor coils isn't up
to spec... but usually that means there's one spot in its
rotation that gives you a dead motor.  But a partially shorted
coil might be erratic.  At low speeds the motor isn't really
turning too rapidly.

If anything else comes to mind, i'll send it along...

good luck
--dick

And:

From:	Andrew Johansen (johansea@optusnet.com.au)
> At least download Andrew's PEC editor so that you can see your Training 
> Results.
> No patching needed for that function.

Yes there is,
The LX200s dont need the patch, but the 497s do
unless he wants to go into download mode every time ;-)

Andrew 

And:

...which does not require patching.

I never said it would be -convenient-.

have fun
--dick

And even more:

Comments interspersed below...

richard seymour wrote:

> Ohhh.... so many questions...   

Sorry... :-)

> Let's try explaining, and maybe that'll answer some (or point to how
> to do so).
>
> When you reverse the motor, the DEC display will stay steady until
> the previously measured backlash has been (theoretically) overcome.
> So if the Autostar -thinks- that it requires spinning the motor
> enough to move 2500 arcseconds *before the scope really moves*,
> then it won't change the DEC display until that much motor motion
> has occurred.
> This might be why you have to wait a REALLY LONG TIME for any change.
> (how about some quantification: how long -is- that?)  

OK, Quantified: 

   1. Ran Center mode to South until it seemed "caught up".
   2. Changed to Guide mode.
   3. Pressed South and it seemed to be moving slowly.
   4. Then held North down to reverse direction.
   5. It moved from -23:13:29 to -23:05:21 in 6 minutes, 41 seconds.
   6. That is a speed of 8/5 or 1.6 Arc Minutes per minute or
      .027 Arc Minutes per second.
   7. It then seemed to pick up.
   8. It can now go North from -23:03:30 to -23:01:44 in 10 seconds
      which is about .14 Arc Minutes per second or about 5 times
      faster than when it starts out.
   9. If I reverse direction again, it will take another 6+ minutesto
      "catch up" before running at any perceptable speed.
  10. So it seems like it has two speeds REALLY REALLY SLOW
      and REALLY SLOW.
  11. The transition on reversal is absolute death to any
      sort of calibration or guide operation.

> If you -have- performed a Setup/Telescope/Train Drives for the Alt/DEC 
> Axis, then it's using your numbers.  IF you're never done a Train, or have 
> RESET or selected your telescope model since then, then it's working with a 
> "factory default" of about 2500.

I have done the training.  Both on "terrestrial" objects and tonight on
Jupiter I was very careful about doing it.  If I set the Dec % higher
than 20, a JUMP occurs on Dec Reversal.  So I don't see how to take up
the slack without causing the jump.

> If your DEC bearings are loose in the forks, that can greatly increase 
> the Training result.

Bearings are not loose.  Seem to fit nicely.  Forks and bearings are
plastic though.  Yuck...

> As an example, my plastic-bearinged 9-year-old (and bought used) ETX90
> Trains to 1100 in the Az axis, and about 3200 in Alt  (yes, thirty-two 
> hundred).

Even after training, it looks like the AZ requires more than 99% of the
additional AZ kick.  I have looked at the motor and the mechanical
stuff.  I don't see what could result in so much slop...

> We don't expect that you'll need patching for HandyAvi to work,
> but we -do- suggest that you patch -your- firmware to have more 
> information
> available about why it's not working (As you expect).

OK, I will do that in the morning.

> At least download Andrew's PEC editor so that you can see your 
> Training Results.
> No patching needed for that function.

OK, No problem.  I was not worried about the patches I just would prefer
that after problems are resolved, users of HandyAvi will not need to do
them as part of the standard HandyAvi setup.

> You were watching the DEC motor stutter along ... well, the optical 
> encoder is quite likely being confused by the ambient lighting.
> Did you do a "Calibrate Motors"  with the forks open?
> If not, you undoubtedly shifted the waveforms from the
> expected 50% square wave to something unexpected.
> (LXD55's -really- go weird if there's ambient light)

I didn't recalibrate.  I did cover the encoders with my hand to shut out
light.  No difference in stuttering.  I was working in a poorly lighted
area.  I did notice that if I shined a flashlight on them that they did
react to it so I was aware of their response to ambient lighting.  I do
not think it was a factor.

> The Autostar sends a -speed- command to the motor cards.
> The PIC on the motor cards watches the encoder disk to maintain that
> -speed-.  It is -not- a "stepper" system, it's an "encoder transitions
> per 6 milliseconds" feedback loop... if it doesn't see enough go by,
> it speeds up (as you saw when you blocked it).

OK, that helps.  I wonder if the -speed- sent by the Autostar is aware
of the particular motor cards in my telescope.  :-)

> It's certainly possible that one of the DEC motor coils isn't up
> to spec... but usually that means there's one spot in its
> rotation that gives you a dead motor.  But a partially shorted
> coil might be erratic.  At low speeds the motor isn't really
> turning too rapidly.

I sort of hate the thought of switching the motors for testing but it
has occurred to me - assuming they are both essentially the same. I am
willing to try that of course.

> If anything else comes to mind, i'll send it along...

Really appreciate your help!  All of you!

I am wondering if the easiest way to resolve this is to buy another
scope...  :-)  Got this one from a friend who rarely used it.  So it is
essentially in pristine condition.  Pretty sure my friend did not
disassemble it like I did today.  Or cause any damage to it.  I'm pretty
sure it is in the condition he received it in.

> good luck
> --dick

-- 

Thanks,

Howard
Support@AZcendant.com
http://www.AZcendant.com
Mike here: Howard wrote:
> Really appreciate your help! All of you!
We are privileged to have an excellent AutoStar support team out there!

And:

>    4. Then held North down to reverse direction.
>    5. It moved from -23:13:29 to -23:05:21 in 6 minutes, 41 seconds.
>    6. That is a speed of 8/5 or 1.6 Arc Minutes per minute or
>       .027 Arc Minutes per second.

Which pretty much agrees with my "roughly 20 seconds per arc minute"
I didn't lean on my slew key for 6 minutes.

I wonder... if you -were- sending a continuous guide signal for that
long, you well could have overflowed some internal Autostar variable.
Meade has-two- speed commands they send to the motor cards.
One is the fundamental "go at speed XXX transitions per second",
(Andrew may correct me on the units), and the other is a "tweaker",
telling the motors to fine-tune from the fundamental.
Guide commands use the "fine tune", and a *long* guide request could be
overflowing or rolling over the "tweak" numbers.  If that's happening in the
motor card's firmware, we'd be in the dark (other than saying: "don't
do that for that long (without a break)"

>    7. It then seemed to pick up.
>    8. It can now go North from -23:03:30 to -23:01:44 in 10 seconds
>       which is about .14 Arc Minutes per second or about 5 times
>       faster than when it starts out.
>    9. If I reverse direction again, it will take another 6+ minutesto
>       "catch up" before running at any perceptable speed.
>   10. So it seems like it has two speeds REALLY REALLY SLOW
>       and REALLY SLOW.

Again, my -expectation- would be that Guiding would move in Dec at a rate
of 10 arcseconds per second, or ten arcminutes per minute. (67% of sidereal)
(ummm...  0.16 arcmin per second, which agrees with your result)

So that makes the slow motion a puzzle, and the "faster"  motion "correct".

>> If your DEC bearings are loose in the forks, that can greatly increase 
>> the Training result.
> Bearings are not loose.  Seem to fit nicely.  Forks and bearings are 
> plastic though.  Yuck...

OH... you have an *old* ETX125... the newer ones have metal forks and
ball bearings.  In my old ETX90, the fork bearings have ellipsoidal holes,
and the OTA can -twist- due to the forces upon the final drive gear.
The reaction to those forces also flexed the fork plastic supporting
the worm carrier.  I overcame that by adding shims to pre-stress the fork
and transfer the load to one of the stiffening ribs on the fork plate.
That dropped the GoTo error from "quite a bit" to under ten arc minutes.
(yeah, a third of the moon's width is still pretty bad, but some nights
it was far better)

I run my anti-backlash percentages fairly low... roughly 10 and 20% (Az and Alt).

>> The Autostar sends a -speed- command to the motor cards.
>> The PIC on the motor cards watches the encoder disk to maintain that
>> -speed-.  It is -not- a "stepper" system, it's an "encoder transitions
>> per 6 milliseconds" feedback loop... if it doesn't see enough go by,
>> it speeds up (as you saw when you blocked it).
> OK, that helps.  I wonder if the -speed- sent by the Autostar is
> aware of the particular motor cards in my telescope.  :-) 

The Ratio setting is in units of "encoder transitions per arc second of
OTA motion", and serve as the scaling factor.

>> It's certainly possible that one of the DEC motor coils isn't up
>> to spec... but usually that means there's one spot in its
>> rotation that gives you a dead motor.  But a partially shorted
>> coil might be erratic.  At low speeds the motor isn't really
>> turning too rapidly.
> I sort of hate the thought of switching the motors for testing but it has
> occurred to me - assuming they are both essentially the same.
> I am willing to try that of course.

You can easily do that (for testing) by opening the base and swapping
the RA and DEC cables on the power panel (carefully observe polarity...
don't trust Meade  to be consistent with regards to wire colors vs polarity).
The wrong axis will move, but you'll be able to see if the speed
variation pattern transfers to the other motor card/axis.

> I am wondering if the easiest way to resolve this is to buy
> another scope...  :-)  Got this one from a friend who rarely
> used it.  So it is essentially in pristine condition.  Pretty sure my
> friend did not disassemble it like I did today.  Or cause any damage
> to it.  I'm pretty sure it is in the condition he received it in.

...cold solder joints and all... (and creaky with plastic bearings)

You could check Mike's Telescope Tech Tips page, and scroll down to
the lower (older) end of the "Misc" column... articles such as:
http://www.weasner.com/etx/techtips/125tuneup.html

I don't remember when the "new" metal-fork ETX125 was introduced,
i believe it was mid-2002 or 2003.

good luck
--dick

And:

Gday Dick/Howard

> One is the fundamental "go at speed XXX transitions per second",
> (Andrew may correct me on the units), 

Yep ( but its pedantic ) . 
For the ETX, the calculated rate appears to be based on encoder
transitions per set no of rti interrupts
( which is the same as transitions per second in the end )

> and the other is a "tweaker",
> telling the motors to fine-tune from the fundamental.

And that is "interesting" in how it works

> I don't remember when the "new" metal-fork ETX125 was introduced,
> i believe it was mid-2002 or 2003.

Nup, earlier than that I was buying an ETX125 and held off till the new
metal fork version became available I got mine in Jan 2002 ( in Oz ) so
it was probably late 2001 when they came out

Andrew

And additional info:

Hi All,

OK, here is the data that I think you need to help figure out
what is happening with this ETX-90/Autostar 497 system;

photo

Dick, your earlier quote: 
"As an example, my plastic-bearinged 9-year-old (and bought used) ETX90
Trains to 1100 in the Az axis, and about 3200 in Alt  (yes, thirty-two
hundred)."
seems to imply that 3200 would be a lot.  My values seem to be lots
higher.  :-)

By the way, NICE JOB ON SOFTWARE GUYS!  Great documentation!

I had a brief encounter with PIC systems and embedded software.  Still
have the ICE packages and the software for doing work with various
microprocessors from when I was working at Anadigm.  (Would still be
there if Vulture Capital Funding had continued beyond the 5.5 years they
gave us.  The company is still running because the Chief Operations
Officer bought it and is single-handedly keeping it going. 
http://www.anadigm.com.  I was Director of Software Development and
wrote much of AnadigmDesigner that programs the Field Programmable
Analog Array.)  Doing embedded software was almost like going back to
the 1960's where I was programming the Philco 2000 in assembly
language...  :-)  It was fun though.  I was in SPACETRACK system inside
Cheyenne Mountain where a software bug could almost start World War III
- LITERALLY!

Thanks,

Howard
 
-- 

Thanks,

Howard
Support@AZcendant.com
http://www.AZcendant.com

And:

Gday Howard
 
> OK, here is the data that I think you need to help figure out
> what is happening with this ETX-90/Autostar 497 system;
 
It helps, but the little button "Print data" just above the "stop slews"
button prints this screen out as a small text file Also, on the List
data tab, there is a full decoded EEProm dump ( which has more data )
And a 512byte binary scopedirect.rom is dumped to the exe directory That
has it all and can be imported into my app to allow others to see the
data as well.

However, 3961 is approx 66arcmins ie over 1degree of backlash in yr
drive train :Mn at guide speed is moving at about 8arcsec per sec so you
wont see much

With a lash of 20% you still have about 60% to do at low speed My ETX125
DEC training gives about 330 and i get annoyed at times reversing in DEC
 
Andrew

And:

Andrew Johansen wrote:

> Gday Howard
>  
> > OK, here is the data that I think you need to help figure out
> > what is happening with this ETX-90/Autostar 497 system;
>  
> It helps, but the little button "Print data" just above the "stop 
> slews" button
> prints this screen out as a small text file

OK, right, I didn't take time to fully assess all the program features.
Great job with LOTS of features...

> Also, on the List data tab, there is a full decoded EEProm dump ( 
> which has more data )
> And a 512byte binary scopedirect.rom is dumped to the exe directory
> That has it all and can be imported into my app to allow others to see 
> the data as well.

(I have an EEPROM dump that I made of the LX-200 from when it was out of
commission just in case I had to rebuild stuff.)

Anyway, do you need the EEPROM dump from my ETX? 

Is there a disassembler readily available for the 68HC11 where we could
study the acceleration algorithm that seems to exist in modes other than
Guide mode?

I suppose you could shut it down in your mods?

>   <>However, 3961 is approx 66arcmins ie over 1degree of backlash in 
> yr drive train
> :Mn at guide speed is moving at about 8arcsec per sec so you wont see much
>  
> With a lash of 20% you still have about 60% to do at low speed
> My ETX125 DEC training gives about 330 and i get annoyed at times 
> reversing in DEC

So there might not be a solution?  Dec reversal will always take too
long?  We could live with one second or so probably.

Maybe what I want to do just isn't possible for ETX scopes?

I set the backlash to higher values and it didn't help much.  Also when
I set to higher values, the scene jumps which indicates over-correction
in an LX-200 system.  The jump would be a problem for calibration.

What one needs for calibration is very little delay, preferably no
delay, and uniform motion with no cutesy acceleration schemes in play. 
Sure looks to me like there is an acceleration algorithm built-in to
modes other than guide mode.  I could work with one of the other modes
except for the acceleration scheme.

I just ordered another Autostar from Astronomics just in case the older
controllers contain something weird that is not being taken into
account.  Chances are that it will not improve anything.  :-)  Worth a
try though.

I would have ordered an ETX-125 but it is out of stock currently.  Need
to try the Autostar first in any case...

> Andrew

-- 

Thanks,

Howard

And yet more:

Gday Howard
 
> Anyway, do you need the EEPROM dump from my ETX? 
 
Nup, just letting you know that all yr "changeable" settings are stored
in that 512byte block, so theres no point looking anywhere else unless
you are going to peek working vars, but thats not trivial
( ie in understanding what to peek. )

> Is there a disassembler readily available for the 68HC11 where we could study the
> acceleration algorithm that seems to exist in modes other than Guide mode?
 
Not "readily". Dick and myself disassemble the 68HC11 code ( and the
ramping is non trivial ) but al lot of the acceleration code is in the
PICs on the motor cards and they are black boxes. I have hundreds of
megabytes of data traces ( i have a logic analyser that grabs the
encoder an motor lines and converts it to speeds ) This can grab 30sec
of so of data in a hit, so i can clearly see trends but im only looking
at the result, not the cause

> I suppose you could shut it down in your mods?
 
I severely doubt it
 
> So there might not be a solution?  Dec reversal will always take too long?
 
With numbers like yours yes, but my scope is only 330, so its acceptable
 
> Maybe what I want to do just isn't possible for ETX scopes?
 
The older plastic ones probably. The newer alloy fork jobs are a much better bet

> Sure looks to me like there is an acceleration algorithm built-in to modes
> other than guide mode. 
 
There is, but as per above, its so nested into the code, its not easy to
turn it off
 
Andrew

And:

Hmmm...

I wonder if they tried -removing- the ramp-up,
and thereby "broke" the LX90?

have fun
--dick

And:

> Is there a disassembler readily available for the 68HC11 where we could 
> study the
> acceleration algorithm that seems to exist in modes other than Guide mode?

The disassembler i use is from:
http://www.dewtronics.com/m6811dis.html

... but that's like telling you i drove from one street address in
downtown New York to another in San Francisco "in a Ford".

Much slicing and dicing of the disassembler and ROM files,
plus more than a dozen of "helper" programs to (try and) auto-comment
the code ensues.
Then you're still faced with having a "disassembly", which is
miles away from the (probably C) source code.

have fun
--dick

And still more info:

Hi Andrew,

OK.  Great information!   Thanks.

OK, if the acceleration algorithms are in the motor PIC
microcontrollers, then there is no way to change them. If I recall
correctly (of course it might depend on the particular PIC chip used)
the PICs are one-time-programmable and you cannot read data out of
them.  This is often required by microcontroller users because they
don't want people dumping their proprietary code. 

So now I understand much better what I am up against. 

I usually find a way to do what I need to do but having enough
information to give up on a particular approach is crucial.  Looks like
I probably have to give up on the most logical approach, i.e., expect it
to behave similarly to the fine control that is in the LX-200.

I am wondering now if I used "centering" mode and used the "Mg" commands
if I could get predictable motion sufficient to calibrate and allow a
modified object centering algorithm to work.

Are there other unpublished commands that the Autostar allows?  I
thought I saw a list somewhere but I cannot find it now...

Had Bluegrass band practice tonight (I am the banjo player - See me at
http://www.shastadaylight.com) and 3 hour Jam session tomorrow night. 
So it will be Thursday night before I can do more testing...

Really appreciate all your help.  Think I am beginning to develop a good
understanding of the features and limitations of the Autostar
controller.

Thanks,

Howard

And:

Hi Richard,

Yes, probably impractical.  I did a lot of disassembly of Apple II code
years ago and managed, for example, to put joystick control into a
copy-protected Pac-Man game.  :-)  Takes lots of time though...

And, if the acceleration routines are in the PIC microcontrollers, then
I cannot get control over what I need to get control over anyway.

I will try "Centering" mode and the undocumented :MgDNNNN# commands and
see if I cannot get the behavior I need.  I think I see how to do it now
that I understand better what the "features and limitations" are of the
Autostar controller. Basically, I have to give up on what seemed the
"logical" approach I guess...

I wonder if anyone would be able to hand-guide an Autostar controlled
scope like we used to do with off-axis hand-guiding when we used film
for photography with the LX-200.

I wonder how SBIG camera autoguide functions are handled on a GPS scope.
 I did not realize that the GPS scopes were Autostar controlled...

Thanks again everyone...,

Howard

And:

> I wonder if they tried -removing- the ramp-up,
> and thereby "broke" the LX90?

Nup, its still there, and clearly visible in my plots
It appears that the system uses a std ramping ( in the PIC )
and the main code breaks the requests into 1/10th max speed blocks
General guid speed corrections "appear" to be handled by the backlash
routines, and speed 2 or above use direct motor calls
Its MESSY

Andrew 

And:

Gday Howard

> So now I understand much better what I am up against. =20

Naaahhh, yr just becoming aware :-)

> Looks like I probably have to give up on the
> most logical approach, i.e., expect it to behave similarly
> to the fine control that is in the LX-200.

Correct. The two designs are lightyears apart in fine control However,
the LX90 also uses the same controller as the ETX and it has much better
control as its mechanicals are much better
( As long as you like ticking :-)    )

> I am wondering now if I used "centering" mode and used=20
> the "Mg" commands if I could get predictable motion

Depends. The Mg commands forcibly set you to guide speed
hence yr back to square 1
Also, if yr alt az, you need to remember guide speed works in RA/DEC
space not up/down space, ( and the :M vs :Mg commands are affected by
the status o= f the REV settings )

> Are there other unpublished commands that the Autostar
> allows?=20

Buckets, :-)    but none that will help you.
Fine control on DEC, even for basic guiding has always been a problem
Even with the LX200s, many of them exhibit retrograde motion which
really buggers up any calibration.

> Think I am beginning to develop a good understanding of the features
> and limitations of the Autostar controller.

Its not the controller, its the mechanicals
The theory is great, but the general support structures/drive train in
the ETXs arent high enough quality to support the code
And EVERY scope is different

Andrew

And:

Gday Howard

> I wonder how SBIG camera autoguide functions are handled
> on a GPS scope.

Depends on how yr driving it :-)
If via the ST4 guideport, it just reads and responds in the primary
interrupt
If via RS232 commands, it just reads and responds ( just slower )
as it waits for freetime to do the comms etc in the background processing

> I did not realize that the GPS scopes were Autostar controlled...

They are, but its a different codebase, and thus works differently
But, its also a much more betterer geartrain etc, so the slop problems
arent as evident
Ya gets what ya pays for

Andrew 

And:

Hi Andrew,

Well, I wonder whose brilliant idea it was at Meade to reset speed to
Guide when issuing Mg!  Booooo!

I woke up happy this morning thinking I had a work-around. Until I read
your note!

Now I suppose you could patch the Mg commands in your patch software to
eliminate the speed change?  However, that would not be optimal for
HandyAvi to satisfy my intent to just have it work without having to put
the user through lots of gyrations.

I tested what you said about the automatic change to Guide speed when Mg
is executed with this:

:GD#
:RS#
:Mgn5000#
:GD#

and the Dec values essentially did not change.  You were absolutely
right of course.

I have about one other thing to try.  Put the scope into Centering mode,
then try to carefully figure out how much time I can let :Mn# run to see
some minimal movement without letting the acceleration progress TOO
far.  Then use that value as part of a stepping subsystem.

BUT...  Is this merely a problem with my current scope?

Can you guys reliably hand guide one of your scopes in Guide mode to
keep a star centered in the cross-hairs of a 9mm Meade eyepiece designed
for hand-guiding?  Or would the star drift out of the cross-hair box
before you could get the direction reversed?

Again, none of these problems exist with the LX-200.  (Assuming of
course that you choose a good value for Dec backlash.)  I think long ago
I did see a tiny bit of retrograde but I repositioned the motor slightly
and got rid of it.

Please tell me the GPS scopes can actually do reliable guide-star
tracking with, for example, an SBIG ST-7XME, and produce good images
without star trails.

How could that be possible given what you've taught me so far? A short
answer would be OK.  I know you guys know this stuff cold... It must be
possible somehow...  (Maybe you answered this already when you mentioned
that the LX-90s behave better.)

I'm pretty sure my current scope would fail miserably with an SBIG
camera.  Of course it probably wouldn't even be able to LIFT the thing! 
:-) And I don't see a CCD port... :-)

You all have helped immensely!  I would have wasted a LOT more time
trying to understand what is happening.  I think I understand enough now
to know which approaches won't work.  :-)

Thanks,

Howard

And:

> Now I suppose you could patch the Mg commands in your
> patch software to eliminate the speed change?

I may vote (without looking) that that may be difficult.

...
> Can you guys reliably hand guide one of your scopes in Guide mode to keep
> a star centered in the cross-hairs of a 9mm Meade eyepiece designed
> for hand-guiding?  Or would the star drift out of the cross-hair box
> before you could get the direction reversed?

I have used my LPI camera to guide the scope (i did try one
session of PEC Training guiding by hand.. but 24 minutes is simply
too long).

> Again, none of these problems exist with the LX-200.  (Assuming of
> course that you choose a good value for Dec backlash.)  I think long
> ago I did see a tiny bit of retrograde but I repositioned the motor slightly
> and got rid of it.

..and going through a "tuning" regimen on the ETX125 may help, too
(it certainly did for mine).  Mike's Telescope Info page has a number
of tear-down articles on the older ETX125 (and ETX90).

> Please tell me the GPS scopes can actually do reliable guide-star tracking
> with, for example, an SBIG ST-7XME, and produce good images without
> star trails.

They do.  Frequently (not always). (although personally i've only
used an LPI or DPI).

> How could that be possible given what you've taught me so far?
> A short answer would be OK.  I know you guys know this stuff cold...
> It must be possible somehow...  (Maybe you answered this already
> when you mentioned that the LX-90s behave better.)

As Mike said, even the -newer- ETX125 will do much better.
You have a particularly "loose" individual example.

> I'm pretty sure my current scope would fail miserably with an SBIG
> camera.  Of course it probably wouldn't even be able to LIFT the thing!  :-)
> And I don't see a CCD port... :-)

YOu can buy a "Meade 909 APM" (or build a clone) which provides one.
Then you'll need my patch kit to get the ETX/Autostar to be willing
to acknowledge its existence (it is only "approved" for LX90 and LXD55/75).

> You all have helped immensely!  I would have wasted a LOT more time
> trying to understand what is happening.  I think I understand enough now
> to know which approaches won't work.  :-)

Hmm... -another- one of my patch options provides for -very- precise individual
control of the two motors' speeds.... to the limits of the machine.
So you -could- invoke any speed you wanted, and i don't think
(but can't guarantee) that the accelerations would happen.

But that, again, would require patching the Autostar, and i can't guarantee
that i could replicate that feature in future firmware versions.

good luck
--dick

And:

Gday Howard
 
> I woke up happy this morning
 
Told you you were only just becoming aware
 
> Now I suppose you could patch the Mg commands in your 
> patch software to eliminate the speed change?
 
Not likely, its too problematical, and would bugger up a lot
of other software that expects it to behave
 
> I have about one other thing to try.  Put the scope into
> Centering mode, then try to carefully figure out how much
> time I can let :Mn# run to see some minimal movement
> without letting the acceleration progress TOO far. 
 
YOU cant figure it out, as every scope is different
( ie drive train slop, friction etc )
If you are purely after direction for a command, then
just log current pos, issue a large move and read pos again
( i do this in the drive train section of my app )
I DEC/RA increased/decreased, you know which way you went
but for precise time x at speed y to do something NUP
 
> BUT...  Is this merely a problem with my current scope?
 
I think so

> Can you guys reliably hand guide one of your scopes in Guide mode to keep
> a star centered in the cross-hairs of a 9mm Meade eyepiece designed
> for hand-guiding? 
 
With my ETX i can sometimes, but i dont really try
The ETX ( for me ) is purely grabngo visual
 
> Please tell me the GPS scopes can actually do reliable guide-star tracking 
> with, for example, an SBIG ST-7XME, and produce good images without
> star trails.
 
Easy peasey, its done all the time. The biggest problem in the LX200s is PE
and for some, retrograde in DEC, but many successfully guide

> How could that be possible given what you've taught me so far?
 
As per prev, its all related to the geartrain quality / repeatability
The ETX drive is dept store quality ( optics are still superb )
The LX90 is much better quality
The LX200GPS is another notch up again
Ie for my GPS, the drive train values ( ie TOTAL geartrain slop )
is only 70arcsec, vs yr 3900 on the ETX
Reversing 70 ( with the aid of a correct % ) is much more repeatable and
accurate than reversing 3900 :-)
 
> And I don't see a CCD port... :-)
For the 497s you need a 909 port ( now discontinued ) or a clone ref
http://home.comcast.net/~lynol1000/as_909/as_909_clone.htm

> I think I understand enough now,
> to know which approaches won't work.  :-)
 
Naaahhhh
 
Andrew

And:

Hi Andrew,

Well, I have the advantage of being able to use the webcam frames to
watch the motion as it occurs.  So I don't really have to figure out a
particular scope's electromechanical behavior.  I merely have to use
timers to issue move commands and adjust the timers until I see
movement.  Then that would tell me how much time to use to nudge the
object I am trying to center.  I did get a rudimentary version of this
to actually work in this manner a few days ago although it (being an
on-the-fly experiment) caused the object to be pushed around in circles
more than I would like. 

I also just noticed that I can issue GD commands during a slew so
perhaps I can monitor declination readout for small changes and see if
there was sufficient motion and save the time values for various motions
as an alternative.  (Then I saw that this is similar to what you were
suggesting except I need to read GD DURING the move.)

Now that I understand things a little better, I think I might be able to
write something that will always work and automatically take a
particular scope's peculiarities into account in "Centering" mode for
Dec motion. 

Not positive I can do it though.  The acceleration scheme programmed in
to the motor PICs is really disgusting... As is the automatic switching
to Guide mode for Mg commands. I mean, couldn't they have trusted us to
set the speed the way we wanted it for Mg commands.  :-)  I used to work
in the Multics system where the philosophy was "If it won't HURT the
user to be able to do something, don't restrict him from doing it...  He
might be smarter than you..."

I am visualizing a two-stage approach where I use Guide mode first.  If
the scope can handle it, then I go with it.  If not, I switch Dec to
Centering mode and gradually increment Mn and Ms times to see how long
is required to cause sufficient motion without overshooting too much. 
The acceleration is the worst part of this scheme though.  I might not
be able to properly take it into account.  I might have to remember
which direction was last issued and have different time values depending
on whether a reversal is called for.  Pretty complicated but only
testing will show whether I can make it reliable.  I have already
separated the code into two different calibration schemes, one for the
LX-200s and one for Autostar-controlled scopes.  This is so I don't
break one while trying to fix the other...  :-)

Enough possibilities to keep me busy for a couple of days anyway.  :-)

I hate giving up on things...  Getting close to that point though...

There must be something funny about this scope...  But I have tried
everything I know and everything you guys have taught me so far...  I
even shimmed the Dec motor so it is FOR SURE pushing against the main
Dec gear.  No effect...  Almost has to be something in the electronics. 
I suspect the motor PICs are misprogrammed somehow but have no proof...

Thanks,

Howard

And:

>I also just noticed that I can issue GD commands during a slew so
>perhaps I can monitor declination readout for small changes
>and see if there was sufficient motion and save the time values
>for various motions as an alternative.  (Then I saw that this is
>similar to what you were suggesting except I need to read GD
>DURING the move.)

There is dither and delay in the production of the GD numbers.
In fact, you can -really- be misled if you try that on an LX200gps.
(in all autostars, do not interrogate it for position more than twice
per second, if that).  At least in the LX200gps, the function which
reads and translates the encoders operates asynchronously from the
:GD# routine... and they're not "thread safe" so you can get mixed
partial results sent back up the wire (see it shift 90 degrees for 1/4 second!).

>Now that I understand things a little better, I think I might be able to 
>write something that will always work and automatically take a particular
>scope's peculiarities into account in "Centering" mode for Dec motion. 

It was hitting the word "always" which caused ROTFL action...
(wiping tears from my eyes...)

>Not positive I can do it though.  The acceleration scheme
>programmed in to the motor PICs is really disgusting...

I'm still not completely convinced it's not in the Autostar programming
instead of the PIC, but Andrew's studied it harder and more recently
than i have.  A test would be to command a guide motion, then *disconnect
the Autostar* and see if the PIC still ramps up after 6 seconds.
If it does, it's PIC and all hope is lost.  If it doesn't, then...

>As is the automatic switching to Guide mode for Mg commands.
>I mean, couldn't they have trusted us to set the speed
>the way we wanted it for Mg commands.  :-) 

Meade's reasonable stance:  If you're guiding, you're not slewing.
Hence once you start sending Guide commands, you -want- to run
at Guide speed.
If you want to slew, or GoTo, then prepare the turf to a known
state by sending a speed command before sending the :Motion command.

> I used to work in the Multics system 

... what is it about Meade scopes that attracts the Multics crowd?
You are perhaps the 5th or 6th whom i've "met" dealing with Autostar issues.

> where the philosophy was "If it won't
>HURT the user to be able to do something, don't restrict him
>from doing it...  He might be smarter than you..."

..and from that crowd we got Unix, whose view is: "ignore the user,
kernel mode is holy" ... so much for "trust".  
Gimme DEC's VMS any day....  (12 microseconds after putting a signal on an
external wire, you could be inside a user's program dealing with it... 
even if the program was written in Fortran).  _That's_ trust.

>I am visualizing a two-stage approach where I use Guide mode
>first.  If the scope can handle it, then I go with it.  If not,
>I switch Dec to Centering mode and gradually increment
>Mn and Ms times to see how long is required to cause
>sufficient motion without overshooting too much.

You have additional speed control... you can set a "maximum slew
speed limit" (:W? I'm not near the docs)... and that's in degrees
per second (floating point allowed, 8 maximum).  Then just command
a max-speed slew (:Mn#).  This gives you far finer control than
just the four :Rate commands.   The 497 (again, i'm not near my notes)
may also support the :R1# :R2# :R3# ...:R9#  commands, which are equivalent
to selecting handbox speed keys 1 thru 9.

> The acceleration
>is the worst part of this scheme though.  I might not be able to
>properly take it into account.  I might have to remember which direction
>was last issued and have different time values depending on whether
>a reversal is called for.  Pretty complicated but only testing
>will show whether I can make it reliable.  I have already separated
>the code into two different calibration schemes, one for the LX-200s
>and one for Autostar-controlled scopes.  This is so I don't break
>one while trying to fix the other...  :-)

If it's a "six second" error, you could do :Mn# (or Mg5000#) and then send a
:Qn#  before the six seconds are up.  Then another :Mn#.  Perhaps you could
-avoid- triggering the acceleration.

>Enough possibilities to keep me busy for a couple of days anyway.  :-)

Pick a soft wall for head-bashing.

>I hate giving up on things...  Getting close to that point though...
>
>There must be something funny about this scope...  But I have
>tried everything I know and everything you guys have taught me
>so far...  I even shimmed the Dec motor so it is FOR SURE pushing
>against the main Dec gear.  No effect...  Almost has to be something
>in the electronics.  I suspect the motor PICs are misprogrammed somehow
>but have no proof...

For chuckles, you could load an *ancient* version of the Autostar firmware.
On the order of 22Eb or even earlier.  See if that exhibits the
same problems.  They're archived on Mile's "Autostar Info" page, left column.

good luck
--dick

Subject:	497 auto star is dead
Sent:	Sunday, October 12, 2008 18:30:28
From:	Marty (js900zxi@roadrunner.com)
My cable became unplugged during an update. The autostar showed a bunch
of f"s accross the screen I turned it off them back on, But it would not
come back on dead no sound or led I tried to get it in safeload but it
does not power up. I have another 497 control and it works fine so I
know the cable is good. I also looked at the plug terminals in the 497
they are all good.

It seems that the unit is corrupt is there another way to fix this or is
this unit junk??
 
Marty
Mike here: You need to do a SAFE LOAD. See "Q. The power went off while I was updating my AutoStar and now it doesn't work. Did I kill it?" on the FAQ page.

And:

I did this it will not work if I hold the enter and scroll down buttons
and turn on the telescope nothing happens.

Marty
Mike here: Be certain you are using the SCROLLDOWN arrow key (at the bottom) and not the SLEWDOWN key. If that wasn't the proble, do you recall what version was in the AutoStar before you tried to update it?

And:

4.3eg I was putting in 4.3gg I have the buttons correct I'm not sure
what's going on
Mike here: Well, it could be that when the cable (the one from the computer, I presume) came out the SAFE LOAD code in the AutoStar might have been corrupted. I've not heard of that happening before. If it was the cable to the telescope it could be that some component on the AutoStar was fried.
Subject:	re:  Meade DS Serries with Autostar
Sent:	Saturday, October 11, 2008 21:42:53
From:	richard seymour (rseymour@wolfenet.com)
Actually, you can -update- the 494's User Object data,
so you can "bulk load" new comets, asteroids, satellites
and Tours.
But the 494 does not allow you to update/upgrade the fundamental
firmware program.

Even without updating/upgrading, all of the "fixed" data (stars,
planets, even the Tours) will be functional and "current" for
quite a long time (say, 50 years, and even then it does calculate
precession, too).

So "over time" should be viewed in an astronomical sense.

have fun
--dick

And:

Thanks for the information. So basically you are saying that, as far as
the list of objects, I really will not need to update them because all
of the "over time" (such as planets movements) have been calculated into
the auto star controller? Or are you saying I can update those types of
things individually? If so, is that an option on the Meade Update page.
I bought the controller used and am not sure how old it is, so I was
just concerned that it may have needed some updates.
 
Thanks,
Brad

And:

> Thanks for the information. So basically you are saying that, as far as 
> the list of objects, I really will not need to update them because all 
> of the "over time" (such as planets movements) have been calculated into 
> the auto star controller?

Stars and "deep space objects" (DSO) such as galaxies and nebulae
are considered "fixed" objects.  They're stored as coordinates.
Precession is applied to correct for the 23,000-year wobble of where
the earth's rotational axis points in the sky.
To be precise, the orbital parameters of the planets are "locked in",
and from those the Autostar calculates a -prediction- of where the
planet will be at the moment you request it to look.
When selecting a planet, you menu to (for example)
Object/SolarSystem/Jupiter
then tap [enter]
It will disply "Calculating...", then it will show the RA and DEC
of where Jupiter should be -now-.
Now tap [GoTo] and it'll get there.
To avoid spending all night at that calculation, (the Autostar's
CPU is 1000x slower than your desktop PC, and less powerful) they
use an approximation, which can yield mild errors... so there will
be times of the year (or relative orbital positions) when it misses
by up to a half degree or so.  This is especially true of the Moon,
since it's dragged around by -everybody- (the Earth, the tides, the
Sun and Jupiter, too)... and the Autostar's predictions will be visibly
better/worse throughout the course of a month.

But even so, the numbers "locked" into the programming should be
reasonably accurate (i.e. no worse than today) for 50 years or more.

> Or are you saying I can update those types of things individually?

You can update *some* things individually.  Not the planets or Moon.
But you can update all of the Asteroids, Comets, Satellites, User Objects,
Landmarks and Tours.  (Tours requires a computer hookup).

See
http://www.weasner.com/etx/autostar/as_iss.html   <-- short
http://www.weasner.com/etx/autostar/as_satellite.html   <---long
for how to do an example satellite.   And
http://www.weasner.com/etx/autostar/as_comets.html
for a comet.   The technique applies to Asteroids, too.

 > If so, is that an option on the Meade Update page.

Down near the bottom are the links to the comet, asteroid and satellite data.
Despite the "date" shown on the Meade page, the actual -data- are fresh
and current (supplied by Harvard, not Meade).

> I bought the controller used and am not sure how old it is, so I was 
> just concerned that it may have needed some updates.

You can see the "version" of the firmware by menuing to:
Setup/Statistics[enter][scroll up]
It will be something like   12Ea
The "12" is the version, the "E" means English,
and the "a" is the 'minor revision' level.
(Usually due to adding more telescope models, sometimes it's a fix)
My ETX70 has 11Ea, i have heard of 12Ea and 12Nf (Norwegian).

To connect a 494 to a computer requires an active electronic device,
not just simple wires.  Meade sold that as the "506 cable/coverter" for $30.
There are plans on the web for building an equivalent device (has other
features) from/by:
http://home.comcast.net/~lynol1000/as_494/as494_i2c_bus.htm

have fun
--dick

Subject:	Autostar 497, ETX 90C, No Dec motion in Guide mode when N/S pushed.
Sent:	Saturday, October 11, 2008 08:48:57
From:	Howard C. Anderson (support@azcendant.com)
I am the author of HandyAvi and have been trying to understand
pecularities of the Autostar and ETX scope I recently purchased for
testing.  One of the features of my software is to keep Jupiter (for
example) centered while shooting webcam movies.  Works fine for the 10"
LX-200 I have.

The Autostar/ETX combo seems to move ok at guide speeds 2 through 9 but
in guide speed 1, just using the keypad, I get RA motion but absolutely
no discernable Dec motion.  (Same under software control command ":Mn#"
or ":Ms#".)  This makes movement calibration in the Dec axis impossible.

Meade's telescope protocol allows only four selections for the "Slew
Rate." The slowest is "Guide", the second slowest is "Centering".  I'm
not sure which rate in the Autostar corresponds with "Centering" but if
I try to move Dec using "Centering", then the scope moves slowly at
first then rapidly accelerates to a speed that is way beyond what I can
calibrate with and the object shoots out of the Webcam view field.

I've spent a lot of time understanding and setting up Training and the
Alt and Az backlash percentage settings but nothing seems to allow any
Dec motion in guide mode.  (If I set the Alt Percent to a very high
setting, of course the scope JUMPS in Dec and I see motion then of
course but continued holding down of the North or South button after the
JUMP produces no further discernable motion in Dec direction.)

I spent a week understanding that the Autostar's response to commands is
very much slower than the LX-200's and if it returns a string of data,
it dribbles it out requiring multiple reads of the serial I/O channel. 
:-)  I have that all under control now I believe.  I can control the
scope remotely very reliably now.  Except for Dec motion in Guide mode. 
:-)

All-in-all, it has been rather frustrating and time-consuming.  :-)

Hoping you can tell me whether the Autostar controller, in Guide mode
(Slew Rate 1), is supposed to produce any Dec scope motion when the
North or South buttons are pressed.  Or if you have seen any scope
actually respond to Dec movement commands in Guide mode.

-- 

Thanks,

Howard, in Tempe AZ

Http://www.astroshow.com
http://www.AZcendant.com
http://www.ShastaDaylight.com
Mike here: I'll let our resident AutoStar expert, Dick Seymour, respond.

And:

Thanks very much for replying! 
I will be awaiting Dick's comments!

And:

From:	richard seymour (rseymour@wolfenet.com)
I'm going to need a LOT more data:
(a) what -kind- of Autostar?  (497 with numeric keypad, or 494 without)
((just specifying "ETX" did'nt answer that.. a -60, -70 or -80 would be
a 494, and the -90,-105 and -125  would be a 497.  The 497 can drive all
of them, the 494 only drives the small ones))
(b) what firmware version?  Menu to  Setup/Statistics[enter][scroll up]
for the full identifier.
(c) Polar or Alt/Az?

Yes, friends, -all- of those factors will change the answer...

There are also additional serial commands available in the current
firmware for the 497... try  :Mgn1000#   ... (the command is :Mg
(move at Guide rate), the "n" is direction,
the "1000" is the duration of the motion in milliseconds).

At guide rate, the current 497 firmware moves in *RA/DEC* coordinate space.
So :Mn# moves *north*, not necessarily "up".

The "percentage" anti-backlash only kicks in if the motor is asked to
-reverse-.  So (in the northern hemisphere, in Alt/Az) if you're east
of the central meridian, it is already moving "up" to follow the sky.
Hence asking for some guide addition won't benefit from the "kick".
If you're west of the central meridian, it's moving down to follow the
sky, and a :Mn# command will reverse it.  Then, when you :Q#, it will
reverse -again- as sidereal drive takes over.  ((effect varies with
position in sky, since the Guie command may only -slow- the up/down
motion, not truly reverse it) (Guide Rate is 67% of sidereal)

have fun
--dick

And additional:

Whoops... i see that the "why type of Autostar" was in
the -subject- line (not obvious enough for me, obviously)

So that makes the rest of my comments in that message (re: Mgn1000 ,etc.)
pertinent.  (whew)

have fun
--dick

And:

Hi Richard,

Thanks,

I see your other message too so will not readdress the 497 issue.

Firmware is 43Eg.  I updated it before the last set of tests.

I was polar aligned for latest tests so pressing N/S should cause the
Dec motor to change the scope's position.

When I say vertical or horizontal below I am saying it with respect to
the fork arms.  (I am fully aware of celestial mechanics...)

I have a couple of LX-200s.  In Guide mode, polar aligned, pressing N or
S moves the field about the same speed vertically as E or W moves the
field horizontally.  That works good for calibration and centering.
Absolutely essential for taking astrophotos with SBIG cameras. (My other
site:  http://www.astroshow.com.)

In the Autostar/ETX scope, pressing E or W (I realize they are not
labeled that way on the Autostar...) causes lateral motion.  Slow but
there is motion. However, pressing N or S does not cause ANY PERCEPTABLE
vertical motion of the star field.  N and S in Guide mode seem to be
broken in my opinion.  Other speeds work and produce perceptable Dec
motion.

So the question is, have YOU ever seen YOUR Dec motor respond to N/S
commands from the keypad when the scope is Polar aligned and in Guide
mode? (I will retest the behavior in Alt/Az mode within a few days...  I
don't think anything  moves there either but now I need to recheck.)

All you have to do is put Jupiter in the field, set Guide mode, Polar
align, press N or S and see if Jupiter moves at all in response to the N
or S command... My scope doesn't respond to N or S no matter how long I
keep the button pressed.  If I set the Dec percentage to 90, it jumps
when I reverse direction but then no more perceptable motion occurs... 
(Maybe I've got weak motors?  :-)

-- 

Thanks,

Howard

And more:

> However, pressing N or S does not cause ANY PERCEPTABLE vertical motion of
> the star field.  N and S in Guide mode seem to be broken in my opinion.  
> Other
> speeds work and produce perceptable Dec motion.
> 
> So the question is, have YOU ever seen YOUR Dec motor respond to N/S 
> commands
> from the keypad when the scope is Polar aligned and in Guide mode? (I 
> will retest the behavior in Alt/Az mode within a few days...  I don't think
> anything  moves there either but now I need to recheck.)

Good question... it's always best to -empirically- (re)check anything
involving Meade firmware.
So i did... i set my ETX90 to Polar (it already was), and played with
the up/down keys ... it -does- move. (ya gotta be patient).
You can also assess the Autostar's idea of the motion by bringing
up the RA/DEC status display (press [mode] 3 seconds, release,
scroll to RA/DEC).  Now start playing with the up/down keys.
It takes about 20 seconds per arcminute ... but they will
increament/decrement.  And those are from encoder feedback from the
motor, not the Autostar doing dead-reckoning.

> All you have to do is put Jupiter in the field, set Guide mode,
 > Polar align, press N or S and see if Jupiter moves at all in
 >  response to the N or S  command...
> My scope doesn't respond to N or S no matter how long I keep the button
> pressed.  If I set the Dec percentage to 90, it jumps when I reverse 
> direction
> but then no more perceptable motion occurs...  (Maybe I've got weak 
> motors?  :-)

Hmm... maybe your DEC motor PIC chip isn't properly handling the least
significant bits of the speed commands?
If the motor falls behind when commanded to do something, the feedback
loop eventually *really* kicks it. (see "LX90", below...)

My ETX90 is ancient: built in March 1999.
I've used Meade's cameras to Autoguide it, and to train PEC.
I've seen it march objects vertically off the screen, so i know
that guide-commands have an effect.

You might, indeed, be seeing some individual unit (just your scope)
or new-hardware-muck-up that affects all ETX-90's (the LX90's are
going through an episode of this at the moment).

I'm going to forward our traffic to Andrew Johansen, who's done
even more detailed study of the nitty-gritties of motor control.

have fun
--dick

And:

Sent:	Saturday, October 11, 2008 18:51:18
From:	Andrew Johansen (johansea@optusnet.com.au)
Gday Howard

I have an ETX 125 and it also moves in DEC when polar and using guide
speed I spent an eternity testing these functions, as there are HORRIBLE
discontinuities in the Meade firmwares, which relate to the status of
the Rev L/R and Rev U/D settings, and for the GPS scopes what they were
on booting.
I have a video drive train routine, and the only way i can determine
what will happen is to do a test slew and read the encoders to see where
it went :-)
As to Reversing in DEC whilst polar
what drive train nos did you come up with for DEC????

Andrew

Subject:	Meade DS Serries with Autostar
Sent:	Friday, October 10, 2008 16:05:07
From:	Jonathan B. Crew (jcrew@hanover.k12.va.us)
I just want to make sure that I read correctly...the #494 Autostar
Controller CANNOT be upgraded at all? So does this mean that over time
it will be useless for "Goto"? Someone mentioned that they thought the
new 43Eg upgrade could be for the #494 as well as the #497 controller? I
hope you can give me some help. Also, thanks for the great website!
 
Thanks,
Brad
Mike here: Currently there are no user-installable updates for the #494 AutoStar. You can add objects but you can not update the software. However, that doesn't mean that GOTOs will deteriorate over time, at least, not so much that you'll notice for fixed objects and most emphemeral objects. Satellites are essentially the only objects that could change significantly. But for most objects there is nothing to lose sleep over. If you want to lose sleep, just go outside and use your DS to enjoy the night sky!
Subject:	Autostar users probably have it too easy....
Sent:	Tuesday, October 7, 2008 13:29:56
From:	Richard Seymour (rseymour@wolfenet.com)
When folks complain about the 20-key Autostar, i suppose we
could refer them to this 19-key computer (it must be simpler...)

http://history.nasa.gov/afj/compessay.htm

have fun
--dick
p.s. above link found on this page:
http://www.hq.nasa.gov/office/pao/History/alsj/a15/a15j.html

Mike here: Ah, the good old days! I used a Wang "desktop mini" back in the late 1960s along with an HP model. But I was pretty good on my slide-rule! The Wang 360SE (http://www.oldcalculatormuseum.com/wang360.html) looks pretty close to what we had in the Astronomy Department. As to the HP, maybe it was a 9100 (http://www.hpmuseum.org/hp9100.htm). But I remember ours being black.
Subject:	Autostar #497: Select my own alignment stars
Sent:	Friday, October 3, 2008 10:09:18
From:	sfu1 (sfu1@gmx.net)
at first: congratulation for the great site!

Here my question: When using the "auto alignment" the AUTOSTAR (ETX-125)
select two stars to align. But I have only a good view to south, so it
takes many time, befor AUTOSTAR find a star in the right position.

Is it possible to select one or two own stars?
tnx.
Gerd
Mike here: You can use the 2-star (non-Auto) alignment mode. However, for best results when skipping stars is for the stars to be about 90 degrees apart and near the celestial equator. Alternatively, you can just accept a "hidden" star as being centered. Many times, especially with a good home position, that will result in a pretty good alignment.

Feedback Archives

Check the Feedback Archives for previous editions of the AutoStar Feedback page.


Go to the ETX Home Page.


Copyright ©2008 Michael L. Weasner / etx@me.com
Submittals Copyright © 2008 by the Submitter
URL = http://www.weasner.com/etx/archive/oct08/autostar.html