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

Re: [BCD396XT] Re: Firmware Release suggestion

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