Re: Decora HCPRF WAS: Re: UPB, etc. WAS: Need some antenna advice...

[nobody@xxxxxxxxxxxx (Dave Houston)]

Reading the docs, are we? Geesh - no wonder things are so confused. ;)

I did not do extensive testing with the HCPRF. Once I saw there was no room
to add an external antenna jack, I lost interest.

What unit codes are you seeing the strange behavior on?

www.mbx-usa.com/multiples.htm gives a very brief summary of what you'll see
with multiple transceivers.

While some have collision avoidance, there are still collisions as there
must be a collision in order for them to detect it and back off. This is one
reason for there being two copies of the X-10 PLC code. If the first gets
corrupted, the second will be OK (assuming that one of the transmitters
backs off). The price is duplicate commands - if the unit that backed off
then resumes transmitting once the line is clear. I consider units that do
automatic retransmission as brain dead. It's easy to envision duel-to-death
powerline storms from two such units. When I design something I limit the
number of times it will try to retransmit before throwing in the towel.

If there's no collision, the codes coincide and all's well.

The TM751 does not have collision detection or avoidance. Since it does not
"listen" to the powerline, it is oblivious to what's coming from other PLC
transmitters. When it receives an RF code for its housecode, its action
depends on the unit code. If it's for units 1 or 9, it has to wait for a
rising edge on the 60Hz in order to trigger the SCR that drives the relay,
before it relays the command to the powerline. For all other units, it just
sends the code at the next ZC regardless of whether it's a rising or falling
edge. If there are two transmitters on different phases, the signals will be
1/2 cycle off for units 1 & 9 but will coincide for all others.

Before ELK bought the design, I was in communication with Paul Beam, the
designer of the ESM1. We were discussing turning it in to a more
sophisticated device with an RS-232 connection and I offered to write a
Windows interface for it. Once ELK bought it, those discussions ended but I
did learn some of the details of the ESM1. It does not do any sophisticated
anaysis of the signal but if it sees a 1110 followed by an appropriate
number of 10 and 01 sequences, it turns on the "X10 Good" LED. If it does
not see a legal sequence, it does not illuminate the LED. So, you will
always see the signal in the LED bar for one full sequence before the "X10
Good" LED lights as the ESM1 has to see a full signal before it can make a
judgement.

Now, even with something that will show you the PLC signal, it's difficult
to identify where a specific burst of 120kHz originated. If we're looking at
two TM751s or a mix of TM751 and some other transmitter, about the only clue
is the amplitude of the signal and that's not always definitive especially
when all of the signal strength meters fail to show the true amplitude for
strong signals. All of them (including the newer ACT) top out below 5Vpp
while most of the older X-10 devices transmit 10Vpp. I have a pre-ELK ESM1
which was calibrated to show 10Vpp as fullscale. The ELK models are
calibrated using a Monterey so fullscale is something less than 5Vpp.

As you can see from the page I cited, I did not do much testing with the
HCPRF. Specifically, I did not test it with other transceivers on opposite
phases which is where most of the interesting things happen. I tested it
using the CM15A as my tarot card. With the Cypress MCU moved to a breadboard
and a ribbon cable from the breadboard to the CM15A MCU socket I could
monitor PLC receptions while disabling the the CM15A's PLC transmissions.

As an aside, the TW523 does not report all powerline activity. Specific to
this topic, it only reports the second half of its own transmissions.
Consequently, it cannot be used to avoid collisions. Anybody who thinks that
it can listen for a clean line doesn't understand how it works. If it is
used as part of a transceiver, there will be lots and lots of collisions
with any other transceivers on opposite phases.

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:

