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.
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.)
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).
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).
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.
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).
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.
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.
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).
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).
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.
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.”
Recent Comments