Re: question about burglar alarm dispute (San Francisco Bay Area)

[Matt Ion <soundy106@xxxxxxxxx>]

Bob La Londe wrote:

> Actually where I have run across this type of problem is when the customer
> has added DSL service to their home or business phone line without bothering
> to notify the alarm company.  What usually happens is either the CS receiver
> can't hear the signals over the DSL carrier OR more often the panel can't
> hear the kissof signal from the CS so it sends the signal again.

Hmm, good point, hadn't thought of that... but as I say, I'm not an
alarm expert... thus my disclaimers :)

> NOW!  Technically it is the customer's fault, or the DSL providers fault in
> this case.  I recently did a DSL self install in my house, and the
> instruction clearly said that if you have an alarm panel notify your alarm
> company.  I have also had clients call me and tell me their self install
> instructions for their new DSL modem said the same thing.  If these
> instruction are well enough known to be documented for self installers there
> is absolutely no excuse for a proffessional DSL installer to make this
> mistake either.
 >
> In this case we can't say who is at fault until we actually discover the
> problem for this run-a-way repeat signal attempt, but addition of DSL to the
> line can cause almost exactly these symptoms.

Yeah, that's the problem with diagnosing something like this online -
ultimately, someone with a clue really should take a look at the system
IN PERSON and determine the actual cause of the problem, before any
"blame" can be assigned.

In the end, it may be equitable for all three parties to simple split
the cost: the alarm company because, as you say, they should recognize
this type of problem right off rather than trying to pass it off on the
customer and/or telco (and because as has been noted elsewhere, because
their system should have registered a problem from missing check-ins
long ago); the telco, because their installer should know enough to
check for these sorts of things when making the hookup in the first
place; and depending on materials provided by the alarmco AND telco, the
customer for not reading the FINE manual (assuming there is a note
somewhere in there to be aware of this sort of issue).

And of course, this all assume that the problem IS related a DSL
installation...

> Of course we have over looked an underlying problem which could be makling
> things worse.  AT&T.  If they have the customer on a carrier where they are
> compressing to many phone lines over the available bandwidth they could be
> distorting the signal enroute.  Usually the kissof signal is the one that
> suffers.  Most of the time you can hear a little echo or tin can sound to
> the lines on a voice call when this is the case, but not always.

Interesingly, this is a similar idea to one that affected a friend's
cable modem some years ago: when she originally had her cable internet
installed, her provider was using those monstrous LANcity cable modems
(the ones that look like car-audio amplifiers).  When they "upgraded"
her to a new Motorola modem, her internet suddenly stopped working.
Numerous visits were made by technicians over the next six months, some
with new modems (of the same type), some with signal boosters, one even
running a new dedicated line from the terminal block to her desk.  Their
diagnostics all showed a good signal strength, the help-desk people
could always communicate with the modems, but she wasn't getting an
internet connection.

Finally, after an extended reaming-out by my friend, the company sent
out one of their most senior techs, with instructions to stay on site
until he had it fixed. It didn't take him long to determine that the
cause was a missing earth-ground connection on the outside terminal
block, which was leading to a 60Hz hum being induced on the all the
cable drops in the house.  It didn't affect the TVs or cable boxes, and
the old modem had had more robust filtering, so it wasn't affected
either, but the new modems couldn't "see through the noise".

Driving a new grounding stake and connecting the block to it cleared
things up, but apparently that sort of hands-on troubleshooting was
beyond the thinking of all the younger, fresh-out-of-tech-college
technicians they'd sent out previously.