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

RE: [BCD396XT] Re: Firmware Release suggestion

Expand Messages
  • 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 1 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.