>"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
>
>> This has drifted rather far afield from the original thread.
>
>Agreed.  And I am going to break it out into two messages because the thread
>splits again!
>
>> I have one of the Leviton HCPRF transceivers but don't recall that it has
>a
>> built-in lamp module. At least not a dimmer - mine has a solid state
>relay.
>
>Correct.  Although the one I have says "300W max., 60W min. Incandescent
>load" and responds to the ALL LIGHTS ON command - it does not respond to DIM
>or BRIGHT commands.  I assumed that made it more of a lamp module than an
>appliance module.  They confuse the issue pretty solidly by stating, in one
>part of the documentation:
>
>    NOTE: If a power interruption should occur while the device
>    in ON, the light load will return to its previous light level when
>    power is restored.
>
>That's a neat trick for a module that doesn't seem to respond to DIM
>commands sent by Palmpad, Sticka Switch, Credit Card/Keychain type
>controllers and Mini-controllers.  The HCPRF PDF file goes on to say: "It
>can also be programmed to respond to scene commands from scene controllers."
>Perhaps if it dims, only Leviton controllers can activate that function.
>
>However, further on down when they discuss testing, they seem to  contradict
>themselves by saying:
>
>    "3. Transmit DIM and BRIGHT commands. The device will not
>     react, but will transmit the DIM or BRIGHT command through
>    the house wiring; all units set to the same code will respond."
>
>So, I'm not quite sure *what* it is.  I'd consider it a "non-dimmable" lamp
>module, but it's definitely a weird duck.  It *always* collides with the
>TM751s that are set to matching housecodes and it doesn't accept commands
>from the older-style transmitters that came with the RR501s (which had the
>somewhat useful 4 position unit slide switch).
>
>The HCPRF got retired because of the interactions with other transceivers
>but I'd sure like to know what it's putting on the line.  The Decora unit
>makes the ESM1 do a weird little dance whenever it's activated on a
>housecode with dedicated TM751 around.
>
>> It's RF range seems comparable to standard X-10 transceivers.
>Unfortunately,
>> there's no room within the case to add a connector for an external antenna
>> so I did not try to trace the circuit to see whether they are using the
>hot
>> side as electronic ground. Without knowing that I cannot make any antenna
>> recommendation.
>
>Yes, it's quite crowded in there.  I suspect that if the HCPRF ever DID dim,
>they disabled that function to limit heat build-up inside such a small unit.
>I'd spring for the CM15A with its far roomier cabinet.  It might be possible
>to remount the HCPRF in an old RR501 case, but it hardly seems worth the
>effort since it doesn't play nice with the TM751's I use.
>
>> There should be no collisions as the Leviton will back off and wait for a
>> clean line before it sends PLC. You will get duplicates of all signals. If
>> you have marginal coupling between phases you might see different results
>at
>> different times. If the Leviton can't "hear" the other transceiver, there
>> will be collisions.
>
>I suspect this is what's going on with the ESM1 showing a definite second
>signal at a lower voltage after it reports a good signal and then a strong
>noise block.  This is what I'd like to be able to "see" in some sort of
>detailed display.
>
>> Your ESM1 tests sound like collisions.
>>
>> I think the Monterey is vastly overpriced. It falsely reports every 1110
>> sequence not followed by a valid X-10 sequence as a "bad start code" when
>> they are usually the results of collisions between signals offset by 1/2
>> cycle. The TesterLinc is cheaper. I think Bruce Robin posted comparisons
>of
>> all of the available testers.
>
>I've read through comments by you and others about the Monterey and decided
>to pass on it.  While it stores captured PLC data, there's NO WAY to output
>it to a PC for analysis.  I ordered the LynX-TOOLS Power Line Analyzer.
>
>http://www.marrickltd.com/lynx_tools.htm
>
>We'll soon see what it says about the Decora's dawdling.  Interestingly
>enough, the ESM1's strength LEDs seem to follow the Decora's status light
>blinks by about 1/2 a second.  I'm determined to figure out why the ESM1
>shows 1.4 volts or the first series of blinks and only .4 volts for the
>second "good" signal.
>
>> This is a good choice for a "scope"...
>>
>>      http://www.usb-instruments.com/documents/small_stingray.pdf
>>
>> You should also get ACT's Scope-Test2 if you want to look at X-10 PLC
>> signals.
>
>I got the strong sense that were a traditional "scope" to appear, I would
>find myself in the doghouse with SWMBO.  The Stingray looks awfully sweet
>and if the Lynx doesn't do what I hope it will do, I'll seriously consider
>it.  I'm really looking forward to seeing what's really on the line, not
>just whether the signal's strong or not.
>
>Thanks again for your comments, Dave