AUTOSTAR INFORMATION Last updated: 11 February 2005

AutostarX Autostar Updater for Mac OS X

27 Dec 04
I tried out the AutostarX Autostar Updater from Rodolphe Pineau (pineau@rti-zone.org). It is a simple application that can be used to apply Autostar #497 ROM files to an Autostar #497. You will need a #505 serial cable and a serial to USB converter. I used my PowerBook 17" 1GHz laptop running Mac OS X 10.3.7 and the Keyspan Twin-Serial adapter with driver 1.8. The laptop was running on battery with the performance setting at "reduced".

I launched the application; this window appears:

I clicked the "Connect" button and see that the application successfully communicated with the Autostar:

It correctly showed version 3.1Ee on the Autostar connected to my ETX-125.

I then selected the 3.3Ef ROM build file (previously downloaded from Meade's Autostar update page, http://www.meade.com/support/auto.html):

I clicked the "Disconnect" button; the Autostar RESET. That surprised me as I hadn't actually done any download yet.

I started over and this time clicked the "Flash" button. The Autostar displayed the normal "Downloading Do not turn off." message. The application displayed page X/30 while downloading where X is the page #. It got up to page 4/30 and reported a communication error after about six minutes. An alert displayed information to go into SAFE LOAD mode and try again. So I did that and got a FLASH LOAD 3.0 READY message on the Autostar. When I connected the application it showed ROM 2.0a (instead of 3.1Ee).

After 41 minutes the application finished downloading the ROM file to the Autostar. But it was not obvious what to do next; Autostar still displayed its downloading message. So, I clicked Disconnect and just like before, the Autostar reset. All seemed OK at this point. I reconnected and the application showed:

The Autostar also shows 3.3Ef. I did a Calibrate, rough drive training, and a test align (it was raining outside). The Autostar picked Arcturus and it slewed the ETX counterclockwise to the hard stop. The altitude slew seemed correct. Something is wrong.

I checked that all settings were OK (date, time, location, telescope, mount). So I tried again. Same problem. I tried once more. I skipped Arcturus and used the 2nd star picked, Altair; this time it slewed clockwise to the hard stop. Altitude seemed correct.

At this point the Autostar is unusable. I have contacted the author and Dick Seymour to see what they suggest.

Until we determine what is wrong, I recommend that Mac OS X users be cautious when trying out this application and have an alternative mode to update the Autostar (which may or may not work). If anyone has successfully updated their Autostar using AutostarX, let me know.

The author replied:

Sent:	Monday, December 27, 2004 17:09:46
From:	Rodolphe Pineau (pineau@rti-zone.org)
Strange behavior
At least the safe load works (i tried it myslef about 40 to 45 times
during development) but I never experienced any actual error during the
flashing unless unplugging the power on purpose to test my error
management.

Once the upgrade is finished I'm not reseting the autostar automatically
but it's something I can add. Disconnecting does it as I'm sending the I
command before disconnecting.

41 minutes seems a little bit long.. I'll see if I can optimize that. I
never actualy tried the 33Ef version on my lxd55 (I'm running 32Ei on my
main autostar).

One last thing.. when reflashing the autostar you need a really stable
and good power supply (which I guess you have regarding your long
experience of the autostar).

Thanks for the feedback.... I'll try to do some test with my mount as
soon as the weather will let me go out.

Rodolphe

I might have located a bug.
I'm doing a test flash and let you know asap.
If I'm right some data could be corrupted on slow machine due to a typo
in a variable (if the low level serial routine wasn't writing all the
data at once, I have loop that continue where it was but I was using the
wrong variable to mark the current position and it might have been off
by up to 64 bytes).

I'm also taking a measure of the time needed to flash on my machine
(Dual G4 1.25GHz MDD).

If this is confirme I'll release a new version this evening (with a few
optimizations and the automatic reset added).
Rodolphe

I also have a 17" G4 1GHz powerbook on which I did a lot of testing so I
don't think your error on page 4 is related to computer speed as I never
had this error.
Rodolphe

From:	Richard Seymour (rseymour@wolfenet.com)
For what it's worth, the Meade Updater takes about 35 minutes,
StarPatch (free) takes 18 minutes, (it does 1/2 at "full" speed,
 then slows down to "Meade Speed" for the 2nd half)
StarPatch (registered) takes two minutes (or less, depending 
 upon previous versions)

Rodolphe: you might add a "Verify" option to allow read-checking
the download.  As long as you're still in control you might be
able to rescue the user from a momentary loss of communication.

Simply re-erase the page that lost contact, and restart the 
uploading there.

have fun
--dick

I will add the verify option latter (next version)
I trigger the "lost communication" error when I'm not receiving the 'Y'
from the autostar which mean it probably still wait for some data, I'll
see if I can come up with a good way of recovering from that (i have one
or two idea on how to do it).

With the 2 latest modifications I did  after Mikes problems report (one
being most probably the cause of the problem Mike had as it might have
corrupted some data) I'm now down to 23 minutes for a full upgrade (from
41 minutes).

I'm finishing a few test and will release this version this evening and
start working on a version with "communication error" recovery.

Thanks to both of you for your help and comments.

