[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]
Re: Cause of some major X10 problems found
"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
<stuff snipped>
> >I seem to recall postings that indicated a device like a noisy PS could
> >never generate a signal randomly capable of triggering an X-10 device but
> >your experience seems to indicate that's not so.
>
> The probability that a noise source will create valid X-10 PLC codes (1110
> followed by manchester encoded data synchonized to powerline half-cycles)
> out of whole cloth is near zero - it ain't gonna happen. However, there
are
> other explanations for the unwanted ONs & OFFs - see the link I cited in
my
> response to Bruce.
Maybe the devices were made by the same 50 monkeys and typewriters that are
claimed to be able to reproduce the works of Shakespeare if given sufficient
time. (-:
There could be a number of reasons for the Stargate not seeing anything. The
power supplies' noise signal could be too weak to activate anything except
nearby lights. Certain lights nearby would be affected, but the Stargate
would not be within range. Since Bruce uses an XTB, one might suspect that
weak signals don't propagate far in his house. There's not enough info to
know for sure.
Also, the PS's noise could have collided with a legitimate command the
Stargate was issuing at the time of occurrence and corrupted it. We don't
know much about exactly which lights came on and off and when they did it.
AFAIK, the Stargate can't transmit and receive a command simultaneously.
While I believe that generating whole commands out of random line noise is
rare, I believe that a continuous noise source corrupting valid X-10
transmissions is far more likely. That might show up if the random "turn
ons" turned out to occur precisely when some other X-10 activity that was
supposed to occur at that time didn't. We don't know if that's the case,
either.
We also don't know whether the Stargate considers a valid command to consist
of a valid first and second copy embedded in the single X-10 message or
either one being valid. More correctly said, at least *I* don't. I suspect
it does, but whenever repeaters are present, both "data frames" within an
X-10 need to be considered.
I do know that the Monterey analyzer is able to distinguish between codes
that are complete (containing two frames) versus ones that have only one
valid 11 cycle frame, which it reports using a lower case housecode A light
switch appears to trigger with either code, from what I've seen. One might
ask why they duplicate the frame if Manchester encoding provided enough
error checking, but there are plenty of other reasons to duplicate frames,
and repeater designers can testify to them all. (-: I'll absolutely agree
it's impossible to duplicate a complete double frame transmission of X-10
data under these circumstances, but a single, 11 cycle frame is a different
animal.
Since I don't have a Stargate, I can't make any guesses about how it reads
commands with only a single frame or whether it sees them at all,
particularly with an XTB and a SignalLinc repeater thrown into the mix for
good measure. FWIW, I doubt the XTB is involved in any way. Its presence,
though, strengthens my belief that the JDS unit just didn't read the
"created command" because it was too far away from the source of the noise
generation. Bruce did say the effects appeared to be local one area in the
house.
What I don't understand about the Bloom theory as it might apply here is why
aren't the lights flashing off and on rapidly in response to the apparently
continuous noise? I'm assuming it's fairly constant in amplitude so if the
switches are truly that susceptible, they should be going on and off like
crazy, shouldn't they? If, however, they're responding to a single 11 cycle
signal they see as valid generated out of random noise, one would expect a
very much more infrequent activation. That latter case sounds more like
what we're seeing. Activations that occur after 10's of thousands of random
bits have been thrown onto the line.
comp.home.automation Main Index |
comp.home.automation Thread Index |
comp.home.automation Home |
Archives Home