Linux Home

(Last updated: Saturday August 25, 2007)


The SD523 device is a replacement for the X10 TW523 Two way interface.

X10 Receive circuitry.

Circuit theory of operation.

The original circuit existed all the way up to R10. At this point it enters my circuit. I modify the signal and the finish product enters back into the existing cicuit at the base of D1. At this point C1/R4/D1 make the signal look more like a logic signal (rise, stay flat, fall). This turns the LED in 4N35 (IC2) on and off at the appropriate time. The reason for the opto isolator is that the ground reference of the TW523's power supply is the house neutral of the the AC.

The basic operation is very simple, C10 acts as a relatively high impedance to 60Hz (~10K Ohms) and a low impedance to 120KHz (~.6 Ohms), R11 limits the amounts of currents and TC2 appears as a low impedance device to the 120KHz signal (tuned to match 120KHz) and as a high impedance device to everything else (C10 could be for phase correction). The diodes D3 and D4 are for voltage regulation by trimming voltages larger than 5.1 v on either peak of the signal. C6 and R10 act as a ??? (what is this doing in the circuit now). The 8.2K & 1K resistors bias the circuit to 1.6V (the R10 is now in parallel with my 1K bias resistor) bias Q1 into it's active region and the 82K & 1K provides a gain (~82). The 0.1uF cap across the emitter to ground of Q1 improves the frequency response (mucho gain). At the collector of Q1 the signal is now inverted. We need to invert it again so we put it through another transitor (Q2) and now get a very strong signal (82 x 33 = 2706). C1 smooths out the pulse so it looks more like logic signal. It is then drives the 4N35's led on when the signal is present.

I need to add the voltages as seen in the circuit, with the IC and my circuit replacing it. Also I need to perform a few tests my circuit may need to be update accordingly.

Signal theory of operation.

Full packet (seen from AC line)

Starting with what has been transmitted onto the AC we have the following: The transmitter transmits a 120KHz pulse up to 50uS after the Zero Crossing (ZC), the pulse is 1mS in duration (we will ignore the other 2 pulses, which correspond with the second and third phase, for now). An X10 message consists of 2 halves. Each half is 22 bits long. The first half (ID) is sent twice, then a pause of 6 ZC's then the second half (CMD) is sent twice. The transmitter must wait at least 6 ZC's before starting to transmit. The entire message takes 94 bits to send, plus wait 6 ZC's before starting, grand total 100 ZC's. Strange how this corresponds exactly to 50Hz (100 ZC's). The TW523 will send the signal to the end user device as it starts to see the second half of the command. I currently don't know what it does if the second half of the command has bit errors. The original TW523 can not see Dims, Brights, Extended Commands or Extended Data because none of these wait for the 6 ZC's between commands.

1/2 packet (seen from TW523 output)

An interesting thing to note, even though the halves get sent twice it appears (a quess on my part) that the TW523 just shifts through the first bits shifted in. I suspect that if the repeated section were all garbage then the first have would still get shifted in. The reason I believe that is only the first and third DIM commands will be caught by the TW523. Of course this just may be caused by the fact that no pause exists with DIMs.

A single X10 command such as turn device A1 on takes a grand total of 50 cycles. For those in Europe (X10 was invented in Scotland) that means that each command takes 1 second. For those of us on 60 cycle AC the each command takes ~0.833 seconds. Here is the break down (this assumes nobody is sending or in the middle of sending):

1) ( 3) The sending device should wait for 3 cyles with no signal seen.

2) ( 2) Then send the Start of Header (1110) this takes 2 cycles.

3) ( 9) Then send the first half of the command (Letter code/Number code) this takes 9 cyles.

4) (11) Repeat steps 2 & 3.

5) ( 3) Pause for 3 cycles.

6) ( 2) Then send the Start of Header (1110) this takes 2 cycles.

7) ( 9) Then send the second half of the command (Letter code/Function code) this takes 9 cyles.

8) (11) Repeat steps 6 & 7.


3 + 2 + 9 + 11 + 3 + 2 + 9 + 11 = 50

One can argue that the first 3 cycle pause can be ignored but I don't recommend it. Also this doesn't take into consideration the BrightDim commands or the Extended Data/Command Commands. These commands don't have the middle pause between the Letter/Number packet and the Letter/Function packet.

Collision Avoidance

Collision detection is a difficult subject, unlike ethernet where the energy can be measured. X10 is not set up to behave this way (Is it?). The best I could come up with was to try collision avoidance. This is done by monitoring the state of the signals on the AC. The TW523 didn't permit the end user device to know that there was a signal already on the line (the first 22 bits). So a collision could easily occur. A way to avoid this is to buffer the commands to be sent to the AC (which means that we still need to echo back the second half of the command). We could then forward the command when the state of the X10 is such that it has completed a command and we have seen 6 ZC's.

Collision Detection

Originally I thought that collision detection was not possible on X10. It actually turns out to be quite easy to do. The first way is to do. First read the Rx before transmitting your 1/2 bit, if there is a one there then someone is transmitting. Therefore you'll need to back off. The second is to read while your sending a 0 1/2 bit, again a 1 means collision. The third has to do with the phase timing. I need to put further thought into this before I can describe it properly. But it should be a variation on the above but delaying the sending of the 1 bit by a small amount of time. This of course is for my own custom created device which allows the end device to see every bit inserted onto the AC.

Circuit Cellar article

Circuit Cellar article