Rodolphe

If you send "xFF" until you receive a "Y" (or exceed your last
total byte count), you will have left the FlashRam in a still-writable
state.  So you can check and resume your writing in that 64-byte area.

>With the 2 latest modifications I did  after Mikes problems report (one
>being most probably the cause of the problem Mike had as it might have
>corrupted some data)
>I'm now down to 23 minutes for a full upgrade (from 41 minutes).

Much better...

have fun
--dick

31 Dec 04

Subject:	AutoStarX V1.1
Sent:	Tuesday, December 28, 2004 01:08:23
From:	Rodolphe Pineau (pineau@rti-zone.org)
I just released the version 1.1 so Mike if you have some time to test it
to see if it fixes your problem..

I added the automatic reset of the autostar at the end (in addition to
the bug fixes and the optimization).

Thank you both for all your help, I'll add a credit section to the about
box for next release and I'll put you in.

Regards, Rodolphe

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
| Coldfire Robot / Unix / Atari / Astronomy |

Mike here: Good news! With a caveat.

Version 1.1 took 33 minutes to load normally. No errors. I did notice that either pages 5 and 6 were skipped or they were so small the display didn't update. There was a "soft" reset at the end of the load. I did an Easy Align; Arcturus again and it slewed to the hard stop. Hum...

I did a manual RESET from the Autostar menu. That reset to all the factory defaults. I went through the normal "first use" steps, including picking my location by zipcode (which is new); (not very accurate however). This time the Autostar picked Capella and Rigel as alignment stars, and it slewed OK to both. I then did a GOTO Saturn; it slewed OK. (these tests were indoors, it is still raining)

The fix seems to be the need for a manual "hard" RESET. Maybe that was all I needed to do with version 1.0. But version 1.1 is much improved over 1.0 and I feel safe recommending that Mac OS X users consider it, at least for ETX owners (see the 31 December update below).

Many thanks to Rodolphe for developing this much needed application for all the Autostar Mac OS X users out there!

Here's some feedback:

Subject:	Re: AutoStarX V1.1
Sent:	Tuesday, December 28, 2004 10:37:11
From:	Rodolphe Pineau (pineau@rti-zone.org)
That's a good news.
The hard reset might be needed if you go from 32xx to 33xx (Dick ?)

Thanks for the quick feedback.

Have a good day.
Rodolphe

PS: iChatAV ID : 15872347 (ICQ id that works with AOL as they both use
the same servers.)

From:	Richard Seymour (rseymour@wolfenet.com)
Pages 5 and 6  (hmm... that should be 6 and 7) are where the
User Objects are stored... so the firmware Update doesn't
write to them.

(5 + 6 vs 6+ 7 varies with how Rodolphe speaks to the user
("the 5th page") vs how the Autostar likes its pages numbered.)
During a firmware update, the first page transferred is actually
the 3rd in the Autostar's addressing scheme (but is internally
addressed as "2").   

Got that?  There'll be a quiz...

I don't remember a reset being needed between 32xx and 33xx.

