Last updated: 11 February 2005
27 Dec 04
I tried out the AutostarX Autostar Updater from Rodolphe Pineau (firstname.lastname@example.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 (email@example.com) 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. RodolpheAnd:
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). RodolpheAnd this:
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. RodolpheAnd this from our resident Autostar expert:
From: Richard Seymour (firstname.lastname@example.org) 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 --dickAnd more:
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. RodolpheAnd:
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 --dickMike here: I will post more information on the next Site update (31 December).
31 Dec 04
Subject: AutoStarX V1.1 Sent: Tuesday, December 28, 2004 01:08:23 From: Rodolphe Pineau (email@example.com) 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 (firstname.lastname@example.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.)And more:
From: Richard Seymour (email@example.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 --dickAnd:
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 ? RodolpheAnd:
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. RodolpheAnd this:
From: Richard Seymour (firstname.lastname@example.org) 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 --dickAnd more:
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. RodolpheMike here: I'm well known for finding oddities in software and/or hardware!
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. RodolpheMike here: That's nice to know. I wonder if there is something odd about that Autostar I have. I grabbed the beta update and tried it out (it is raining anyway). It connected fine and showed that 3.3Ef was on the Autostar. Started the flash, got a single click from the Autostar, the communication error, and the Autostar display blanked out. Turned off the LXD and powered it back up. The Autostar clicked continuously and its display was blank.
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 ? RodolpheMike here: The first Autostar I did (with version 1.0 and 1.1) on the ETX-125 is labeled with "Autostar" above the display. The one connected to the LXD55 is labeled "ETX Autostar". I probably switched them during some upgrade months ago. But they have both worked fine on their respective telescopes. Maybe there is some difference in the two models? Of course, they both had problems with AutostarX but not with Meade's app.
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. RodolpheMike here: Both are #497 and AutostarX reported that for each. And the same #505 cable was used for each.
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 --dickMike here: Thanks Dick. I do have another PowerBook, a G4/500 TiBook. I will install the Keyspan software on it.
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. RodolpheMike here: I tried my PowerBook G4/500 (TiBook). Same problem; as soon as I click the "Flash" button, it fails. This time there was no click from the Autostar, just the blank display. Used VPC on the PowerBook 17" to get the Autostar working again.
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. RodolpheMike here: Mine does have the RS-422 to DB9 converter. But it works OK in VPC with Meade's updater. Also, I've not had any (recent) problems with other Mac OS X applications that communicate with the Autostar.
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 (email@example.com) and Rodolphe Pineau (firstname.lastname@example.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 (email@example.com) 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: firstname.lastname@example.org (email@example.com) 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 (firstname.lastname@example.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 (email@example.com) 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 (firstname.lastname@example.org) 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 (email@example.com) 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 DavenportAnd:
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 DavenportAnd:
From: Rodolphe Pineau (firstname.lastname@example.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 (email@example.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 KettleAnd:
From: Rodolphe Pineau (firstname.lastname@example.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 (email@example.com) 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. DonMike here: Yes, that's correct. I had a problem with the Autostar connected to the ETX. When I put it into FLASH LOAD it successfully did the update. That was v1.0. But there was still something amiss since it shouldn't have trashed the Autostar in the first place. With the Autostar connected to the LXD55, it would never work, v1.0 or 1.1.
27 Jan 05
Subject: Re: Hi again problem fixed don't know how Sent: Wednesday, January 19, 2005 20:20:56 From: Rodolphe Pineau (firstname.lastname@example.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 (email@example.com) 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 DavenportMike here: Yes, it was the "ETX Autostar" box that never worked. But the working one could have been just luck. I will be testing an update to AutostarX tonight and hope to have good news soon.
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. DonaldAnd:
From: Rodolphe Pineau (firstname.lastname@example.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 ? RodolpheAnd:
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. DonAnd:
From: Richard Seymour (email@example.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 --dickAnd more info:
From: Donald Davenport (firstname.lastname@example.org) 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. DonaldAnd:
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, RodolpheMike here: Started the test with new version 1.2. No failure on the initial click of "Flash"! Writing pages now!!!
And a little later: Version 1.2 - success - 23 minutes!
Cool So now we need to figure out what is Donald problems/diffrences RodolpheAnd:
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. DonMike here: Yes, the Autostar I did was already functioning.
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. RodolpheAnd an update:
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 (email@example.com) 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 (firstname.lastname@example.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, ...) RodolpheAnd:
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. DonaldAnd:
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. RodolpheAnd this:
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. RodolpheAnd more:
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.Mike here: Very strange.
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). RodolpheAnd this:
From: Richard Seymour (email@example.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 --dickAnd:
Donald Davenport wrote: So, it the verdict in? Success?And:
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). RodolpheAnd:
From: Donald Davenport (firstname.lastname@example.org) 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! DonaldMike here: I think it is great. And the thread is entertaining and hopefully useful to many people. At least it shows what went into this!
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 (email@example.com) 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 (firstname.lastname@example.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). PlatoMike here: Thanks for the report. Earlier ROM versions on the Helpful Information: Autostar Info page in the archive link.
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. PlatoMike here: I hadn't heard that the current build on Meade's site had a problem. And all those patches are totally optional. But hopefully we can get you working again.
From: Rodolphe Pineau (email@example.com) 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. RodolpheMike here: 3.2Ei is on the Autostar Software Archive page on my ETX Site.
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. PlatoMike here: So your Autostar was at 2.6Ec when you tried to do the update to 3.3Ef?
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) PlatoAnd:
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
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
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. RodolpheAnd:
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 (firstname.lastname@example.org) 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. DonaldMike here: Outstanding!!!! Thanks Rodolphe and thanks to all the testers!
And the official announcement:
Subject: AutoStarX 1.4 Sent: Wednesday, February 9, 2005 16:12:23 From: Rodolphe Pineau (email@example.com) 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.