Re: XTB-II Options

[ddl@danlan.*com (Dan Lanciani)]

In article <I63fh.183692$Fi1.41054@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, JeffVolp@xxxxxxx (Jeff Volp) writes:
|
| "Dan Lanciani" <ddl@danlan.*com> wrote in message
| news:1335290@xxxxxxxxxxxxxxxxxxxxxx
| > In article <xigeh.170378$Fi1.6598@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
| "Jeff Volp" <JeffVolp@xxxxxxx> writes:
| >
| > | I am familiar with their unit.  As you know, the TW523 returns data to
| the
| > | host controller during the last 11 cycles of each X10 command.  When
| > | enabled, that is when the XTB-II transmits repeated data to the
| powerline.
| > | So the boosted signal is transmitted bit-synchronous with the second
| copy of
| > | each normal X10 command.  I believe that is how most repeaters work.
| > |
| > | Because the 120KHz bursts are not phase-locked, this approach can result
| in
| > | destructive cancellation of that second copy on the original
| transmitter's
| > | circuit.  However, any receivers on that circuit should respond to the
| > | unaltered first copy from that transmitter.  Since the XTB-II would
| normally
| > | be driving at the electrical distribution panel, its output would
| override
| > | the original transmitter's signal on all other circuits.
| >
| > This seems to be the unstated (except occasionally by me :) theory behind
| > most repeaters.  Sometimes I wonder, though, how probable it would be to
| > have a pathological case where the level heard by a particular receiver
| > from a transmitter is below the receiver's threshold, the level it would
| > hear from the repeater is above its threshold, but the difference between
| > the two signals is again below its threshold.  Operation could then depend
| > on the relative phase of the two free-running oscillators in the
| transmitter
| > and repeater, and that could lead to some head scratching--especially if
| > the levels shift in and out of the pathological ranges as other parts of
| > the network change.
|
| I don't think that would happen.  Assuming the repeater is at the
| distribution panel, then the signal from the remote transmitter must be
| strong enough to get that far.  So receivers on its own circuit should have
| sufficient signal to detect the first half of the message.  When the
| repeater transmits during the second half of the message, it should dominate
| at the distribution panel, and on all circuits other than the one feeding
| the remote transmitter.  Some receivers on that circuit could get a
| corrupted second half, but they should have already accepted the good first
| half.
|
| One case where this would not be true is when the "remote" transmitter is
| very close to the distribution panel.  In this case, that transmitter signal
| should be similar in strength on its own phase to the output of most common
| repeaters, and the first half of its message should propagate through the
| house just as well to devices on that phase.  The second half of the message
| can be corrupted on the transmitter's phase due destructive cancellation,
| but the repeater's output should be OK on the second phase.

What if we look at it from a receiver's point of view?  Say the receiver
has a threshold of 50mV and that it normally hears the repeater at that
level, giving reliable operation.  Assume it can also hear (but not act
on) a transmitter on another circuit at 25mV.  Depending on the relative
phase of the carriers won't it see between 25mV and 75mV during the repeater's
retransmission of that particular transmitter?  It obviously won't respond
to the first copy, so operation may appear random for that particular
transmitter/receiver pair.  I'm making all the usual linearity assumptions
so superposition works, and I'm ignoring variable loading of the repeater
itself (this may be important, but since some vendors' designs don't
unload when not driving anyway...).

Of course, the above values are chosen to provoke a worst case, but they
aren't all that different from what I had before I started adding filters
and such.  And we are talking pathological situations.

				Dan Lanciani
				ddl@danlan.*com