Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tuicemen]

I was asked to test the prototype and give some input.
Not having any PLC range issues I tried Unsuccessfully to create some  
Throwing a XTBM Pro at it showed no really remarkable results.

I just receive the release version  PLC Repeater, the only visible difference in the two is the color (test unit was black this is white)
I again performed some tests with a XTBM Pro.
There was a improvement in signal strength
There is no signal booster in this (which would have been nice) but tests reveled only a 0.04 signal difference from the originally sent signal.
This was with the X10 transmitter being on the opposite Phase and both the transmitter and repeater at the last outlet on each wire run.
That doesn't say much as I'm in a small home which was just rewired.

I only have one noisy outlet hear however it is hard to get to so I wasn't able to test from it but the prototype performed well in a noisy environment. So I expect the same if not better results from this one.
I'll post test results once I'm able to get to this outlet.

Bottom line:
Some may say Authinx is not addressing the problem, just like the old X10 WTI.
I have to disagree, the new modules Authinx has reintroduced that I've tested so far shouldn't need this.
Why replace all your equipment with the newer stuff if a simple repeater with help.

[Tuicemen]

I did some more tests with the release build (PLC01)
Originally I was testing this with the prototype CC3000 which my meter shows a signal of 9.99 (actually it is much higher then that) This was why I wasn't seeing much of an improvement
This time I tested with my Cm15 with a signal of 7.41Vpp at the outlet it is connected to.

Authinx states there is no booster in this unit but this unit is heavier then the proto type. I never noticed this until I held both at the same time.

The new unit does send a much stronger signal then the proto type sending a repeat reading of 9.99 from a received PLC reading of 0.70Vpp
Is this enough to blast threw the noise?
I guess that would depend on how much noise is on the line.
I had a laptop producing a noise level of n.70 and this was enough to stop it even showing collisions on the meter.
A noise of n.01- n.14 wasn't a issue though usually this isn't a issue without the repeater either.

The fact that this sends a stronger signal then my cm15 is a sign X10 is improving transmitters across the board.
This should help on long wire runs where the PLC signal drops so much that a device doesn't see the command.

[dhouston]

It would be helpful to know the timing on the repeat commands. Does it repeat in real-time or wait until after the original command?

[Tuicemen]

It sends supposedly after it sees the original command.
The XTBM pro shows same second to 1 second difference on the same circuit tests

[dhouston]

That could create problems for older controllers using TW523 or compatible PLC interfaces.

[Tuicemen]

It may, I have no way of testing that. 

[dhouston]

Jeff Volp can probably test it. He had an Ocelot & a Leopard although his TW523 emulator may not have the same issues as the TW523.

[JeffVolp]

Jeff Volp can probably test it. He had an Ocelot & a Leopard although his TW523 emulator may not have the same issues as the TW523.

I actually have quite a lot for testing, including a PSC05, TW523s, a couple of Ocelots, your Leopard, and HomeVision.  I even picked up one of those RCS X10 thermostats to debug a problem.  Add to that many other X10 and Leviton PLC products.

Test equipment includes two Tektronix analog scopes, a 150MHz Instek digital storage scope (invaluable during firmware development), two Wavetek function generators, frequency counter, power supplies, meters, etc.

Jeff

[JeffVolp]

It may, I have no way of testing that. 

Most the repeaters I am familiar with receive the first half of the X10 doublet, and repeat that overlaid in bit sync with the second half.  I believe there was a SmartHome "booster" that amplified signals bit-by-bit as they arrived.  The current XTBR supports that mode for a nearby transmitter.

You can check how it works with the XTBM-Pro using the Bitmap mode.  Capture a command and scroll through the bits.  If all the "1" bits are at the full amplitude it is boosting the signal bit-by-bit.  But if the only the "1" bits in the second half of the doublet are full amplitude, it is working like most repeaters.

If it is storing the command and re-transmitting it after the original transmission has ended, that is a new kind of repeater.  If that is how it works, it could cause difficulty for any controller that issues multiple commands one after another.

Jeff

[dhouston]

Polite controllers that follow the X10 Access Protocol (below) should be able to handle multiple commands as long as the chain is not too long.

When a transmitter has a message it wishes to transmit, it must wait
for access to the powerline for either 8, 9, or 10 half mains cycles -
during which the line must have been continuously clear of data '1'
bits. If a '1'bit is detected, it must restart it's access timing and
wait for another 8, 9, or 10 cycles.

After line access has been achieved, the transmitter must check the
line during the transmission of a '0' bit (no carrier) to see that no
other transmitter is transmitting. If a collision occurs, the
transmitter must abort its transmission immediately and again go
though the line access procedure.

