Welcome to the AutoStar feedback page. This page is intended to provide user comments on using the Meade Autostar #494, #495, #497, #497EP, AudioStar, cables, and 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 for posting. Please use an appropriate Subject Line on your message per the Site Email Etiquette. Thanks. Remember, tips described on this site may invalidate the warranty on your telescope or accessories. Neither the submitter nor myself are responsible for any damage caused by using any contributed tips.

Subject:	ETX Electrical connections
Sent:	Friday, March 30, 2012 10:08:14
From:	mamonett@comcast.net (mamonett@comcast.net)
This may have been addressed on your site before if so please disreguard
the following:

I have noticed a few references here end elsewhere about eratic AUTOSTAR
handboxes. I had the same problem; during a session if I moved the cable
connector on either the AUTOSTAR or the scope base I might get an
AUTOSTAR reset or the text might disappear. This also seemed to happen
if the power connection to battery pack or the scope base were moved. I
noticed this more often in cold weather, probably because the cables
become stiffer and flex less thus a intermittent connection is more
likely to occur.

I now use a small amount of DIELECTRIC TUNE-UP GREASE (see photo) on all
the connections and the intermittent connections have not been a
problem.
 
MIKE AMONETT

Subject:	I think I bricked my #494 Autostar, is there any hope??
Sent:	Thursday, March 29, 2012 11:34:33
From:	Claudius Stute (claudius.stute@gmail.com)
I found this site a day earlier,

I received my #506 cable yesterday to attach my DS-114 with #494
Autostar to my computer.
Everything was working great, than I decided to upload ISS data to the
#494, BIG mistake.

Something went wrong during the upload and the #494 powered its self
off. Now when I try to turn it on I get nothing. No beep, and no back
lighting. But I do see the LED screen flashing if I hold it up to the
light just right.

I've check the power pack, and it's putting out a full 12v. I have even
replaced all the batteries in it, but that didn't help. The mount is
getting power, the red LED on the mount illuminates when plugged in.

From reading other post here, it looks like I have bricked my #494, but
I'm kinda in denial, and am looking for a second opinion.

I have read the post at this link, but I'm no electrical engineer, and
looks like I would need to build some kind of circuit board to preform
the fix. Or is there a site with step-by-step instructions?

Has anyone here dealt with this issue?  
Is there a way to directly connect the telescope to my computer, without
the Autostar, and get it to slew and track?
Any help would be appreciated.

