XTB-II TW523 Emulation

I don't know whether it will cause any problems. I doubt it but only the manufacturers of various controllers can answer that.

When Dan Boone was still at ADI we discussed a TW523 compatible interface that would do what you propose and Dan indicated he would willingly rewrite his PIC code to handle it should it become available. At that time Paul Beam (he designed the ESM1) was considering designing something along those lines. Whether ADI or other controller makers would make changes to accomodate it is an open question.

The XTB-II has been working fine with my Ocelot for the last couple of days. I can trigger macros from various Leviton 16400s or via RF through a RR501. So the standard communication mode is working fine. The LM14A supposedly includes a mode where it returns its brightness setting as an extended message, but I haven't tested that mode since the Ocelot has no support for it.

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.

If anyone can see a problem with this approach, please let me know. I could eliminate error checking during transmission, but that does not meet the condition that the TW523 is supposed to return only valid X10 codes. The TW523 receiver works the same for both transmit and receive. If it can return a corrupted message during transmission, it must also return a corrupted message during normal receive.

Jeff

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.

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.

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.

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.

Thanks for the feedback Dave,

I replied below:

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.

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.

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?

It wasn't clear from your wording that you were relaying all of the 512 bit patterns of the X-10 universe or just those that matched the code being transmitted. ADI originally did not report codes that differed from what was being transmitted.

From your wording, "It checks the next 18 bits, and rejects any message without 9 "1" bits." codes of 1110111111111000000000, 1110111000111000111000 or even 11101111111111111111111111 could be valid - all with 9 "1" bits.

I'm not familiar with how all the various controls deal with collisions. Initially, ADI would retransmit forever (as does ACT). I tried to persuade Dan Boone otherwise to no avail but I think they later did change it and now retransmit some maximum number of times. The original LynX-10 could be set to retransmit (forever) or the auto-retransmit could be disabled. Some of the others talk about polite transmissions, checking for a clear line, and collision avoidance so it's obvious they never understood the TW523.

The TW523 does report the first 22 bits of an extended code.

Ah, I didn't make that clear. As you know, each data bit is transmitted with its compliment in adjacent half cycles. I should have said it checks the next 18 "half cycles", and exactly 9 of those should be "1". A collision must add an extra "1" to be detected. That causes uncertainty at that bit position, and the message should be rejected.

Here is a case where a TW523 steps on a line message in such a way that its own transmitted signal appears valid from the beginning of its own start pattern: (view in fixed font)

Msg 1: 1110101001101010010110 (line) Msg 2: ------------1110010110101001100101 (TW523) Msg +: 1110101001101110010110101001100101 (collision) Decod: 1110101001101110010110 -> Rejected (module)

Assuming the module can hear both transmitters, it should be decoding the message on the line when the TW523 steps on it. The extra 1 from the start pattern causes uncertainty in that bit position, and the module should reject the message. The receiver in the TW523 should also have been decoding the line message when its transmitter started, and should also reject the corrupted message. The XTB-II does the same.

Regardless of who steps on who, or how well data bits are aligned, I believe the start pattern will almost always cause an extra "1", resulting in an error. The only case I can come up where this is not true is if the second transmitter comes on during the last "1" of the first transmission. In that case the first transmission is valid even though it did not end in a gap.

Jeff

| 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

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