Re: XTB-II TW523 Emulation

["Jeff Volp" <JeffVolp@xxxxxxx>]

Thanks for the feedback Dave,

I replied below:

"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
news:452806c7.180293062@xxxxxxxxxxxxxxxx
> "Jeff Volp" <JeffVolp@xxxxxxx> wrote:
>
> >The one thing I am concerned about is collision detection.  Documentation
> >for the TW523 says: "Any signals applied to the O.E.M. product are
> >error-checked, valid X10 codes."  Since all bit patterns are defined, the
> >only possible errors are a bad start pattern, or a mismatch in the bit
> >halves.  The XTB-II rejects any message with either of those errors.
During
> >transmission, X10 says: " The ability to read X-10 codes from its own
output
> >also allows the O.E.M. to incorporate data collision detection.  If the
code
> >received differs from the code transmitted, the code can be assumed to
have
> >been corrupted by noise (or another transmission) on the powerline."  The
> >fact that the XTB-II does not return any message when there is an error
> >meets that condition.
>
> That's a problem. ADI did this initially with the first few CPU-XAs but I
> caught it and they fixed it early on. You need to report the errors when
> they form valid X-10 codes (almost always from collisions) as X-10
receivers
> will respond to the erroneous codes if they happen to be for their address
> or housecode. The TW523 will report them.

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.

> There may also be a problem with the way you determine good/bad. Just
> checking for nine 1s isn't adequate. You need to check that there are no
> runs of three consecutive 1s or 0s.

I'm not sure how to create a bogus start pattern from a collision without
counting the extra "1".  The only way we can detect a collision is have a
"1" appear in a "0" half cycle.  That would corrupt the tally at the
decision point.  The only messages that will be accepted must begin with a
start pattern, and have exactly 12 "1"s at the 22 half-cycle point.  That
includes all 512 valid X-10 codes.

> It should be noted that since the TW523 delays its output for 22
half-cycles
> its impossible to avoid collisions or to practice "polite" transmissions
> when using it. All that can be done is to detect collisions after the
fact.
>
> In your case, you can monitor the powerline and stop transmitting when you
> see a 1 when sending a 0. This is how the CM11A and CM15A operate. While
the
> first copy of any code may be corrupted, the second copy will be OK. You
can
> then retransmit once the line is clear.

That is easy to do, but I don't want to stray too far from how the TW-523
operates to avoid unforeseen problems with the controller (which is supposed
to have the smarts).  I wanted the XTB-II to be virtually identical to the
TW-523 for all standard length messages.  The only deviation would have been
in accepting concatenated dims and extended messages.

However, if the XTB-II automatically aborts a transmission immediately upon
detecting a collision, and doesn't echo that message to the controller, then
the controller should recognize the corrupted transmission and try again.
Can anyone shoot holes in this scenario?

> Also, off the top of my head, I think the Ocelot/Leopard will report the
> first part of the extended code but I may be confused from staring at
> roZetta's output screens for a few hours.
>
> http://www.davehouston.net
> http://tech.groups.yahoo.com/group/roZetta/
> roZetta-subscribe@xxxxxxxxxxxxxxx