Which One Should I Use #16
The TI103!! 

There are a lot of misunderstandings about the TI103 that need explaining.  I suppose some of the confusion is that the X-10 part number for their device and the ACT part number for our device are very similar.  That is just coincidence.  Actually, they are very different devices which do a similar job.  However, clarifying the difference is going to require a long explanation.  For almost two years, I have received inquires on the TI103 PCC interface.  It is not uncommon for me to get one or two emails each week asking if our TI103-RS232 is a replacement for the  X-10 TW523 (X-10 Pro's PSC05).  There is a simple answer ("No, it is not"), and a long answer. 

Here is the long answer. 

For a long time, the TW523 has been the most common way of allowing OEM systems to participate in the X-10 world.  With the purchase of a TW523, the user was also granted a "license" to use the X-10 protocol.  Of course, now the patents have all expired and the protocol is now open to all. 

Before the TW523, there was the PL513.  "PL" stands for "Power Line" and allowed the host to send X-10 signals onto the line, but the PL513 could not receive.  Then came the TW523 which allowed for two-way communications ("TW" stands for "Two Way").  Neither device is a true computer peripheral. 

This is basically how the TW523 works. 

The host (most of you already know that you cannot connect the TW523 'directly' to a computer) receives a zero crossing synchronizing signal from the TW523.  That is the timing pulse, like the beat of a drum.  When the host wants to send an X-10 address, it has to send to the TW523, the TTL (transistor to transistor logic) pulse pattern that corresponds to the bit string that needs to go out on the powerline.  Instead of sending the ASCII string "A01", the host has to send this: 

11100110100101101001011110011010010110100101 

In reality, the host does not really send "ones" and "zeros".  It actually sends 0 volts and 5 volts.  Like this (only a very small part of a basic X-10 data frame is shown below):

If we break up that long complementary bit string for the address A01, this is what it would look like:    

At this point it is imperative that you understand the X-10 protocol, so if you are reading this, and you are already confused, I strongly suggest that you study the explanation of the protocol in WOSIU#13, found at: http://www.act-solutions.com/PCC/kingery13.htm 

The TW523 is based on a "FIFO" (first in, first out) shift register.  The host sends its pulse train to the TW523 and loads up the shift register like ammunition in a bandolier, with bullets where you want to send a "1" and no bullets where you want to send a "0".  That also means that while it is listening to the host, the TW523 ignores anything that is happening on the powerline. 

When the shift register (bandolier) is full, the TW523 then shifts the bits onto the powerline.  Everywhere there is a "1", it switches on the 120kHz oscillator so that a 1 millisecond pulse is placed on the powerline just past the zero crossing.  Everywhere there is a "0", the oscillator remains off. 

(In reality, it is more complicated that that.  The user must write his application to accommodate 3 pulses per half-sine wave so that the 1ms pulses appear at the 0°, 60° and 120°, plus there are a few other considerations, but what I have described is the basics.) 

The reverse happens when the TW523 receives data from the powerline.  It monitors the powerline and when it detects a bit string, the TW523 loads it into its shift register.  When the register is full, it dumps it to the host.  Here is the problem.  The TW523 can only receive standard length data frames.  When it gets an "A01", it is full until it can dump those bits to the host.  Timing is critical.  It takes just as long to empty the shift register as it did to fill it, so all the while it is giving the host the "A01" it cannot listen to anything on the powerline.  Usually, this is not a big deal until a string of "Dim" or "Bright" commands come down the powerline. 

Quoting from X-10's own document, http://www.x10.com/support/technology1.htm, 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." 
(That is the document that X-10 published for the TW523, however you should be aware that it shows some outdated information.) 

Okay, what about "Extended Code"?  Nope, sorry, the TW523 cannot receive Extended Code.  It is also not very good at collision avoidance and has no collision detection.  Even if it could detect a signal collision, it has no ability to do anything about it. 

Please don't misunderstand me.  I am not saying that the TW523 is a "bad" device.  What I am saying is that it cannot do the things that are demanded by modern 2-way, extended code, powerline systems. 

When we at ACT became interested in designing a "better" TW523 (I'll call it the "TW-Better", for discussion purposes), these were some of the things we had to consider:

1. How can we give the host the ability to send a data stream to the "TW-Better" in such a way as to allow the "TW-Better" to continue to look at the line so it wouldn't miss anything?
2. How can we give the "TW-Better" the ability to send that data stream onto the powerline, while still looking to see if the host was wanting to give it a new data stream to send out on the line?
3. How can we give the "TW-Better" the ability to accept an extended code data stream from the powerline and get that to the host in its entirety.
4. How will this new device detect signal collisions and how will it try to resend that data if a collision does occur?

It became clear that if we were to design a better "TW523", it could not be a direct replacement for the existing TW523.  What we decided to do was design a completely new device that connected directly to an RS232 port.  It would communicate with its host at a fast 9600 or 19.2K baud.  It would have the sole responsibility for getting the information onto and off of the powerline. 

You can see the specifications and instructions for the TI103 at:

http://www.act-solutions.com/PCC/pdfs/PCCSpecs/ti103_spec.pdf
http://www.act-solutions.com/PCC/pdfs/PCCInst/ti103_instr.pdf

Now is a good time for me to beg your forgiveness.  When talking about this product (either in writing or verbally) I usually use a shortened version of its part number.  Its correct part number is TI103-RS232.  However, I often use the short version of just "TI103", or sometimes the even shorter "TI".  Occasionally, I use this term, "TIxx3" in writing, to mean any one of the three units listed below.  However, for official "order entry"  purposes, it is important for me to inform you of the proper part numbers.  We currently (as of 7/26/02) have 2 versions and are planning a third: 

TI103-RS232 = Transceiver Interface, 120v North American plug (available now.)
TI203-RS232 = Transceiver Interface, 240v Australian plug (available now.)
TI213-RS232 = Transceiver Interface, 230v Euro plug (available soon, but you can cut the plug off of the TI203 and use that in the meantime.) 

Remember to place your orders accordingly.  There really is no "TI103" part number, but we can usually figure out what you mean.

Okay, lets get back to this long explanation.  Let me start by explaining what your computer (or "host") needs to send to the TI103 (…okay, "TI103-RS232" ). 

You start by sending the "$>", which is the protocol format preface, then the device type (in this case "28", all TIxx3's are named "28").  Follow that with the device address (which is set by the internal dip switches, factory set at "00").  Then you must include a command that identifies what you are wanting the TI103 to do.  If you are merely asking it to give you anything it has received (a "query"), then you would include the ASCII "00".  (That is really "Command Ø" and "Sub-command Ø", but I am simplifying it.)

Then near the end, the communications "check sum" must be entered.  This is the part with which I think most non-programmers are going to have difficulty.  A "check sum" is the sum of all the hexadecimal characters that comprise the complete message.  Although this is usually three hex digits, we only use the lowest two significant hexadecimal digits as the check sum.  This is a common "error checking" method in digital packet communications. 

Finally, the last character in the string, is the "#" which signifies the "end of packet" protocol format. 

Therefore, if the host wants the TI103 to report everything it has heard (received) on the powerline, the command string would be: 

$>2800008C# 

This ASCII string (above) assumes the TIxx3 is set to is factory default of "device address ØØ".  

The latest version of the TIxx3 allows for the user to ignore the checksum.  It is designed to give the user this option.  When set to device address "15₁₀" (and I'm talking about the RS232 device address, not the X-10 address), hexadecimal "ØF" (or ØF₁₆), the TIxx3 will ignore the checksum characters in any packet from the host.  There must still be something  in those two character locations, but you can make them anything you like.  You can use my initials "PK" if you want (or any other 2 ASCII characters).  This does not mean that all you have to do is send the ASCII string using "ØF" as the device address and end it with "PK" as the checksum.  That won't work.  You will also have to physically open the TIxx3 and change the dip-switches (#1, #2, #3, and #4), to "On" in order for it to accept any packets intended for "device ØF". 

This means that if you want to physically set the internal dip-switches, 1 through 4, to "On", the correct command string for the TI103 to report everything it has heard, would now  be: 

$>280F00A2# 

The older version TI103 required all communication packets to/from the host to end in a valid hexadecimal checksum, regardless of which device address is used.  If the packet did not have a checksum, or it was incorrect, the packet was discarded.  Obviously, if the TIxx3 would accept a packet with a wrong checksum, it wouldn't be a very good error checking method, now would it.  (If you are not sure which version you have, it is easy to tell the difference.  The older versions of the TI103 have a detachable RS232 cable.  The new ones do not.) 

The TIxx3 (old and new versions) will always send its packets with the correct hex checksum at the end, regardless of its device address, but your software does not need to look at them if you don't want to.  Obviously, we would recommend that you write your software to always use the checksum characters, but writing your preliminary software code without checksums and then setting the TIxx3 to " ØF ", does allow you to do some easy testing. 

For the rest of this article, I will assume the TIxx3 is set to the factory default device address of ØØ. 

Before I tell you what you might get back from the TI103, allow me to set up several scenarios. 

Let's assume that you have everything ready to go.  You transmit a "B03 BON"  to the TI103 from a nearby desktop transmitter (a "maxi controller" for instance).  You then have your computer software send the query command ($>2800008C#) to the TI103 over the RS232 port.  The TI103 will respond with this: 

$<2800! B03B03 BONBON93# 

You will notice that the message has two spaces in it.  A space is used to denote any non-contiguous event.  The space is just saying there was a gap between data frames. 

Note:  If you did not realize that all commands are preceded by the letter code (we don't say "house" code here at ACT), or you didn't realize that all data frames are sent twice, I urge you to review the protocol in WOSIU#13, found at:

http://www.act-solutions.com/PCC/kingery13.htm 

It is more likely, however, to get only 1 space (none between data frames) if you happen to poll the TI103 at a time where it has only received contiguous data.  For instance, this sequence happens: 

C11C11   -original signal from a nearby transmitter is received by the TI103. 

Then you poll the TI103 ($>2800008C#), you should get back: 

$<2800! C11C11[chksum]#   ...then a few seconds later, 

C12C12 C13C13 COFFCOFF    -original signal from that same nearby transmitter is received by the TI103.  Then you poll the TI103, you should get: 

$<2800! C12C12 C13C13 COFFCOFF[chksum]# 

The TI103 will never give you more than one space "at a time" since one space represents at least 6 clear zero crossings, but may represent many more.  In other words, if the TI103 receives:

A01A01 AONAON                        -original signal from a nearby transmitter, then 10 seconds later,

B01      BSON                             -repeated signal from a distant receiver, then 10 seconds later,

C11C11 C12C12 C13C13 COFFCOFF                     -original signal from a nearby transmitter. 

Then you poll the TI103.  You should get back: 

$<2800! A01A01 AONAON B01 BSON C11C11 C12C12 C13C13 COFFCOFF[chksum]# 

If the TI103 receives original signal, it should always get both data frames (as in "B03B03 BONBON" ) but if it receives only repeated signal (from a coupler-repeater) then it will only receive one data frame each (as in "---B03 ---BON").  If a transmitter is not sending duplicate data frames, it is NOT X-10 compatible. 

There is also a very rare situation where this happens.  Let's say, the TI103 is in the middle of receiving a long string of dim or bright commands (for the sake of brevity, lets say 6 dim commands) when the host asks "Gimme what you got!" right after the third dim frame.  The TI103 reports: 

$<2800! ADIMADIMADIM[chksum]# 

A few seconds later, the host again asks "Gimme what you got!" after the sixth dim frame.  The TI103 reports: 

$<2800!ADIMADIMADIM[chksum]#              …notice, no spaces at all! 

If you are hopelessly lost at this point, it may be that you have some misunderstanding about the X-10 protocol itself.  If so, I would suggest you review http://www.act-solutions.com/PCC/kingery13.htm.

Now, lets talk about how you tell the TI103 to transmit stuff! 

If you are asking the TI103 to "send" data onto the line (transmit), you would start the same way as before, by sending the "$>", which is the preface, then the device type ("28"), then the device address (still " ØØ ", unless you changed the dip-switches).  Then comes the command that tells the TI103 that you want it to send something on the powerline.  That command is the ASCII "1".  Now give it what you want sent onto the line (examples below) finally, followed by the "check sum", and lastly the "#" meaning "end of packet". 

I was deliberately vague about what you can put in the middle, so here is some more information.  Since the X-10 protocol dictates that you should always send the data frames twice, you will need to send the ASCII equivalent twice (such as "P01P01" to send the address "P1").  A space allows the TI103 to insert the necessary 3-cycle gap between data frame pairs.  Then if you want to send something else, like a command, you enter the ASCII equivalent twice (such as "PONPON"  for "P-ON").  Here is an example of a data packet to send the command "P01 P01 PON PON". 

$>28001P01P01 PONPONB9# 

Below is an example of a data packet to send the command "P01 P01 POFF POFF". 

$>28001P01P01 POFFPOFF35# 

Please notice that the "check sum" characters changed.  The first example had a check sum represented by the hex digits "B9", but that changed in the second example to "35".  Because of the complex error checking used by the TI103, you can NOT simply replace the "PON" with "POFF" and get it to work.  Unless you understand hexadecimal arithmetic and know the hex values of the ASCII characters you are wanting to send, you are going to have a tough time using the TI103 in any address other than "ØF". 

Let's say that you want the TI103 to send multiple dim commands.  As an example, assume that you want to turn on a standard X-10 dimmer and then dim it down 3 steps (or about 80%).   This example assumes that you are sending to a standard X-10 dimmer, (which always comes on at 100%) which is set to A01.  This is what you would send to the TI103 over the RS232 line: 

$>28001A01A01 ADIMADIMADIMADIM[checksum]# 

That means, send the address twice ("A01, A01" ), a gap of 3 cycles, then send the dim command 4 times (ending with a checksum and the end of packet character).  That will turn on the standard dimmer and then dim it down 3 steps.  Since there are 16 dim levels using the standard dim commands, that should be about 80%.

[The TIxx3 will only accept 24 characters in the middle, between the $>28001 and the checksum.  If you need to send more address/command data than that, there is a way to store the information in order to string it all together, but this article is only to get you started with the basics.  See the actual instruction sheets for the nitty gritty complicated stuff.] 

If you are sending to a more sophisticated dimmer, like the RD104, that method will probably not work.  The RD104 has "remembered state dimming" which means that when commanded to come on, it will ramp up to its "last known state".  That means that either your front-end will have to keep track of the dimmer's state (level) or it will have to use the extended code direct dimming commands to take it directly to 50% regardless if it was on or off, brighter or dimmer.

(See http://www.act-solutions.com/PCC/kingery15.htm for details.) 

One more piece of information on getting the TI103 to send stuff.  All our A10 devices have very sophisticated algorithms for getting signal onto the powerline.  This explanation will help you understand how it works and why it's better. 

Let's say that you tell the TI103 to send a simple command (like "A-All-Lts-On, A-All-Lts-On" ).  The TI103 looks at its constantly rotating number generator and finds that it is set to "9" (it could have been 8, 9 or 10).  It now knows that it needs to wait for 9 clear zero crossings before it can even make its first attempt to transmit.  In a very large system with many other A10 based devices, they too, have a constantly rotating 8-9-10 counter that dictates when they can start transmitting.  Even with 24 hours in a day, it is still possible for two A10 transmitters to try and transmit at the same time.  If some other (older) transmitter is hogging the line, and two A10 transmitters both are given data to send, odds are that they will not pick the same number. 

Even if they do happen to pick the same number, they also have very sophisticated collision detection algorithms.  If one of them senses that it is "colliding" with another signal, it will back off and reset its counter and try again when the line is clear.  If both detect a collision, both will stop and reset their counters.  It is unlikely that they will again pick the same number as their "clear zero crossing" counter.  However, even if they do (odds are that they won't, but even if they do), they will again see the collision and one (or both) will stop and wait its turn. 

How will you know if your X-10 commands were successfully transmitted?  The next time you query the TI103, it will tell you by giving the same data frames back to you.  If it is prevented, for some unknown reason, from sending its data, it will report back with "nothing", until it is successful. 

Giving the data back to the host appears to be an "echo" of what you asked the TI103 to send, but it is really the confirmation that the data was properly sent.  It is intended that programmers write their host software to expect this confirmation.  That way, their computer can deal with the powerline communications failure.  Perhaps they will log an error message at the host and then wait before sending anything new to the TI103 until it is able to report its success. 

That is a little insight into how it transmits, and I haven't even gotten into how well it receives! 

I think this is a good place to stop.  This document is already about 7 pages long.  This information should be adequate for most competent programmers to begin working with their new TIxx3's. 

Obviously, there is much more we could discuss, like how to send an extended address string for one of the new ACT devices capable of 4,096 addresses.  (Oh, that got your attention!)  Or perhaps how to interpret an incoming direct dim command.  Before we do that, you may want to review the most recent document on the X-10 protocol.  It 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 does it update a few of the standard commands, it also goes into the often (and still) misunderstood, "Extended Code". 

We have come to the end of yet another episode in this gawdauful, never ending series. I am about 80% through a couple of other articles that I want to get finished up and on the web, but I never seem to have the time.  This one floated to the top of the pile when it became a necessity that I explain some new things so, unfortunately, the others got pushed back.  Even though I have several more articles in the pipeline, I thought I would give you a chance to vote on which one you would like me finish next: 

1. An in-depth explanation of the standard X-10 binary code structure with an introduction to the X-10 Extended Code set. This one may be a little boring to the do-it-yourself-ers out there, but to the professionals, it promises to be very enlightening and would explain a lot of the "why does it do that" questions.
2. A discussion of complex coupling situations not previously covered. For instance, what if your house has two 200-amp panels side-by-side.  Do you need to couple both of them?  Or what can you do if an installation has many sub-panels and no matter what you do, there is never enough signal where you needed.  (This is a common question in my emails. )
3. Anything else!  (That is dangerously open ended, but what the heck.)

Send me your votes on 1, 2 or come up with your own subject.  Like they say in politics, vote soon and vote often and keep those emails coming. 

To infinity…AND BEYOND!!

 -"Uncle" Phil Kingery.

Phillip Kingery is a representative of Advanced Control Technologies, Inc.
pkingery@act-solutions.com