"Two Way and Extended Code"
Which One Should I Use, Part XIV (Preamble)

Email Uncle Phil

For those of you who are already familiar with these technical articles know that the original 14 essays were first published on the HomeToys website beginning back in February 1997.  After that first article, 13 more followed that explained, in a somewhat, laid back, easy to read manner, the basic workings of Powerline Carrier communications. (Should you decide to save yourself from this summary, you can skip directly to the technical part. )

These articles were such a success that we finally duplicated all of them here, on our own website.  The last of those articles detailed the digital technology which is the basis of the X-10 protocol and illustrates exactly how our PCC devices communicate.  It was written in February, 1999, and was titled "Digital X-10" and although it, too, was first published on the HomeToys website, others felt it was good enough that a number of other websites linked to it.   That article also carried the same sequential subtitle as had the previous 12 articles, “Which One Should I Use”.  That one was also the last of the original series.

In the past year and a half, ACT has developed and released a dizzying array of new products.  Most of them have been geared toward our industrial/commercial customers and so there was little to interest the home automator.  One of those products was this RB304. Even I have to admit that there are very few residential installations that could use a 30 amp, 277/480V, X-10 compatible, relay receiver.  Even so, the development of receivers like the RB304 has allowed our talented engineers to hone their skills in preparation for our most recent release of products.

Now, however, ACT has released so many new products that are of great interest to the home automation market, we felt that another article was long overdue.  It is the intent of this one to introduce you to the many new products that ACT now has to offer and the many new features that these new products bring to the market.

Before we get into that, I have to make you aware of something.  The very first article I wrote for HomeToys, was almost 4 years ago and it had a very different purpose than this one.  That article and nearly all of the ones that followed were intended to educate the home automator and contribute to the industry without being too specific.  In other words, I wrote about the technology, not any one company’s products.  Even so, it didn’t take too long to read between the lines and figure out my opinion of some companies and their products, but I did try to present many different sides.  No one can accuse me of not giving respect, where respect was due.

This time,  however, I have the freedom to talk about some of the new developments in HA and in order to do that, I am proud to use only ACT products.  Therefore, this article, like no other in this series, will concentrate on new stuff in the HA industry by highlighting new stuff from Advanced Control Technologies.

I also have one more ulterior motive.   Later this month, Southern California will host the "EH-Expo", October 25-27, 2000, at the Orange County Double Tree, Costa Mesa.   I have been asked to teach a short class on (what a surprise) “Extended Code and two-way Communications”.  The last time I taught a similar class, I was very disappointed to find that many of the attendees were woefully ignorant of “basic X-10” and so had very little foundation on which to build their understanding of “Extended Code and Two-Way Communications”.  Many of them were confused right from the start.

Now, don’t get me wrong.  I want all of you to attend my class (it will make the other speakers jealous), but I also want you to be prepared to get the most out of it.  That is one of the purposes of this article.  It will allow you to gather some much needed background on the subject.  (For anyone reading this at some point in the future, please understand that this part is “date sensitive”.  Remember, I wrote this in the autumn of 2000.)

Like most of my articles, this one will probably not be complete by itself.  It’s subject matter is so complex that I doubt that I will get very far into it.  At the end I will give you a chance to vote for the subject of the next one in the series.

All the previous 13 articles in this series, plus one extra, are archived here at ACT and available for your pleasure.  Logically, this makes this the 14^th in the series and it seems only fitting that it, too, carry the same subtitle.  And so, without further adieu, allow me to present…  

"Two-Way and Extended Code"
Which One Should I Use, Part XIV

I am amazed at the number of times I have been involved in conversations (okay, debates) where someone would be promoting the need for all X-10 compatible devices to have two-way capability primarily in the belief that this feature alone would solve their perceived problem of X-10 unreliability.  Current X-10 systems, even in very large, multiple transformer, multiple building systems, usually work very well. They do so because professional, trained and experienced designers and installers did all the right things to make sure that the signal gets to all the receivers.  In poorly designed systems, unreliability has more to do with signal strength and noise levels than it does with the lack of two-way communications.

