X10

X10 is a protocol for communication among electronic devices used for home automation (domotics). It primarily uses power line wiring for signaling and control, where the signals involve brief radio frequency bursts representing digital information. A wireless radio based protocol transport is also defined.

Programming the LM15A


To program the Socket Rocket (LM15A):

  1. Plug your lamp into an outlet (no extension cords, surge protectors, or power strips).
  2. Plug your controller into the outlet nearest the LM15A.
  3. Turn the lamp on.
  4. Unplug the lamp, leaving the switch in the On position.
  5. Unscrew the bulb and screw in the Socket Rocket, and then the bulb.
  6. Plug in the lamp’s power cord. You now have thirty seconds to program the Socket Rocket.
  7. With your plugin controller, send the On command for the code you want to assign to the Socket Rocket (i.e. A4). Send the On command every half-second until the Socket Rocket turns on. In reality, you only need to send three On commands, but send more than three, just in case a signal is not received.
  8. When the light turns on, wait until the thirty seconds have passed. The Socket Rocket is now programmed with the code you want.
  9. If the Socket Rocket does not program, relocate the controller and the lamp to a surge protector. This will create a small closed circuit. Also, verify that the bulb used is 60 Watts or higher. Go back to step 6.

Note: If the Socket Rocket loses power and then regains it, the thirty second programming window opens. If you do not want to change the code, do not send any On commands during this time and the previous code will remain.


April 2, 2014 by X10 0

CM11A Communication Protocol File


Interface Communication Protocol
Version DBS 1.2

Originally taken from the X10 web page Dec 25, 1996. Some
mistakes corrected. DBS Jan 1, 1997 Updated Jan 24 to match the
Jan 6th version of X10’s doc. The main difference was the cable
pin-out.

Index

1. X-10 Transmission Coding (overview).

1.1 Housecodes and Device Codes.

1.2 Function Codes.

2. Serial Parameters.

2.1 Cable connections:

3. X-10 Transmission.

3.1. Standard Transmission.

3.1.1. Header:Code.

3.1.2. Interface Checksum and PC Acknowledge

3.1.3. Interface Ready to Receive.

3.1.4. Example.

3.2. Extended X-10 Transmission.

4. X-10 Reception.

4.1. Interface Poll Signal.

4.2. PC Response to the Poll Signal.

4.3. Interface Serial Data Buffer.

4.4. Dim or Bright.

4.5. Extended Code.

4.6. Example.

5. Fast Macro Download.

5.1. Power-fail Macro Download Poll Code.

5.2. PC Response to Macro Download Poll Code.

5.3. Macro Code (CM10).

5.3.1. Dimming and Brightening within a macro.

5.3.2. Extended codes in macros.

5.3.3. Checksum.

5.3.4. Example.

5.4. EEPROM Code (CM11 and CP10).

5.4.1. Macro Offset.

5.4.2. Timer Initiator.

5.4.3. Macro Initiator.

5.4.4. Macro data.

5.4.5. EEPROM Data Transfer.

5.4.6. Example.

6. Serial Ring Disable

7. EEPROM Address (executed via macro initiator).

8. Set Interface Clock.

9. Status Request.

10. Power-up Timer.

10.1. Transmission Protocol

11. Relay Control.

12. Input Filter Fail.

April 2, 2014 by X10 0

How X-10 Works


The method used by X-10 is based on a simple
data frame with eight data bits (one byte) preceded by a predetermined start code.

hti-2-01.gif (12580 bytes)The complicated part of this technology was not the system of binary data,
but the method in which it was transmitted from one device (the transmitter) to another
device (the receiver). The key was for every device to have an integral “zero
crossing” detector so that all of them were synchronized together (figure 1). A
receiver opens its receive “window” twice each sine wave (figure 2), that is 120
times each second or 7,200 times each minute. (ThatÂ’s 432,000 an hour, or 10,368,000
a day! That means itÂ’s looking for little pulses of data 3,784,320,000 times a year
!!….at 60Hz, anyway.)

hti-2-02.gif (12500 bytes)Since these devices would not have any direct wiring between them, it was
necessary to devise a way of sending the data over the existing electrical wiring. The
actual binary data is transmitted by sending 1ms bursts of 120kHz just past the zero
crossing of the 60Hz power. (While North America remains the primary market for X-10 based
devices, products are also available which are designed for use on 50Hz electrical
distribution systems.) It was also obvious that complementary bit pairs were necessary.
Therefore, a binary “1” was defined as the presence of a pulse, immediately
followed by the absence of a pulse. A binary “0” was defined as the absence of a
pulse, immediately followed by the presence of a pulse (figure 3).

hti-2-03.gif (23622 bytes)

While the transmitted pulses were to be a full 1ms in duration, the
receivers were designed to open a receive window of only .6ms. That allowed for the loose
tolerances of the 1978-era components to “slop” plus/minus 200m sec.