Guess the best option would be to buy a used #495 or #497, but I can't
seem to find many for sale are a reasonable price. 
           ___l___ 
 \____@=('''')=@____/

Claudius Stute

And:

Well looks like I'm stuck then. 
The #494 is completely dead,  I can't access any menus, so no reset. 
At least I have a used #495 on the way.  Found one for $40.00 on amazon. 
Hope I can upgrade the firmware to a #497.

And:

Yup, I tried using a terminal app to reset the Autostar, no dice.
But while messing around with the controller, I did get it to light up
for a few seconds. But still can't communicate with it.

I'm going to be making a #505 cable with the wonderful plans I found on
your site.  As luck would have it, I have all the parts laying around!

The USB-serial adapter I used before I bricked my Autostart was bought
at Staples, Staples brand no less.  It seamed to work well,

Subject:	Re: help with audio star troubles
Sent:	Friday, March 23, 2012 09:43:05
From:	Theresa Zittritsch (theresamarie11@gmail.com)
I tried to revert back to the original software version using star
patch, and was eventually successful.   

Here's how it went.  

I did a reset on the controller first.

I entered the build  AUA1F7.ROM into the box 'select patch or rom file'.

I get a confirm box that comes up asking me if I want to use this
unpatched version of the software.
	I selectYES

I get another confirm Found Audiostar (version A1F7), do I want to continue with the update?
	I select YES

I GET AN ERROR MESSAGE TELLING me that I need audiostar version A1F7 or
later..  and it exits.

I got this 3 times  and on the 4th time it is now updating.         
Does this give any clue to issues with my  audiostar?

This seems flakey, is this typical?

Thanks,
Terri

And:

From:	richard seymour (rseymour@wolfenet.com)
Let me (attempt to) help by explaining *how* the 909APM and Autostar
operate with respect to guiding signals.  ("Autostar" and "Audiostar"
are synonyms below)

The 909APM has its own little "computer", a PIC chip. (Peripheral
Interface Controller)
When it sees a guiding signal on the ST-4 socket, it sets a bit flag
(which pin) and starts counting the time duration of the assertion.
It does NOT "interrupt" the Autostar, it does NOT assert any signal on
the AUX bus.

Every so often (1/10th second, if i recall correctly), the Autostar (as
AUX bus master) sends out a status request to the 909APM.  If no guiding
signals were asserted since the last query, it gets back a message
containing a zero.
If guiding signals *were* being asserted, it gets back a bit-flagged
byte (showing which pins) and a count of the duration.   The "duration"
counter inside the 909APM is zeroed.
If the signal is still present, the next query will see that new count.

If the query result was non-zero, an adjustment to the telescope's motor
speeds is made, for a duration dictated by the count.

Quasi side-note: whether or not there's a 909APM attached, the Autostar
does an update of the telescope motor speeds once per second.  For Polar
mounting, this is pretty invisible.
For Alt/Az mounting, it's when the motor speeds are adjusted to deal
with the fact that the telescope's axes are not parallel to the earth's
axis.
---
So: that's why you don't see measurable activity on the AUX bus when
guiding signals are asserted.  All that assertion does is affect the
content of one class of message being passed on the bus.  To see that
you either need a logic analyzer or eyeball-watering scrutiny of
oscilloscope traces.

The AUX bus, like the motor channels, is an IIC (or I2C) -bus-like system.
One master (the Autostar) using addressed byte message packets.
--------
Speaking of eyeball-watering, if you wish to see the full description,
read Meade's patents on the Autostar system.  The base patent is 
6,304,376 and 6,392,799  6,445,498  6,563,636  and (alignment) 6,922,283
also apply.
I use http://www.pat2pdf.org/  as an easy way to fetch/read them.

The other functions of the 909APM are all *output*... the Autostar sends
"run the focus motor" and "blink the reticle LED" commands, but (other
than noting that the 909APM exists), it does not *interrogate* them. 
Only the Guiding socket is an input channel.

Andrew may well illuminate and correct the above arm-waves.

have fun
--dick

And more:

Ok Dick, thank you much for this.

But if the 909 is working correctly, and I have the RA/DEC status screen
up on audio star, and I send an ST-4 signal (essentially driving one of
the direction inputs low), it should change the motor speed and the
RA/DEC location.   Correct?   If it's not, it's either the 909 APM clone
OR the Audiostar.

So after the audiostar gets back a non-zero query and gets passed the
duration, the 'Audiostar' then updates the motor speed, correct?       
So this must be why the audiostar needs a patch.      So now I
understand that the handset needs to be working properly as well for
ST-4 to APM guiding to work.       

Now that I've reloaded the original A1F7 ROM.  

Can you tell me which, and only which, updates I need for either serial
guiding:

Which updates I need for 909 APM guiding:

I will patch only those absolutely necessary for each type of guiding
and re-check the 909 APM with my test rig and also make sure serial
signals get through.

One thing that frustrates me here, is I really didn't expect to have to
do so much playing around.     And given meade doesn't accept the LX90
to be able to guide, and if there's a problem, will they even fix it or
consider it an issue?    I am at the point where I'd like to toss this
thing in the trash (if it didn't cost me $2K) and pick up something more
purpose built like the LX200.     To be honest though, at the weight of
the LX90, I am kind of at my limit for putting it on the wedge.  It's a
bear.     I know the LX200 is heavier.  

Thanks,
Terri

And:

Mike, what's your opinion on the new mounts versus the LX90 and LX200?  
 Would the LX200 serve me better.  It doesn't seem the LX80 or LX800 are
sub's for the LX200.

The LX800 mount by itself is around 8K, which is not realistic  for me
to spend for casual viewing, astrophotos... although maybe there really
is no such thing as 'casual' when it comes to astrophotography.

I any case, I had read the forums before I jumped, but guess I didn't
read close enough.    

Terri

And:

Thanks Mike.

Would you be referring to the larger and more expensive LX800 or the
LX80 as well?    I'm asking because i see the go-to accuracy of the LX80
at 10arc minutes in high accuracy mode, where the LX90 is 3 arc seconds
in high accuracy mode.

And this:

Now that i've covered the overall operation, i'll address Theresa's individual questions:


>>> When I say they go bad, the star just takes off and guiding can't seem to recover.
>>> I had been using the 909 until a few days ago when the 909 stopped working completely.
>>> No ST4 commands are getting through to the mount.

"Takes off" implies that the motor is actively "guiding", instead of simply ignoring the 
909APM (in which case the star would stay in-frame, perhaps with some drift).

But then (earlier) T said:

> I have been using PHD for guiding with the 909, and all of a sudden it just stopped
> working while out doing photos. PHD could not get the stars to move, would not calibrate,
> etc. I also did the tests Gene Nolan gave me, by making up a test rig to ground each one
> of the directional ST-4 inputs to see if the mount did what was being asked. It does not.
> I am getting 5V on all directional signals, but grounding them does not move the mount.
> Verified by both no sound, and no changes in RA/DEC.

(i'm glad you have the manual test rig... otherwise i'd ask you to build one:
http://www.weasner.com/etx/autostar/as_apm_sim.html  )

 > Now if i connect up PHD via ASCOM
> drivers and use manual mode, the mount moves fine and I can see it moving on status screen
> (holding mode down after align for 5s).

Now, i don't have a PHD setup (and that name applies to a variety of devices).
Does PHD "manual mode" send its commands via the serial (505 cable to Autostar's RS232 
socket) channel, or via the ST-4 cable into the 909APM?

> So I am basing my comments on what Gene told me.
> He says that if I have 5V on signals, and 909 is seen by the mount, it should work. That
> seems a bit of a leap because it implies whatever transfer function the 909 applies goes
> go the output.. but he knows this more than I. He has told me I can't really measure the
> output with a DVM.

I agree that it does require the leap of faith that the 909APM hasn't crashed internally, 
or "locked up" in terms of sending (for example) xFF FF FF as its "what's pushed for how 
long" message.

Thing to try: unplug/replug the 909APM from the Aux socket *during* a test. (after the 
scope goes drift-about, but (during the plugging) no guiding signal asserted)
See if that restores "guiding".  (note: the Autostar and Audiostar may well differ in how 
they handle a mid-session unplug/replug... the 497 Autostar handles it gracefully.
If memory serves, the Audiostar's main difference is that it wants the 909 to be plugged 
in during the Audiostar's initial power-up.  After that it's friendly to the unplugging 
(may not even notice it).

>>> I tried my hand at serial guiding through the audiostar.
>>> My experience has been terrible.
>>> Even if my polar alignment is outstanding,
>>> and I can take 2 minute photos with round stars
>>> (longer usually ends up with some imperfections),
>>> once I hook up phd and try guiding, my stars take off again
>>> and I'm getting east corrections like crazy,
>>> but the star is just shooting out of the box and loosing lock.

Try "manual guiding" from the Autostar keypad, not from your PC.
(set speed to "1", then use the slew keys).  See if that's not (lots) better.
((manual guiding drives me nuts after a few minutes, too...))

As Andrew said:
>> There is a bug in the unpatched A1F7 where if "pulseguiding" is used
>> the scope actually sends DEC corrections to the Az motor.
>> Thus DEC never corrects and the further it drifts N/S from the XHair
>> the more the guider applies an East/West correction.

So, if you were running "unpatched" during your PHD-in-the-middle "manual guiding", then 
that bug would definitely be a contributing factor.

> So just so I understand, the 909 APM provides pulse guide commands to the autostar which
> provides corrections to the mount, or is there a facility on the AUX bus which will take
> the 909 commands and directly apply them to the axis motors?

As described in the "how it works", there is no direct 909APM-to-motors command path.
The Autostar interrogates the 909APM, and then the Autostar adjusts its motor speed 
command stream based upon that (additional) input.  "Serial" (pulse guide (:Mgx) or simple 
motion (:Mx)) commands are also "inputs" to the Autostar's list of things to do.
(PEC (Smart Drive) also can affect the instantaneous speed that might be being sent to the 
motors))

> Also, I know when using ascom drivers for serial guiding, it specifically says do not
> check pulse guiding for LX90. I assume this is because the 909 isn't being used? Is there
> any concern with doing serial guiding, when this box is checked?

The 909APM is not told (by the Autostar) *anything*.  So the 909APM does not know (or 
care) what's coming in the RS232 serial line to the Autostar. The 909APM is merely 
reporting the status of the pins on the ST4 socket.
Checking "use pulseguiding" *should* (i don't know *specifically* what PHD does) merely 
tell PHD/ASCOM to use (or not use) the :MGxtttt# commands ("x" is direction, ttttt is 
duration in milliseconds) serial commands.  Since those commands include a time-out value, 
they don't require a "stop guiding" command to arrive later.
If you're not using "pulseguiding", then the commands from the PC become
   :RG#:Mx# (delay) :Qx#
:RG#  sets "guide speed",
:Mx#  (x being n,w,s,e) means Move at the requested rate in the requested direction
:Qx#  means Quit moving in the requested direction.

(delay) means that the PC does NOT send a command during the "guiding" interval.

> My serial guiding does all 4 direction calibration, goes to the start, starts guiding, and
> then my star always starts to shoot off, almost immediately. In I'd say 15s the star is
> out of the box and PHD is doing it's blinking telling me guiding has stopped. This is when
> my polar alignment is good enough for no discernible Dec drift and I can take 2 minute
> pictures with round stars.
>
> It seems directions are reversed in serial guiding from doing 909 guiding.
>
> In calibration for serial guiding: West on my PHD screen is left (cal movement was speedy)
> , east is right (cal star moved very slow and never back to center... just enough to know
> it moved and it snapped to center), North was up, south was down and they both went
> through most of the motions before snapping to center and starting guiding. These were 180
> degrees different when using 909.
> In any case, it calibrates every time, but then the star takes off in the right (east in
> this case) direction. And it's giving east commands at maximum, one after another.

If i'm following this correctly: guiding EAST is achieved by *slowing* the RA motor.

A note: "guide speed" in an LX90 is either 50% or 66% of sidereal.  Thus the RA motor 
never *reverses* during a guiding/no-guide transition.  Thus the Autostar's anti-backlash 
actions should not be triggered (unlike DEC).

New Test: with the star in the PHD screen, turn OFF the RA motor by using the Autostar 
menu to select  Utilities/Sleep Scope (enter).  (tap any *other* key to resume)
You should see the star move off in the West direction when you put the scope to SLEEP.
(during SLEEP, you will not lose alignment)
Is the "take off" speed the same/faster/slower than the PHD-losing-the-track speed?

T>>> And even if I stop guiding, after having hooked up the serial connection and trying PHD,
T>>> the scope is basically unusable until I restart and do software align
A>>
A>> That isnt something i have heard of.
A>> Going to need more data there.

I've seen it if a *stack* of serial commands have been received.  The Autostar can appear 
unresponsive as it processes them (manual key servicing is not high priority).  New serial 
commands are also (apparently) ignored, since they have to wait until the current buffer 
is emptied (FIFO).  If the buffer is *way* over-stuffed, the new commands are completely 
dropped on the floor. (or, in some cases, mangled and later misinterpreted).

> So after doing the above guiding, something has changed and it's no longer tracking
> accurately even though polar is very near perfect. What I have to do, is shut off the
> system, restart, and do a easy align on 2 stars and it starts tracking again just fine.

If you know your mounting is "near perfect" (2 Star gets a "<5 from pole"?),
i suggest doing either a One Star (just tap Enter for Polaris), or even a "just SYNC on a 
star" alignment.
---------

I'm going to break off here and send this now, and then i'll address the next (patches) chunk.

have fun
--dick

P.S. On the took-4-tries-to-load question, i'll forward that to Chris
Carson (author of StarPAtch).   ccarson@pixsoft.ca

It *may* simply be his belts-and-suspenders-and-staple-pants-to-hip
approach to prevent people from mistakenly loading Audiostar code into
497EPs (Meade (bless their confused little hearts) made the "what is
that?" response the *same* for the two models... hence confusion (and
misloadings) reigned (and rained))).

now i'll answer the next message...

have fun
--dick

The StarPatch i use now is pretty much bulletproof
but there were a few buggies found during our attempts
to prevent the bricking of Audiostars.
This was discovered via users whose Audiostars had
lost the ability to be updated.
What we found is that Meade swapped the memory
type used in the Audiostars after about 6mths.
The commands to erase and write the new flash are different
and A1F7 has code to test for and handle both types.
Thus, you can use A1F7 to update itself to an earlier
version, but once rebooted, the old version doesnt know
about the new flash. Everything works as per usual
until you want to write to flash or do an update
at which point it wont play anymore.
The latest model Audiostars MUST NOT get any firmware
earlier than A1F7 loaded onto them,
and the error you are getting was part of that process.

Andrew

And this:

Hello Mike, et al

I had a similar problem with my LXD75 SN6 but using an old 497 (Made in
Taiwan) with current firmware and updates and Meade APM 909.  I use the
Orion Mini Guide Scope (50mm) and StarShoot Auto Guider with PHD.

On the night of 22 March I was imaging some obscure galaxy groups in
regions with dim stars.  I used 5 sec exposure to increase the star
brightness for autoguiding.  I normally use 3 sec exposures.  I got a
raggedy sine wave presentation top to bottom in RA on the PHD graph.  I
struggled until I finally gave up and reduced my imaging exposure to 1
minute to complete the series.  Last night, 23 March, I started up with
the same setup and settings.  Again I hade the raggedy sine wave top to
bottom in RA.  this time I tried several objects and the guiding was the
same.  I started to back track with the settings.  The first thing I did
was set the exposures to 3 seconds.  The graph then went to a near
straight line presentation. it always wavers less than .5 to and fro.  I
then imaged several objects in different areas of the sky with success.

I didn't stop imaging and reset to 5 seconds to see if that was the
problem I had objects I wanted to image and the guiding was good enough
for me to move up to 4 min subframes and have a happy night.

I usually have the guiding to jump on the Dec axis and present me with
an irregular saw tooth pattern on the graph..  It isn't at regular
intervals to indicate it is Periodic Error.

anyhow I followed the thread with great interest though the problem was
on different mounts using different controllers.  I thought I would
contribute my experience to be thrown in to the ring for consideration.

The LXD75 is as it came from the factory and purchased in Fall 2011.

Thanks for all the help your site and AutoStar Dick and Andrew have
provided me.

Ron 

And some good news:

> In Andrew's analysis :Mge5000#  *sped up* the motor?
> I would think a "guide east" command should slow it down

We now have a confirmed smoking gun.
( i think )

> (Andrew's in the southern hemisphere, so "east" may being reversed
> to match a "Rev E/W" setting...

Nup. Just tested in polar for Seattle and Melbourne
with Rev L/R "off" in both cases
All the motor effects simply change direction ( as expected ) 
for basic tracking, when the hemisphere changes.

However, 
there does appear to be a new and subtle bug
 in the speed setting mechanisms.
I have a lead there, so will now dig and test some more,
 but basically, no matter what else happens
using :Mgeddd# speeds up the drive in both hemispheres. 
( which I agree it shoudn't )

If i set the slew speed to "1/guide" serially 
then using :Me# also speeds up the drive ( ie wrong )
If i set the slew speed to "1/guide" via the 1 button on the hbx 
then using :Me# now slows down the drive. ( as expected )

If PHD does its calibrate using :Mx# commands 
on a clean handbox
( ie with no previous serial commands to set speeds )
then does its guiding using :Mg commands,
it would ( i think ) end up going the wrong way????
We really need to see the detailed log for what happens,
but it does throw a new semi random variable into the mix.

As noted I need to reread the relevant code with a finetooth comb
to see what is different, but at first blush, there is something
there and it is tied into speed setting.
What i cant understand is why it hasnt been reported before.????

Andrew 

And:

> or does this anomaly exist in the autostar as well?

Not sure yet.
I have found annotations on "part" of what is happening
in my notes, but i havent ever patched it as ( i suspect )
i just forgot about it as i was walking the code.
The "specific" bug i just found  only cuts
in if there are different ratios ( sign or magnitude ) in the scope.
Most of my testing was on an ETX motorset
( as its real easy to see the gears as they spin )
and ETXs have common magnitude/sign  ratios.
As such i never saw it and hence never dug backwards.
Even tho the LX90s have a common magnitude in the ratios
they have different signs ( and hence motor directions )
As such, using :Rd# to set speeds in an LX90 effectively
pre swaps the "direction" of the defined AZ slewing speed
( which is what i am seeing ), until something resets it.

> If it is in the autostars as well, it is very odd and improbable
>  that it hasn't shown up there as well.

It "looks" like the same effect is there, but i havent tried it
on a real hbx yet.

>  Seems like loads of people do guiding with the autostar
> successfully but haven't found references to those using an audiostar 
> successfully.

The bug i have detected here explains part of the problem,
but it will only get invoked if serial :R commands are used to set the 
speeds.
If something else resets them afterwards
then it would appear "random", hence the need for the "real" loggies.
Im sure timing will also cut in somewhere as well.

I also still need to check the :Mge direction tests with a std 497.
Other stuff is getting in the way, so it may take a few hours.

Andrew 

And more:

Folks have been guiding LX90's with the classic 497 for a decade.
I *think* this would've come up in that interval.

The only models i can think of with different ratios (vs signs) were the early ETX-60/70.

good hunting...
--dick

And:

I agree, but i am definitely seeing the bug after using the :R commands.
I have just run some scripted commands to confirm it.
Once the bug is initiated, slewing via the hbx may not clear it
but changing the slew speed from say 1 to 2 then back to 1 should reset it.
Doing a "goto" should also reset it correctly.
I am more suspecting the :Mge commands are getting mixed into this as well
ie its a blend of two or three things that are being mixed in a new sequence
that has now triggered it. Probably part of the sequence / timings in the
PHD calibration.
All good fun.

Andrew

The DS/DSX also have different magnitudes.
I note that the LX90 and LXD55/75 are the ones with different signs
and both these are the ones being enquired about.
Still all just interesting possibilities, but the breadcrumbs are getting fresher.

And:

When it occurs for me, like last night.   I did several go-tos back to
M42, and the same behavior continued with no guide control plugged in.

Since you're all taking drive ratios.  I noticed that the drive ration
changed between the base rom load and the patch file.

The drive ratios were initially -/+ 2.75075 and after  the patch they
are -/+ 02.75074492.     I'm sure it's totally ok, but it was just
something I've noticed because I've been looking at everything trying to
figure out what's going on.
I also noted that there are patches for data lengths..     In any case,
just something I noticed.

Thanks,
Terri

And:

Poop :-(
Just for info, you dont turn on PEC at all do you ????
I have just confirmed that :Mge in the 497 also speeds up the motors
and the serial bug is also there, hence others should have seen it
if this were the cause. :-(

> The drive ratios were initially -/+ 2.75075 and after  the patch
> they are -/+ 02.75074492.     I'm sure it's totally ok,

Yep. Meade have no concept of "round()", they truncate()
or ceiling() everything.
If you got your unpatched handbox and brought up the ratio
on screen as 2.75075, and just hit enter ( without changing anything )
then hit enter to bring it back up again, you will note it gets changed ????
This happens for all the float edit type screens.
As part of patching that, i was also able to crib a bit better precision on the displays.

Andrew

Subject:	Troubles with Audiostar on LX90
Sent:	Thursday, March 22, 2012 16:31:09
From:	Theresa Zittritsch (theresamarie11@gmail.com)
I've recently purchased a LX90 with Audiostar.     I have been
successfully using it (kind of) for a bit of visual observation and to
take some astrophotos.   I have a 909 APM made by Astro-Gene.      Since
I've had the scope, it's always done a good job at guiding when I first
start the night, but then things seem to go bad and I can never recover.
I have not been able to figure it out.     When I say they go bad, the
star just takes off and guiding can't seem to recover.      I had been
using the 909 until a few days ago when the 909 stopped working
completely.     No ST4 commands are getting through to the mount.

So while sorting out the 909 issue, I tried my hand at serial guiding
through the audiostar.    My experience has been terrible.    Even if my
polar alignment is outstanding, and I can take 2 minute photos with
round stars (longer usually ends up with some imperfections), once I
hook up phd and try guiding, my stars take off again and I'm getting
east corrections like crazy, but the star is just shooting out of the
box and loosing lock.      And even if I stop guiding, after having
hooked up the serial connection and trying PHD, the scope is basically
unusable until I restart and do software align (polar is still find and
very good at < 5').

So where's the question about audiostar?    My question is a couple
fold.     I've tested my APM per the maker and while it's not
controlling my mount, the maker says it should b working per tests I've
done.     What would cause the communications breakdown between the APM
and audiostar and mount?   I've done the 909 patches, and in fact most
of the patches in A1F7 except those that don't get checked when I go to
do the patch.      The audiostar sees the APM because when I do a
status, I get the focuser and reticule setting screens.    The ST-4 port
has 5V on all of the directional control lines.       I've tried both
aux inputs.

Secondly, on serial guiding.   I understand there are patches that fix
problems with that as well.    Like I said, I have applied most patches.
My question here is, is there any incompatibility between the serial
guiding patches and the 909 enablement patches, or the alt/az 909
enablement patch? Or is there any danger in applying any combination of
patches?       I have read all of the descriptions, but some are more
cryptic than others, and require some knowledge.     For instance, the
patch line called fix :mg Alt guiding description refers to selecting
this if you want DEC pulse guide to work.   I am pretty sure the
audiostar doesn't use pulse guiding but this patch was required to get
the 909 APM to work and would not until I applied it.     

Is there any deeper description of the various line items so that I
understand what's going on?    And again, any incompatibilities or
dangers?

Since my 909 APM has died, I've had some wild behaviors.    Like doing a
polar alignment and then finding my tracking way off and going into the
telescope settings and finding it reset to ALT-AZ mode by itself.  I've
had this happen several times.

I have had some power issues as well.   I have been using an jump start
battery pack and have recently figured out it's not very good any more,
so am using a vehicle battery until I can replace it.    I had also used
that same battery to power the scope in parallel with a thousand oaks
Dew heater controller, which can really cause demand (and subsequent
voltage droop) oscillations of > 700mv.      I was surprised at how that
thing works.   I'll need as strong battery to run that off of.     On
this, could voltage issues cause any kind of corruption of code in the
audiostar?  

Of course I've tested after putting on stable power, and no changes to
any of the issues.

I have also noted that Meade has a new patcher and patch file dated
November 11, and much later than the one in star patch from April 11.   
Is there any knowledge of what this fixes?

Lastly, if I wanted to remove a patch, or revert to original firmware,
is there a way to do this?   Is it just a matter of re-patching and
selecting nothing?

I feel like I'm grasping here.   I'm an EE and no stranger to debugging
things, and this is my second LX90 (first one had accessory holes
misaligned).    I hope I don't have to return this one as well.

Thank you in advance for any light you can shed, or alternatively, any
more tests I can do.    

Terri

And:

I have (a bunch of times) ..

As i understand it, the Audiostar is a 497EP with some hooks to provide
audio.  I do believe it can be patched the same, and resulting function
is the same, as a 497EP.

So your experience is probably relevant.

Thanks,
Terri

And:

To unpatch, is that just running star patch with all of the boxes unchecked?

Did I ask inappropriate questions?

Terri

And this:

Sorry for bothering you...   Evidently I made a mistake.

And:

I was referring to making a mistake by asking questions.  I had the
impression you welcomed them.     I will fwd to the other two people you
copied.

Terri

And:

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

> When I say they go bad, the star just takes off and guiding can't seem to 
> recover.
> I had been using the 909 until a few days ago when the 909 stopped working 
> completely.
> No ST4 commands are getting through to the mount.

The 909 is actually treated as a "lump" on the Aux Bus of the scope.
If your scope can detect the 909, then the bus is working, and part of
the 909 is working, so i must ask,
how do you know the ST4 commands arent getting to the mount???
Ie the 909 may be sending them and the handbox side isnt working
or "a portion" of the 909 may not be working.
( Im not sure how Gene buffers the ST4 port in his unit )

> I tried my hand at serial guiding through the audiostar.
> My experience has been terrible.
> Even if my polar alignment is outstanding,
> and I can take 2 minute photos with round stars
> (longer usually ends up with some imperfections),
> once I hook up phd and try guiding, my stars take off again
>  and I'm getting east corrections like crazy,
> but the star is just shooting out of the box and loosing lock.

There is a bug in the unpatched A1F7 where if "pulseguiding" is used
the scope actually sends DEC corrections to the Az motor.
Thus DEC never corrects and the further it drifts N/S from the XHair
the more the guider applies an East/West correction.

> And even if I stop guiding, after having hooked up the serial connection 
> and trying PHD,
> the scope is basically unusable until I restart and do software align

That isnt something i have heard of.
Going to need more data there.

> What would cause the communications breakdown between the APM and 
> audiostar and mount?
> The audiostar sees the APM because when I do a status, I get the focuser 
> and reticule setting screens.

The fact the menus appear means the scope has detected the APM,
ie the Aux bus and the 909 are working and communicating.

> Secondly, on serial guiding.   I understand there are patches that fix 
> problems with that as well.

That is the "Fix :Mg Alt Guiding".
If that was selected, then the pulseguiding "should" work.

> My question here is, is there any incompatibility between
> the serial guiding patches and the 909 enablement patches,
> or the alt/az 909 enablement patch?

There shouldnt be any problems.
Part of the problem we face is different functions get enabled by
the scope asking the RA motor card what type it is on booting.
We know Meade have changed the way the motor cards work
without updating the firmwares, but to date, that hasnt caused
any cross contamination in the patching.
Need to get some data from your scope when its "semi patched"
( ref lower re my Editor )

> I have read all of the descriptions, but some are more cryptic than 
> others,
> and require some knowledge.
> For instance, the patch line called fix :mg Alt guiding description refers 
> to
>  selecting this if you want DEC pulse guide to work.
> I am pretty sure the audiostar doesn't use pulse guiding

You did yr dough :-)
There are 4 ways to guide the Audiostar
1) via handbox keys
2) via ST4 port in an APM909
3) via :MgxDDD# serial commands
4) via :Mx# then :Qx# serial commands

2) and 3) invoke the "Pulseguiding" mechanisms.

> but this patch was required to get the 909 APM to work and would not until 
> I applied it.

Correct, if you have an APM, it "pulseguides" by default,
due to the way the Hbx firmware works internally.

> Since my 909 APM has died, I've had some wild behaviors.
> Like doing a polar alignment and then finding my tracking way off
> and going into the telescope settings and finding it reset to ALT-AZ mode 
> by itself.
> I've had this happen several times.

This isnt something i have heard of.
I also cannot see how an APM909 misbehaving could do this.

> I had also used that same battery to power the scope in parallel
> with a thousand oaks Dew heater controller, which can really cause demand
> (and subsequent voltage droop) oscillations of > 700mv.
> I was surprised at how that thing works.
> I'll need as strong battery to run that off of.
> On this, could voltage issues cause any kind of corruption of code in the 
> audiostar?

It wont corrupt the FLASH code, but may cause funny operation
if it affects the working RAM ( where some code gets copied when running ).
I dont know how the DEW controller you have works
but if it is dropping the supply rail by that much
( and probably using PWM ), that may be feeding high freq noise into the 
Hbx.

> I have also noted that Meade has a new patcher and patch file dated 
> November 11,

Meade dont have "patches", i am responsible for the Audiostar patches.
Meade changed their ASU updater recently to prevent it bricking
Audiostars, but thats all.
You should always use StarPatch with the Audiostars.
Its much smarter and more robust comms wise.

> Lastly, if I wanted to remove a patch, or revert to original firmware,
>  is there a way to do this?   Is it just a matter of re-patching and 
> selecting nothing?

Yes, or simply select the A1F7.rom instead of the A1F7.spf

> I'm an EE and no stranger to debugging things, and this is my second LX90
> (first one had accessory holes misaligned).    I hope I don't have to 
> return this one as well.

Based on yr EE knowledge, there are several diagnostic tools we can use to 
help
debug the status of the scope at different times.
It requires that the scope is initially patched with the Peek/Poke section 
only.
In that case, my PEC Editor ( grab the beta at the bottom )
http://members.optusnet.com.au/johansea/
can read out a whole lot of working ram associated with encoders, aligning,
motor types, APM applicability etc.
If you are happy to run a few tests via that, we can maybe see if anything
else pops up.

Andrew

And:

From:	richard seymour (rseymour@wolfenet.com)
Let's start with the easy answer:
To use StarPatch to load a *totally* non-patched version of the firmware:
(assuming you've already used it to load a patch, so you've already got the files on your PC)
(a) start StarPAtch
(b) use the "drop box" labeled "select patch or rom file"
(c) for the Audiostar, choose BuildEPA1F7.rom
(d) click Update Autostar
(e) StarPatch will verify that you really want to use the UNpatch rom file.
(f) assure it that you really do, and it'll load the "clean from Meade" file.
------------

If you choose the (as you suggested) the "untick all boxes" route, you
may still get a few vestiges of patch effects (such as the modified
version number).  By chooseing the ROm file itself, you avoid any of
that.

I'll try to address the other stuff in a subsequent (not too far off) message.

have fun
--dick

And more:

(first subsequent (i think there will be more... we'll find out))

Hi...
Next almost-easy answer:

>> As i understand it, the Audiostar is a 497EP with some hooks to provide audio.
 >>  I do believe it can be patched the same, and resulting function is the same, as a 497EP.

Yes, that's armwave-level correct.
The Audiostar and 497EP are *almost* exactly the same, with some devil-in-the-details 
differences:
(a) there are subtle differences in the hardware: specifically the deep-down device 
characteristics of the FlashRam is a real gotcha... it affects:
(b) the firmware differs.  Yes, you can load 497EP's 5CE1 or 5CE2 into an Audiostar, and 
it will run as an "Autostar", BUT the 497EP "erase and reload FlashRam" section (which 
controls loading the firmware *again*) does not properly handle the Audiostar's FlashRam. 
  Therefore, you can't (given Meade's firmware) go *back* to being an Audiostar if you 
mistakenly load 497EP code into it. (Andrew has a fix for this)
(c) the firmware differs, so you can't use the 497EP's patch kit on the Audiostar's 
firmware and vice versa.  The things we change/tweak have moved (or may not even exist) 
between the two.

I see Andrew has answered a bunch of the 909APM questions.
Downloading his MyScope app gives you a much deeper view into the environment the 
Audiostar is seeing.

good luck
--dick

And this:

Andrew, Dick,  for the notes and all of the information, it's very very =
helpful for me.     Mike, thank you for getting them engaged.

I will try to answer follow-up questions for me here.

This is from Andrew:

>> When I say they go bad, the star just takes off and guiding can't =
seem to recover.
>> I had been using the 909 until a few days ago when the 909 stopped =
working completely.
>> No ST4 commands are getting through to the mount.

> The 909 is actually treated as a "lump" on the Aux Bus of the scope.
> If your scope can detect the 909, then the bus is working, and part of
> the 909 is working, so i must ask,
> how do you know the ST4 commands arent getting to the mount???

I have been using PHD for guiding with the 909, and all of a sudden it =
just stopped working while out doing photos.   PHD could not get the =
stars to move, would not calibrate, etc.    I also did the tests Gene =
Nolan gave me, by making up a test rig to ground each one of the =
directional ST-4 inputs to see if the mount did what was being asked.   =
It does not.  I am getting 5V on all directional signals, but grounding =
them does not move the mount.   Verified by both no sound, and no =
changes in RA/DEC.   Now if i connect up PHD via ASCOM drivers and use =
manual mode, the mount moves fine and I can see it moving on status =
screen (holding mode down after align for 5s).     So I am basing my =
comments on what Gene told me.   He says that if I have 5V on signals, =
and 909 is seen by the mount, it should work.   That seems a bit of a =
leap because it implies whatever transfer function the 909 applies  goes =
go the output.. but he knows this more than I.    He has told me I can't =
really measure the output with a DVM.

> Ie the 909 may be sending them and the handbox side isnt working
> or "a portion" of the 909 may not be working.
> ( Im not sure how Gene buffers the ST4 port in his unit )

>> I tried my hand at serial guiding through the audiostar.
>> My experience has been terrible.
>> Even if my polar alignment is outstanding,
>> and I can take 2 minute photos with round stars
>> (longer usually ends up with some imperfections),
>> once I hook up phd and try guiding, my stars take off again
>> and I'm getting east corrections like crazy,
>> but the star is just shooting out of the box and loosing lock.

> There is a bug in the unpatched A1F7 where if "pulseguiding" is used
> the scope actually sends DEC corrections to the Az motor.
> Thus DEC never corrects and the further it drifts N/S from the XHair
> the more the guider applies an East/West correction.

So just so I understand, the 909 APM provides pulse guide commands to =
the autostar which provides corrections to the mount, or is there a =
facility on the AUX bus which will take the 909 commands and directly =
apply them to the axis motors?

Also, I know when using ascom drivers for serial guiding, it =
specifically says do not check pulse guiding for LX90.     I assume this =
is because the 909 isn't being used?   Is there any concern with doing =
serial guiding, when this box is checked?
My serial guiding does all 4 direction calibration, goes to the start, =
starts guiding, and then my star always starts to shoot off, almost =
immediately.   In I'd say 15s the star is out of the box and PHD is =
doing it's blinking telling me guiding has stopped.    This is when my =
polar alignment is good enough for no discernible Dec drift and I can =
take 2 minute pictures with round stars.     

It seems directions are reversed in serial guiding from doing 909 =
guiding.   

In calibration for serial guiding:  West on my PHD screen is left (cal =
movement was speedy) , east is right (cal star moved very slow and never =
back to center... just enough to know it moved and it snapped to =
center), North was up, south was down and they both went through most of =
the motions before snapping to center and starting guiding.    These =
were 180 degrees different when using 909.
In any case, it calibrates every time, but then the star takes off in =
the right (east in this case) direction.    And it's giving east =
commands at maximum, one after another.

>> And even if I stop guiding, after having hooked up the serial =
connection and trying PHD,
>> the scope is basically unusable until I restart and do software align

> That isnt something i have heard of.
> Going to need more data there.

So after doing the above guiding, something has changed and it's no =
longer tracking accurately even though polar is very near perfect.     =
What I have to do, is shut off the system, restart, and do a easy align =
on 2 stars and it starts tracking again just fine.

> What would cause the communications breakdown between the APM and =
audiostar and mount?
> The audiostar sees the APM because when I do a status, I get the =
focuser and reticule setting screens.

> The fact the menus appear means the scope has detected the APM,
> ie the Aux bus and the 909 are working and communicating.

>> Secondly, on serial guiding.   I understand there are patches that =
fix problems with that as well.

> That is the "Fix :Mg Alt Guiding".
> If that was selected, then the pulseguiding "should" work.

Ok, thanks, but this is where i get confused on which patches to apply.  =
Most get checked.

fix :sc     (this says it fixes serial command.... so why don't I need =
this?)

Fix :EQ, :ED :ES   most of these imply fixes to serial commands...      =
ED says something else so I have unchecked it.

>> My question here is, is there any incompatibility between
>> the serial guiding patches and the 909 enablement patches,
>> or the alt/az 909 enablement patch?

Here are 909 patches I have applied besides the ones above:

Enable 909APM

Allow :MG in alt az    (I am wondering if i don't need this if it's only =
to do guiding while in alt az mount mode)       The verbage isn't exact, =
so I get confused.    All of these scopes have alt-az mounts, it really =
matters if polar aligned or not I think but that's not really what it    =
 says, so I'm left wondering what it means.

A bunch of the fixes seem totally independent of mount control, like =
fixing comet times, rise/set descriptions, etc... so I have checked =
them...

> There shouldnt be any problems.
> Part of the problem we face is different functions get enabled by
> the scope asking the RA motor card what type it is on booting.
> We know Meade have changed the way the motor cards work
> without updating the firmwares, but to date, that hasnt caused
> any cross contamination in the patching.
> Need to get some data from your scope when its "semi patched"
> ( ref lower re my Editor )

>> I have read all of the descriptions, but some are more cryptic than =
others,
>> and require some knowledge.
>> For instance, the patch line called fix :mg Alt guiding description =
refers to
>> selecting this if you want DEC pulse guide to work.
>> I am pretty sure the audiostar doesn't use pulse guiding

> You did yr dough :-)
> There are 4 ways to guide the Audiostar
> 1) via handbox keys
> 2) via ST4 port in an APM909
> 3) via :MgxDDD# serial commands
> 4) via :Mx# then :Qx# serial commands

> 2) and 3) invoke the "Pulseguiding" mechanisms.

So when I do serial guiding with ascom drivers and connecting through =
the handset, which one of those above is it?  Is it 1 or 3 or 4?      =
Specifically in the ascom driver read me file, it says that pulseguiding =
should be unchecked because that's only applicable for newer LX200  with =
autostar II controllers.    In fact, I think the first time I tried I =
had it checked and nothing worked.   Can you clarify?

>> but this patch was required to get the 909 APM to work and would not =
until I applied it.

> Correct, if you have an APM, it "pulseguides" by default,
> due to the way the Hbx firmware works internally.

>> Since my 909 APM has died, I've had some wild behaviors.
>> Like doing a polar alignment and then finding my tracking way off
>> and going into the telescope settings and finding it reset to ALT-AZ =
mode by itself.
>> I've had this happen several times.

> This isnt something i have heard of.
> I also cannot see how an APM909 misbehaving could do this.

Yes, this was very wild.... had it happen a few times one night, but not =
since...   I have changed my power around too, so not sure if this =
effected (fixed) it.  Now using our truck battery instead of the =
portable which seems to have gone bad (another thing to buy).
In any case, haven't seen it happen since.

>> I had also used that same battery to power the scope in parallel
>> with a thousand oaks Dew heater controller, which can really cause =
demand
>> (and subsequent voltage droop) oscillations of > 700mv.
>> I was surprised at how that thing works.
>> I'll need as strong battery to run that off of.
>> On this, could voltage issues cause any kind of corruption of code in =
the audiostar?

> It wont corrupt the FLASH code, but may cause funny operation
> if it affects the working RAM ( where some code gets copied when =
running ).
> I dont know how the DEW controller you have works
> but if it is dropping the supply rail by that much
> ( and probably using PWM ), that may be feeding high freq noise into =
the Hbx.

It uses PWM but not in a way I suspected.   I though, like I'm reading =
you think, that PWM is higher frequency.    This baby seems to pulse at =
around a second.    I don't have a scope at home, but looked at my power =
supply and while the heater was running (1/2 power), the voltage was =
swinging between 12.3 and11.6 on about a 1 hertz cycle.     I did not =
expect this!      So I have had it removed of late until I can figure =
out how to decouple it or use strong enough battery so that it doesn't =
effect voltage.   I had been running a common power cord to the scope, =
and then tapping dew heater and power to scope from that.     I need to =
rethink this.

>> I have also noted that Meade has a new patcher and patch file dated =
November 11,

> Meade dont have "patches", i am responsible for the Audiostar patches.
> Meade changed their ASU updater recently to prevent it bricking
> Audiostars, but thats all.
> You should always use StarPatch with the Audiostars.
> Its much smarter and more robust comms wise.

>> Lastly, if I wanted to remove a patch, or revert to original =
firmware,
>> is there a way to do this?   Is it just a matter of re-patching and =
selecting nothing?

> Yes, or simply select the A1F7.rom instead of the A1F7.spf

Thanks.   I may do this just to get back to ground zero again.

>> I'm an EE and no stranger to debugging things, and this is my second =
LX90
>> (first one had accessory holes misaligned).    I hope I don't have to =
return this one as well.

> Based on yr EE knowledge, there are several diagnostic tools we can =
use to help
> debug the status of the scope at different times.
> It requires that the scope is initially patched with the Peek/Poke =
section only.
> In that case, my PEC Editor ( grab the beta at the bottom )
> http://members.optusnet.com.au/johansea/
> can read out a whole lot of working ram associated with encoders, =
aligning,
> motor types, APM applicability etc.
> If you are happy to run a few tests via that, we can maybe see if =
anything
> else pops up.

Thanks, have already been using the Myscope beta code extensively for =
some time (smile).     I have used it to verify firmware loads each time =
I do it (getting the tested ok messages).       Just tell me what I need =
to do or validate.  Didn't really notice any tests other than validating =
patches.
Thank you for this...where do I send the beer?   

Subject:	code error autostar 497
Sent:	Thursday, March 22, 2012 05:25:04
From:	ricardo fantini (rfantinister@gmail.com)
I have the model 497 Autostar and da display 40E, I need the tables for errors
the model is MOTOROLA Micro or is old 
Thanks for your time 
welcomes Ricardo 

-- 
Ricardo Fantini
Villa La Angostura
Neuquen  ,Patagonia  Argentina

And:

THAK ,ok   Ricardo

And:

Thank you very much for the  response, I do not understand you send what read the display
             .(c) 05 Meade /40/...
               ...AUTOSTAR
PD)Attached photos of the display

And:

OK Mike, the problem is that the display shows (c) 05 Meade/40E/and not
work the AUTOSTAR, I need to know that it means reading the display
Many thanks Mike 

And:

Thanks Mike, I have the hard, cable and pc, it gave me a good orientation 
Really very valuable your help
Eternally thankful Ricardo

And:

Thanks Mike, if I have material to proceed and will send you the results 
Welcomes Ricardo

Subject:	Auto Star computerized telescope
Sent:	Monday, March 19, 2012 05:56:01
From:	Jack Butcher (unchained2@hotmail.com)
Will my scope work with windows 7? I have had this scope for yrs and it
will not work with vista. Only xp. I also have the lp camera and would
like to take pictures with it from my new laptop and control the scope
with it. I have stuck a lot of money into this scope and it works great
but not with vista. Thank You, Jack Butcher. 319-465-5525 or email at
unchained2@hotmail.com

Subject:	Re: Autostar 497ep corrupted and doesn't want to update/restore
Sent:	Friday, March 16, 2012 15:08:09
From:	Andrew Johansen (johansea@optusnet.com.au)
> As for the Autostar, thank you again for making this freeware
> version of the software. I'll deselect the GPS section (I rememeber it's 
> the first option).
> Is there any other suggestion to check/uncheck functions?

Depends on what you want to do??
Read each item and select what suits you.

> The main use of the telescope is to take images
> with SBIG ST-7 imager, initially in Alt-Az mode.

For polar if you want to guide, you need to apply the DEC guide patch
but other than that, the std parts of the patch should be OK.

> So do you think it's enough to just tighten firmly (but not exaggeratedly)
> that knob and then reset, calibrate, train drive and set percentages,
> as recommended on the page below?

The only two knobs you should be using are the RA and DEC clutches
and they are just that "clutches".
You only tighten them enough to stop the axis slipping in normal operation
but not tight enough to prevent them slipping if the tube gets blocked.
Reset only needs to be done if things have really turned to custard.
Calibrate motors isnt as critical for an LX90, but can always be run
every 6mths or so if desired.
Drive train also only requires to be done every 6mths or so
( unless you open the scope and adjust the gearing, in which case it
must be done immediately )
Setting percentages is necessary if you are guiding,
but otherwise, its not too critical.

> Shouldn't I worry to try to make the altitude motion speed match the 
> azimuth one?

Dont understand this bit.
The alt and az axes MUST operate independently in order to track the sky.
How do you plan to make them match????

> And, based on the experience of you guys, ST-7

I'm not the one to help with piccies etc, i do mechanicals and firmware :-)

Andrew

And:

From:	David Duarte (david.duarte@ymail.com)
> The only two knobs you should be using are the RA and DEC clutches

That's exactly the problem. Someone has loosen a "third" knob, as I had
said. That's the opposite knob of the DEC/Alt axis. When looking from
the back of the tube, the DEC clutch we use normally is at the right.
Another person accidentally forced the left knob (on left fork arm)
until it got loosen (even the setting circle got loosen), and then I
became worried about the factory-tuned torque on that knob.

> Dont understand this bit.
> The alt and az axes MUST operate independently in order to track the sky.
> How do you plan to make them match????

I meant I would set a slow speed (2 or 3 key) and then use a terrestrial
object as reference (targets: terrestrial) and move the telescope
alternatively in one direction and the other using the arrow keys and
visually compare the speed on each axis. Then I would, by trial and
error, tighten or loose that left knob until it moves at about the same
speed as the RA/Az axis.

However, according to what you said, I don't need to do that, right?
Just tightening that knob to a firm feel (like we do to the right knob)
and then calibrating the motors should be enough, right?

Thanks again for everything, Andrew.

Thank you once again for the wonderful site,

David

And:

From:	richard seymour (rseymour@wolfenet.com)
I haven't dug back through the entire thread to find out what scope you
have,
BUT: The "left knob" on the dual-fork scopes (ETX-xxx, LX-90) has no
effect upon scope operation.  The *only* thing it does is keep the
DEC/Alt scale from falling off.
I can run my LX200gps/ETX=90 with the knob totally removed and they
don't care.

The proper torque for that knob is "snug" (which is qualitatively less
than "firm").
If the DEC scale doesn't slip during operation, it's correct.

The actual support and torqued parts of the DEC support assembly are the
bearings
(plastic sleeves on my ETX-90, ball bearings on an LX-90) are held by
fixtures and screws inside the fork body.  The DEC scale and knob are
just decorative frippery.
(*useful* frippery, but not mechanically necessary)

have fun (but don't over-analyze too much)
--dick

Subject:	Autostar tour question
Sent:	Thursday, March 15, 2012 11:04:28
From:	Julie Clayton (jules1.clayton@yahoo.com)
Hello... I want to add these coordinates that I got from simbad to an
autostar tour I'm creating..
Just not sure how it would be configured: 21h53m60s + 62d36m00s?

Many thanks for any assistance.
julie

And:

my apologies.. i left something out of my original email..

i'm trying to convert these coordinates that i got from simbad to
autostar tour coordinates:

21 53.6 +62 36 

Am not sure how to convert the numbers after the decimal..
should it be 21h53m60s or 21h53m06s?

Thanks again..

Subject:	Re: Wanted 'ad' for 494
Sent:	Tuesday, March 13, 2012 11:07:47
From:	Tom Murphy (tmmurphymn@gmail.com)
Hi Mike - BTW, thanks for this:  I may end up being, like the person
with the latest post in your "helpful information: AstroStar" section,
on the hunt for an separate replacement display.  Meade will not sell
them (as your contributor said before, and now I know from a phone
call).  My hope, is that with the newer display - not compatible with
the older 494 - there might be a more easily-found replacement that (one
can hope!) displays right-side-up!  I want to sell this along with the
otherwise nice condition ETX-80 backpack unit I picked up for a song.  I
can always use it as a second scope with either the broken display, or
my 497 possible, but $$ is more tempting in the tight times I find
myself in! :^j

But...Thanks again!
-Tom Murphy

Subject:	Autostar 497ep corrupted and doesn't want to update/restore
Sent:	Tuesday, March 13, 2012 04:27:44
From:	David Duarte (david.duarte@ymail.com)
First, thank you for your site. It's been very useful.

I'm having a problem in trying to update/restore a 497EP Autostar
Controller. The telescope is a LX-90 ACF.

The Autostar was corrupted after an attempt to update it normally
through the Meade Autostar Updater Software from version 59ef to version
5CE2 using a USB-to-Serial cable.

It looks like the USB cable was "partially" compatible, as the Autostar
was recognized by the ASU, but was corrupted after an attempt to update
it. And it was not recognized at all by Starpatch even before it was
corrupted.

I have searched your site and learned about the safe load and patched
versions. I found out that, in my case/version, I have to press the
"Mode" and "?" keys while turning on to make it load the safe mode.

When I do so, it shows the screen:

"Monitor Mode" - 1st line
"Bootloader v2.3a" - 2nd line

When turning on normally (without pressing the keys), it flashes this
screen once very briefly:

"08 Meade 2008"
"Bootloader v2.3a"

And then it shows just a blank lit screen.

So, after the corruption of the firmware, I tried as stated in this page
(http://www.weasner.com/etx/autostar/as_safeload.html).

I used an old desktop which has a RS-232 serial port and with Windows XP
installed, with almost no other software installed, just the OS. 

I hooked up the cables, started the computer, started the telescope
(Autostar in "Monitor Mode"), and then started the ASU. Then I tried the
"Connect" button in the Autostar Commands box, but it immediately says
"Could not find Autostar", "Check your connection and try again". Then I
tried "Upgrade Autostar Software Now", but it says the same message and
then opens the box to select the type of Autostar, then I select the
497EP, but I cannot access the option to update it from Local, only from
the Internet, and, if I click ok, it downloads the rom file (5CE2), but
then opens a dialog box saying that the Autostar has not been upgraded,
that I should connect the handbox to the PC first and click the upgrade
button.

I have tried it putting the 5CE1 rom file in the Ephemerides folder, as
well as the 5CE2 and the patched 5CE1a9, but it doesn't make difference,
as I can't access the option "Local".

I also tried the Starpatch program, but it doesn't recognize the
Autostar as well.

An interesting fact is that, when I try in safe load (Monitor Mode),
both the ASU and Starpatch INSTANTLY says they could not find the
Autostar. However, when I try in normal (corrupted blank screen) mode,
they take SOME SECONDS to say they could not find it.

Another interesting fact is that the ASU didn't recognize the Autostar
in "Monitor Mode" even before it was corrupted. I had tried it with the
USB cable. It recognized the Autostar in normal mode, showing model and
version, but didn't recognize it in "Monitor Mode". Then I tried to
update in normal mode, using the usb cable, and you already know what
happened... after several hours, with percentage increasing extremely
slowly it showed a dialog box saying that "the Autostar has not been
updated, check your connections" or something like that, and the
Autostar firmware was corrupted.

One more important fact: when checking the Ports (COM & LPT) in the
desktop with real RS-232 port, it only shows COM1 and LPT1, and that
doesn't change when the Autostar is connected (and turned on). Is there
anything I should do in the RS-232 port before hooking up the 505
cables? Or this port is ready to use anything after the OS is installed?
I only checked the configurations... 9600-8-none-1-none.

So I'd like to know if there is any way to make the computer (ASU or
Starpatch) recognize the Autostar and allow to update/restore it.

If possible and necessary, please talk to Dick, Andrew and other people
who can help.

Thank you in advance for your help and congratulations for your site,

David

And:

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

> I have searched your site and learned about the safe load and patched 
> versions.
> I found out that, in my case/version, I have to press the "Mode" and "?" 
> keys
> while turning on to make it load the safe mode.

Close, but "no wabbit".
Firstly, just for info, where did you find this combination?
as if its on a site somewhere we need to get it amended.

For 59Ef, you need to use "Enter" and "?" to get into safeload.
"Mode" and "?" actually puts you into an interactive form
of download that requires a special factory program
to be running on the PC end.

> When I do so, it shows the screen:

> "Monitor Mode" - 1st line
> "Bootloader v2.3a" - 2nd line

Good, that means it is basically still working and has got into factory 
mode.
If that is the case, then the basic safeload firmware should still be there.

What you should see ( for safeload mode ) is
"Download Mode"     <<<<<
"Bootloader v2.3a"

> When turning on normally (without pressing the keys), it flashes this 
> screen once very briefly:
>
> "08 Meade 2008"
> "Bootloader v2.3a"
> And then it shows just a blank lit screen.

Correct.
EVERY time, you start the hbx, it uses the "generic" safeload code first
( as thats where the basic startup comms is )
and then, unless it detects the keys pressed, it starts as per normal.
If the keys are down, it diverts to a special section
in the safeload code.
In your case, during a std boot, the initial screen flash is the safeload 
pass
and the dead screen following indicates some normal code is missing.
Sooo, at this point, we know that the safeload code is still there and the 
screen works.

> I used an old desktop which has a RS-232 serial port and
...
> I also tried the Starpatch program, but it doesn't recognize the Autostar 
> as well.

Neither will recognise it in factory mode, so thats probably not a drama.
I strongly suggest you only use Starpatch and the PC with the com port
and retry the process using 5CE1 firmware ( as that is the only one we have 
patched )
In "safeload mode" it should now detect your Hbx.

> One more important fact: when checking the Ports (COM & LPT)
> in the desktop with real RS-232 port, it only shows COM1 and LPT1,
> and that doesn't change when the Autostar is connected (and turned on).

Correct. Com1 is a native hardware rs232 port, hence is always there
and always works correctly.
USB converters only show up when you plug them in.

> Is there anything I should do in the RS-232 port before hooking up the 505 
> cables?
> Or this port is ready to use anything after the OS is installed?
> I only checked the configurations... 9600-8-none-1-none.

ASU and Starpatch would reconfigure the port correctly anyway,
but basically, if you have a true com1, then you only need to plug in the 
cable.

> So I'd like to know if there is any way to make the computer
> (ASU or Starpatch) recognize the Autostar and allow to update/restore it.

In this case, it may be as simple as press the correct buttons
to get into safeload vs factory mode

Andrew 

And:

Thank you very much, Andrew.

So it seems the only thing I did wrong was the keys combination. I'll
try again pressing "Enter" and "?".

The "Mode" and "?" combination is found in this page:
http://www.weasner.com/etx/autostar/as_safeload.html

I'll retry using the 5CE1 firmware, as you said. Then, if it, God
willing, succeeds/restore, I'll update to the patched 5Ce1v09. By the
way, Starpatch also offers to download the 5Ce1v10 version. Is it also
made by you? Is it preferable instead of v09?

I'll let you all know the results soon after retrying.

Thanks from Brazil,

David

For versions starting with "59E" (so: 59E7, 59Ed, 59Ef)
the "safe load" key sequence is  simultaneous [Mode] and [?]

For version 5BE2 (the "current" one) they're back to [enter] [scroll down]

And:

You didnt do anything wrong, just the instructions are out of date
and have got missed for updating.
We will get them amended to reflect the correct sequence.

> I'll retry using the 5CE1 firmware, as you said.
> Then, if it, God willing, succeeds/restore, I'll update to the
> patched 5Ce1v09. By the way, Starpatch also offers to download
> the 5Ce1v10 version. Is it also made by you? Is it preferable instead of 
> v09?

Yes, i make the 497EP patches
Just do a single load of 5CE1v10, as its the latest and best to date.

> I'll let you all know the results soon after retrying.

Will await yr results

Andrew

And an update, with more questions:

Hello Andrew, Mike, Dick,

Thank you again, Andrew, both for the help and for making the patch.

It worked!

By turning on while holding "Enter" and "?", the Autostar screen showed
"Download Mode", as you said, and ASU recognized it ("Autostar found at
COM1"). It even recognized the model and version, and it's interesting
that the version informed was 5CE2, which was the version I tried to
upload through the USB cable. Anyway, I was able to upload the 5CE1
version to the handbox (updated database, software and flash loader)
through ASU. It took less than half an hour.

A curious fact: After the update, the screen showed on the handbox was
"Press 0 to align or Mode to setup". Then I pressed mode (with Autostar
still connected to the computer) and, to my surprise, the next screen
was "Sun sets at:", then I pressed mode again and the next screen showed
unrecognizable characters on 2nd line. After pressing mode one more
time, just a blank lit screen appeared. I turned off, disconnected from
the computer and turned on. Everything was normal then, but I didn't
test Go To or anything.

Anyway, I turned off the computer, reconnected the Autostar and turned
on both. I went to Starpatch to upload the 5Ce1v10.spf. I didn't change
the checked/unchecked boxes. Done in less than 10 minutes.

And some more questions now:

It now shows every time during initialization: "GPS trial version", then
"GPS not found", then it asks to put Date and Time, and the time it
shows (before I set again) is not close to the correct time from which
was set before. Is that normal?

And does this GPS trial version of Starpatch disable the built in GPS of
the mount? Or can I use it normally?

The handbox has a few "always lit" pixels in the bottom right corner,
like hot pixels, at least since it was corrupted, I don't remember if
they were there before that. Is it possible to know if it is related
with the software corruption? Or is it a hardware issue? Is it anything
that I should worry about, like a warning that there is a hardware
problem that will grow in the near future?

And changing the subject from handbox to motors, maybe any of you can
help. Someone accidentaly has loosen the opposite knob of the altitude
axis (not the one you use normally to release and lock the altitude
axis). The telescope was often showing "Motor unit failure" when doing
"Calibrate motors", the go to and tracking was bad, and there was a
significant speed difference between altitude and azimuth motion. That
was one of the reasons why I wanted to upgrade from the 59ef version.
But not everything was its fault, as I found this knob issue later. We
tightened the knob, but I read in some sites that the knobs
(screws/bolts) on Meade telescopes that are not supposed to be touched
by users have a factory-tuned torque, which, once changed, can make the
telescope seriously lose its GoTo and Tracking precision. So my question
is: is it true? Or is it enough to just set the torque something close
to the original one and the "Calibrate motors" will do the rest? The
telescope is a LX90-12 ACF.

Is it a good idea to try to set accurately the knob torque by making the
altitude axis match the same speed as the azimuth axis, by trial and
error, observing a terrestrial object through the eyepiece using one of
the slowest speeds? Should I do it before or after "Calibrate motors"
and "Train drive"?

Sorry for so many questions.

Thanks,

David

And:

> It worked!

What!!!!!!!, you doubted us?  :-)     ( but congratulations anyway )

> A curious fact: After the update, the screen showed on the handbox
> was "Press 0 to align or Mode to setup". Then I pressed mode
>  (with Autostar still connected to the computer) and,
> to my surprise, the next screen was "Sun sets at:",

Not strange at all.
After updating firmwares using ASU or Starpatch,
the handbox does whats called a "softboot" ie it doesnt fully restart.
Old data is still left in memory and can affect the menus presented.
I have never heard of what you saw, but am not surprised.
After updating firmware on a 497EP or Audiostar handbox
you MUST reboot the handbox a second time using the on/off switch
before it really takes.

> It now shows every time during initialization: "GPS trial version",
> then "GPS not found", then it asks to put Date and Time,
> and the time it shows (before I set again) is not close to the correct 
> time
> from which was set before. Is that normal?

Yes and no.
The author of Starpatch has very generously made a freeware
version of his firmware loader available for general firmware loading.
It is far superior to Meades ASU in all respects.
Starpatch was originally written to allow a third party ( StarPatch )
GPS receiver to be integrated into the 497 firmwares via the Aux port.
The code to do this is part of the standard patches, and is selected by 
default.
That is what it is testing for and hence results in the screen message you 
see.
If you reload the firmware patch, but deselect the GPS section of the patch
then you wont get this prompt on starting.

> And does this GPS trial version of Starpatch disable
> the built in GPS of the mount? Or can I use it normally?

It shouldnt, but im not 100% sure there.
Again, reload without the GPS part of the patch
and all will be well.

> That was one of the reasons why I wanted to upgrade
>  from the 59ef version. But not everything was its fault,

Not sure there. 59Ef is basically not fit for purpose,
it had more bugs than a boarding house mattress.

> I read in some sites that the knobs (screws/bolts) on Meade telescopes
> that are not supposed to be touched by users have a factory-tuned torque, 
> which,
> once changed, can make the telescope seriously lose its GoTo and Tracking 
> precision.
> So my question is: is it true?

Nup.
The torque settings in the axis bearings and worm bearings can certainly
affect operation, but in general, its not a problem for "user accessible" 
knobs

Andrew Johansen Melbourne Australia

And:

As for the Autostar, thank you again for making this freeware version of
the software. I'll deselect the GPS section (I rememeber it's the first
option). Is there any other suggestion to check/uncheck functions? The
main use of the telescope is to take images with SBIG ST-7 imager,
initially in Alt-Az mode.

"Nup.
The torque settings in the axis bearings and worm bearings can certainly
affect operation, but in general, its not a problem for "user
accessible" knobs"

So do you think it's enough to just tighten firmly (but not
exaggeratedly) that knob and then reset, calibrate, train drive and set
percentages, as recommended on the page below? 

http://www.weasner.com/etx/autostar/as_info.html

Shouldn't I worry to try to make the altitude motion speed match the
azimuth one?

And, based on the experience of you guys, do you think the LX90 mount
goto and tracking precision are enough to take images with the ST-7
(narrow field) and this 12" (3000mm focal length) telescope?

And what is approximately the maximum exposure time in Alt-Az so that
there won't be field rotation?

Thanks,

David

Subject:	AutoStar LNT Proc Trap 2 Error
Sent:	Friday, March 9, 2012 13:08:03
From:	Gabe Ochoa (grkfire8a@gmail.com)
Since I have you reading now, I did have a technical question of
sorts....

Here is my scope info:
ETX-125 PE w/the new LNT module.
Autostar 497

I'm assuming my LNT has stopped working, I keep getting a proc. trap 2
error when Autostar attempts to grab time info on start up, yet when I
disconnect the LNT, all is OK.  What is strange is that it only started
happening when I attempted to install the firmware patches using
StarPatch.  StarPatch error-ed out on me when patching and I had to go
into Autostar's "safe mode" to install the stock 43eg firmware again
using Meade's ASU.  It went through ok, but now I have this proc. trap 2
error.  

I've tried a new battery on the LNT & my scope was connected to an a/c
power source during install.

Did I unintentionally fry the LNT?  I'm beginning to think so because
Autostar is perfectly fine when it is unplugged.  Just wondering if
you've heard of that before.

And:

When the LNT is connected and I power up to choose either "mode" or "0"
for alignment procedures, it just goes to proc 2 error.  It doesn't even
let me select easy, 1 star, 2 star, etc...

I've never used my etx w/batteries, I've always had it powered through
my home a/c.  Strange.  Again, everything was working fine before, it
only just started happening when I reflashed the firmware.  :(

And:

I haven't had any luck using StarPatch, it always errors out at the 5%
mark and asks me to choose a slower upload speed (I always choose the
slowest), I'll try again with batteries and see what happens.  I hope I
can get it resolved, because it feels like my perfect scope is broken,
even though I can manage without it.

Thanks again.

And more:

I know this may be asking for too much, but if I can't get it to work,
would you be willing to flash my AutoStar for me and test to see if that
resolves my issues?  I will pay for roundtrip shipping.  I'm almost
beginning to think it could be an issue with my usb/serial combo that is
causing my errors, I don't know, just trying to exhaust all
possibilities before I buy a new handset & see if that works.

And:

That's ok, I wish I could find an old machine with a serial port on it
so i can just connect directly without any usb, etc...and flash that
way.

The adapter I purchased was one off of Ebay, I'm thinking that is what
may be the problem...I don't think it is a Keyspan adapter....doh!!!

And:

Lesson learned.

And an update:

It looks like the adapter was the problem after all!  I was able to
borrow a "prolific usb to serial" adapter from work and I reinstalled
the drivers and everything patched through correctly using StarPatch. 
My LNT is working again and no more proc 2!!!  Hooray!  Thanks again for
your trouble shooting help. :)

Gabe

Subject:	One more question
Sent:	Friday, March 9, 2012 11:00:58
From:	John Colby (balder29456@yahoo.com)
I was on the site but couldn't find an answer. When I go to an object I
have to hunt a moment, when I find the object, the scope will
immediately move away from the object. Is there a way to stop this?

Subject:	etx 80 polar alignment
Sent:	Thursday, March 8, 2012 21:56:07
From:	John Colby (balder29456@yahoo.com)
I had an ETX-70 and was able to polar align it. Now I got an ETX-80 and
it does not give me the option to polar align in the autostar
controller, not sure what version it is, should I upgrade controllers?

Subject:	Re: Autostar 497ep safe mode question
Sent:	Thursday, March 8, 2012 16:06:04
From:	Andrew Johansen (johansea@optusnet.com.au)
Gday Peter

> Furthermore I discovered that if i hold a bright incandescant bulb in a 
> certain position I can
> stop the motor running ot of control and return it to a more normal 
> tracking type speed.

That does indicate a calibration error ( for whatever reason  ).
When assembled, the encoder needs to be shielded from all light
when it gets calibrated, to avoid this problem.

> This would suggest that the receiver is OK but bit the led isn't. I have 
> found a source for a
> suitable replacement led   - however I have failed to detect any 
> significant voltage across
> the led pins.

IIRC, there was a post on this LED/Detector unit on the Yahoo Roboscope 
group
recently ( along with others test results with LXD75 cards )

> I cannot find a circuit diagram for this pcb (or for any other part of the 
> mount for that
> matter).

I have a very rough hand scrawled diag for a card i once traced,
but its not really user readable :-)

> Do you know where the led derives its power from? and whether that is 
> continuous power or
> variable, switched, pulsed etc.

That bit is easy
The +ve side of the led and detector are fed directly from the 5V rail.
The detector ground goes straight to ground.
The A and B encoder lines from the detector go to pins 2 and 3 on the PIC.
The -ve side of the LED actually goes to pins 23 .. 28 of the PIC,
via 6 paralleled resistors of varying value ( R9-R12 on my board)
When the system calibrates, it effectively runs an algorithm that sinks 
these
resistors to ground in "sets". Ie it simulates a Digital to Analogue 
converter
to adjust the current going through the LED itself.
It does this to find the best setting that gives a clean square wave on the
detector.

> Or do you have any other ideas?

Try the roboscope site,
http://tech.groups.yahoo.com/group/RoboScope/message/13545
It was a Honeywell HLC2701 detector
and SEP8506 or SEP8706 Leds

Andrew 

And:

From:	Andrew Johansen (johansea@optusnet.com.au)
Andrew
Thanks again for the response.
I was reading 5V on either side of the IR led, so I shunted the negative
side to earth via an 
820 Ohm resistor and achieved IR illumination!

After re-assembling the drive I have RA tracking and the right hand
arrow buttun works 
properly as do the dec drive buttons, but the left hand arrow button
merely stops the 
tracking and fails to move the motor at all.

This is a huge step forward thanks to you -  but I suspect that the PIC
has lost its 
programming and although I have the hardware to program PICs I don't
have the dexterity 
to to remove a soldered one or for that matter the correct binary.

I suspect that I will have to send it to meade, who will take it in and
fix it, but will not send 
me individual components.

Thank you very much for your help, I've learned a lot

Cheers
Peter

And:

Thanks very much Mike for facilitating this exchange
Cheers
Peter

Thanks Andrew.

And more:

> I was reading 5V on either side of the IR led, so I shunted the negative 
> side to earth via an
> 820 Ohm resistor and achieved IR illumination!

Top stuff, it lives.

> After re-assembling the drive I have RA tracking and the right hand arrow 
> buttun works
> properly as do the dec drive buttons, but the left hand arrow button 
> merely stops the
> tracking and fails to move the motor at all.

This is sounding more and more like a dud mosfet channel.

What handbox speeds did you try ????
Ie if the scope is tracking, then the PIC itself has to be working ( in 
part )
as the motor speed is controlled by a closed loop feedback from the encoder.
If it isn't registering moves, it will declare a "Motor Fault".
If you can slew in RA and or DEC ( on the axes that work )
you should see the RA/DEC ( or AltAz ) display change on the handbox 
display.
If they change as you slew, then the encoders are at least working.

> This is a huge step forward thanks to you -  but I suspect that the PIC 
> has lost its
> programming and although I have the hardware to program PICs I don't have 
> the dexterity
> to to remove a soldered one or for that matter the correct binary.

The motor PICs are programmed and "protected", hence you cannot reprogram it 
anyway,
as noone i know of has access to the assembler hex files.
However,
As per above, the fact it tracks in one direction indicates that the PIC 
itself may be OK.
It may be a failed channel in one of the HBridge mosfets
as that is the classic way for these boards to fail.
Have you checked the P and Nchannel mosfets for shorts ????
Look for little pimples in the surface of the PChannel mosfet as that is the 
normal one to go.
That may explain it also.

Andrew

And more:

Hi Andrew

Thanks again for your response - so I'm not giving up just yet!

>What handbox speeds did you try ????
On the axes that work - all speeds seem to work OK.

>If you can slew in RA and or DEC ( on the axes that work )
>you should see the RA/DEC ( or AltAz ) display change on the handbox
>display
I'm not finding a display on the handbox that shows this - could be that this is not displaying  
- or more likely that my ignorance of navigating the handbox means that i've failed to find 
the correct display.
If I ask it to "goto" a star then the dec axis at least seems to move and then stop so I'm 
guessing that it thinks it knows where it is.

>Have you checked the P and Nchannel mosfets for shorts ????
>Look for little pimples in the surface of the PChannel mosfet as that
>is the normal one to go

Both mosfet cases seem completely undamaged to my untrained eye.
I am seeing shorts between pins 1 and 3 (S1 and S2), pins 5 and 6 (both shown as D2) and 
between pins 7 and 8 (both shown as D1).
This result is the same for both mosfets ( the pinouts are identical) and as one seems to be 
working ok I'm thinking the mosfets may well be OK.

I was unable to extract the schematic from the roboscope link that you sent me, but I have 
just found a bmp file that may be the right one so I have attached it.  The PIC on my board 
is a 16c628 but so far i am struggling to find a pinout for it.

Regret time constraints have meant that progress has been a bit limited today, but I would 
be grateful for any thoughts.

Cheers
Peter

And:

Thank you Mike that worked perfectly - and yes the RA/DEC displays do both change on the 
handbox as the mount moves.

Cheers
Peter

And:

> Both mosfet cases seem completely undamaged to my untrained eye.
> I am seeing shorts between pins 1 and 3 (S1 and S2), pins 5 and 6 (both 
> shown as D2) and
> between pins 7 and 8 (both shown as D1).

S1 and S2 are 12V on the PChannel and ground on the NChannel so thats 
expected when fitted.
D1 and D2 are paralleled outputs for each channel, so on each chip they 
should be joined.
However for a Hbridge to work properly, one side of the P and N channel 
units
must work correctly for one direction and the other channels must work for 
reverse.
Thus in those two chips, you effectively have 4 switches.
Only one needs to be dead to prevent one direction from working.
So we need to see if the mosfet itself has a dead channel or otherwise
the feed supply to trigger the mosfet may be dead.
I will try and make my trace acceptable and scan it, but that may take
a day.
At least it looks like the encoder itself is working tho.

> The PIC on my board
> is a 16c628 but so far i am struggling to find a pinout for it.

Thats cos its a 16C62B ( or at least it was on my board )
and i found a datasheet that matched the pinouts.
Looking at my walkies
Pins 21 and 22 on the PIC are used to "preload" the HBridge direction.
The PChannel is always turned on for raw supply
The NChannel is fed via a buffered PWM from Pin 13.
Ie Pin13 feeds into U4 ( quad AND gate ) and merges with
the data from pin 21/22
The output of the ANDing then feeds the relevant Mosfet.
Thus the pwm drive energy comes from the AND gate.

Andrew

And this:

Andrew
Once again I have to thank you for your considerable time and effort
on this.

I have what I hope is more progress to report.
When I check the voltages on the PIC side of R1 and R7 (pins 21 and 22) they vary out of 
sync between 0  and 5V as the left and right buttons on the handset are pushed, which I 
believe is correct.
However when I check the transistor side of R1 and R7 then R7 is the same as the PIC side 
i.e. 0v and 5v, and R1 varies between 0v and 0.7v.
Now R1 is connected to Q3 which in turn is connected to G1 of the P channel and the 
voltage on g1 varies between 0v and 12v in sympathy with PIC pin21.
But the R7 side (connected via q6 to g2 on the P channel) has no effect on g2 which 
remains at 12v throughout as if q6 is failing to pull down R6.

I am therefore strongly suspecting q6 as being OC. Do you agree?

Unfortunately I have no idea whether q6 is a transistor a mosfet or something else, have 
you any suggestion as to what might be a suitable replacement?

The other worrying factor is that I cannot see how this might account for the failure of the IR 
led to light without my shunt.

Incidentally G2 of the Pchannel (4947) is the only one of the four gates of the H bridge that 
doesn,t vary as the left and right arrow butons are pressed.

I hope that you can make sense of this and would as ever be grateful for your comments

Cheers
Peter

And:

>> When I check the voltages on the PIC side of R1 and R7 (pins 21 and 22) 
>> they vary out of
>> sync between 0  and 5V as the left and right buttons on the handset are 
>> pushed, which I
>> believe is correct.
>
> Yep, and it indicates that part of the PIC is working ( which is good )
>
>> However when I check the transistor side of R1 and R7
>> then R7 is the same as the PIC side i.e. 0v and 5v,
>
> Thats bad.
>
>> and R1 varies between 0v and 0.7v.
>
> Thats good. Ie when energised the resistor only limits the current to the
> transistor gate, and there should be about a diode drop across the gate
> so it should show about 0.7v as noted when the PIC is at 5V
>
>> Now R1 is connected to Q3 which in turn is connected to G1 of the P 
>> channel and the
>> voltage on g1 varies between 0v and 12v in sympathy with PIC pin21.
>
> Good.
>
>> But the R7 side (connected via q6 to g2 on the P channel) has no effect 
>> on g2 which
>> remains at 12v throughout as if q6 is failing to pull down R6.
>> I am therefore strongly suspecting q6 as being OC. Do you agree?
>
> Yep. Fully concur here. The lack of the forward voltage drop from gate to 
> ground
> indicates something bad has happened.
>
>> Unfortunately I have no idea whether q6 is a transistor a mosfet or 
>> something else, have
>> you any suggestion as to what might be a suitable replacement?
>
> It will 99% sure be an Ntype transistor and actual specs shouldnt be too 
> critcal
> as it is only operating as an ON/OFF switch. Ie it doesnt do any pwm
> hence doesnt require any great speed.
>
>> The other worrying factor is that I cannot see how this might account
>> for the failure of the IR  led to light without my shunt.
>
> You have said that slewing in one direction works
> hence i do suspect your encoder is OK.
> The LED doesnt need much light to actually work properly,
> so it may be too dim to see at the voltage where it works.
> You could always test the voltage between the led
> and the resistor feed to see if its something different than 5V or zero.
> Ie if it is, then you are getting feed through it.
>
>> Incidentally G2 of the Pchannel (4947) is the only one of the four gates 
>> of the H bridge that
>> doesn,t vary as the left and right arrow butons are pressed.
>
> That is to be expected. Ie refer to the truth table on the motor diag i 
> sent.
> It shows 12, 0 and F ie when the PIC pins are set as defined,
> it should be 12V, 0=ground, or Floating.
> What you see is perfectly correct for the case where Q6 has died
> What you can do ( if you have a spare pair of hands ) is
> set the Hbx to say speed 5 and then press the slew key to
> start it on the "non working" direction
> Now use a shunt to short the join between ( Q6,R6, PCh G2 )  to ground
> If the motor now runs/behaves correctly, its Q6.
>
>> I hope that you can make sense of this
>
> Perfect sense, Good analysis and testing
>
> Andrew 

And this:

> I replaced q6 with a BC547 from the junk box
> and I immediately had full control of the mount.

Excellent

> WhenI disconnected the shunt for the IR led however I was left again with 
> RA runaway, but
> this time when I did "calibrate motors" both motors moved and I once again 
> had a mount in
> full working condition.
>
> I suspect that when the calibrate motor command was originally unable to 
> move the RA
> motor at all, it left maximum resistance in the RA IR led line effectivly 
> switching the IR led
> off.

Sounds correct. If you had our patches loaded on your handbox
you could have used my PEC Editor to actually read out what value was stored 
in EEProm.
Each motors value is stored as a byte, and is sent to the motor cards on 
each boot
( vs be stored on the motorcard PIC ), so can be read out/modified as 
required.

> When subsequently calibrate motors was able to move both motors it was 
> able to
> calibrate the led strength correctly.

Another option was reset then calibrate motors.
This also resets the EEProm and runs the calibrations, but you lose drive 
train data etc
so reset is a last resort

After rereading this last bit i wrote as a test method for Q6,
i must put in a disclaimer for anyone else who reads it.

> What you can do ( if you have a spare pair of hands ) is
> set the Hbx to say speed 5 and then press the slew key to
> start it on the "non working" direction
> Now use a shunt to short the join between ( Q6,R6, PCh G2 )  to
> ground
> If the motor now runs/behaves correctly, its Q6.

WARNING
Doing the shunt MUST be a short "manual" make break shunt whilst the button 
is depressed.
Under NO circumstances should it be a fixed shunt, and under no 
circumstances
must it be done whilst the opposite slew button is used.
Doing so can result in a direct short of the mosfets, with magic smoke.

Andrew 

Subject:	Autostar 497ep safe mode question
Sent:	Wednesday, March 7, 2012 04:21:03
From:	crid@blueyonder.co.uk (crid@blueyonder.co.uk)
I recently bought an lxd75 mount. It is in very good condition but is
out of warranty.

It came with an Autostar 497ep which was loaded with 5CE2 and which I
subsequently flashed to patched 5ce1.

I have been very pleased with it - until this last weekend when I
managed to bring the two motor boxes together.
It was dark (of course) and the motor boxes are black and the first
indication I had of the problem was when the autostar controller (497ep)
rebooted
itself (presumably because the stress on the motor caused the battery
voltage to drop).

When I got the mount back inside the house I performed a "calibrate
motors" and the RA motor immediately began to run out of control - and
has done so ever since whenever the power is switched on. It can only be
stopped by switching the "target" to "terrestrial".

I immediately suspected the autostar controller but have tried resetting
it and reflashing the software to no avail.

I read somewhere on these pages that 5CE2 no longer allows the "safe
mode" ultility but assumed that a successful flash to 5ce1 would
re-introduce it, however when I press the keys to go into safe mode the
handset shows "Download mode Bootloader v2.3b" - is this the correct
response?

I have also tried reset on the handset and reset from software. Both
reset the handset but I am still left with RA runaway!

I have taken the RA motor box to pieces and examined the contents. The
pc boards seem pristine with no sign of overheating or damage to
components, pcb tracks, the encoder wheel or anything else.
I have tested the 497ep cable for continuity and shorts and all seems
OK.

Can anyone help please

Peter
Blackpool
UK

And:

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

>> When I got the mount back inside the house I performed a "calibrate 
>> motors"
>> and the RA motor immediately began to run out of control -

If it wont calibrate ( even after a reset ) then that normally indicates 
that there
may be something wrong with the encoder or its feedback loop.

>> I read somewhere on these pages that 5CE2
>> no longer allows the "safe mode" ultility but assumed
>> that a successful flash to 5ce1 would re-introduce it,
>> however when I press the keys to go into safe mode
>> the handset shows "Download mode Bootloader v2.3b" -
>> is this the correct response?

Yes, that is safeload mode.
The 497EP and Audiostars DO have a safeload mode.
The problem comes from the fact that it is not "protected".
Ie in the 497s and ASIIs, the safeload code is factory loaded
and neither standard nor safeload updates ever touch it again.
In the 497EPs and Audiostars, the safeload code gets erased and rewritten
EVERY TIME you do an update.
Thus, if anything goes wrong during the erase/rewrite of this specific bit
of the firmware, then the Hbx is dead.

>> I have taken the RA motor box to pieces and examined the contents.
>> The pc boards seem pristine with no sign of overheating or damage to 
>> components,
>> pcb tracks, the encoder wheel or anything else.
>> I have tested the 497ep cable for continuity and shorts and all seems OK.

The encoder leds are infrared, you can try looking at the led with a webcam 
etc
as they will show if the led is on.
Also, if you have access to a CRO, you could try to see if there is a
steady pulsetrain coming from the encoder led.

Andrew 

And:

Andrew

Thank you very much  for a comprehensive, informative and useful
response.

Firstly I don't have access to an oscilloscope, however a webcam with
The IR filter removed 
failed to detect any difference from the IR led wheter the unit was
switched on or not.
Furthermore I discovered that if i hold a bright incandescant bulb in a
certain position I can 
stop the motor running ot of control and return it to a more normal
tracking type speed.

This would suggest that the receiver is OK but bit the led isn't. I have
found a source for a 
suitable replacement led   - however I have failed to detect any
significant voltage across 
the led pins.

I cannot find a circuit diagram for this pcb (or for any other part of
the mount for that 
matter).

Do you know where the led derives its power from? and whether that is
continuous power or 
variable, switched, pulsed etc.

Or do you have any other ideas?

Thanks again for your help

Peter

Subject:	Meade LXD75 - any info on the internal protocol?
Sent:	Friday, March 2, 2012 11:31:57
From:	Steve Hobley (stephen@stephenhobley.com)
This is Steve Hobley from the Astronomy Forum. 

I recently had the controller on my LXD75 go bad, and I'm investigating
the option of building my own interface. 
In an attempt to assess whether the internal PIC-based axis controllers
are still usable I was wondering if you have any information on the
internal protocol used by the handbox when talking to the axes. 
I'm assuming this is probably a serial protocol too. If not then I'll
have to tap into the encoder output and roll my own.

I looked at some of the articles you have on your site, but did not see
anything pertaining to the internal comms.

Steve

-- 
www.stephenhobley.com/blog
www.youtube.com/shobley
For all your laser harp, tesla coil, and killer robot needs...

And:

O.M.Gosh - that's great thanks - found the patent and it does seem to
cover a lot of the internals.

Steve 

And more:

Yeah, the design is... ...interesting.

Not how I thought it was.

Steve

Subject:	Meade Autostar #494 on ETX-125EC ?
Sent:	Thursday, March 1, 2012 18:13:35
From:	Dieter Van de Walle (dietervdw@gmail.com)
After searching quite a bit on the internet and specifically your site,
I haven't exactly found the information I am looking for.

I was wondering if it is possible to use a Meade Autostar #494
controller with an ETX-125 telescope?

The #497 is mentioned everywhere, but I don't find any reference stating
this is not possible...

I suspect if anyone knows this, you are probably the right person to
ask.

Great site! I am just getting started with astronomy, and feel
stimulated by your passion!

Best regards,

Dieter Van de Walle

Ghent, Belgium

And:

Thanks for the swift reply!

Too bad, I was hoping maybe there was a way to make the #494 work with
the ETX-125 anyway.
I can buy the #497 new for 190, but that's quite a hefty price for what
it does ...

Maybe there is a way to control the ETX-125 using a computer and just
and a correct adapter cable?

Thanks for the advice!

Best regards,

Dieter

Subject:	Proc Trap 2
Sent:	Thursday, March 1, 2012 08:01:48
From:	Jose Luis Gonzalez (jose.luis@brilloestelar.com)
I own a Meade DS  mount, just turned on it and after the initialization,
the display of handbox shows: Proc Trap 2.
Please, can you help me?
 
Thanks in advance
Jose Luis Gonzalez
Spain

And:

OK, Mike.

Thanks
JL,

Feedback Archive

Check the Feedback Archive for previous editions of the User Feedback pages.

Go to the ETX Home Page.