Loading ...
Sorry, an error occurred while loading the content.
 

Re: Autostar II Update Problems

Expand Messages
  • autostaretx
    ... There are rarely too many details. Lengthy is good. First guess: your Autostar may have a flaky bit in its high memory. That s most likely in the
    Message 1 of 5 , Aug 1, 2011
      --- In LX200GPS@yahoogroups.com, "peter_0905" <xaxys0@...> wrote:
      >
      > Firstly apologies for the lengthy post but wanted to recount
      > exactly what I did.

      There are rarely "too many" details. Lengthy is good.

      First guess: your Autostar may have a flaky bit in its high memory.
      That's most likely in the general background text section, so *may* go undiscovered (i.e. it will never affect your operations), except for when Updating.
      StarPatch generates different error messages if an Erase operation fails, compared to what it says/does if the write-to-memory fails.
      ("fails" means at least one bit differs from the desired pattern).
      From your description, i think it was the Write which had problems, and the location of the failure is quite likely in a "safe" area.

      Now let's visit the report:

      > I decided to apply Dick Seymour's LX42gg11 patch to my scope
      > yesterday. As I don't anticipate updating very often I decided
      > to use Meade's ASU rather than download Starpatch. I followed the
      > instructions in the patchLX42gg11 Readme file exactly, creating
      > the 'buildLX42gg11.rom' file and copying it to the Ephemerides
      > folder in Updater.
      > Having first saved the user data I started the update. I didn't
      > touch the PC, but on returning after about 15mins I saw the dreaded
      > Update Failed message.
      > The handbox was displaying Updating...Do Not Power Off.

      ASU checks the write operation (but not the erasures), and takes no further action when it sees a failure... including leaving the Autostar in Download mode. So ASU had "quit", and the handbox would have been in Download until you shut it down.

      > I waited a while but didn't see I had much option but to power off.

      That was the correct action.

      > When I powered on again, the ROM version on the handbox came up as
      > 4.2G (it had definitely been lower case 'g' before). And it was
      > asking me to choose which scope i.e. its variables had been wiped.

      When you use ASU, it *does* force a semi-Reset.
      So Site, Model and Drive Training data are lost.
      SMT and PEC data survive.
      StarPatch tries to *not* do that to you (but Meade's firmware changes may occasionally still force one)

      > I guessed that the update had only partially worked, and since
      > the Readme file says ASU is more flaky than Starpatch I decided
      > to download Starpatch and try with that. This I did, and having
      > copied the 'buildLX42gg11.rom' and the other patch files to the
      > Starpatch folder I ran the update. I noticed that no options list
      > came up when I selected the ROM file, and a message told me that
      > no options had been selected.

      Correct. StarPatch was telling you that you had not attempted to *further* patch the rom file you pointed at. It had no idea that you had inserted changes in the creation of buildLX42gg11.rom

      > So I instead loaded the 'patchLX42gg11.spf' file, checked the
      > options I wanted and ran the update. (I'm guessing this is not
      > the right procedure?)

      No, that *is* the correct procedure for having StarPAtch insert the changes (and present you with the option list). That's why i've started including the ".spf" file in the kits. It's "Star Patch Fodder".

      > The update started OK and began counting down from about 9m 30s,
      > but with a few minutes to go I got Update Failed again. Again I
      > cycled power on the scope and on restart got the 4.2G version
      > displayed.

      Your downloads are probably proceeding far enough to get all of the "code" (instructions) loaded safely. Then a memory problem in your scope's data area is triggering the failures.

      > Still believing the update had failed, I tried again with
      > Starpatch, this time selecting the 'buildLX42gg11.rom' file
      > despite the warning that no options had been selected (I just
      > wanted an Update to run through successfully).
      > Again I ran the update and again it failed 88% of the way through.

      Ah... 88% ... this means that the top 12% haven't been loaded.
      BUT... since you already had 4.2g loaded, *that data hasn't changed*.
      (with the exception of the 64 Kbyte section containing the error.
      The Autostar memory gets erased in 64KB chunks as the programming proceeds. When the "bad bit" (a 1 not flipping to a zero) was detected, writing to the rest of that "page" didn't happen.)

      I'll send a note to Chris (StarPatch author) to consider adding a "damn the torpedos" switch... in cases like yours, leaving "one bad bit" is a lot better than leaving up to 64KB of erased memory.

      > This time I tried the 999 entry on power up but the display just
      > changed to 'Updating...Do Not Power Off' again.

      That's what it does. That would be a useful process if your Updates had created an "unbootable" scope. Although a bad memory chip at a low (early) address really is a severe problem.

      > I cycled power and this time entered all the scope data. It took
      > its GPS fix and I reconnected the PC and checked that date, time
      > and LST looked correct. I ran Andrew's PEC Editor which
      > successfully read the variables from the scope. I also checked
      > that connection speeds up to 115,200 baud were accepted.
      >
      > The big question is - is the Autostar corrupt or did the update
      > work even though it reported a failure?

      The Autostar probably is corrupted due to a bad memory chip.

      But it may be in an area that won't materially affect your operations.
      ('fess up: would you ever know if 50 crater's textual messages were lost? Or a few chapters of Ancient Greek Heros and Gods tales?)

      > Once again sorry for the long post but I would like some advice/
      > reassurance on this matter.

      I'm sorry i cannot say "no problem".
      StarPAtch usually reports an Erasure error differently from a Write error, and i infer from your description that it's a Write error.

      As i said, i'll check with Chris to see if we can create a version of StarPAtch which would minimize the fault's effect to less than 0.001% of your scope's memory.

      If the above description isn't clear, think of it as you have updated a phone book. But due to a moth-eaten hole in one page, the back half of the "R" section didn't get written (it's blank). But since the update didn't affect S through Z, they're OK.

      good luck
      --dick
    • peter_0905
      Hi Dick Thanks very much for your detailed comments. I am reassured but with obvious reservations about a possible bad memory chip. Should I look into getting
      Message 2 of 5 , Aug 2, 2011
        Hi Dick

        Thanks very much for your detailed comments. I am reassured but with obvious reservations about a possible bad memory chip. Should I look into getting this checked/replaced under warranty?

        I have since found that there have been more recent versions of your patch (LX42gg13 is the latest one I have found - is that the latest?) and I was thinking of trying to download it so I can suppress the PEC index slew on Unparking (am I a sucker for punishment?)
        Are you aware of any reason I shouldn't try this, given the problems I have had?

        Thanks again

        Peter.


        --- In LX200GPS@yahoogroups.com, "autostaretx" <rseymour@...> wrote:
        >
        > --- In LX200GPS@yahoogroups.com, "peter_0905" <xaxys0@> wrote:
        > >
        > > Firstly apologies for the lengthy post but wanted to recount
        > > exactly what I did.
        >
        > There are rarely "too many" details. Lengthy is good.
        >
        > First guess: your Autostar may have a flaky bit in its high memory.
        > That's most likely in the general background text section, so *may* go undiscovered (i.e. it will never affect your operations), except for when Updating.
        > StarPatch generates different error messages if an Erase operation fails, compared to what it says/does if the write-to-memory fails.
        > ("fails" means at least one bit differs from the desired pattern).
        > From your description, i think it was the Write which had problems, and the location of the failure is quite likely in a "safe" area.
        >
        > Now let's visit the report:
        >
        > > I decided to apply Dick Seymour's LX42gg11 patch to my scope
        > > yesterday. As I don't anticipate updating very often I decided
        > > to use Meade's ASU rather than download Starpatch. I followed the
        > > instructions in the patchLX42gg11 Readme file exactly, creating
        > > the 'buildLX42gg11.rom' file and copying it to the Ephemerides
        > > folder in Updater.
        > > Having first saved the user data I started the update. I didn't
        > > touch the PC, but on returning after about 15mins I saw the dreaded
        > > Update Failed message.
        > > The handbox was displaying Updating...Do Not Power Off.
        >
        > ASU checks the write operation (but not the erasures), and takes no further action when it sees a failure... including leaving the Autostar in Download mode. So ASU had "quit", and the handbox would have been in Download until you shut it down.
        >
        > > I waited a while but didn't see I had much option but to power off.
        >
        > That was the correct action.
        >
        > > When I powered on again, the ROM version on the handbox came up as
        > > 4.2G (it had definitely been lower case 'g' before). And it was
        > > asking me to choose which scope i.e. its variables had been wiped.
        >
        > When you use ASU, it *does* force a semi-Reset.
        > So Site, Model and Drive Training data are lost.
        > SMT and PEC data survive.
        > StarPatch tries to *not* do that to you (but Meade's firmware changes may occasionally still force one)
        >
        > > I guessed that the update had only partially worked, and since
        > > the Readme file says ASU is more flaky than Starpatch I decided
        > > to download Starpatch and try with that. This I did, and having
        > > copied the 'buildLX42gg11.rom' and the other patch files to the
        > > Starpatch folder I ran the update. I noticed that no options list
        > > came up when I selected the ROM file, and a message told me that
        > > no options had been selected.
        >
        > Correct. StarPatch was telling you that you had not attempted to *further* patch the rom file you pointed at. It had no idea that you had inserted changes in the creation of buildLX42gg11.rom
        >
        > > So I instead loaded the 'patchLX42gg11.spf' file, checked the
        > > options I wanted and ran the update. (I'm guessing this is not
        > > the right procedure?)
        >
        > No, that *is* the correct procedure for having StarPAtch insert the changes (and present you with the option list). That's why i've started including the ".spf" file in the kits. It's "Star Patch Fodder".
        >
        > > The update started OK and began counting down from about 9m 30s,
        > > but with a few minutes to go I got Update Failed again. Again I
        > > cycled power on the scope and on restart got the 4.2G version
        > > displayed.
        >
        > Your downloads are probably proceeding far enough to get all of the "code" (instructions) loaded safely. Then a memory problem in your scope's data area is triggering the failures.
        >
        > > Still believing the update had failed, I tried again with
        > > Starpatch, this time selecting the 'buildLX42gg11.rom' file
        > > despite the warning that no options had been selected (I just
        > > wanted an Update to run through successfully).
        > > Again I ran the update and again it failed 88% of the way through.
        >
        > Ah... 88% ... this means that the top 12% haven't been loaded.
        > BUT... since you already had 4.2g loaded, *that data hasn't changed*.
        > (with the exception of the 64 Kbyte section containing the error.
        > The Autostar memory gets erased in 64KB chunks as the programming proceeds. When the "bad bit" (a 1 not flipping to a zero) was detected, writing to the rest of that "page" didn't happen.)
        >
        > I'll send a note to Chris (StarPatch author) to consider adding a "damn the torpedos" switch... in cases like yours, leaving "one bad bit" is a lot better than leaving up to 64KB of erased memory.
        >
        > > This time I tried the 999 entry on power up but the display just
        > > changed to 'Updating...Do Not Power Off' again.
        >
        > That's what it does. That would be a useful process if your Updates had created an "unbootable" scope. Although a bad memory chip at a low (early) address really is a severe problem.
        >
        > > I cycled power and this time entered all the scope data. It took
        > > its GPS fix and I reconnected the PC and checked that date, time
        > > and LST looked correct. I ran Andrew's PEC Editor which
        > > successfully read the variables from the scope. I also checked
        > > that connection speeds up to 115,200 baud were accepted.
        > >
        > > The big question is - is the Autostar corrupt or did the update
        > > work even though it reported a failure?
        >
        > The Autostar probably is corrupted due to a bad memory chip.
        >
        > But it may be in an area that won't materially affect your operations.
        > ('fess up: would you ever know if 50 crater's textual messages were lost? Or a few chapters of Ancient Greek Heros and Gods tales?)
        >
        > > Once again sorry for the long post but I would like some advice/
        > > reassurance on this matter.
        >
        > I'm sorry i cannot say "no problem".
        > StarPAtch usually reports an Erasure error differently from a Write error, and i infer from your description that it's a Write error.
        >
        > As i said, i'll check with Chris to see if we can create a version of StarPAtch which would minimize the fault's effect to less than 0.001% of your scope's memory.
        >
        > If the above description isn't clear, think of it as you have updated a phone book. But due to a moth-eaten hole in one page, the back half of the "R" section didn't get written (it's blank). But since the update didn't affect S through Z, they're OK.
        >
        > good luck
        > --dick
        >
      • autostaretx
        ... If your scope is still under warranty, i d certainly look into that. If you bought Meade s Sky Assurance (with shipping) then the cost is minimal.
        Message 3 of 5 , Aug 2, 2011
          --- In LX200GPS@yahoogroups.com, "peter_0905" <xaxys0@...> wrote:
          >
          > Hi Dick
          >
          > Thanks very much for your detailed comments. I am reassured but
          > with obvious reservations about a possible bad memory chip. Should
          > I look into getting this checked/replaced under warranty?

          If your scope is still under warranty, i'd certainly look into that.
          If you bought Meade's Sky Assurance (with shipping) then the "cost" is minimal. Expect down-time to be 4 to 6 weeks.
          Your specific problem could be solved by swapping the main board (behind the power panel), but Meade requires the entire scope.

          > I have since found that there have been more recent versions of
          > your patch (LX42gg13 is the latest one I have found - is that
          > the latest?) and I was thinking of trying to download it so I can
          > suppress the PEC index slew on Unparking (am I a sucker for
          > punishment?)

          The initial PEC slew can also be suppressed by turning ON the RA PEC (Smart Drive) feature. As long as you PARK, the next session will NOT seek the index (since it remembers is as part of PARKing).

          > Are you aware of any reason I shouldn't try this, given the
          > problems I have had?

          Feel free...
          It won't make a difference as to the memory problem
          (and i'm hoping to work up some way around the problem).
          Andrew wrote me in the background suggesting that we have ways of finding out *where* the problem occurred... but it's somewhat of a rub-tummy-pat-head-stand-on-one-foot sequence, and wouldn't fill in the extra bits (maybe). Let's leave that as a fall-back.

          good luck
          --dick

          >
          > Thanks again
          >
          > Peter.
          >
          >
          > --- In LX200GPS@yahoogroups.com, "autostaretx" <rseymour@> wrote:
          > >
          > > --- In LX200GPS@yahoogroups.com, "peter_0905" <xaxys0@> wrote:
          > > >
          > > > Firstly apologies for the lengthy post but wanted to recount
          > > > exactly what I did.
          > >
          > > There are rarely "too many" details. Lengthy is good.
          > >
          > > First guess: your Autostar may have a flaky bit in its high memory.
          > > That's most likely in the general background text section, so *may* go undiscovered (i.e. it will never affect your operations), except for when Updating.
          > > StarPatch generates different error messages if an Erase operation fails, compared to what it says/does if the write-to-memory fails.
          > > ("fails" means at least one bit differs from the desired pattern).
          > > From your description, i think it was the Write which had problems, and the location of the failure is quite likely in a "safe" area.
          > >
          > > Now let's visit the report:
          > >
          > > > I decided to apply Dick Seymour's LX42gg11 patch to my scope
          > > > yesterday. As I don't anticipate updating very often I decided
          > > > to use Meade's ASU rather than download Starpatch. I followed the
          > > > instructions in the patchLX42gg11 Readme file exactly, creating
          > > > the 'buildLX42gg11.rom' file and copying it to the Ephemerides
          > > > folder in Updater.
          > > > Having first saved the user data I started the update. I didn't
          > > > touch the PC, but on returning after about 15mins I saw the dreaded
          > > > Update Failed message.
          > > > The handbox was displaying Updating...Do Not Power Off.
          > >
          > > ASU checks the write operation (but not the erasures), and takes no further action when it sees a failure... including leaving the Autostar in Download mode. So ASU had "quit", and the handbox would have been in Download until you shut it down.
          > >
          > > > I waited a while but didn't see I had much option but to power off.
          > >
          > > That was the correct action.
          > >
          > > > When I powered on again, the ROM version on the handbox came up as
          > > > 4.2G (it had definitely been lower case 'g' before). And it was
          > > > asking me to choose which scope i.e. its variables had been wiped.
          > >
          > > When you use ASU, it *does* force a semi-Reset.
          > > So Site, Model and Drive Training data are lost.
          > > SMT and PEC data survive.
          > > StarPatch tries to *not* do that to you (but Meade's firmware changes may occasionally still force one)
          > >
          > > > I guessed that the update had only partially worked, and since
          > > > the Readme file says ASU is more flaky than Starpatch I decided
          > > > to download Starpatch and try with that. This I did, and having
          > > > copied the 'buildLX42gg11.rom' and the other patch files to the
          > > > Starpatch folder I ran the update. I noticed that no options list
          > > > came up when I selected the ROM file, and a message told me that
          > > > no options had been selected.
          > >
          > > Correct. StarPatch was telling you that you had not attempted to *further* patch the rom file you pointed at. It had no idea that you had inserted changes in the creation of buildLX42gg11.rom
          > >
          > > > So I instead loaded the 'patchLX42gg11.spf' file, checked the
          > > > options I wanted and ran the update. (I'm guessing this is not
          > > > the right procedure?)
          > >
          > > No, that *is* the correct procedure for having StarPAtch insert the changes (and present you with the option list). That's why i've started including the ".spf" file in the kits. It's "Star Patch Fodder".
          > >
          > > > The update started OK and began counting down from about 9m 30s,
          > > > but with a few minutes to go I got Update Failed again. Again I
          > > > cycled power on the scope and on restart got the 4.2G version
          > > > displayed.
          > >
          > > Your downloads are probably proceeding far enough to get all of the "code" (instructions) loaded safely. Then a memory problem in your scope's data area is triggering the failures.
          > >
          > > > Still believing the update had failed, I tried again with
          > > > Starpatch, this time selecting the 'buildLX42gg11.rom' file
          > > > despite the warning that no options had been selected (I just
          > > > wanted an Update to run through successfully).
          > > > Again I ran the update and again it failed 88% of the way through.
          > >
          > > Ah... 88% ... this means that the top 12% haven't been loaded.
          > > BUT... since you already had 4.2g loaded, *that data hasn't changed*.
          > > (with the exception of the 64 Kbyte section containing the error.
          > > The Autostar memory gets erased in 64KB chunks as the programming proceeds. When the "bad bit" (a 1 not flipping to a zero) was detected, writing to the rest of that "page" didn't happen.)
          > >
          > > I'll send a note to Chris (StarPatch author) to consider adding a "damn the torpedos" switch... in cases like yours, leaving "one bad bit" is a lot better than leaving up to 64KB of erased memory.
          > >
          > > > This time I tried the 999 entry on power up but the display just
          > > > changed to 'Updating...Do Not Power Off' again.
          > >
          > > That's what it does. That would be a useful process if your Updates had created an "unbootable" scope. Although a bad memory chip at a low (early) address really is a severe problem.
          > >
          > > > I cycled power and this time entered all the scope data. It took
          > > > its GPS fix and I reconnected the PC and checked that date, time
          > > > and LST looked correct. I ran Andrew's PEC Editor which
          > > > successfully read the variables from the scope. I also checked
          > > > that connection speeds up to 115,200 baud were accepted.
          > > >
          > > > The big question is - is the Autostar corrupt or did the update
          > > > work even though it reported a failure?
          > >
          > > The Autostar probably is corrupted due to a bad memory chip.
          > >
          > > But it may be in an area that won't materially affect your operations.
          > > ('fess up: would you ever know if 50 crater's textual messages were lost? Or a few chapters of Ancient Greek Heros and Gods tales?)
          > >
          > > > Once again sorry for the long post but I would like some advice/
          > > > reassurance on this matter.
          > >
          > > I'm sorry i cannot say "no problem".
          > > StarPAtch usually reports an Erasure error differently from a Write error, and i infer from your description that it's a Write error.
          > >
          > > As i said, i'll check with Chris to see if we can create a version of StarPAtch which would minimize the fault's effect to less than 0.001% of your scope's memory.
          > >
          > > If the above description isn't clear, think of it as you have updated a phone book. But due to a moth-eaten hole in one page, the back half of the "R" section didn't get written (it's blank). But since the update didn't affect S through Z, they're OK.
          > >
          > > good luck
          > > --dick
          > >
          >
        • John Mahony
          ... And yes, that s as counter-intuitive as it sounds.  You d think that turning PEC _off_ would cause it to not do the PEC index search.  But this is Meade
          Message 4 of 5 , Aug 2, 2011
            ----- Original Message -----

            > From: autostaretx <rseymour@...>
            >
            > --- In LX200GPS@yahoogroups.com, "peter_0905" <xaxys0@...>
            > wrote:
            >>
            >> I have since found that there have been more recent versions of
            >> your patch (LX42gg13 is the latest one I have found - is that
            >> the latest?) and I was thinking of trying to download it so I can
            >> suppress the PEC index slew on Unparking (am I a sucker for
            >> punishment?)
            >
            > The initial PEC slew can also be suppressed by turning ON the RA PEC (Smart
            > Drive) feature.  As long as you PARK, the next session will NOT seek the index
            > (since it remembers is as part of PARKing).

            And yes, that's as counter-intuitive as it sounds.  You'd think that turning PEC _off_ would cause it to not do the PEC index search.  But this is Meade we're dealing with...

            I think it does the index search just in case you decide to train the PEC while you have the scope on.  But then if you PARK without training PEC, it decides it doesn't need to remember the index position, since you didn't train the PEC and turn PEC on.  So then it does the search again the next time you turn it on.  Much easier to just do the index search when you decide to train PEC, but that would make sense...

            -John
          Your message has been successfully submitted and would be delivered to recipients shortly.