Re: Cause of some major X10 problems found
- From: "bruceR" <nospam@xxxxxxxxxxxxx>
- Date: Tue, 11 Sep 2007 16:40:54 -0500
I'll be to provide the Power Supply (as soon as I get my wife a replacement)
for further research. I can probably provide the switch as well. The switch
is most likely an X10 Pro or Leviton ONE way switch.
Robert Green wrote:
"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.
From what Bruce described, these switches, if X-10, are the two-way
model because the regular WS-467 doesn't have the "soft ramp" feature
he was describing. Without a make and model number though, we really
don't have good information as to whether those switches are similar
enough to the ones Bloom tested to know if they're triggering as a
result of line noise. Without pulling a susceptible switch and bench
testing it against the powersupply, we've got less than enough facts
to reach an unimpeachable conclusion.
Too bad the Monterey doesn't log events because someone might be able
to catch a a valid single frame transmission among all the BSC's if
it were possible to capture the reams of data the Monterey produces
under such conditions. I wonder if I can put a macrocam on the
display and feed the image into an optical scanner with OCR. It
should be able to see each update of the display and then I'd just
text search the resulting document for letters other than BSC. Oh
great, another damn project. If only I had grad students slaves! (-:
If the funky power supply can trick the Monterey into reporting bad
strings of X-10 signals to the point of differentiating such noise as
X-10 1 or 0 bits, it's already half-way to the point of creating
something that can trick a much dumber lightswitch to activate.
I understand that there's error-checking built-in the X-10 protocol,
but it's pretty primitive. I also understand that there are plenty of
impossible things that happen all the time. Who would have thought
light pieces of foam could do enough damage to the shuttle to bring
it down? Until they ran the tests and they saw the pictures and
examined the damage very closely, there were plenty of engineers and
rocket scientists who went on record with great conviction to say it
was impossible.
I guess the only person who can make the determination of why those
lights lit for certain is Bruce, since he's got the magic power
supply, the light switches in question and a means to further analyze
the situation: the Monterey.
Sadly, most threads about bad X-10 devices usually end here with the
application of a filter because most people just want to get their
system back to working order. I doubt many people would want to sit
around in a dark house next to a Monterey analyzer waiting for a
light to turn on randomly so they could freeze the display when it
happened to see what was coming down the wire at the time.
Maybe Bruce will buy a replacement and send the magic supply to you
for further analysis so you can see on the scope what's happening.
It would be nice to know for sure because reports like this seem to
turn up with regularity. Maybe he'll give us the exact model number
of the PS so anyone so inclined to investigate further could buy
their own.
So I guess these are all "questions for the ages." I'm still
troubled by why the activations are so infrequent if the noise level
is constant. Perhaps the power supply produces noise irregularly at
different points in its operation cycle. Or maybe by saying "random"
Bruce did imply that they were activating incorrectly fairly rapidly.
Knowing the switch make/model, the rate of activation, the PS's
proximity to the affected switches, the noise level at those switches
and the strength of the noise emanating from the PS would all be very
useful items in determining the true nature of the interaction.
As far as I can tell, no one claims that Manchester encoding is highly
resistant to errors. AFAIK, it was used by X-10's designers mainly
to save bandwidth. At least that's how ACT's Phil Kingery describes
it:
http://www.act-solutions.com/kingery18.htm
<<Since the X-10 protocol is limited in baud rate by the very sine
wave itself (either 60Hz or 50Hz on this planet), the X10 engineers
could not afford to include sophisticated checksums, nor cyclic
redundancy checks or even a parity bit to increase dependability.
They only had two ways to do it. First, they used what is called
"Manchester encoding". That meant that every "1" bit was actually
sent with its complement, or 1+0. Every "0" bit was sent with its
complement, or 0+1. This greatly increased the reliability of the
data frame since single-bit errors were quickly identified and the
data frame could be discarded.>>
Without parity bits or CRC checking, I'm not sure how error-resistant
the X-10 protocol truly is, especially when "attacked" by 5 million
random bits* per day.
The bottom line is still "get a meter and a box of X-10 filters" if
you want to keep your X-10 running smoothly. I'm a little surprised
that the noise overwhelmed the XTB, but I assume the PS was located
fairly far from the XTB. I also never realized how difficult a good
repeater is to design until I read the Kingery article about preset
dims and the changes X-10 made to the protocol in midstream.
*5,184,000 bit at 60Hz times 60 seconds times 60 minutes times 24
hours. Granted, that has to be divided by eleven for a sequence of
bits to constitute a single, valid X-10 frame, so the number drops to
471272.
.
- References:
- Cause of some major X10 problems found
- From: bruceR
- Re: Cause of some major X10 problems found
- From: Dave Houston
- Cause of some major X10 problems found
- Prev by Date: Re: Cause of some major X10 problems found
- Next by Date: Re: Cause of some major X10 problems found
- Previous by thread: Re: Cause of some major X10 problems found
- Next by thread: Re: Cause of some major X10 problems found
- Index(es):
Relevant Pages
|
Loading