Does this sound like I am against “two-way”?  I’m sorry if that is how it appears.  On the contrary, I am very much for it, but not so much for reliability but for capability.  To better understand my thought processes, lets begin by defining “two-way Communications”. Way back in “Part V” I asked the question, “What is two-way?”  I went on to answer, at least partially, my own question.  I won’t repeat what I said then, since you can of course, read it for yourself. so instead, I will be more specific.

Before I tell you what X-10 two-way “is”, let me tell you what it is “not”.
-          It is not a complex method of error checking using a parity check bit.
-          It is not an a cyclic redundancy check to make sure that the data is received correctly.
-          It is not a complex system where every data packet is acknowledged.

Why can’t it be something complex?  The answer is because we are limited by the protocol and we don’t own the medium over which we communicate.

You don’t have to worry about any part of your computer being able to “talk” to any other part of your computer.  All the parts communicate with each other very well.  You usually don’t have to concern yourself with any computer on a network being able to communicate with any other computer on that network.  Today, we take it for granted that nearly any computer on the planet can communicate with any other computer because of the internet.  You probably haven’t really thought about it much, but this two-way communication works so well because computerized data transfer is done with very sophisticated error checking built into its inherent duplex (or “two-way”) communications’ architecture.  This data transfer is done by way of a communications medium designed for, built for, reserved for and controlled by, that computer network.

Sophisticated control protocols require complex two-way capabilities because decisions can be made at many different locations. In the case of some of the newer powerline communications, like LonWorks and BacNet, the system itself has what is called "distributed intelligence". That means that there is no one central location in which decisions are made. Since all the parts must work together and each may have a say in the decision making, each part (or node) must be able to both transmit and receive data.

Until recently, X-10 systems were nothing like that. Transmitters transmitted and receivers received.  That, in itself, was not a bad thing.  Now, however, the line between the two is starting to blur.  We now have transmitters that can also receive and receivers that can also transmit.  Remember that RB304 that I showed you back a couple of paragraphs?  (Click this link to see the instruction sheets  for the RB304  and click this link to can see the instruction sheets for the RB104, the 120v version.)  Well, the RB304 was one of the first receivers we released with reliable and workable, two-way communications.

Okay, so what exactly does that mean?

First, please understand that we at ACT wanted to make our products as close to “X-10 compatible” as we could.  (That in itself is an ongoing battle, but I will tell you more about that in a later article.)  Remember that the X-10 protocol has been around for a very long time.  Anyone can learn how the protocol works.  X-10 has been good enough to publish several documents on their website that will help any DIY’er, HA hobbyist or professional better understand the protocol.  The oldest of these is the one found at http://www.x10.com/support/technology1.htm. This is the document that X-10 published for the TW523, however you need to be aware that it shows some outdated information.  There is also a document that explains the protocol from the point of view of the CM11A (ftp://ftp.x10.com/pub/manuals/cm11a_protocol.txt) but it, too, shows some outdated information.  A more complete and up to date document is the one which can be found at ftp://ftp.x10.com/pub/manuals/xtc798.doc .  It is the most recent version (at least, as far as I know) and not only updates a few of the standard commands, it also goes into the often (and still) misunderstood, “Extended Code”.

It is now clear that “X-10 two-way” is a far cry from the complex algorithms used by computers.  It is also clear that we must conform to the published X-10 protocol.  Okay, I can finally tell you what “X-10 two-way” really IS!  It is simply this:

X-10 two-way is the ability for transmitters to receive, and for receivers to transmit.

Receivers have the ability to be “polled” so that a transmitter (or controller) can ask the state (level) of that receiver.

Receivers also have the ability to transmit their change of state when manually operated.

  That’s it, not too complicated.However, it may not be quite as simple as that statement appears to be.  Let’s expand on it.  Earlier, I mentioned the TW523. It is, I believe, the biggest selling two-way X-10 device for sale today.  For years, it has been used by companies who wished to sell X-10 compatibility with their own products.

