[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: XTB-II TW523 Emulation



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


comp.home.automation Main Index | comp.home.automation Thread Index | comp.home.automation Home | Archives Home