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

Re: [jp1] Rob: simple request, Mill. 4

Expand Messages
  • Rob Crowe
    ... Here s a better method... 1) Download and save the current memory image (as a backup) 2) In IR, select Advanced Purge Memory, then load to the remote. 3)
    Message 1 of 6 , Aug 31, 2003
    View Source
    • 0 Attachment
      > Rob,
      >
      > I assume from your post yesterday that you have a millenium 4.
      > Since i doubt you're using it, can you please do a simple test for me
      > and see what happens.
      >
      > 981 the remote. 1. Hook up JP-1 and open IR, with the RDF set
      > at 01B. Download from remote. Pick any of the device modes, just
      > leave it at the default setup code. Go to keymove tab. enter in a
      > keymove, ie. keymove a change of the power key to any other efc (pick
      > one at random if you want, doesn't matter). UPLOAD to remote. Once
      > uploaded, then simply re-download Check the results.

      Here's a better method...

      1) Download and save the current memory image (as a backup)
      2) In IR, select Advanced > Purge Memory, then load to the remote.
      3) Do a 981 reset
      4) Download (save this image if you like, it's the "virgin" image).
      5) In IR, go to the Raw Data tab, then select Tools > Set Baseline
      6) Program a keymove on the remote
      7) Download. All the changed data will be highlighted in red. The first
      two bytes will change because they are a checksum but the only other data
      that should change is the place where the keymove is stored, which should
      start at either $01B or $01C.

      It occurred to me that if some remotes use $01C and some use $01B, I wonder
      what the $01B byte is used for in the $01C remotes, so I looked in the RDF,
      it's the byte that controls which device mode gets to use macros (labelled
      "Macro Device"). Therefore, I'm guessing that the remotes that use $01B for
      the keymoves probably don't have this restriction.

      Of course, it could mean that they do have this restriction but a different
      byte is used for it, in which case maybe it's the "Channel Lock to Cable"
      feature that's missing.

      Rob
    • James H. Gammel
      ... first ... other data ... should ... Mark suggested this, perhaps a slightly different step-by-step, I need to print that message and this one out and sit
      Message 2 of 6 , Sep 1, 2003
      View Source
      • 0 Attachment
        > Here's a better method...
        >
        > 1) Download and save the current memory image (as a backup)
        > 2) In IR, select Advanced > Purge Memory, then load to the remote.
        > 3) Do a 981 reset
        > 4) Download (save this image if you like, it's the "virgin" image).
        > 5) In IR, go to the Raw Data tab, then select Tools > Set Baseline
        > 6) Program a keymove on the remote
        > 7) Download. All the changed data will be highlighted in red. The
        first
        > two bytes will change because they are a checksum but the only
        other data
        > that should change is the place where the keymove is stored, which
        should
        > start at either $01B or $01C.

        Mark suggested this, perhaps a slightly different step-by-step, I
        need to print that message and this one out and sit down and absorb
        them. But thanks, it may be a big help.

        >
        > It occurred to me that if some remotes use $01C and some use $01B,
        I wonder
        > what the $01B byte is used for in the $01C remotes, so I looked in
        the RDF,
        > it's the byte that controls which device mode gets to use macros
        (labelled
        > "Macro Device"). Therefore, I'm guessing that the remotes that use
        $01B for
        > the keymoves probably don't have this restriction.

        and the way to test is...........?

        >
        > Of course, it could mean that they do have this restriction but a
        different
        > byte is used for it, in which case maybe it's the "Channel Lock to
        Cable"
        > feature that's missing.

        The boards call the "lock" button "ppv" most have "lock" on the
        physical button. Is it safe to assume that *IF* the physical button
        is labeled "LOCK" then that remote has "channel lock to cable
        feature", and those (much fewer) that don't have "LOCK" labeled on
        the key itself may/may not and would be the only ones that need
        examined to know for sure? Seems it'd be really silly to have a key
        labeled "lock" when it doesn't "lock" anything.

        Jim
      • johnsfine
        ... That feature is not related to any physical button. Channel Lock to Cable is a feature similar to VPT. When turned on it causes the channel keys to
        Message 3 of 6 , Sep 1, 2003
        View Source
        • 0 Attachment
          --- In jp1@yahoogroups.com, "James H. Gammel" <jamesgammel@y...> wrote:

          > > "Channel Lock to Cable" feature that's missing.
          >
          > The boards call the "lock" button "ppv" most have "lock" on the
          > physical button.

          That feature is not related to any physical button.

          "Channel Lock to Cable" is a feature similar to VPT. When turned on
          it causes the channel keys to operate the cable device even when the
          remote is in a device mode other than cable (just as VPT makes the vol
          keys operate the selected VPT device when in other modes).
        Your message has been successfully submitted and would be delivered to recipients shortly.