Please don’t misunderstand.  The TW523 does not magically make all your transmitters and receivers “two-way”.  It’s just that the TW523 can transmit X-10 signals that your computer (or other RS232 equipped device) tells it to, and it can report back to your computer (or other RS232 equipped device) any X-10 signals that it receives.

So, the TW523 is a two-way device.   In all honesty, however, it is not a very good two-way device.  Quoting from X-10’s own document, it says, “ The TW523 … cannot receive Extended Code…”, and then it says, “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. i.e. the output from the TW523 will not be a continuous stream of dim and bright codes like the codes which are transmitted”.

If you want the rest of your system to have two-way capability, what will you need to do?  You will need to install transmitters and receivers which are designed to be inherently two-way capable.  Let’s use a different one of ACT’s new receivers as an example.  The RI104 is another unlikely product for use in home automation since it is a 4-relay receiver.  It is, however a good one to use for this illustration.

Let’s first assume that this RI104 is set to addresses A1, A2, A3 and A4.  That means that although it is one single receiver, it has 4 separate relays each having their own sequential X-10 address code.   Now let’s say that your front-end computerized intelligent controller is scheduled to send out an "A1, A1, A-On, A-On" command at a particular time of day. A few minutes later, it was also scheduled to send out an "A1, A1, A-Status-Request, A-Status-Request" just to make sure that A1 received that earlier command.  The RI104 can reply to that command.  Sure, it’s a receiver, but it is also a transmitter.  (All of ACT’s new products have this capability.)  If you look at any of the X-10 documents which explain the protocol, you will see that “Status Request”, “Status On” and “Status Off” are all valid X-10 data packets.  What’s more important is that they are all standard code data packets.

Your intelligent front-end (JDS-StarGate, HAI-Omni, or whatever) may then be programmed with a sophisticated routine that says that if it fails to get a reply to its “Status Request” command, or receives the wrong reply, it should try again.  It will then send the "A1, A1, A-On, A-On”, after which, it will again ask the question, "A1, A1, A-Status-Request, A-Status-Request".  Perhaps the second time it will work, or perhaps after a predetermined number of attempts, it will log an “Error” report for you to look at later.

Now lets say that this same RI104 was also configured to accept the “All-Lights-Off” command. You may have misread that so let me repeat it: “All-Lights-Off”.  I didn’t say “All-Off” which is more accurately, “All-Units-Off”.  Neither did I say “All-Lights-On”.  Again, look at any of the documents explaining the protocol and you will see that “All-Lights-Off” is a valid X-10, standard code command, even though, until recently there weren’t many X-10 receivers able to do anything with it.  The RI104 can do something with it.  And it (like many of the its new features) is user configurable.

Now, your intelligent front-end (JDS-HAL-CM11A-Omni-Home-Gate) transmits an “A-All-Lights-Off, A-All-Lights-Off” command.  If desired, your intelligent front-end can also ask for the status of each of the four outputs of the RI104, and it will answer!!

Now I promised that I would also talk about “Extended Code” in this edition, so now is a good time to bring it up.  Unfortunately, this article is getting pretty bloated so I am sorry to say that, as expected, I will only be able to scratch the surface of this very complex subject.

Instead of using the RI104, allow me to use the RD104 (ACT’s newest 600 watt, wall 
mount dimmer) as our example. First lets look at this from the prospective of the intelligent front-end (pick whichever one you want) and we  will have it send out some “Extended Code” stuff to the RD104.

If you care to wade through the document found at ftp://ftp.x10.com/pub/manuals/xtc798.doc you will find that it allows for a single 62 bit (31 cycle) data frame that combines the address with a preset dim command, all in one.  Any manufacturer who claims that their dimmers are “X-10 compatible” needs to understand that this is the “new” 64 level, “Extended Code” preset dimming, not the “old” 32 level, “Standard Code” preset dimming model.  (I know that this is confusing, but trust me, all will be revealed, but admittedly, not in this edition.)