In order to provide a predictable start point (figure 4), every data frame would always
begin with at least 6 leading clear zero crossings, then a start code of
“pulse”, “pulse”, “pulse”, “absence of a pulse”
(or 1110).

hti-2-04.gif (16616 bytes)hti-2-05.gif (16874 bytes)

Once the Start Code has been transmitted, the first nibble is sent. (If you are not
familiar with the term “nibble”, that means 4 bits or half a byte.) In order to
make it easier for the consumers to operate the devices, this first 4-bits were given
“letter” code designations (figure 5). It was also decided to randomly rearrange
the patterns so that the “A”, “B”, “C” codes, etc., did not
fall in the predicable binary pattern. It is easy to see that in reality, the
“M” code is first in the binary progression.
hti-2-06.gif (21026 bytes)

In one contiguous bit stream, the second nibble provides the second
half of the address (figure 6). The last bit appears to be a part of the
“number” code but in reality it is a function bit. Whenever this function bit is
a “0”, it designates the preceding nibble as a number code and therefore a part
of the address.

For purposes of redundancy, reliability and to
accommodate line repeaters, the X-10 protocol calls for every frame of data to be
transmitted twice (figure 7).

hti-2-07.gif (22038 bytes)

Whenever the data changes from one address to another address, from
an address to a command, from one command to another command or from one command to
another command (figure 8), the data frames must be separated by at least 6 clear zero
crossings (or “000000”). When teaching classes in this stuff, I often say that
this gap “gives the receivers a chance to catch their breath“. In
reality, of course, the sequence of six “zeroÂ’s” resets the shift
registers.

hti-2-08.gif (19819 bytes)

Once a receiver has processed its address data, it is ready to
receive a command. As before, all data frames must begin with a start code. Then the
following nibble gives the letter code (figure 9). The next nibble is the command. Since
the last bit is the function bit (bf = 0 = address number, bf = 1 =
command) all the commands end in a binary 1.

hti-2-09.gif (20733 bytes)

This diagram (figure 10) only shows the six most often used
commands. A later graphic will illustrate all the available commands. As before, all X-10
protocol transmitters send their data frames twice (figure 11).

hti-2-10.gif (17792 bytes)hti-2-11.gif (22216 bytes)

hti-2-12.gif (24333 bytes)

Figure 12 shows that an example transmission of two data frames (A1 A1 A-On
A-On, for instance) would take 47 cycles of the 60Hz sine wave. That would equate to
0.7833 seconds, or in practical terms, just under 1 second. Of course, some commands take
less time. When sending an “All-Lights-On” command, for example, no address
needs to be sent. Therefore the entire two frame sequence takes only one third of a second
(actually, 0.3666 seconds, but whoÂ’s quibbling). If your receivers react on the first
frame, it could take a mere two tenths of a second (0.1833 seconds).

Up to this time, all the diagrams have shown only one pulse but that
is not entirely correct. I did that just to make it easier to explain. In reality, it is
not a “single phase” world. On this planet, we generate our electrical power in
3 phases (figure 13) and so all X-10 compatible transmitters “should” send out 3
pulses (as in figure 14).

hti-2-13.gif (22065 bytes)
hti-2-14.gif (16179 bytes)

Finally, I promised to give you an “introduction” into
X-10Â’s Extended Code Protocol. IÂ’m going to take the easy way out and just give
you first a graphic showing all of the available bit sequences in the X-10 standard code.
Instead of making this just part of the text of this article, I have made it a graphic so
the word-wrap feature of your browser wonÂ’t screw up the alignment.

hti-2-15.gif (13673 bytes)

Almost everything I have said since the beginning of this
explanation can be summed up in this one graphic, but arenÂ’t you glad I took the time
to explain it?

You will notice that there are some changes in four of the command
codes.

  • Ext Code0111- Now designated as “Ext Code 1”, for data and
    control
  • Preset Dim (1)1010- Now designated as “Ext Code 3”, for
    security messages
  • Preset Dim (2)1011- Now designated as “Unused”
  • Ext Data1100- Now designated as “Ext Code 2”, for meter
    read and DSM

 

As far as we know (at the time of this writing) only “Extended
Code 1” has a defined frame length which is 31 cycles (62 bits) and is described as:

  • Start Code = 4 bits,
  • Housecode = 4 bits,
  • Extended code 1 = 5 bits (01111),
  • Unit code (device code) = 4 bits,
  • Data = 8 bits,
  • Command = 8 bits..

The explanation for not having a defined frame length for the other
two is:

“Extended code 2 is variable in length, depending on the
type of message. It has its own separate “attention” marker to separate it from
all other formats.

Extended code 3 has been “assigned” for security but
doesn’t actually exist yet so its format has not yet been defined.”


April 2, 2014 by X10 0