The choice of 8, 9, or 10 half cycles is chosen randomly for each line
access attempt.

The X10 Access Protocol was added to handle extended codes but controllers designed before this (that expect a TW523/PSC05) cannot implement the protocol as the TW523/PSC05 do not report PLC commands in real-time, rendering the controllers powerless to detect whether the line is clear nor can they avoid collisions.

[JeffVolp]

Polite controllers that follow the X10 Access Protocol (below) should be able to handle multiple commands as long as the chain is not too long.

A number of our customers have run into the default XTB-IIR command storm shutdown, which allows a burst of up to 200 commands before it disables the transmitter until the line clears.  So some folks are sending very long streams of commands.  I usually get an email that the XTB-IIR has failed.  After finding out what is happening, I direct them to the page in the instruction booklet to choose the higher threshold that allows a burst of 400 commands.

The power-up initialization sequence for our own home that reconfigures all X10 devices depending on the time of day lasts over 10 seconds of continuous transmission, or about 30 commands.  Since most of our dimmers only require one extended command to set the brightness, there aren't any long dim sequences.  I believe that is what has caused the shutdown in some installations.

Jeff

[toasterking]

If it is storing the command and re-transmitting it after the original transmission has ended, that is a new kind of repeater.  If that is how it works, it could cause difficulty for any controller that issues multiple commands one after another.

Polite controllers that follow the X10 Access Protocol (below) should be able to handle multiple commands as long as the chain is not too long.

But in the case of a polite repeater that waits until an existing transmission has ended to retransmit it, couldn't a sequence with multiple state changes yield very undesirable results?  Example:
Input sequence: A1 on A2 off A1 off

Code: [Select]

Original: [A1] [on] [A2] [off] [A1] [off]
Repeated:      [waiting to send A1------] [A1] [on] [A2] [off] [A1] off]Output sequence: A1 on A2 off A1 off A1 on A2 off A1 off
A1 would go on and off twice instead of once.  If A1 is just a lamp, that's just annoying.  If A1 is a logic pulse to toggle something (e.g. a momentary power switch, a shutter opening direction, etc.), it's disaster.

Or if they are both polite transmitters and wait the requisite random number of half-cycles before sending the next transmission, the output sequence could become very messy as a result:
Input sequence: A1 on A2 off A1 off

Code: [Select]

Original: [A1] [w-] [on] [A2] [off] [w-] [A1] [w-] [off]
Repeated:      [A1]      [w-] [w--] [on] [w-] [A2] [w--] [off] [A1] [off]Output sequence: A1 A1 on A2 off on A1 A2 off off A1 off
This time, A2 gets turned off, then on, then back off again even though there was originally no command to turn A2 on at all.
There may be ways to work around this by breaking protocol.  For example, the repeater could wait longer than the number of half-cycles specified in the line access protocol to make sure that it always gets in last, but you would still have the problem of entire sequences being repeated and would only encourage collisions since you broke protocol.  Maybe there is a way around all of this than I'm not considering, but it doesn't seem like a very solid start to solving the problem.

[haroldbr18]

I have purchased a PLC01 repeater. It works well, however I have experienced a condition where the unit goes int a mode whereby it continues to blink and keeps sending out the same command. The only way to reset is to pull out the unit and then replug it in. I am not sure if this is a design flaw or a defective unit. Has anybody experienced this problem. Has there been any update in SW to correct this problem

[dhouston]

I don't know whether it is a design flaw (although I suspect it is) but the "repeater" in its name worries me.

If I understand it correctly, Jeff Volp sells a PLC booster which amplifies the signal in realtime without repeating. If this is the case, IMHO, it's a better approach to weak PLC signals.

[JeffVolp]

If I understand it correctly, Jeff Volp sells a PLC booster which amplifies the signal in realtime without repeating. If this is the case, IMHO, it's a better approach to weak PLC signals.

Both the XTBR and XTB-IIR are repeaters.  As you know, the X10 command is comprised of two identical halves.  All the "repeaters" I am familiar with - XPCR, similar Leviton units, the ACT units, and our own units - receive the first half over the powerline, and re-transmit that overlaid in bit-sync with the second half.  So the command isn't stretched, just the second half is boosted by the repeated first half.

The XTB, XTBR and XTB-IIR also provide direct boost, where a device connected directly to it keys on the high power transmitter bit-by-bit.  In the case of the new XTBR, that works with an X10 transmitter plugged into a nearby outlet on the same circuit.

Jeff