[sci.electronics] X-10 protocol, and TW523

dennisg@felix.UUCP (Dennis Griesser) (03/23/91)

Awhile ago, I posted:
> Although I have one of the TW-523 two-way power-line interface modules, I can
> not recommend it in good conscience.  The interface is much tougher than it
> need be, it costs too much, and it has been castrated so that a large and
> useful subset of the X-10 commands cannot be received (you can send anyhting
> you want).

This caused bender@oobleck.Eng.Sun.COM (Michael Bender) to ask:
> How does it work?  What do you get out of it?  A bit stream?  How
> did they castrate it?

The following information comes from several published sources, with special
emphasis on a technical note entitled "The X-10 POWERHOUSE Power Line
Interface Model #PL513 and Two-Way Power Line Interface Model #TW523", revision
2.4, by Dave Rye.  No visible copyright.

For a moment, let us digress into the format of X-10 signals on the line.
To send a "1" bit, you transmit a set of three pulses, each 1 millisecond
long, starting on a zero crossing, with 1.778 milliseconds between pulses.
If you look at the AC power line, the pulses take the form of 121-kHz bursts.
From a binary standpoint, you turn on the oscillator gate.  To send a "0"
bit, you don't send out the set of three pulses.  Whichever bit you send must
be complimented on the following half of the line cycle.

So, through the magic of ASCII graphics, we can show a "1" bit:
                 ## ....
                 ##.    ...##--------- 121 kHz
              ...##        ##.      __ 60 Hz.
            ..             ## ..   /
           .     |         |    . /
          .                      .
         .       |         |      . 
         .                        . 
        .        |         |       .
        .                          .
       .#        |         |        . 
       ##                           . 
  -----##--------|---------|--------.----------------------------.----
       #                            .                            . 
       |         |         |        .                            . 
                                     .                          .
       | 2.778-> |         |         .                          .
                                      .                        . 
       | 5.556->           |          .                        . 
                                       .                      .
                                        .                    . 
                                         ..                ..
                                           ...          ...
                                              ...    ...
                                                 ....

Observe that a "0" bit looks rather like a "1", except that it does nothing
for the first half cycle, and puts the three bursts in the second half.
Since a bit can start on any zero-crossing (either a positive-going or
negative-going half cycle), it is possible to mistake a "0" for a "1" and
visa-versa if you don't know exactly when the message starts.  For this
reason, the protocol begins with a special "start code", which consists of
three consecutive half-cycles containing triple bursts, and one quiet
half-cycle.

A single X-10 packet takes 11 cycles of the AC line:
  o 2 cycles for start code
  o 4 cycles to transmit a 4-bit house code
  o 5 cycles to transmit a 5-bit function/key code
If we use '*' to indicate a set of three 121 kHz bursts, a packet looks like
this:
   _     _     _     _     _     _     _     _     _     _     _     _     _    
  / \   * \   * \   / \   * \   * \   / \   / \   * \   * \   / \   / \   / \  
     \_/   *_/   \_/   *_/   \_/   \_/   *_/   *_/   \_/   \_/   *_/   *_/   \_/
        |           |  0  |  1  |  1  |  0  |  0  |  1  |  1  |  0  |  0  |
        |start_code |       house_code      |        function_code        |

OK, let's get down to the Two-Way Power Line Interface Model #TW523, starting
with the transmit side.  You are provided with:
  o a 121 kHz oscillator, coupled into the AC line
  o an amplified and clipped copy of the AC power line
By watching the AC line, which comes in as a square wave, you can detect
zero-crossings.  This is necessary to properly synchronize X-10 transmissions.
To transmit, you toggle a bit that gates the oscillator.

I like to refer to this type of interface as "gate and sync".  Due to the
particular format of the signal, you can't use a vanilla UART or any
common serial code for this.  Either you cobble up your own UART out of
discrete parts like shift registers, or you write bit-banging code.  No
big deal, really.

Given the simplicity of the transmit function, I would expect the receiver
to be equally bare-bones, such as a PLL or filter that tells you when you have
a 121 kHz signal on the line.  Then you write the receive side of the
software UART (with X-10 torques) and off you go.

But X-10 USA _loves_ us!  They don't want us to have to wade through all that
icky code.  So they embedded a single-chip micro into the interface.  This
MCU does a couple of things for us:
  A - converts incoming 3 bursts per bit into 1 pulse
  B - demands two adjacent packets for redundancy
  C - eats half of the packets
It might also be doing the following:
  D - compares 121-kHz bursts with the line zero-crossing to insure validity
  E - compares two adjacent packet samples for redundancy

In other words, you have to send everything _twice_, right next to each other.
And then, before sending anything else, you need to wait for 3 full cycles.
The MCU absorbs the first packet.  If it is properly formatted, the first
packet is clocked out to the computer while the second packet is coming in.

Let's consider what the MCU buys us, using the letters for the functions
above:
  A - Converting the 3 bursts into 1 pulse makes things a tad easier for us.
  B - Not a bad idea, IFF everything is guaranteed to be in pairs and hence
      checkable.  Unfortunately, certain legitimate X-10 codes are _not_
      sent in pairs.  They can not be received by this unit!
  C - Only a win if pairs are guaranteed for all good packets.  Nope.
  D - I doubt that they did this, because it would require acceptance of three
      different possible zero crossings to accommodate the three phases in
      the line.  If they really do, it's a win.
  E - They don't do this, which pretty much makes the whole pair of packets
      thing a farce.  From the way that I read the paperwork, they hold the
      first packet until they see the second, then ship the first while the
      second is coming in.  Then they catch the third and ship it while the
      fourth is arriving.  They state that "The TW523 can receive dim and
      bright codes but the output will represent the first dim or bright
      code received, followed by every third code received..."
Actually, even if they _did_ conduct more stringent tests on the second
packet, we are hosed because the first is clocked out as the second comes in.
If the second packet turns out not to match after getting half-way in, there
is no mechanism to abort!

So where do we get really bitten?
  o Can't receive the following codes:  "extended code", "extended data".
  o "bright" and "dim" are quirkey
So who cares about the "extended" codes.  They were wedged into unused bit
patterns of the X-10 protocol for future use.  Nobody uses them now.  Who
cares?  Well, why was the cover of the document emblazoned with an exhortation
to "See the exciting new additions to X-10 Code Structure on page 5"!
Exciting codes that we can't receive.  Wow!

May I provide a theory about why this was done?

The X-10 code format is patented.  Yeah, like "backing store" and "XOR cursor".
When you buy this interface module, you effectively receive a license to
use X-10 codes through the device.  Let me quote from the note:
  Any O.E.M. product designed to receive X-10 codes MUST use the TW523.
  X-10 will not grant permission to receive X-10 codes by any other method.

There you have it.  You can compete with X-10 USA by making plug-compatible
equipment.  But you have to use their box in your unit, and it is unable
to use the exciting new codes.

Normally, I don't buy conspiracy theories, but this time....

While I'm in a feisty mood:
  o Since they went to the trouble of putting an MCU into the interface, I
    would just as soon have the thing convert the code into a bitstream
    acceptable by normal serial ports.  Then we could bail the bit-banging
    software.
  o Does anybody know the patent number for the X-10 protocol?  I would love
    to have a copy of the thing.
  o The zero-crossing synchronization is an important part of the X-10
    protocol.  If I wrote bit-banging receive software that didn't test for
    zero transition, but error-checked the packet other ways, could I receive
    packets from genuine X-10 transmitters without violating the patent?