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

Re: Typical Misdirection



On Jul 13, 9:19=A0pm, "Bob La Londe" <n...@xxxxxxx> wrote:
> "Jim" <alarmi...@xxxxxxx> wrote in message
>
> news:b601b768-5216-4969-b3f9-42f3909b5eeb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
>
>
>
> > On Jun 23, 7:57 pm, "Bob La Londe" <n...@xxxxxxx> wrote:
> >> On a site with a Napco P1632 the customer complained of being constant=
ly
> >> disconnected. =A0The CS history all looks normal. =A0The only abnormal=
 was
> >> the
> >> panel reporting a restore when the phone service tech reconnected the
> >> phone
> >> line to the house. =A0The panel reported a phone line restoral... =A0o=
f
> >> course
> >> the phone tech happened to have his butt set hooked up and claimed tha=
t
> >> was
> >> a guaranteed demonstration that the panel was causing the problem.
>
> >> I don't see anything wrong. =A0Is it possible that the panel is seizin=
g the
> >> line and then releasing it without calling out for no reason? =A0Just =
want
> >> to
> >> be sure. =A0 I suppose if it had been mis-programmed it could do that,=
 but
> >> not
> >> continuously every day, and not as a recent symptom.
>
> >> Its in an outer suburb area that I think is running over a small carri=
er
> >> system. =A0I suppose the phone company might not be providing full vol=
tage
> >> at
> >> all times, but then the panel should report when the voltage comes up.
> >> Not
> >> seize the line and then drop it without reporting. =A0Seems weird to m=
e.
>
> >> Sounds like a telco problem and they are just trying to blame the
> >> alarmco,
> >> but if anybody can think of a possible cause I would sure like to chec=
k
> >> it
> >> out.
>
> >> Of course the phone company guy told the customer he is an expert on
> >> alarm
> >> systems.
>
> >> --
> >> The Security Consultant
> >> P.O. Box 5720
> >> Yuma, Az 85366
>
> >> (928) 782-9765 ofc
> >> (928) 782-7873 fax
>
> >> Licensed Communications Contractor
> >> Residential & Commercial since 1994
> >> ROC103044 & ROC103047
>
> > Hi Bob
> > I know that out in your area a service call can be an all day affair,
> > however, I know that when you have the panel set for telephone line
> > monitor, it will periodically check the line. I'm wondering if,
> > because of the possible weak telephone line service, that when the
> > panel checks the line that it might be causing the problem. The only
> > way you could tell would be to remove line monitoring from the
> > programing.
>
> That seems to be it. =A0I guess now I get out my little box of beat the p=
hone
> company test tools and prove it's a phone line problem after all. =A0Sigh=
!-


Bob, If the line is weak, and you're going to temporarily remove the
panel from the line, you may want to find out what the ringer
equivilancy of the panel is ( although I think all the panels are 0.0)
In any event, you may want to add another cheapy hand set to the line
just to load it down a little more.

I'm trying to remember what I did a lotta years ago when I had a
problem with a phone line and the Telco saying the line was alright. I
remember thinking that I would "flash" the line with 110VAC. That way
if it blew, at least the telco would have to come back and fix it and
probably switch the pair rather than try to fix it ..... as they
usually do. But I don't remember if I actually did it or not. Telco
said it was the alarm panel. I remember that the customer knew it was
the phone line because the problem occured AFTER the Telco worked on
the lines outside of his house. It's just that Telco wouldn't do
anything about the "hum" and weak connection because you could still
hear a conversation reasonably well. Most of the "noise" was on the
line when it was on hook. It was just that the alarm panel was
detecting line loss and sometimes during an alarm condition, had to
multiple dial taking central a long time to receive the signal. Could
be the customer complained loud enough for them to fix the line,
also .... it's to long ago to remember.


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