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

Re: Firmware Release suggestion

Expand Messages
  • Doug Hutton
    Folks, y all are making this suggestion WAY more complicated than it deserves. Of the 5 commenters, only Tom Hayward has thought this through carefully and
    Message 1 of 19 , Dec 31, 2012
    • 0 Attachment
      Folks, y'all are making this suggestion WAY more complicated than it
      deserves. Of the 5 commenters,
      only Tom Hayward has thought this through carefully and understands
      what I would like to get fixed and why.
      He described my situation exactly with a little more detail than I provided.

      The main EDACS system I monitor is large with lots of traffic. A longer
      DELAY is not a good solution
      because I would miss replies and other traffic. My suggestion is a very
      simple one with no downside that I can
      think of and deserves some serious consideration. Uniden has used it in
      a previous trunking scanner, so it must
      have some merit.

      Doug
      ----------------------------------------------------------------------------------------------------------------------------

      1g Re: Firmware Release suggestion
      Sun Dec 30, 2012 6:32 pm (PST) . Posted by:
      "MCH" NCC74656_USS_Voyager
      The original problem was described as the scanner moving on before the
      operator had a chance to stop the scan. The delay would give enough time
      to stop it before it starts, so that would solve the issue of it
      starting to scan 'too fast'. You wouldn't have to return to the last
      active channel because the scanner would still be there.

      I have a GRE unit that returns to the last active channel, and while
      that is sometimes nice, it has drawbacks, too. If you want to move
      several channels (or systems) ahead, you cannot because after you start
      the scan, wait, then stop it you are back where you started. So, you are
      forced to wear out the channel up button trying to get to a channel far
      from where you are.

      What you need is a scanner that can read your thoughts of what you want
      to do, but I wouldn't hold my breath for that.

      So, unless you want to create another problem, you have two choices:

      1. Increase the delay so you have time to stop the scan where it is, or

      2. Hit the button faster.

      Joe M.
      -----------------------------------------------------------------------------------------------
      Tom Hayward wrote:
      > No, delay is different. Delay does not let you return to the last hit
      after
      > scanning resumes. There are many reasons why you would want to keep delay
      > short but have a way to return to the last hit.
      >
      > Tom
      >
      > On Sun, Dec 30, 2012 at 12:57 PM, MCH <mch@...> wrote:
      >
      >> That's what the DELAY function is for, but he said he didn't want to use
      >> that. I don't see the need for a new feature when a current feature
      >> exists that will do what you want.
      >>
      >> Joe M.
      >>
      >>
      >> Tom Hayward wrote:
      >>> Milton, I think you misunderstood Doug's request. Here's an example:
      >>>
      >>> Scanning three control channels in a system:
      >>> Control 1
      >>> Control 2
      >>> Control 3
      >>>
      >>> Scanner hits on Control 1, TG500.
      >>> Doug decides he wants to hold on Control 1, TG500, and begins
      moving his
      >>> arm.
      >>> Transmission ends and scanning continues.
      >>> Doug's hand reaches the Hold button and presses it.
      >>> Scanner holds whatever it's currently scanning, e.g., Control 3.
      >>>
      >>> Doug is requesting that, within a defined period (10 seconds?),
      Hold will
      >>> not hold the current channel as it does now, but go back to the
      last hit.
      >>> In this example, Hold would bring you back to Control 1, TG500, instead
      >> >of quiet Control 3.
      >>>
      >>> I agree with Doug that this change in behavior would very useful. I
      often
      >>> find myself hitting Hold too late and having to disable scanning and
      >>> manually recall the talkgroup to get back to what I want to listen to.
      >>>
      >>> Tom
      >>>
      ----------------------------------------------------------------------------------------------------



      [Non-text portions of this message have been removed]
    • MCH
      I posted an example of a downside based on the use of that exact feature. Should it be considered, of course. But, it s not a simple win-win feature. There are
      Message 2 of 19 , Dec 31, 2012
      • 0 Attachment
        I posted an example of a downside based
        on the use of that exact feature.

        Should it be considered, of course. But, it's not
        a simple win-win feature. There are drawbacks.
        (not to mention the fact that there will be users
        whose scanner works one way, and others whose
        scanner works a different way. That will confuse some)

        If it is added, I would hope it will only be as a user-settable
        feature, as I want the scanner to scan when it is in scan mode.

        Joe M.

        Doug Hutton wrote:
        > My suggestion is a very simple one with no downside that I can
        > think of and deserves some serious consideration.
      • Robert Klamp
        But if you want to return to the last hit by pressing hold how is that any different than the scanner waiting 4 more seconds or so before moving on. Sure you
        Message 3 of 19 , Dec 31, 2012
        • 0 Attachment
          But if you want to return to the last hit by pressing hold how is that any different than the scanner waiting 4 more seconds or so before moving on. Sure you could have it do that but as soon as it picked up another transmission on another channel that would become your last hit. And will accomplish nothing but returning to a channel that if held for 5 seconds you would here the response anyway. And if Uniden did have it in earlier trunking models they must have had good reason to re-think its implementation and came to the same conclusion most people on the board did that it is unnecessary . If you want that feature so bad trade your 996 for a 500 GRE scanners do that and it drives me nuts.

          Bob

          Sent from my U.S. Cellular® Windows® phone.

          -----Original Message-----
          From: Doug Hutton <Doug2@...>
          Sent: Monday, December 31, 2012 11:39 AM
          To: BCD396XT@yahoogroups.com
          Subject: [BCD396XT] Re: Firmware Release suggestion


          Folks, y'all are making this suggestion WAY more complicated than it
          deserves. Of the 5 commenters,
          only Tom Hayward has thought this through carefully and understands
          what I would like to get fixed and why.
          He described my situation exactly with a little more detail than I provided.

          The main EDACS system I monitor is large with lots of traffic. A longer
          DELAY is not a good solution
          because I would miss replies and other traffic. My suggestion is a very
          simple one with no downside that I can
          think of and deserves some serious consideration. Uniden has used it in
          a previous trunking scanner, so it must
          have some merit.

          Doug
          ----------------------------------------------------------

          1g Re: Firmware Release suggestion
          Sun Dec 30, 2012 6:32 pm (PST) . Posted by:
          "MCH" NCC74656_USS_Voyager
          The original problem was described as the scanner moving on before the
          operator had a chance to stop the scan. The delay would give enough time
          to stop it before it starts, so that would solve the issue of it
          starting to scan 'too fast'. You wouldn't have to return to the last
          active channel because the scanner would still be there.

          I have a GRE unit that returns to the last active channel, and while
          that is sometimes nice, it has drawbacks, too. If you want to move
          several channels (or systems) ahead, you cannot because after you start
          the scan, wait, then stop it you are back where you started. So, you are
          forced to wear out the channel up button trying to get to a channel far
          from where you are.

          What you need is a scanner that can read your thoughts of what you want
          to do, but I wouldn't hold my breath for that.

          So, unless you want to create another problem, you have two choices:

          1. Increase the delay so you have time to stop the scan where it is, or

          2. Hit the button faster.

          Joe M.
          ----------------------------------------------------------
          Tom Hayward wrote:
          > No, delay is different. Delay does not let you return to the last hit
          after
          > scanning resumes. There are many reasons why you would want to keep delay
          > short but have a way to return to the last hit.
          >
          > Tom
          >
          > On Sun, Dec 30, 2012 at 12:57 PM, MCH <mch@...> wrote:
          >
          >> That's what the DELAY function is for, but he said he didn't want to use
          >> that. I don't see the need for a new feature when a current feature
          >> exists that will do what you want.
          >>
          >> Joe M.
          >>
          >>
          >> Tom Hayward wrote:
          >>> Milton, I think you misunderstood Doug's request. Here's an example:
          >>>
          >>> Scanning three control channels in a system:
          >>> Control 1
          >>> Control 2
          >>> Control 3
          >>>
          >>> Scanner hits on Control 1, TG500.
          >>> Doug decides he wants to hold on Control 1, TG500, and begins
          moving his
          >>> arm.
          >>> Transmission ends and scanning continues.
          >>> Doug's hand reaches the Hold button and presses it.
          >>> Scanner holds whatever it's currently scanning, e.g., Control 3.
          >>>
          >>> Doug is requesting that, within a defined period (10 seconds?),
          Hold will
          >>> not hold the current channel as it does now, but go back to the
          last hit.
          >>> In this example, Hold would bring you back to Control 1, TG500, instead
          >> >of quiet Control 3.
          >>>
          >>> I agree with Doug that this change in behavior would very useful. I
          often
          >>> find myself hitting Hold too late and having to disable scanning and
          >>> manually recall the talkgroup to get back to what I want to listen to.
          >>>
          >>> Tom
          >>>
          ----------------------------------------------------------

          [Non-text portions of this message have been removed]



          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.