But i may have performed one for other reasons (i bounce
up and down between versions when testing things... i -try-
to avoid resets just to see what'll break...) 

Rodolphe: what is your algorithm for the writing?
(the choices i could think of are: "don't write any xFF's",
or "write all data as 64-byte blocks, skip any which are all xFF"
or  "write all data as 64-byte blocks, don't skip any".
Associated with that question is what you do if you are writing
variable block sizes, and what happens if you overwrite the 
parameter EEPROM 

have fun
--dick

as page 0 and 1 aren't to be flashed I didn't want to start the counting
at 2 so just for a display matter pages are off by 2 but starting at 1
instead of 0.. so the actual page 6 & 7 are page 5&6 in the display and
I don't write them are the file is all $FF for those 2 pages which
explain that the program pass on them realy quickly.

I'm not sure my explanation was really clear.. so :
autostar  : 0 1 2 3 4 5 6 7 ...
AutoStarX : - - 1 2 3 4 5 6 ...

so Dick guessed this right :-)

the algo is:

- I'm testing to see if the double page is all $FF
- if yes.. don't erase and go to the next double page

- otherwize, erase double page

then for each page (2 per double page):
- take 64 bytes of data
- test if we're in the eeprom range, if yes go to next 64 bytes block
- test if they are all $ff, if yes, go to next 64 bytes block
- otherwize flash 64 bytes, wait for "Y" from the autostar, go to next 64 byte block
   ->it should be ok if there are a few $FF in the 64 byte block.

repeat that for all double page.

I'm never writing anything in the eeprom as I'm testing if my address is
within the range of the eeprom addresses

Regards, Rodolphe

Mike here: Now some bad news.

I tried to update my LXD55-8"SC Autostar #497 to 3.3Ef using the AutostarX version 1.1 application. The LXD Autostar also had 3.1Ee. The laptop was running on battery with the performance setting at "highest", unlike what it was for the ETX update.

First attempt: I selected the 3.3Ef build file. I clicked the "Connect" button and it successfully connected. But the Autostar display blanked when I clicked the "Flash" button on the application and a communication error alert appeared in the application. It said to use Flash Load mode. The Autostar clicked a few times. I powered off the LXD and powered it back up, and again the Autostar clicked a few times and the display was blank. So I powered up in FLASH LOAD mode; the display showed "FLASH LOAD 2.0 READY." Started the flash load from AutostarX and got the same communication error. I tried one more time, this time quitting and relaunching AutostarX. Same problem.

I then launched Virtual PC 6.1.1 with Windows 2000 and used the Meade Autostar Updater application 3.61 to update the Autostar to 3.3Ef. It took 21 minutes for the Meade app to successfully bring the LXD Autostar back to life.

So, while AutostarX 1.1 seemed to work OK with the ETX, for some reason it had a problem with the LXD55. Stay tuned.

Again, if any Mac OS X user has tried AutostarX, I welcome your comments.

And from the developer:

That's extremly strange.
I never had this behaviour with any of my autostar.
It looks like the autostar isn't writing the data where it should and
most probably write them in the register area ($0000-$003F) instead of
writing them in flash ($8000-$FFFF).
I'm going to check my code again to be sure I'm not doing something
wrong but there is clearly something wrong.

Unfortunatly I can't reproduce the error here so it's not easy for me to
debug this.

Richard, any idea ?

Rodolphe

The autostar prevents you from writing on page 0 and 1 where the safe load code is located.
I'm checking my code right now and don't see anything wrong.
I'm doing so debuging and cleaning (rewriting some parts in a better way).
I'll make a new version just for you today and I'll send you the url to download it if you have time to try it.

Rodolphe

From:	Richard Seymour (rseymour@wolfenet.com)
I'm a little surprised by the "instant black screen".

Even if the Autostar crashed (writing to ram instead of FlashRam),
the -display module- should remain showing/doing whatever
it was last doing.  (the "lamps on" is handled by a  PIC chip,
the module has its own two-line memory).
Of course a "reset" signal could maybe clear things, but i
don't think the mc68hc11 has access to such an output wire.

have fun
--dick

I agree with Dick, this is a really strange
Even if my code by misstake (As everybody, I can write code with bugs)
write in the register or RAM, it shouldn't "blank" the screen.
At most the screen should remain the same and the autostar itself would
reply to any serial command.
the clicking seems also strange.

I'm doing more cleaning in my code and re-re-re-checking everything
If needed I can send my code.

Rodolphe

And:

I did 3 upgardes in a row (33Ef->32Ei->33Ef-->32Ei) with no errors.
The eeprom is still having my old setings (telescope type, mount, focal
length, ...) so I can say it's not writing to the eeprom (i did the
whole tests in debug mode displaying all the addresses I'm writing to or
skiiping).

As I did some cleanup in the code I'll put a new version online in ~ 21
minutes (time to test the release version) and you can download it.

Rodolphe

And this:

I did more tries (3 more since this new version)

Even if I disconnect the power during the upgrade (I have the
communication error) and restart the autostar in safe load, I can
reflash it right away without any problems.

I really would like to find what's going on, specially if the meade ASU
is able to flash it. If it was a bug I will have it here too (I'm not
ruling out a bug..).. but unfortunately  I can't reproduce your problem.

I'm going to think about it and recheck my code again.. Dick, any idea ?

Rodolphe

And:

What does AutoStarX display in the "Unit Version" field ?
I'm using the value returned by the autostar ($0F for a 497, $0A for a
495) and i have to admit I just display "other" if it's not one of
those.

And (mea culpa, mea maxima culpa) I don't check the type when trying to
flash... so if it's not a 495 or 497... this might be the source of the
problem. I don't know any other type than 494 or autostar II
I should definitely check the type before flashing rather than just
display it as an info.

Rodolphe

And this from Dick Seymour:

I would suspect that it's partly due to the Mac and USB->Serial
Mike's using... you could be sending characters too quickly for
the Autostar to process (it's limited to about 900 char/sec at
best).  You only have to have it mix up a page or memory address
(or lose a character), and things go bad immediately.

In the Windows world, it's possible to turn off all buffering
and FIFOing for the serial port, so that all accelleration is
turned off.  This frequently solves Updater issues on too-fast PC's.

Is there an equivalent for the MAc world?

If memory serves, Mike's using a Keyspan USB->Serial.
In our uses of them at work, the Keyspan is by far the best for
Macintosh usage.
All other brands cause issues somewhere in the mix of missions
we assign to them.  The Keyspan just works and works and works.

But i've never tried doing Autostar Updates with them.

There's enough variation between the various Mac models
that i wouldn't rule out a platform difference too...
If Rudolphe could duplicate Mike's setup, or Mike could
duplicate Rudolphe's, i'd be a lot happier... i suspect
that a duplicate-Rudolphe's would work, and that a dupe-Mike's
might not.

If Mike simply had -another- Mac he could test wirh,
that might shed light...

good luck
--dick

And:

I don't think I'm sending more than that.. 9600 bauds is going to be 960
char/sec at best. I did tests on both my dual G4 1.25GHz and ny
powerebook G4 1GHz and I didn't have any of the issues Mike has (which
doesn't mean there is no bug in my soft). I did a long test this
afternoon, printing all the pages and addresses I'm writing to as well
as the addess in the page I'm reading the data from. all the addresses
were ok and the read address correspond to the writen ones.

