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

7134Re: [BCD396XT] Firmware Release suggestion

Expand Messages
  • MCH
    Dec 30, 2012
    • 0 Attachment
      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 talkground to get back to what I want to listen to.
      >>>
      >>> Tom
      >>>
      >>> On Sat, Dec 29, 2012 at 10:28 AM, Milton Engle <mengle@...> wrote:
      >>>
      >>>> **
      >>>>
      >>>>
      >>>> The scanner must listen to the control (or home) channel in order to
      >>>> follow
      >>>> transmissions on the system.
      >>>> In a very general sense that is the way any trunking system functions.
      >>>> Likewise user radios in a trunking environment will always listen to the
      >>>> control channel or home channel.
      >>>> In most trunking systems the control channel is a continuous data
      >>>> tranmission, all voice or digital voice communications occur on other
      >>>> channels in the system. The user radio listens for and finds the active
      >>>> control channel and stays there unless directed to a different channel
      >> by
      >>>> the system controller. Once the transmission or conversation that the
      >> user
      >>>> radio was directed to is over the user radio returns to the control
      >>>> channel.
      >>>> In a basic LTR system the user radio remains on the home channel
      >>>> programmed
      >>>> into the user radio unless directed by the trunking controller to
      >> another
      >>>> channel in the system. Basic LTR systems can have each system frequency
      >>>> function as a home channel depending on how the system is designed.
      >>>> If the scanner held on the last received frequency you would not receive
      >>>> any
      >>>> transmissions until another call was sent to the channel on which the
      >>>> scanner was holding, and then only if listening in ID Search mode. The
      >>>> chances that this next call would be related to the one last heard are
      >>>> very
      >>>> limited.
      >>>>
      >>>>
      >>>> ----- Original Message -----
      >>>> From: "Doug Hutton" <Doug2@...>
      >>>> To: <BCD396XT@yahoogroups.com>
      >>>> Sent: Saturday, December 29, 2012 12:00 PM
      >>>> Subject: [BCD396XT] Firmware Release suggestion
      >>>>
      >>>>> UPMan:
      >>>>>
      >>>>> Since you are releasing an update, may I suggest a minor change that
      >>>>> would be
      >>>>> very helpful to me and perhaps others.
      >>>>>
      >>>>> When HOLD is pressed while trunk scanning, the scanner holds on the
      >>>>> control
      >>>>> channel. It would be much more helpful to hold on the last received
      >>>>> channel.
      >>>>>
      >>>>> There are times when I hear something unusual or interesting and
      >> scanning
      >>>>> resumes before I can look at the display. I have DELAY set to 1 second
      >>>>> and don't want to increase it.
      >>>>>
      >>>>> Several years ago, I had a Uniden trunking scanner with a D suffix that
      >>>>> behaved this way and it was very handy.
      >>>>>
      >>>>> Doug H
      >>>>>
      >>>>>
      >>>>> [Non-text portions of this message have been removed]
      >>>>>
      >>>>>
      >>>>>
      >>>>> ------------------------------------
      >>>>>
      >>>>> Yahoo! Groups Links
      >>>>>
      >>>>>
      >>>>>
      >>>>
      >>>
      >>> [Non-text portions of this message have been removed]
      >>>
      >>>
      >>>
      >>> ------------------------------------
      >>>
      >>> Yahoo! Groups Links
      >>>
      >>>
      >>>
      >>>
      >>> ----------------------------------------------------------
      >>>
      >>>
      >>> No virus found in this incoming message.
      >>> Checked by AVG - www.avg.com
      >>> Version: 9.0.930 / Virus Database: 2637.1.1/5497 - Release Date:
      >> 12/30/12 02:34:00
      >>
      >>
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Show all 19 messages in this topic