Re: Cause of some major X10 problems found

["bruceR" <nospam@xxxxxxxxxxxxx>]

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.