I'm also using only keyspan product (USA19QW (1 serial 230Kbps) and 
USA49W (4 serial 230Kbps))

here are my 2 configs known to work :

PowerBook G4 17" 1GHz, 1GB of Ram + keyspan USA19QW
Dual G4 MDD 1.25 GHz, 2GB of Ram + keyspan USA49W

I just did a test on a friends iBook G4 1GHz with my keyspan USA19QW ..
no problem.
AutoStarX flashed the autostar without any error
On reset the autostar still had all my settings (i.e.  eeprom wasn't
touched duriing the flashing).

Let me know what are your result Mike.

Rodolphe

And:

I put the 1.1b as the main version as the download on my website.
This version has been working for me and not for you.
The only difference between our configuration (besides the computers) is
the keyspan adapter, you use the twin adapter and I use the regular
rs232 ones. It would be good to have more user reports for each adapter
(and possibly other ones like sone using the FTDI chips).

I've check the keyspan twin serial adapter and it's in fact a RS422
adapter (old mac style). I know that it ca be used as a serial adapter
but could it be the cause for the problem you're having ?!

I'm only using plain RS232 adapters.

Thanks again to both for your help.

Rodolphe

If there are Mac OS X users who are willing to test out the AutostarX application, we would like to get more user feedback, both positive and negative. Please download the software at http://www.rti-zone.org/macosx_autostarx.php and try it out for updating your Autostar #495 or #497. Report your results and your configuration (Macintosh model, OS version, USB-serial converter model) to both me (etx@me.com) and Rodolphe Pineau (pineau@rti-zone.org). Many thanks.

IMPORTANT: You will need an alternative method to restore the Autostar to functionality if anything goes wrong during the update.

I will update this page with any user reports.

05 Jan 05

Subject:	Re: [LXD55telescopes] Mac OS X autostar flasher, testers and feedback needed.
Sent:	Sunday, January 2, 2005 18:53:36
From:	Robert Thompson (rtthompson@comcast.net)
Rodolphe,

Thanks for providing the updater. I tried it out last night on my LXD55
mount, and it seems to have worked just fine. I am using an imac g3 500
running Panther. The serial adapter is a iConcepts USB/serial adapter
for PDAs, part 60446.

It's nice being able to update the firmware without having to boot
Virtual PC.

Robert

