Re: XTB-II TW523 Emulation

["Jeff Volp" <JeffVolp@xxxxxxx>]

Thanks for the input Dan,

Obscure is good.  And yes, I care.  I worry about the details.  I did make a
change based on this discussion to properly handle the case when a second
transmission steps on the last "1" of the previous transmission.

The XTB-II will accept another start pattern immediately after a corrupted
fixed length message (no gap necessary).

Unfortunately, the X10 documentation is open to interpretation.

Jeff

"Dan Lanciani" <ddl@danlan.*com> wrote in message
news:1334143@xxxxxxxxxxxxxxxxxxxxxx
> In article <ZPVVg.36970$QZ1.22584@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
JeffVolp@xxxxxxx (Jeff Volp) writes:
>
> | All possible 512 bit patterns are defined by X10, and would be reported
by
> | the XTB-II.  The only erroneous codes would have an extra "1" pop up in
a
> | complimentary zero position.  Those patterns are now rejected by the
XTB-II.
> | Since there doesn't appear to be an "error" message to alert the
controller,
> | the only option seems to be to reject that message entirely.  If the
TW-523
> | returns messages with corrupted bit patterns, the XTB-II can certainly
do
> | that too.  But that means the X10 statement that the TW-523 only passes
> | valid X10 codes is incorrect.
>
> This is getting kind of obscure, but just in case you care...  When I was
> doing all the SwitchLinc testing I found that (some?) genuine X10 modules
> fail to verify one of the complement bits as well.  I forget which bit it
> is (it isn't at the end so it doesn't cause much trouble) and I didn't
> check whether the TW523 has this problem.  If the TW523 does ignore that
> one error you might want to as well since receivers may act on the
command.
>
> Another interesting issue is what you do once you have decided that a
frame
> is bad.  Original X10 modules appear to skip the (as far as they are
concerned)
> fixed-length frame before looking for a new start code.  They do *not*
look
> for a gap first, so a corrupt frame followed immediately by a good frame
> (as you might see in a repeated environment) works correctly.  Some third-
> party products appear to start looking for a start code immediately after
> seeing a complement error, and this seems to cause problems.  Other
products
> look for a fresh gap followed by a start code, breaking repeater
operation.
> Extended codes violate the fixed-length frame assumption, so a module
which
> does not understand them will be looking for a start code while the
extended
> code is still in progress.  I don't think this causes much trouble.
>
> Dan Lanciani
> ddl@danlan.*com