Re: Cause of some major X10 problems found

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Jeff Volp" <JeffVolp@xxxxxxx> wrote in message
news:sjxFi.526260$p47.277528@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
> news:46e77e9f.1595333671@xxxxxxxxxxxxxxxx
> > "Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:
> >
> > 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.
>
> It may be near zero, but I have documented on my logic analyzer that it
can
> happen.  You may remember an earlier post regarding beating compact
> fluorescent lights producing peaks and valleys similar to a X10
> transmission.  I found that about 2 minutes after I switch on my CFL
"noise
> generator" the beat frequency between a couple of the bulbs gets low
enough
> that the peaks and valleys occur on alternate half cycles.  If the
receiving
> module just happens to catch enough noise 3 times in a row to recognize a
> start pattern, the remainder of the message with alternating 1-0's does
get
> through as a valid command.  Even with the enhanced error detection
> requiring complimentary 1-0's, I did capture one squeaking through.

That's fascinating.  Do you remember the strength of the signal the CFL's
generated?  Was it low enough so that something like a Stargate located at a
distance might not even record it but a nearby light switch would?

You've touched on two things that could shed a little more light on the
problem (and that I touched on my in previous screed).  Noise generators can
act differently depending on their operational cycle.  Bruce's charger could
easily emit three different types of noise depending on whether the charger
had nothing in it to recharge, whether it was loaded but the batteries were
dead or whether they were fully charged.

More importantly you've actually observed the ivory billed woodpecker of the
X-10 world in the wild.  We've seen repeated reports of ghost commands in
this group for a long time now.  While sightings don't necessarily prove the
existence of the ivory bill, in this case there's relatively little
motivation for people to repeatedly report seeing bizarre codes coming out
of nowhere.  The woodpecker's at least brought in the tourist trade and
stands at the cusp of important environmental issues, so phony sightings
could be made by folks with an agenda.

The random code generation reports seem to imply (some do, anyway) the bad
codes come at an interval that would more in line with the random good code
generation theory than the Bloom theory.  It doesn't mean the Bloom theory
is invalid, it's just that it might not be sufficient to explain all cases
of random turn ons.  The issue gets even more complicated when you realize
that light turned on by the Bloom method may indeed be swamped by 1,000s of
spikes that trigger false ON's, but since it's ON, it shows no further
influence until you turn it OFF again.

Maybe Bruce will donate his noisy PS to you in the name of science so that
you can examine it on your logic analyzer.  Do you give XTB factory tours?
(-:  I'd love to see the analyzer in action.  It sounds far superior to both
the O'scope and the Monterey for getting detailed information about the X-10
signal.

The more I read at the ACT site, the more respect I have for all the cases
the XTB-IIR has to recognize and deal with (and fast enough to be useful!).
Especially as I piddle along with my lowly 6 input/two clock BSD.  When you
around to designing the XTB-IIIR please add an auto-configure mode like my
LCD TV.  It figures out what I plugged into it and sets its mode
accordingly.  (-:  At least I understand why repeating preset dims (PK calls
them Direct Dims, more intuitively) is next to impossible and why X-10
abandoned them.

--
Bobby G.