Subject:	AutoStarX Testing
Sent:	Tuesday, January 4, 2005 06:25:09
From:	pst@ksu.edu (pst@ksu.edu)
I tried out the new OSX program AutoStarX
(http://www.rti-zone.org/macosx_autostarx.php) and it worked fine for
me! I used version 1.0 of AutoStarX to go from Autostar ROM 2.5 to
3.3Ef. My set-up: PowerBook (400mhz G3), OSX 10.3.6, Keyspan High Speed
USB-Serial Adapter (19QW) with the latest drivers (1.8, default
settings), Meade 505 cable, home-made power cable (Autostar NOT
connected to my ETX125). It took 40 minutes to upgrade the ROM. I then
used the "Reset" function on the Autostar. After reset, calibrate, and
selecting my location, (I did not run the "Train" function), I tested
the Autostar INDOORS by aligning and slewing to 6 or 8 star positions
(cloudy outside). It worked fine. I then tried the 1.1b version of the
AutoStarX program and re-flashed my Autostar with ROM 3.3Ef using the
same hardware as above. It took 24 minutes this time and worked fine
also after a reset, calibrate, and location set. Again, I tested the
Autostar indoors since it was too cloudy to see stars.

This is a great program and I thank the author Rodolphe Pineau
(pineau@rti-zone.org) for creating it! I have used VirtualPC with the
same hardware set-up as above and on other, newer Macs, and it rarely
works. It usually leaves my Autostar in an unusable state.

I wonder if there is any way that Rodolphe could add the DATA moving
functions to his program too? That would be outstanding since the data
need to be updated much more often than does the ROM.

THANKS RODOLPHE!!!!!
Paul

Subject:	Re: AutoStarX Testing
Sent:	Tuesday, January 4, 2005 09:23:39
From:	Rodolphe Pineau (pineau@rti-zone.org)
Thanks for this reports.
The Data moving isn't on my list (yet) but I'll have to study it and see
if it's doable.

The next step for me will be to add the possibility of patching the
autostar with Richard 'Dick' Seymour 's patches and to add support for
the Autostar II.

I don't have any description of how the user data/object are actually
stored in the autostar (I have a short description on where they are
stored but that's about it).

Subject:	Re: AutoStarX Testing
Sent:	Tuesday, January 4, 2005 23:22:32
From:	Richard Seymour (rseymour@wolfenet.com)
Rodolphe Pineau wrote:

>I don't have any description of how the user data/object are actually
>stored in the autostar (I have a short description on where they are
>stored but that's about it).

It's a mix of easy and complicated.

In the 497 Autostar, they use pages 6 & 7 to hold the user objects.
(in the Autostar II, they start at page x60 and continue for 300K)

At the start of the area, there are 3-byte headers of linked lists
for each class of object or data type.
Each 3 bytes refers to the page (one byte) and address (two bytes)
of the first item in the list.
Each list-type has records of different lengths (satellites are
51 bytes, Tours can be any length)

For the 497 Autostar (v26Ed is my latest tracing of these)
the datachains are (hex addresses)
6-8000: (ff)
6-8001: User Obj  
6-8004: landmarks  
6-8007: guided tours 
6-800a: asteroids 53 bytes
6-800d: comets    
6-8010: satellites  51 bytes
6-8013:  (00)

For the Autostar II, the data chains  (and record lengths) are:
60-8000 18.   User Flags  
60-8003 54.   Motor/State Flags
60-8006 205.  RA PEC tables
60-8009 205.  DEC PEC tables
60-800c 773.  EditUserData buffer?
60-800f 167. owner info
60-8015 41.   SiteShortList
60-8018   (25 bytes per(x19)) landmarks
60-801b   (bytes per) guided tours 
60-801e   (57. bytes per (x39)) asteroids: 
60-8021   (49 bytes per(x31)) comets: 
60-8024  (indx 3b09)   (51 bytes per) satellites: 
60-8027 37.   AzTrain,AltTrain,CalSensors
60-802a (
60-8039   (bytes per) User Obj: 

have fun
--dick

15 Jan 05

Subject:	AutostarX  problem report
Sent:	Thursday, January 13, 2005 10:37:11
From:	Donald Davenport (djdavenport@earthlink.net)
I wanted to report that I had the exactly same problem as you did when
you tried to update your LXD55 autostar.

All was well until I hit "connect" and then the Autostar when blank
(along with a few clicking noises) followed by an Communications Error
message on the computer.

Next, I tried a "safe" upload.  The Autostar flashed that it was ready
but would not communicate with the Updater and resulted in another
Communications Error prompt.

I am using the Keyspan USA-28 with the 1.8 driver.  OS 10.3.7.  Autostar
was running v.2.5 and was configured for a ETX-90.

I dropped Rodolphe a note and hopefully he might have some ideas.  At
least your experience has been independently duplicated.  Always some
comfort in that!

Best,

Don Davenport

In reviewing the discussion on the ETX site about those who have had the
crashing Autostar (Mike and I, for two) and who hasn't (everybody else),
it seems that those who have had success were using AutostarX version
1.1b along with the Keyspan USB to serial adaptor with the RS-232 ports.

Both Mike and I are using the USA-28X or USA-28 (in my case), with the
RS-422 to RS-232 adaptor.  I find it curious that initially there is
communication between the Mac and the Autostar--but crashes when it
attempts to flash.

At the very least, the model of Keyspan adapter seems to be one common
element about who gets the blank screen of death and who doesn't.

Don Davenport

From:	Rodolphe Pineau (pineau@rti-zone.org)
That was also one of my suspitions.
Now that my server is back online I hope to have more feedback and start
investigating why it fails with the USA-28x

Thanks for the feedback
Rodolphe

Subject:	Autostar updates from Mac OSX - success using AutoStarX
Sent:	Friday, January 14, 2005 15:26:16
From:	Julian Kettle (juliankettle@mac.com)
Rodolphe,   Many thanks for writing AutoStarX for Mac OSX users.

I read about AutoStarX on Mike Weasner's Mighty ETX Site.

I have been able to access AutoStarX today to download, and have just
successfully updated my ETX105 with Autostar #497 to version 33Ef.

I was using an ETX105 with an Autostar #497 on version 26Ec, it is now
on version 33Ef.

The upgrade with AutoStarX 1.1b took 24 minutes on my Powerbook G4 12"
Al 867MHz 512Mb running Mac OSX 10.3.7, with processor performance set
to highest, mains powered.

I am using a Keyspan USA19H(HighSpeed) single USB Serial adaptor with
driver 1.8 - which also works with ScopeDriver X and my ETX105.

My ETX105 appears to be working normally after the upgrade. I had to do
a dummy run due to cloud cover (Edinburgh), but the Go Tos went where I
expected them to point to.

Julian Kettle

From:	Rodolphe Pineau (pineau@rti-zone.org)
Thanks for the feedback
Rodolphe

18 Jan 05

Subject:	Re: AutostarX problems--commons
Sent:	Saturday, January 15, 2005 08:30:22
From:	Donald Davenport (djdavenport@earthlink.net)
One quick thought (and then I'll let us both get on with our lives), but
it seems you got the thing to work on one of your Autostars (the
ETX-125).  If I remember your report, it hung about page 4.  You tried
again and that time it worked.

It was only after Rodolphe cleaned up the code--resulting in 1.1b--that
it crashed your second Autostar.

Did I get the sequence right?

I'm wondering if he did something inadvertent in the 1.0 to 1.1 upgrade
that resulted in the bug?

Just a thought.

Don

27 Jan 05

Subject:	Re: Hi again problem fixed don't know how
Sent:	Wednesday, January 19, 2005 20:20:56
From:	Rodolphe Pineau (pineau@rti-zone.org)
Thanks for the feedback

Could you give me a decription of your configuration and keyspan adapter
used?

Thanks, Rodolphe

	On Jan 19, 2005, at 8:15 PM, Pops wrote:
	Downloaded 1.8 of Keyspan driver didn't fix the problem. Tried driving
	the scope with equnox5.1 scope could still be driven. Decide to update
	Autostar again and it worked. My autostar now works. Thanks for your
	program.
	
	Ray Husk

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
| Coldfire Robot / Unix / Atari / Astronomy |

Subject:	AutostarX handbox model differences?
Sent:	Wednesday, January 26, 2005 09:05:09
From:	Donald Davenport (djdavenport@earthlink.net)
I downloaded Rodolphe's newest version, but am still having no luck.

The updater still does not want to communicate with the handbox.  The
handbox reads "Flash Load Ready" but the updater times out and I get a
Read Error message.

Something you mentioned earlier caught my attention.  Of your two
handboxes, one was simply labeled "Autostar" and the other ETX Autostar
(which is like mine.)  Was there one handbox that you never got it to
work on?  And, if so, was it the "ETX Autostar."  I'm now wondering if
perhaps there is some hardware differences between the two.

Don Davenport

And:

Rodolphe--

In re-reading Mike's notes, it seems the Autostar handbox that crashed
(of the two he tried) was labeled ETX Autostar.  The other was simply
Autostar.  My unit is also  labeled "ETX Autostar."

If we assume that any (potential) problem has been eliminated with the
various models of USB-serial adapters, could it be possible, as Mike
also suspected, that there are some hardware differences between the two
units other than just the labeling?

I really can't think of any other variables.

Donald

From:	Rodolphe Pineau (pineau@rti-zone.org)
I have 2 autostar ad they are both labeled "Autostar"
As far as I know there is no physical difference between the "ETX
Autostar" and "Autostar".
Dick , any clue on this ?
Rodolphe

I agree.  It's very strange, but it's not out of the question that, if
the hand units are physically different, they might reflect different
manufacturing sites and, perhaps, some other inadvertent differences. 
Slightly different chip specs. Maybe something even Meade doesn't know
about.

If you run out of ideas, as a last resort, I can send you my Autostar,
Keyspan and cables for you to run tests on, if you're interested.

Don

From:	Richard Seymour (rseymour@wolfenet.com)
I'm not at home to look at my two, but i'm aware of three 
different variations on the theme:
anything with "ETX Autostar" on the front left Meade's factory 
programmed as a 497.
In the early years (pre-2001), the ones with "Autostar" -probably-
left the factory programmed as a 495.  Meade reprogrammed some
of those before they were sold as "497's", since folks have opened
some 497's and found the paper label identifying the older programming.
(the FlashRams had paper stickers showing the original programming).

The  label "Autostar" and "ETX Autostar" is a separate piece
of adhesive-backed plastic which can be applied to any Autostar
(one of mine keeps falling off).

I am aware of two electronically different "ETX Autostars"... 
the difference starts with the display module (the "new one"
cannot do the "splotch" graphics characters that the "old one" can).
The display cable is slightly offset, there is a rearrangement of the
voltage regulator, and one pin of the computer chip is tied to ground
to tell the firmware that the display module is different.  That's the
-only- change in firmware  operation between "new" and "old", the
"new" one doesn't try to use the graphics characters to show the 
slew speed.

Chris Carson's researches showed that some -ancient- models
have slower FlashRam... 120 nsec instead of (i don't know the
faster speed.. i don't have one to look at).  Meade's "burn the
firmware" programming keeps looping until the data are -written-,
so that shouldn't be a factor (and it works with Autostar Updater).

have fun
--dick

From:	Donald Davenport (djdavenport@earthlink.net)
I cracked the case on mine and can give you some specs on a model that
doesn't seem to want to work:

Printed on the board are:  copyright 1999    Autostar PCB Rev C  P/N 19 8002-00

The stickers on the ROM read:  ETX 13BL.ROM ver:1.3 and ETX13BH.ROM ver:1.3

Don't know if this is helpful or not.

Donald

I will open the test one I'm using and take picture so we can compare
them (and note the rev and rom version).

As some have different speed for the flash, my program actualy send the
data and then wait for the autostar to answer (with a 'Y' preferably)
before sending more data (and it timeout after 1 seconde without
answer).

So It should be same no matter what speed the flash is.

Regards, Rodolphe

And a little later: Version 1.2 - success - 23 minutes!

And:

Cool
So now we need to figure out what is Donald problems/diffrences

Rodolphe

Mike--

I *guess* I'm happy for you.

But I am also very puzzled.  I'm assuming you are doing the update from
a *functioning* Autostar.  Since mine is still crashed, my only (non-PC)
option is to try and do a safe load, which fails, even with the ver 1.2.

I've been holding off bringing it back to life by using someone's PC
because it seemed it might be helpful to keep mine crashed as kind of a
control group.  But I don't much want to be a control group of one, if
it means not having a working AS.

So, Rodolphe, if you want to play with my Autostar I'll keep it crashed
and send it to you.  Otherwise, I'll just chalk it up to the glich gods
and get the d**m thing working again.

The *only* variable now seems to be that I'm using a Keyspan USA-28 (now
discontinued).  In talking to Keyspan, they say the only difference
between the 28X (Mike's) and the 28 (mine) is that mine does not have
the built-in external clock, which seems to be necessary for some MIDI
applications and some printers.  Or so they say.

Don

And:

Cool
So now we still have a problem with donald autostar and adapter .

I'm going to redo a safe load test this evening to be sure but it does
the same thing as a regular load

Thanks to all of you for your help, feedback and borowed equipement.

Rodolphe

Ok so I just did a safe load update that worked using Don twin serial
adapter and his 505 cable

So everything worked so far for me with AutoStarX 1.2 and the twin
serial adapter.

rodolphe

31 Jan 05

Subject:	Re: AutoStarX V 1.2
Sent:	Friday, January 28, 2005 16:32:18
From:	Rodolphe Pineau (pineau@rti-zone.org)
I updated the website and put version 1.2 as the main download.
I'll update the page after my tests with Donald adapter.

Rodolphe

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
|   Robotics / Unix / Mac OS X / Astronomy  |

Subject:	Re: AutoStarX V 1.2
Sent:	Saturday, January 29, 2005 14:12:54
From:	Rodolphe Pineau (pineau@rti-zone.org)
Don, I started to test your adapter and autostar your autostar crashes
no matter which adapter I use (my USA-49WLC, my USA-19QW, your USA-28)
With my Autostar and your adapter (USA-28) it works without any
problems.

So the problems comes from your Autostar.
I'm going to reflash it using a PC and the Meade ASU and then redo all
the tests (Safe load, normal upgrade, ...)
Rodolphe

Donald Davenport wrote:

Very interesting.

The Autostar was working perfectly before the first time I ran the
program.  In fact, I had just used it just the night before.  It had ROM
ver 2.6 installed.

I wonder if the flash is so corrupt it will only be revived with Meade's
ASU.

Let me know.

Donald

I'm in the process of reflashing your autostar with ASU and it works
I think I need to change the way I handle the Safe Load. My method works
in all the case except if the eeprom contain corrupted data or if some
data the the command I send is trying to access is also corrupted.
So I can ask the status, determine that the autostar is in safe load and
not ask any other information (unit version, rom version).
This way the flash should work directly when in safe load.

Once I'm done reflashing your autostar with the ASU, I'll do tests with
AutoStarX to confirm that everything is OK.
If it works I'll send it back to you asap.

Rodolphe

The ASU reflashed your autostar.
First try with AutoStarX and it clicked and went back to black screen
then no more reply from the autostar
I'm reflashing it with the Meade ASU again.

Rodolphe

So after a few tries I still can't flash your autostar (normal and safe
load) with AutoStarX.
I did a ASU upgrade each time to restore your autostar.
usual the connect works and give me the unit type and rom version. But
as soon as I start a flash it click, black screen and it's dead (so I
reflash with ASU from the PC after that each time).
I tried with your adapter (USA-28) and both mine .. still the same so
the problem comes from the Autostar and I don't know yet what's going
on.

And an update:

I have good news
So the problem is idead related to the "slow" flash rom.
the autostar was crashing just after a double page erase if I was trying
to do anything just after (too fast).
As of now I have a new version (I'm still testing but as of now Donalds'
autostar is being updated in Safe Load by AutoStarX)
I'm doing a pause just after the page erase which gives time to the
68hc11 to finish the erase of the double page.
For an unknown reason it crashed when I was trying to read the 'Y' from
the autostar.
Dick, I think this can be related to the remark in the doc you gave me
concerning changing the read timeout, which as you I don't understand
why but it does do something to the autostar.

If the safe load currently in progress work and a few retest of normal
and safe load works I will release this version a 1.3

Mike : there was 2 problems, the one I fixed concerning the twin serial
adapter, and this one regarding "old" generation autostar (with slow
flash).

Rodolphe

From:	Richard Seymour (rseymour@wolfenet.com)
As a wild guess:

A thing to remember is that the "slow flash rom" is on -older- Autostars.
Therefore they may -also- be carrying "buggy" Flash Load programming
(since -that- code is not updated with the rest of the firmware).

That may be a contributing factor 

I'm happy to hear that you have solved it.

have fun
--dick

Donald Davenport wrote:

So, it the verdict in?

Success?

Yes success.
All work well now (I reflashed your autostar in both mode a couple of
time as well as mine, all with your twin adapter).

I'm in the process of posting the release version on my website (version
1.3).

Rodolphe

From:	Donald Davenport (djdavenport@earthlink.net)
Mike--

Thanks for all your help in getting my Autostar (with slow ROMs) invited
to the AutostarX party.  Rodolphe says it's all working and I couldn't
be happier.

I do apologize for all the posts, however.  The AutostarX thread is
starting to read like the Warren Commission.

Cheers!

Donald

And, hopefully the final update to resolve the Autostar issues:

Thanks to all the testers we now have a version 1.3 that works with the
Keyspan Twin serial adapters (USA-28X and USA-28).

The 1.3 version also fixe the problem of the "old" autostar  with slow
flash memory (in both normal upgrade mode and safe load mode).

You can grab it at http://www.rti-zone.org/macosx_autostarx.php

Rodolphe

11 Feb 05

Subject:	AutostarX report
Sent:	Saturday, February 5, 2005 20:42:14
From:	Donald Davenport (djdavenport@earthlink.net)
I guess Rodolphe is getting married tonight, so I thought I'd spare him
the banalities of yet another report.

My autostar successfully loaded ver 3.3 using ASU and my friend's PC. 
It now operates normally.

So, I can only conclude that there's still some software issues with
AutostarX and certain Autostars.  Maybe ones with older, slower ROM. 
Who knows?

But, after many, many tries using various data versions, normal and safe
uploads, I could not get it to work with my unit.  It would apparently
load successfully, but the handbox would not work.

It would be very interesting to me, in this period of beta testing, if
anyone else out there encounters a similar problem.

For now, however, I'm just thrilled to have it working.

Donald

Subject:	Autostar hang follow up
Sent:	Tuesday, February 8, 2005 12:45:35
From:	Laurence L Plate Jr (platojr@amug.org)
Confirmed Donald's Autostar hang-up on ROM 33Ef uploads via AutostarX
and I ca not use Meade updater on VPC on my G5 due to XP hating KeySpan
19QWb2P1.1 so no way to update Autostar via Meade.

Could not find earlier versions of 33E's (Mine was 33Eb).

Plato

And:

I did try to load ROM 32Ei build without success as it was the latest
build in your archive. There are no 33E builds besides 33Ef (current) in
the archives and I can not use all those idiotic Windows patch exe files
on my Macintosh systems. and VPC with XP is USELESS due to an USB quirk
in VPC/XP so I can not update my ETX 125 Autostar in this manner, I do
not have any local DIEHARD Wintel friends to resolve such things. The
next question is how to update Autostar suites without using Windows
programs. For now, my Autostar 497 handset is dead until a saver ROM
build is found. I think that the 33Ef ROM build has an error.

Plato

And:

From:	Rodolphe Pineau (pineau@rti-zone.org)
I have a 32Ei rom here if you want to try (that was my test ROM for the
develpment), so I can put it on a ftp (or email it).

If you haven't try the verion 1.3 of AutoStarX you might want to give it
a try with this ROM version.

Rodolphe

And:

Oh well, I did get the ROM 32Ei and tried to load it and it froze on me.
I will try again tomorrow. THe ROM 33Ef build worked until the Daylight
option came up. After choosing NO or YES, it froze after ENTER pressed.
my Meade scope is one of the first ETX125-AT models out of the OPT store
last year. (UHTC model).  My Autostar handset label says version 26Ec.

Plato

And:

The label on the handset said ver.26Ec and the ROM build was 33Eb when I
tried to upgrade to 33Ef in the ver.26Ec handset with legend of
"Autostar" and "Meade" in front (label was in back)

Plato

So it appears you have one of the "old" autostar as Donald has (and he
also has the same problem).

This problem occurs only on the "old" autostar and I should have done
more test while I had Donald's one.

I can try to slowdown the upgrade (make a small pause after each block
is sent to the autostar) to see if it solve the problem.

I will do a special version of AutoStarX tomorrow and let you know when
it's ready for download if you're willing to do some tests.

Rodolphe

And:

Game to try things out as I have been doing things for over forty years
on computers. Too bad that Meade is still burying its head on the
subject of multiplatform programming and the new Mac mini may crack the
Gates wall. (I do have one here)

Plato

And:

It looks like the problem is general to the "old" autostar and I'm going
to work on it and try to find a solution.

Rodolphe

I did quick check on the autostar I'm using for my test... and I have
the same behavior so it's obviously a more general problem in AutostarX
instead of a specific one to "old" autostar.
I'm working on it and I hope to have a fix today.
Rodolphe

And an update:

Subject:	AutoStarX 1.4 beta
Sent:	Wednesday, February 9, 2005 16:31:18
From:	Donald Davenport (djdavenport@earthlink.net)
We have a winner.  It works fine.  I've gone through all the set ups
(except training motors which I'll do in a few minutes).

One thing that is interesting.  I don't know if you guys noticed it, but
the contrast adjustment after flashing with AutostarX is off.  I get
some bleed of red even in the blank squares.  I noticed this in earlier
versions, but it went away after I used the ASU to flash.  Now, it's
back.

I wonder if that's a reset issue in the code.  Then, again, it might
just be my unit.

Easily solved by adjusting the contrast, but maybe it is something that
could be fine-tuned.

Oh, and the flash time was 23 minutes, as predicted.

Donald

And the official announcement:

Subject:	AutoStarX 1.4
Sent:	Wednesday, February 9, 2005 16:12:23
From:	Rodolphe Pineau (pineau@rti-zone.org)
There was a bug in AutoStarX 1.3 so for all the mac users...upgrade to
version 1.4 asap as version 1.3 is not upgrading the autostar properly.

Thanks to all for the feedback.
The official 1.4 is now on my website (and check the credits in the
about box... you're all in there).

Thanks again for all the report, testing and sorry for the problems I caused.

Rodolphe

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
| Coldfire Robot / Unix / Atari / Astronomy |

Go back to the Autostar Information page.

Go back to the ETX Home Page.