Version 3.6

Published by:

BARAN-HARPER GROUP INC

18 Grandview Blvd

Markham, Ontario

Canada, L3P 1E8

The function of this Information Series paper is to provide the reader with the technical aspects of the X-10 Powerline Carrier Current product TW523.. Explanations of the communications protocol with reference to timing constraints is discussed. A complete copy of the X-10 protocol is also covered. A sample source code listing in Borland C is included with a simple connection drawing to interface the TW523 with a Parallel port of a computer. Specific aspects of the control signal not covered by this booklet can be resolved by calling the BARAN-HARPER GROUP at the phone number posted on the inside front cover of this manual. Every effort has been made to assure the quality of this information. However, errors do occur.

The X-10 POWERHOUSE code format was first introduced in 1978 with the Sears Home Control System and shortly after with the Radio Shack Plug 'n Power System. Since then, X-10 has developed and manufactured O.E.M versions of its Home Control System for Stanley, Heath/Zenith, Leviton, General Electric, C & K Systems, Schlage Lock etc, etc. Versions have also been introduced in Canada, Germany, Holland, France, Switzerland, Japan, Australia, New Zealand, Thailand, Taiwan.

All of these systems use the X-10 code format, all are compatible. It is therefore advantageous for any Home Control System to be compatible with the X-10 standard.

This manual discusses the technical aspects of the X-10 TW523 module designed for the North American electrical power system which is 110V 60Hz. The 60Hz. is used for timing and is therefore very important. The TW523 can be modified, by the replacement of capacitors to work in the 220V 50Hz environment.

The TW523 was developed as a cost effective interface to the 110 volt AC system. All connections to the power line are made by the TW523 and all connections between the TW523 and your O.E.M. equipment are opto-coupled. This relieves the O.E.M. of any U.L. or C.S.A. considerations.

The TW523 plugs into a regular North American 110V 60Hz AC outlet and connects to the O.E.M. product via a modular RJ11 telephone jack. It provides an opto-coupled 60 Hz. square wave trigger signal to the O.E.M. product. This signal is used to synchronize X-10 transmissions to the zero crossing point of the AC line. The O.E.M. generates the X-10 code 'envelope' with respect to this reference and applies it to the opto-coupled input of the TW523 which modulates the envelope with 120KHz and applies it to the power line.

The TW523 also has an opto-coupled output which provides an isolated demodulated X-10 code envelope which represents x-10 codes received from the power line.

The TW523 allows the developer to build products that "talk" to each other on the AC wiring. Of the over 200 items carried by X-10/LEVITON, only the PR511 motion detectors and the RR501 RF base receivers can put up a STATUS ON/OFF type conversation, nothing else. Through two-way control systems you can actually ask for the status of a module to be sent back on to the AC wiring. It is possible to read back into the TW523 the data sent out the Transmit pin. This feature is very important in algorithms concerned with collision avoidance, detection, and resolution.

The TW523 was first produced and sold to the O.E.M. market. To the dealer consumer market this product did not exist as a catalogued number. The adaptation of the TW523 to micro-controllers and desktop 80XXX machines adds a whole new dimension to the X-10 standard. The problem of "did that signal get there?" is gone.

To transmit x-10 signals the user must supply to pin 4 (TX) on the TW523 a predefined collection of bits serially. A "ON" bit is achieved by pulling pin 4 high for a 1ms period relative to the Zero-Cross pin being high. An "OFF" bit is just a low pin.

The Custom proprietary IC chip is designed to encode/decode signals from the AC line. The means that your controller does not have to monitor the AC on a continual basis. When a valid X-10 code is received, it is stored in the custom IC and retransmitted (in envelope form) to the OEM product. This transmission is coincident with the second X-10 transmission. X-10 codes are always transmitted in-groups of two, except Bright and Dim.

