Re: Cause of some major X10 problems found

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

bruceR" <nospam@xxxxxxxxxxxxx> wrote in message news:46e70b19$0$32469

> 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.

You just made me spit my coffee on the screen.  My bifocals elided the
letter "a" in your first line so I saw "as soon as I get my wife
replacement."  (-:  I thought "boy is this guy tough.  His wife plugs in a
signal sucker and she's out the door!"

I'm sure other X-10 diehards like me appreciate your contribution to
science.   I'd be interested to know if the same power supply effects
Insteon transmissions, so if you can, you might want to wait to send the
gear to Jeff or Dave after you've tested it against Insteon.  That would
really give us some insight into the X-10 v. Insteon debate.  The unit
certainly sounds as if it would be a great item for Jeff to check his noise
rejection circuitry against, as well.

--
Bobby G.


> 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.
>
>