If the intelligent front-end of your choice uses the TW523 as it’s powerline interface, then it is (of course) capable of sending out these preset dim commands.  Please, don’t misunderstand.  The TW523 is capable of sending out the new “Extended Code” commands, but your front-end hardware/software may not be.  (We are already working with many of the larger front-end guys but I urge you to contact the manufacturer of your front-end system to check for compatibility.)

Okay, let’s assume that yours is capable of sending out the new “Extended Code” preset dim commands and so at a particular time, it is programmed to send out, “A[1]01-level-28, A[1]01-level-28”.  Assuming that you configured your new RD104 for address “A1”, it will now ramp directly to level 28.  It will not have to go to 100% first.  I just goes directly to level 28 (which equates to about 45%).  If it was already above that, it simply ramps down to that level.  If it was below that, it just ramps up to that level.  (Is that cool, or what?)

In reality, it is a little more complicated than that.  We at ACT have adopted a few notation shortcuts that help us document extended code data frames. For instance, “A[1]” means “Letter Code A”, “Extended Code 1”.  Since there are now 3 different “Extended Code” formats, we designate them as [1], [2] and [3].  After the “Extended Code 1” notation, then the next two characters designate the number code.  It is an often held misunderstanding that X-10’s “Extended Code” allows for more than 256 addresses. Technically speaking, there are still only 256 individual addresses, even when “Extended Code” is used.  After that, there are 8 bits of data code which I simplified as just “level-28” in the above example. I took additional liberty in omitting the last command section.  In reality, the last two nibbles would be “31₁₆”.  If that little “₁₆” is confusing, it means that the “31” is not really “thirty-one” in your standard base-10 method of counting.  It means that it is a “three-one” in hexadecimal.  The “3” means “Type 3 = Control Modules (Dimmers and Appliances)” and the “1” means “PRESET RECEIVER”.

Okay, I’m sorry.  That last paragraph may have been a little much for some of you.  I try to write all my articles so that they are understandable to non-engineers, but suddenly jumping to hex notation was a huge leap.  I’ll tell you what.  At the end of this piece I will give you a chance to vote on the direction of the next one in this series.  But first, let me tantalize you with two more little tidbits.

Let’s say that you want to configure a bunch of RD104’s for a bunch of scenes.  Well, I have good news for you.  The RD104 can store up to 64 different scenes and any or all of them can overlap with the scenes that you configure into all your other RD104’s.  (Is that just about the coolest feature you have ever heard of? Huh!?!)  Of course, all of this “scene” stuff requires the use of “Extended Code”.

Okay, one more and we will have to quit for this session.  Remember when your intelligent front-end sent out an "A1, A1, A-Status-Request, A-Status-Request"?  Lets say that your front-end is using the TW523 as it’s interface.  Remember that the TW523 can send, but it cannot receive “Extended Code”.  Therefore, if you ask the RD104 it’s “status” in standard code, it can answer in standard code.  You won’t know the exact level, but at least you can find out if it is “On” or “Off”.

Now,  lets assume that your intelligent front-end uses something else (hint hint) as it’s powerline interface, and that something else is capable of sending and receiving “Extended Code”.  You can now send “A[1]01-Req-Output-Status-37₁₆, A[1]01-Req-Output-Status-37₁₆”, and guess what?  The RD104 will reply with its exact dim level, in “Extended Code”.

I don’t know about you, but I’m worn out.  This has been an exciting article to write.  It has also been a tough one to write because there is so much information that I could have included.  I found it hard to know what to include and what to hold back for another day.  I hope I have given you some food for thought.  I also know that I have presented as many questions as I have answers.  Therefore, here is your opportunity to vote on the subject of the next article.

Here are your choices for "Which One Should I Use, Part XV":

      1: More on two-way: Receivers which announce their state when manually activated.
2: More on two-way: Wall-mount transmitters which track the state of the receivers they control.
3: More on Extended Code: Including New Preset Dim commands, verses the old preset dim commands.
4: A tutorial on binary and hexadecimal code notation in relation to X-10 standard and extended code.
5: What did you really mean when you were talking about "compatibility" and then said, "That in itself is an ongoing battle, but I will tell you more about that in a later article".
6: Your choice (within reason).