Start code (1110) can be used to alert the OEM product `that an X-10 code will follow. A '1' bit from the TW523 appears as a negative going pulse 1.1 ms long, beginning approx. 100us after zero crossing. The user should sample his data between 500 and 700 us after zero crossing. The LED is illuminated when AC power is applied to the TW523, and blinks whenever a valid X-10 code is received, or is transmitted.

The TW523 can read X-10 codes from its own input. This feature allows the OEM to implement data collision, avoidance and resolution routines.

The line monitor capability of the TW523 allows the OEM to ensure that the power line is free from X-10 signals before starting a transmission. For example, if after detecting that the line is free, a transmitter waits for a random number of power line half cycles before transmitting, the chances of collision is reduced. A different priority can be assigned to each transmitter by including a fixed delay before the random delay. The shorter the fixed delay, the higher the priority.

From what I have seen to date, there are very few modules in the marketplace that utilize the X-10 "intelligence" parts of the command set. Most devices respond only to On, Off, Dim, Bright, All On/Off. Very few devices use the Status Request, Hail Request, Preset Dim and so on. In short there are no standards as to the defining of time-outs as discussed in the previous paragraph. As you look at the command set available on the TW523(which is not the complete command set available) you will observe that we will not be discussing the USE of the command set. We have our definition of the USE, and you can have yours. As you read further into tis manual, you should see what I'm talking about.

The power supplies in the PL513 and TW523 are capacitively derived from and directly referenced to the 120/240V AC line. Care should be taken when monitoring and internal circuitry with the oscilloscope as the 0V reference in the units are NOT isolated from the line voltage.

X-10 transmissions are synchronized to the zero crossing point of the AC power line. The design goal should be to transmit as close to the zero crossing point as possible but certainly within 200 microseconds of the zero crossing point. The Interface provides a 60 Hz. square wave with a max. Delay of 100 usec from the zero crossing point of the AC power line. The maximum delay between signal envelope input and 120 us of the square wave.

A Binary 1 is represented by a millisecond burst of 120 kHz. at the zero crossing point and a Binary 0 by the absence of 120 kHz. The Interface modulates it's input with 120 kHz., therefore only the 1ms "envelope" need be applied to it's input. These 1 millisecond bursts should actually be transmitted three times to coincide with the zero crossing points of all three phases in a three phase distribution system. This 3 burst pattern is mandatory. Single burst systems work, but always.

Note.- For clarity, the signals in figure 1 are shown as they would be seen through a high pass filter. The 60 Hz. waveform is only shown for reference. In reality the signals are actually superimposed on the 60 Hz. waveform and look more like that shown in figure 2.

Figure 1.

Code transmitted when a nA complete code transmission encompasses eleven cycles of the power line. The first two cycles represent a Start Code. The next four cycles represent the House Code and the last five cycles represent either a Number Code or a Function Code (On, Off, All lights on, All units off, Bright or Dim). This complete block, (Start Code, House Code, Key Code) should always be transmitted in-groups of 2 with 3 power line cycles between each group of 2 codes. Bright and dim are exceptions to this rule and should be transmitted continuously (at least twice) with NO gaps between codes.

Figure 3: Power Line Cycles

Code transmitted when a number button is pressed

Code transmitted when a function button is pressed

Within each block of data, each four or 5 bit code should be transmitted in tru complement form on alternate half cycles of the power line.Note: Within each block of data, each four or five bit code should be transmitted in true and inverse form on alternate half cycles of the powerline. I.E. if a 1 millisecond burst of signal is transmitted on one half cycle, (binary 1) then no signal should be transmitted on the next half cycle, (binary 0).

The tables in figure 5 show the Binary Codes to be transmitted for each House Code and Key Code. The start Code is always 1110 which is a unique code and is the only code which does not follow the true complement relationship on alternate half cycles

Figure 5: House Code & Key Code Tables

The Start Code is Always 1110 which is a unique code and is the only code which does not follow the true-complement relationship on alternate half cycles.

*Hail Request is transmitted to see if there are any other X-10 transmitters within listening range.

**In a Pre-set Dim instruction, the D8 bit represents the M.S.B. of the level and the 4 Housecode bits represent the 4 Least Significant Bits.

***The Extended Data code is followed by 8 bit bytes which can represent Analog Data (after A to D conversion). There should be no gaps between the Extended Data Code and the actual data, and no gaps between data bytes. The first 8 bit byte can be used to say how many bytes of data will follow.

****The X-10 Powerhouse R.F> to X-10 gateway (model number RR501) is a Two-Way Module. If the RR501 is first addressed by transmitting it's Housecode and Unit Code, and then the code "Start code Housecode -Status request" is transmitted: the RR501 will respond by transmitting "Start Code Housecode - Status" where "Status will be 11011 if the RR501 in On and 11101 if the RR501 is Off.

Note: X-10 Powerhouse receiver modules require a "silence of at least 3 cycles of the power line between complete code transmissions. The one exception to this rule is the bright and dim codes, which are transmitted continuously with no gaps between transmission.

A square wave representing zero crossing detect is provided and is within 100us of the zero crossing point of the AC power line. The output signal envelope should be within 50 us of this zero crossing detect. The signal envelope should be 1 ms - 50us + 100us.

0V in this product is directly connected to one side of the AC line. Therefore, for safety, an ISOLATING power transformer MUST be used when attempting any internal measurements.

The power supply for the interface is capacitively derived from, and is directly referenced to, the 120V AC power line. Care should be taken when monitoring any internal circuitry with an oscilloscope, as the OV reference in the interface is NOT isolated form 120 volts.

The supply provides a +30 V supply for the output drive circuit and L.E.D.

Transmissions are to be synchronized to the zero crossing point of the AC power line and should be as close to true crossing as possible but certainly within 200 microseconds.

The Interface is designed to be interfaced to other microprocessor circuitry which provides output compatible with the X-10 code format and therefore synchronized to the zero crossing point of the AC power line. It is therefore necessary to provide a zero crossing reference to the OEM microprocessor. It is likely that this microprocessor will have it's own "isolated" power supply. It is necessary to maintain this isolation and therefore a trigger circuit such as that normally used in X-10 Powerhouse controllers not desirable as this would reference the OEM power supply to the AC power line. It is also not desirable to take the trigger from the secondary side of the power supple transformer as some phase shift is likely to occur. It is therefore necessary to provide and opt-coupled trigger.

The input signal required from the OEM equipment is the signal "envelope" of the X-10 code format, i.e. high for 1, ms. coincident with zero crossing represents a binary "1" and gates the 120 Khz oscillator through to the output drive circuit thus transmitting 120 Khz. onto the power line for 1 ms.

Low for 1 ms. coincident with the zero crossing point represents a binary "0" and turns the 120 Khz. oscillator/output circuit off for the duration of the 1 ms. input.

This signal envelope is also applied to an LED driver circuit to indicate power-on and transmission status. The LED is normally on to indicate the presence of power, and "blinks" OFF to indicate that a signal has been transmitted or received.

The "X-10 received" output from the TW523 coincides with the second half of each X-10 transmission. This output if the envelope of the burst of 120 kHz received. Only the envelope corresponding to the first burst of each group of 3 bursts is available at the output of the TW523.

The input to the output drive circuit is provided from a free running 120 kHz. oscillator. The frequency of this oscillator is critical for reliable operation of X-10 Powerhouse receiver modules and is factory set to within 2%.

The 120 Khz. X-10 code is coupled to the power line by an isolating tuned circuit. The input to this circuit is provided from the 120V AC power line is accomplished within the Interface and therefore the OEM need not be concerned with any safety and regulatory restrictions.

X-10 codes present on the AC power line are coupled to a custom Integrated Circuit in the TW523. This IC checks incoming 120 kHz. for X-10 compatibility and provides a 1 ms envelop the OEM. This envelope is coincident with the second X-10 transmission (X-10 codes are always transmitted in-groups of two). A "1" bit is represented by a 1 ms burst of 120 kHz. on the power line coincident with zero crossing points in a three-phase distribution system. The "X-10 received" output from the TW523 looks like a string of negative going 1 ms "envelope" pulses occurring just after zero crossing. Although X-10 transmitters send three 1 ms bursts per half cycle to represent a "1" bit, the TW523 will output only a single negative 1 ms envelope corresponding to the zero crossing of the phase the TW523 is connected to.

The interface outputs a 60-Hz square wave to the OEM equipment to provide a reference for code generation. The x-10 signal envelope is generated (within the OEM equipment) with reference to this square wave. The signal envelope modulates a 120 kHz, carrier and the resultant X-10 code is capacitively coupled onto the AC power line in synchronization with the zero crossing point. A signal "envelope" representing received valid X-10 codes is available to the OEM. The X-10 code format is patented, but as X-10 transmission and reception is performed within the TW523 all patent related criteria are satisfied by the TW523. Permission to transmit or receive the X-10 code format is granted only in conjunction with the use of X-10 Powerhouse Power Line Interfaces.

Connection between the OEM equipment is via a standard modular phone jack, the connections for which are as follows:

Absolute maximum Ratings.

DC characteristics:

Serial Data input

Voltages and currents measured with respect to terminal 2.

Note: This output is an open collector transistor. Therefore, the logic '1' voltage is quoted as a reference for defining the output leakage current. An output pull-up resistor is required to generate a logic level. This pull-up can be returned to any voltage up to +20V with respect to terminal 2.

Zero crossing detect output and receive output

(Voltages and currents measured with respect to terminal 2)

AC characteristics

A Logic "1" at the transmitter input will send a burst of 120 kHz data onto the power line for as long as the transmitter input remains high. Zero crossing output and receive output are active low and open collector high. The width of X-10 code envelope pulses 950uS 1100us Max. Delay from zero crossing output is 50us to the start of a transmit envelope

To facilitate the operation of the TW523, a serial or parallel interface can be connected to the TW523 and presented to the serial/parallel port on a PC. This technique allows the user to view, query, and set the status of the X-10 based product line. When dealing with micro-controllers, a direct connection between the TW523 and the selected micro-controller is possible. Check the specifications of your micro with that of the TW523 to see if enough drive current is available.

This first introduction of the TW523 Serial/Parallel interface was designed to work within the DOS environment, on a 80xx based machine. An old machine such as that is more than sufficient to drive the TW523 and perform all of the looping algorithms required to receive and transmit the X-10 protocol. By 1994 286 and even 386 machines were being allocated to the task, with an increasing majority of users wishing to port to the Windows environment and integrate into the multi-media lof Voice and Sound Blaster type cards. CD ROM's and Infrared control is also starting to surface as a requirement.

In the following pages we discuss the use of two different methodologies to connect the X-10 TW523 to a Computer Serial Port. Two basic type of units are available:

* Under Review to change to N,8,1,9600

IBM DOS Parallel and Serial

The first generation of units contain simple circuit boards that are parasitic, in that they take power from the serial or parallel ports to drive the circuitry in the TW523. As the application programmer, your task is to look at the transmit and receive pins for a "high" signal for an ON bit, no signal for an OFF bit. You look at these pins when the zero-cross pin is also high. You collect these high and lows and parse together a string that you compare against a translation table to see what you have, for example A1 ON.

This type of programming can be done on IBM DOS machines quite easily. The included "C" code in this example shows how. One problem with this technique is that the programmer tends to spend a LOT of time designing and refreshing the screen I-O.You may "miss" a bit or two while doing a screen refresh. This of course is a function of the machine speed. 286 and above machines should not present you with this type of problem - as much. It does happen. A more robust solution is to run a TSR that scans the TW523 interface and decodes the signals for you. The application programmer in then only concerned with the loading and unloading of buffers and may concentrate on the application. We have used this enqueue/dequeue technique in the drivers of the HC2000 automation language since first released in 1992. The TSR programs are included with the "C", BASIC, PASCAL source code systems for the TW523S/P.

True RS232 Serial

Our second generation serial interface is a true RS232 device. You open it as COM Port on any machine that supports standard RS232 format, voltage, and current levels. The reason for the design is that the first generation, above, will not work within the Windows environment. You cannot address the serial port on a bit/pin basis. You must go through the UART and use RS232 8 bit-byte format. Also, under Windows, forget about the parallel port completely, just hook a printer to it.

We designed a double-sided surface mount board to fit inside the same shell as the old "DOS" version (this new unit will work within DOS). On the board is a micro-controller and RS232 chip. It is also parasitic and requires no additional power. A feature is that it auto-detects 50Hz crossings and will therefore work in a 220/240V 50Hz environment.

When you plug the TW523S10 into the COM port and open the unit it will immediately start to send you back a status byte. This byte should then be trapped by your application program as an interrupt. Your interrupt program is then written in such a way to review the status byte and take appropriate action. An explanation as to the status of each bit is listed below.

#include <stdio.h>

#include <string.h>

#include <dos.h>

#include "compiler.h" /* You add this part, if required for compiler specifics */

int pindx = -1; /* port index */

int pbase = 0; /* base of port */

int zero = 0; /* zero cross flag */

int rdtmr = 0; /* read timer address */

/* transmit translation table */

int tbltx[] = {0x6,0x7,0x4,0x5,0x8,0x9,0xa,0xb,

0xe,0xf,0xc,0xd,0x0,0x1,0x2,0x3};

/* receive translation table */

int tblrx[] ={0xc,0xd,0xe,0xf,0x2,0x3,0x0,0x1,

0x4,0x5,0x6,0x7,0xa,0xb,0x8,0x9};

/* default port table */

int deftbl[] = {0x3f8, 0x2f8, 0x3e8, 0x2e8, 0x378, 0x278, 0x3bc};

int tw523ok(int index)

{

int i, zcnt, oindx, obase;

int far *ptable;

if((index < 0)||(index > 6)) /* ensure valid index */

return(-1);

oindx = pindx; /* remember preset

obase = pbase;

pindx = index; /* assign global */

if(atorxt() != 0) /* must find read timer */

{

pindx = oindx; /* no change */

pbase = obase;

return(-2);

}

ptable = (int far *)0x400; /* get port table pointer */

pbase = ptable[pindx]; /* get pbase */

if(pbase == 0) /* invalid port ? */

pbase = deftbl[pindx]; /* use defaults */

if(pindx < 4)

outportb(pbase + 4, 1); /* init RS232 signals */

else

{

outportb(pbase, 0); /* init parallel signals */

outportb(pbase + 2, 0);

}

for(i = 0; i < 250; i++) /* delay for power-up */

dly1000();

disable();

testz(); /* clear status */

for(zcnt = 0, i = 0; i < 18; i++) /* in 18 ms */

{

dly1000();

if(testz()) /* should be 2 or 3 zero xings */

zcnt++;

}

enable();

if((zcnt != 2) && (zcnt != 3)) /* 2 or 3 zero xings ? */

{

pindx = oindx; /* no change */

pbase = obase;

return(-4); /* oops no tw523 there */

}

return(0); /* yes, all is fine */

}

sendx10(int house, int unfu)

{

int i;

waitz(); /* synchonize */

waitz();

waitz();

setting */ waitz();

for(i = 0; i < 2; i++) /* send transmissions 2x */

{

send1();

send1();

send1();

send0();

sendb(house & 0x1);

sendb(house & 0x2);

sendb(house & 0x4);

sendb(house & 0x8);

sendb(unfu & 0x1);

sendb(unfu & 0x2);

sendb(unfu & 0x4);

sendb(unfu & 0x8);

sendb(unfu & 0x10);

}

was just sent */

waitz(); /* stay in sync chained rx */

waitz();

return(0);

}

int recvx10(int *house, int *unfu) /* receive a code if available */

{

if(!recvh()) /* check for sync */

return(1); /* no, quit */

if(!recvh()) /* check for sync */

return(-1); /* no, quit */

if(!recvh()) /* check for sync */

return(-2); /* no, quit */

if(recvh()) /* check for sync */

return(-3); /* no, quit */

*house = 0; /* init return values */

*unfu = 0;

*house |= recvb() ? 0x1 : 0 ;

*house |= recvb() ? 0x2 : 0 ;

*house |= recvb() ? 0x4 : 0 ;

*house |= recvb() ? 0x8 : 0 ;

*unfu |= recvb() ? 0x1 : 0 ;

*unfu |= recvb() ? 0x2 : 0 ;

*unfu |= recvb() ? 0x4 : 0 ;

*unfu |= recvb() ? 0x8 : 0 ;

*unfu |= recvb() ? 0x10: 0 ;

return(0); /* mark valid reception */

}

sendb(int bit) /* send a full bit */

{

if(bit)

{

send1();

send0();

}

else

{

send0();

send1();

}

return(0);

}

send1() /* send a half bit 1 */

{

if(pindx < 4) /* if serial */

{

disable();

enable(); /* jic a 1 waitz();

outportb(pbase + 4, 3);

dly1000();

outportb(pbase + 4, 1);

dly1778();

outportb(pbase + 4, 3);

dly1000();

outportb(pbase + 4, 1);

dly1778();

outportb(pbase + 4, 3);

dly1000();

outportb(pbase + 4, 1);

}

else /* if parallel */

{

disable();

waitz();

outportb(pbase, 0xff);

dly1000();

outportb(pbase, 0x00);

dly1778();

outportb(pbase, 0xff);

dly1000();

outportb(pbase, 0x00);

dly1778();

outportb(pbase, 0xff);

dly1000();

outportb(pbase, 0x00);

}

return(0);

}

send0() /* send a half bit 0 */

{

enable(); /* jic a 1 was just sent */

waitz();

return(0);

}

int recvb() /* receive full bit */

{

int retc;

retc = recvh(); /* get bit value */

waitz(); /* discard next half bit */

return(retc);

}

int recvh() /* get the half bit on the line */

{

int retc;

disable();

waitz();

dly0600();

retc = samprcv();

enable();

return(retc);

}

int samprcv() /* sample the half bit on the line */

{

if(pindx < 4)

{

if(inportb(pbase + 6) & 0x10)

return(1);

else

return(0);

}

else

{

if(inportb(pbase + 2) & 0x02)

return(1);

else

return(0);

}

}

waitz() /* wait for zero xing */

{

while(!testz());

return(0);

}

int testz() /* test for zero xing */

{

int temp;

if(pindx < 4)

{

temp = zero; /* remember previous zero */

zero = inportb(pbase + 6) & 0x20; /* get new zero */

return((zero ^ temp) ? 1 : 0);

}

else

{

temp = zero; /* remember previous zero */

zero = inportb(pbase + 2) & 0x08; /* get new zero */

return((zero ^ temp) ? 1 : 0);

}

}

int atorxt() /* find terminal count bit */

{

int x, i, j;

x = inportb(0x61);

x = (x & 0xfc) | 0x01;

outportb(0x61, x); /* enable gate disable speaker */

outportb(0x43, 0xb6); /* set mode */

outportb(0x42, 0x00); /* set time constant */

outportb(0x42, 0x01);

for(rdtmr = 0x61; rdtmr <= 0x62; rdtmr++)

{

x = inportb(rdtmr) & 0x20;

for(j = 0, i = 0; i < 1000; i++)

{

if(x == (inportb(rdtmr) & 0x20))

continue; /* no change in bit */

x ^= 0x20;

j++;

}

if(j >= 4) /* if 4+ transitions */

return(0); /* found correct bit */

}

return(-1); /* timer read not found */

}

dly0600() /* delay 0.600ms */

{

outportb(0x43, 0xb0); /* set mode */

outportb(0x42, 0xa6); /* set time constant */

outportb(0x42, 0x02);

while((inportb(rdtmr) & 0x20) == 0);

return(0);

}

dly1000() /* delay 1ms */

{

outportb(0x43, 0xb0); /* set mode */

outportb(0x42, 0x6a); /* set time constant */

outportb(0x42, 0x04);

while((inportb(rdtmr) & 0x20) == 0);

return(0);

}

dly1778() /* delay 1.778ms */

{

outportb(0x43, 0xb0); /* set mode */

outportb(0x42, 0xda); /* set time constant */

outportb(0x42, 0x07);

while((inportb(rdtmr) & 0x20) == 0);

return(0);

}

x10msg(unsigned char *prefix, int house, int unfu) /* display x10 message */

{

char *funcmsg[] = { /* function messages */

"All Units Off",

"Hail Request",

"Dim",

"Extended Data",

"On",

"Pre-set Dim",

"All Lights Off",

"Status = Off",

"All Lights On",

"Hail Acknowledge",

"Bright",

"Status = On",

"Off",

"Pre-set Dim",

"Extended Code",

"Status Request"

};

union REGS regs;

char tstr[12];

regs.h.ah = 0x2c; /* get dos time */

intdos(&regs, &regs);

sprintf(tstr, "%2d:%02d:%02d ", regs.h.ch, regs.h.cl, regs.h.dh);

house = tblrx[house & 0xf] + 'A'; /* covert to ascii */

if(unfu <= 0xf)

{

unfu = tblrx[unfu & 0xf] + 1; /* covert to decimal */

}

printf("%s%sDevice %c-%d\n", prefix, tstr, house, unfu);

}

else

printf("%s%sFunction %c-%s\n", prefix, tstr, house, funcmsg[unfu & 0xf]);

return(0);

Now that the communications protocol has been defined, we now present you with an example of a program to put the X-10 functions into effect.

#include "tw523.c"

int house = 0x6; /* init for house A */

int aschouse = 'A';

int unit = 0x6; /* init for unit 1 */

int valunit = 1;

char line[80] = {0};

void main(void)

{

int retc, key;

memset(line, 0xc4, 80); /* init line */

retc = 0; /* init return code */

while(1) /* scan in main menu */

{

if(retc != 1) /* display menu if ness */

mainmenu();

disprx(); /* display any rx activity */

if(!kbhit()) /* if no key input */

{

retc = 1;

continue;

}

key = toupper(getch()); /* the the key */

if(key == 0x1b) /* exit ? */

break;

if(pindx < 0) /* is port ok ? */

key = 'P'; /* no, fake key */

switch(key) /* look at input key */

{

case 'M': /* menu again */

retc = 0;

break;

case 'P': /* port change */

retc = getport();

break;

case 'S': /* selection */

retc = gethoun();

break;

case '0': /* off function */

dofunc(0x1c);

retc = 1;

break;

case '1': /* on function */

dofunc(0x14);

retc = 1;

break;

case 'D': /* dim function */

dofunc(0x12);

retc = 1;

break;

case 'B': /* bright function */

dofunc(0x1a);

retc = 1;

break;

case '?': /* status req function */

case '/':

dofunc(0x1f);

retc = 1;

break;

default:

retc = -1; /* set for error */

break;

}

if(retc < 0) /* if error */

{

printf("**********************************\n");

printf("* Invalid Entry, Please Re-Enter *\n");

printf("**********************************\n");

printf("(Hit any key to continue)\n\n");

getch();

}

}

}

mainmenu()

{

char port[5];

switch(pindx)

{

case 0:

strcpy(port, "COM1");

break;

case 1:

strcpy(port, "COM2");

break;

case 2:

strcpy(port, "COM3");

break;

case 3:

strcpy(port, "COM4");

break;

case 4:

strcpy(port, "LPT1");

break;

case 5:

strcpy(port, "LPT2");

break;

case 6:

strcpy(port, "LPT3");

break;

default:

strcpy(port, "?");

break;

}

printf("\n\xda%.37s\xbf\n", line);

printf("\xb3 TW523 DEMO by Sting Technology \xb3\n");

printf("\xb3 Distributed by: BARAN-HARPER Group \xb3\n");

printf("\xb3 Voice:905-294-6473 BBS:905-471-6776 \xb3\n");

printf("\xc0%.37s\xd9\n\n", line);

printf("Settings: Port-%s Device %c-%d\n\n", port, aschouse, valunit);

printf("M - Display this Menu\n");

printf("P - Port Select\n");

printf("S - Select Device\n");

printf("0 - Unit OFF\n");

printf("1 - Unit ON\n");

printf("D - Unit DIM\n");

printf("B - Unit BRIGHT\n");

printf("? - Unit Status Request\n\n");

printf("Esc - Exit Demo\n\n\n");

return(0);

}

getport()

{

char input[81];

int index;

printf("\nWhat Port is being used ? 1 - COM1");

printf("\n 2 - COM2");

printf("\n 3 - COM3");

printf("\n 4 - COM4");

printf("\n 5 - LPT1");

printf("\n 6 - LPT2");

printf("\n 7 - LPT3\n");

printf("\n (1-7) > ");

scanf("%1s", input);

printf("\n");

if((*input < '1')||(*input > '7'))

return(-1);

index = *input - '1'; /* calc port index */

if(tw523ok(index)) /* try to init port */

{

printf("*********************************\n");

printf("* Cannot Communicate with TW523 *\n");

printf("*********************************\n");

printf("(Hit any key to continue)\n\n");

getch();

}

return(0);

}

gethoun() /* get house and unit # */

{

char input[81], c;

int index, i;

printf("\nEnter House code & Unit number (A-P 1-16) > ");

scanf("%1s%d", input, &i);

printf("\n");

c = toupper(input[0]);

index = c - 'A';

if((index < 0)||(index >= 16)) /* set house if in range */

return(-1);

house = tbltx[index];

aschouse = c;

index = i - 1;

if((index < 0)||(index >= 16)) /* set function if in range */

return(-1);

unit = tbltx[index];

valunit = i;

return(0);

}

dofunc(int func) /* txmit an x10 command */

{

x10msg("TX: ", house, unit); /* display the message */

sendx10(house, unit); /* select device */

x10msg("TX: ", house, func); /* display the message */

sendx10(house, func); /* perform funtion */

return(0);

}

disprx() /* receive routine */

{

int rhouse, runfu;

if(pindx >= 0) /* make sure valid base */

if(!recvx10(&rhouse, &runfu)) /* check for receive */

x10msg("RX: ", rhouse, runfu); /* display a message */

return(0); /* no entry error */

}

Note:

This C source code is available on both 3.5 and 5.25 inch IBM formatted diskettes. Ordering forms are at the back of this paper. Source code is also available in both Basic and Pascal.

A simple parallel interface may be constructed to test the above code sample. Tare should be taken in using this design in that you may blow your parallel port. Test your port with a printer or a known working device before you attempt to test this connection. Diodes, 1N4148, can be used to connect the transmit pin # 1 of the TW523 to each pin 3,5,7,9.

Using the parallel port on your PC can always be an interesting task. If you connect this unit as shown and after using the above source code to test it your unit still "will not communicate" then I would suggest you review your parallel card. Other than it not being blown, is it a true bi-directional card ? You may wish to try a different machine. Since this unit is "parasitic" and draws its current from your printer card, there may not be enough power in the port to drive everything. This is very common problem on laptops.

Although this unit will work, properly constructed units using 2N3906/2N3904 transistors, diodes, and a few resistors allow for a reliable multi machine/I-O card utilization to properly implement this solution

The TWSER is an asynchronous RS232 hardware interface device that connects to a X10 TW523 interface. The TWSER interface removes all of the critical timing concerns when talking to the TW523.

Features

Restrictions

The TWSER interface runs asynchronously at 300 baud, 8 data bits,

1 stop bit using RS232. The TWSER interface steals power from the

RS232 signals.

The following RS232 DB-25 pins are used:

The user should set pins 4 & 20 to inactive for four seconds then set pins 4 & 20 to active in order to reset the TWSER.

The TWSER interface runs half duplex, meaning that the TWSER and the user cannot send data at the same time. There is a simple protocol that is exchanged between the TWSER and the user.

When the TWSER sends a poll request type command (three most significant bits zero 000xxxxx) the user has up to 100ms to respond, else the TWSER will re-send the poll. When responding to this poll, the user sends a poll reply type command (three most significant bits zero 000xxxxx) so the TWSER knows when

the user is finish sending.

There are dual X10 transmit buffers so the user can send up to two X10 commands in a row. Likewise when receiving X10 data, there are dual buffers so up to two X10 commands can be queued. Each X10 buffer position contains House Unit or Function and Repeat amounts.

The TWSER may send any of the following commands:

Poll Request

Once this command has been sent, it is safe for the user to send any reply data.

Note that when the X10 receive activity bit is set, the user should NOT send House, Unit/Function or Repeat codes to ensure a X10 receive buffer overflow condition will not occur.

This command details the error type from the poll command.

1 0 0 0 x x x x

The four bits indicate the House code. Details follow.This is sent in response when the user asks to read the received X10 data.

1 0 1 0 x x x x

The four bits indicate the Unit code. Details follow This is sent in response when the user asks to read the received X10 data, following the House code.

1 0 1 1 x x x x

The four bits indicate the Function code. Details follow. This is sent in response when the user asks to read the received X10 data, following the House code.

1 1 0 0 0 0 1 0

This code is sent to indicate that the TW523 has received two X10 repeated commands.This is sent in response when the user asks to read the received X10 data, following the Unit or Function code.

The user may send any of the following commands:

Poll Reply

----------

0 0 0 0 0 0 0 0 - simple null reply

0 0 0 0 0 0 0 1 - request TWSER error status

0 0 0 0 0 1 1 1 - request TWSER X10 receive

(House, Unit/Function, Repeat)

After sending any one of these replies, the user must wait for the next poll request before sending more data.

House Code

----------

1 0 0 0 x x x x

The four bits indicate the House code. Details follow. This is sent in when the user wants to send X10 data.

Unit Code

---------

1 0 1 0 x x x x

The four bits indicate the Unit code. Details follow. This is sent in when the user wants to send X10 data Must be sent after House Code.

Function Code

-------------

1 0 1 1 x x x x

The four bits indicate the Function code. Details follow. This is sent in when the user wants to send X10 data. Must be sent after House code.

Repeat Amount

-------------

1 1 0 x x x x x

The five bits (range 2 -> 1f) indicate the number of times the X10 House Unit/Function codes should be sent. Only Dim and Bright codes should be sent more than once. Must be sent after Unit or Function code.

Delay X10 Transmit

------------------

1 1 0 0 0 0 0 0

This special command may be sent after a normal X10 transmit command to "listen" to the X10 line for four seconds. This would be particularly useful after sending a Status Request Function code. This command is queued on the X10 transmit buffer. This code need not be preceded by House, Unit/Function.

Notes: The following are limitations of the TW523

* If more than two continuous Dim or Bright codes are received, every third code is missed.

** These continuous streams of data are not supported.

The following flow chart details the serial protocol:

[1]

|

v

wait for a receive data

character

|

v

is it a Poll Request? --yes--> [2]

000xxxxx

|

v

is it an Error Status? --yes--> keep Error statistics -->[1]

001xxxxx

|

v

is it a House Code? --yes--> save House Code -->[1]

1000xxxx

|

v

Unit/Function Code? --yes--> save Unit/Function Code-->[1]

101xxxxx

|

v

is it a Repeat Amount? --yes--> save Repeat Amount

110xxxxx X10 receive complete -->[1]

|

v

unknown data character -------> keep Error statistics -->[1]

[2]

|

v

X10 receive Data? --yes--> [3]

000xxxx1

|

v

Error Status available? --yes--> send Error read request

0001xxxx 00000001 -->[1]

|

v

X10 receive active? --yes--> [1]

000xxx1x

|

v

X10 transmitter full? --yes--> [1]

000xx1xx

|

v

any X10 to Transmit? --yes--> Send House: 1000xxxx

| Unit/Function:101xxxxx

v Repeat Amount:110xxxxx

[1] Null Reply: 00000000 -->[1]

[3]

|

v

user ready to receive --yes--> send X10 read request

X10 data? 00000111 -->[1]

|

v

not ready to receive -------> send Null Reply for now

X10 data 00000000 -->[1]

(should only be done once)

The revised version of the TW523 interface allows for a much more user friendly approach to the problem. Listed below is a sample coe listing written in qbasic, running on a Compaq 286 in Dos:

TYPE Event

house AS INTEGER

unitFunc AS INTEGER

repeat AS INTEGER

END TYPE

DIM SHARED rxEvent(0 TO 255) AS Event

COMMON rxPut%

COMMON rxGet%

CLS

rxPut% = 0

rxGet% = 0

OPEN "COM1:300,N,8,1,BIN,CD0,CS0,DS0,OP0,RS" FOR RANDOM AS #1

Null% = 0

PUT #1, 1, Null%

COM(1) ON

ON COM(1) GOSUB ComHandler

DO WHILE INKEY$ = ""

COLOR 5

PRINT "X";

COLOR 7

IF rxPut% <> rxGet% THEN

PRINT ""

PRINT "RX: House:"; HEX$(rxEvent(rxGet%).house);

PRINT " Unit/Func:"; HEX$(rxEvent(rxGet%).unitFunc);

PRINT " Repeat:"; HEX$(rxEvent(rxGet%).repeat)

rxGet% = rxGet% + 1

IF rxGet% = 256 THEN rxGet% = 0

END IF

LOOP

COM(1) OFF

END

ComHandler:

GET #1, 1, twrx%

mode% = twrx% AND &HE0

SELECT CASE mode%

CASE &H0

IF twrx% AND &H1 THEN

twtx% = &H7

PUT #1, 1, twtx%

ELSEIF twrx% AND &H10 THEN

twtx% = &H1

PUT #1, 1, twtx%

END IF

CASE &H20

CASE &H80

rxEvent(rxPut%).house = twrx% AND &HFF

CASE &HA0

rxEvent(rxPut%).unitFunc = twrx% AND &HFF

CASE &HC0

rxEvent(rxPut%).repeat = twrx% AND &HFF

rxPut% = rxPut% + 1

IF rxPut% = 256 THEN rxPut% = 0

END SELECT

RETURN

The TW523 could be either for the 110Volt 60Hz market, which is North American(generally) or the 220V 50Hz flavor, which is the rest of the world. Read the back of the unit to make sure what you have.

Note: It is possible to convert the 110/60 TW523 to the 220/50 TW523. Contact your supplier or the BARAN-HARPER GROUP for details.

DOS Parallel/Serial kits

Congratulations on your purchase of the TW523 Developers Kit. Depending upon the software you have selected, startup instructions may vary. We have included in the kit two disks: 5.25 /360k and 3.5/720k, formatted for the IBM environment. On these disks should be the software you ordered: 'C',BASIC,PASCAL,or a RUNTIME program called TW523-40/HC2000 AND a collection of other TW523 based files. Read the file called README.1ST for specific information. Each file is self-extracting except CMD523.EXE and should be copied into its own directory before executing.

To get up and running right away perform the following:

1: Connect the Serial/Parallel interface to your computer.

2: Connect the RJ-11 cable to the Serial/Parallel interface.

3: Connect the other end of the cable to the TW523

4: Plug the TW523 into a working 110 Volt AC outlet.

5: Run the program CMD523 from one of the disks supplied.

6: Select the correct sequence eg: 1 A1 1 for Com 1, A1, ON.

7: Hit enter, A1 has just gone on.

8: Now read README.1ST

However.....

If a message of CANNOT COMMUNICATE appears when you select the port, or at any other time, make sure all of the connections are correct, and the port selection is correct. Retry. If this fails, you may have a dead unit(it does happen).

Problem determination:

X10 is registered trademark of X10 Powerhouse.

IBM is a registered trademark of International Business Machines.

All hardware and functions of the TWSER have been developed by Sting Technology.

The Baran-Harper Group owns all rights to the TWSER product.

_