[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: "Failure to communicate" problems




"Frank Kurz"  wrote in message
news:pZGdnXD46PqqXizQnZ2dnUVZ_rmdnZ2d@xxxxxxxxxxxxxxx

On 22/04/2011 7:19 AM, tourman wrote:
> Perhaps some of the regulars can suggest a solution to a problem I'm
> having.  For years now, I've been having random failures to
> communicate that are not caused by improper programming of the panels.
> There seems to be no pattern to them that I can determine, nor is it
> make specific. The station is no help and insist there are enough
> lines coming in to handle any amount of traffic. Whenever they happen,
> I have the client send a manual test through to the station, and it
> always goes through properly. This only seems to occur with
> conventional land lines
>
> I get daily reports and every day, and there is at least one panel
> that doesn't seem to have communicated it's test signal (out of a base
> of 1100 accounts). When I check, rarely is it a real problem....
>
> Can anyone familiar with station technology suggest potential
> solutions/problems that could be occurring. I'm at a loss...


In addition to Jim R's excellent points, you should call your station
manager and find out when the bulk of their dealer test signals are
coming in, then choose a time window outside of that.  We have some
accounts transmitting in the early afternoon (when things are usually
really quiet).

--
Frank Kurz
www.firetechs.net


---------

The other suggestions are right on,  I've had at least one of each  over the
years causing problems..
The DSL signal  is a real problem on FBII panels...
(a standard notch -20db filter  won't do it either,  takes an extra deep
notch -50db  to keep the DSL tones out of the processor..)
You might inquire when the phone company  does its line sweeps..
I've had lost calls  if they tried to test with a tone  when the phone guys
computer was doing the line sweep..

RTS



alt.security.alarms Main Index | alt.security.alarms Thread Index | alt.security.alarms Home | Archives Home