Re: Cause of some major X10 problems found

["D&SW" <d&sw@xxxxxxxxxxx>]

>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!"

Bob! you are a home automation guru and you don't have a Stepford model?

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote in message
news:Ds-dnfYNcqYuuXrbnZ2dnUVZ_hqdnZ2d@xxxxxxxxxx
> 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.
>>
>>
>
>