Re: Cause of some major X10 problems found

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

Jeff Volp and Robert Green wrote:

RG> > Also, the PS's noise could have collided with a legitimate command the
> > Stargate was issuing at the time of occurrence and corrupted it.
>
JV> This does happen, and is not rare.  Here we have four Ocelot macros that
> turn on/off all interior or exterior lights.  Those are the ONLY commands
> that can cause the Ocelot to issue a long series of X10 commands.

Corrupted commands are another reason why I like the Monterey (sorry for the
brief excursion but your comment brought it to mind and I'm too lazy to
start another message!)  Sometimes, in the midst of BSC's streams I'll see a
lower case letter of a housecode I don't use.  I assume that's a collision
creating a valid *single* frame of X-10 data.  While I believe it would take
a very long time indeed for random noise to generate a double data frame
with a perfect second copy, I think the creation of the single frame has a
far greater probability of occurrence.

Am I correct in assuming these Frankensteinian combined codes work because
the X-10 error protocol is a single bit one and does not provide any method
of knowing if all the transmitted characters came from the same source or
arrived without corruption or substitution?  That might have been done using
the second copy of the frame against the first, but it seems the 2nd frame
was there mostly for redundancy.

I wish this had all come up when I still had the Marrick Lynx and could see
the raw data bits and what the Lynx interpreted them to be.  Since it showed
data at the one's complement level, you could see what the receiver saw
without any further processing (unless you asked it to do that).

> While developing the XTB-II a year ago, there were numerous occasions when
> my CFL "noise source" morphed another X10 command into triggering one of
> those macros.  At first I didn't understand what was going on, but
capturing
> the data strings on the logic analyzer showed the imbedded extended
commands
> used for the Leviton dimmers.  I was triggering remote commands from a
> palmpad via a RR501.  The CFL noise apparently morphed the RR501 output
into
> one of the macros when it was received by the PSC05 feeding the Ocelot.

This behavior, IMHO, explains at least a few of the reports of strange
housecodes and commands showing up in the file.  I think Dave suggested that
some created commands are more likely than others.  I wonder if I could
deliberately set up two minicontrollers on different housecodes, lock them
in to transmit forever and then process the resulting huge log from the
CM11A.EXE program to extract a distribution of the randomly created "fused"
commands.  After a while, it should tell us something about which valid
commands are more likely to be synthesized via collisions.  Especially if I
stepped through each house code and unit code for an hour each for a few
days.  God, I wish I had ten grad students!

I'm not sure how useful such information would be to anyone, or even how
germane it is to the noise issue, but it would be nice to know if something
like J Status request really did appear far more often than any other code.
Particularly in helping people who post questions about seeing command "X"
in their logs, when they're sure they didn't send it.

> I haven't seen this recently while working on the XTB-IIR - possibly due
to
> my now using a XTB-II as the powerline interface for the Ocelot.

Something tells me yours might be the better of the two designs considering
in all their 20+ years of designing X-10 gear, they never thought of the
XTB. (-:

--
Bobby G.