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

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

Dave Houston wrote:

> The only error checking is the Manchester encoding wherein each 1 bit is
10
> on the powerline and each 0 bit is 01 on the powerline. If you analyze it,
> after the start code (1110) there's no way you can have a "legal" run of
> more than 11 or 00 within the code. That's fairly robust. The probability
> that a ~120kHz "noise" source will create such a pattern out of whole
cloth
> is nil.

I agree that it's unlikely a valid code would come from random noise burst.
I suspect that in cases where oddball codes appear to come from nowhere
people are actually seeing interactions between various modules. I have a
couple of power strips that make the ESM1 meter light up ever so faintly
when I plug them into or unplug them from a nearby power outlet.  It's one
of the things I hope LynxTools will help me analyze.  I also note that the
LM14A module makes the ESM1 show a strong signal when I first plug it into
the wall.

This makes me wonder if the weirdness people see isn't related to small
powerline interruptions that often occur late at night when the power
companies do maintenance.  If units that transmit upon activation all fire
together there could be an awful lot of powerline traffic generated from a
very short interruption.  I'm assuming I can simulate this with a quick
flick of the main breaker switch.  In any event, I'm trying to figure out an
"experiment design" that can replicate the oddball behavior consistently.

As you said in an early message, though, it may be very difficult to
determine which unit in a collison sent which bit other than by amplitude,
which is unreliable.  From what I saw at your site, a collision between a
CM11A and a TM751 might be distinguishable because the bit "signature" of
each unit is different.  The CM11A shows a distinct "fall off" - I'm not
sure the Lynx can detect that although I suspect an oscilloscope should. I'm
hoping that the Lynx will read out signal strength precisely enough to "get
a fix" on the source at the bit level.   The more I read, the more I wish I
had purchased the scope and interface you recommended.  If the Lynx doesn't
lead to answers, I may well yet purchase the scope.

> I don't think there is a requirement that a 3 cycle silence precede a
start
> code. The second copy of the code follows without such a gap.

Yes, sorry.  I see that now.  I was confused by the line from the X-10 site
says: "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."   I confess that I didn't clearly understand the implication of
the Manchester coding until you explained it in this very message, at least
in terms of how unique it would make the '1110' pattern of the start code.
Thanks for revealing that particular mystery!  I'm still a little hazy about
the "Bad Start Codes" that the Monterey analyzer reports.  Does that mean
they detected a valid '1110' sequence but that the data that follows is NOT
legitimate X-10 data?

> The likelihood of RF collisions that create valid codes is very, very,
very
> low. The RF codes also incorporate error checking. If two motion sensors
see
> the same motion, the transceiver will likely see a corrupted RF code and
> will ignore it. The transceiver receives the RF, decodes it and then (if
> it's OK) sends it to the powerline. There is no one-to-one correspondence
> between the RF code bits and the PLC bits. Some transceivers will relay
> certain commands that others do not - All Units On, All Lights On, All
> Lights Off are not universal.
>
> However, if you have multiple transceivers and multiple motion detectors
you
> might see some really complex behavior where one transceiver "hears" from
> one motion sensor and another transceiver "hears" from another a few ms
> later. That could cause PLC collisions. It all depends on the strength of
> the RF signals (as seen at the transceivers) and the timing between when
the
> motion is detected by the sensors. The AGC/ATC in the RF receiver circuits
> will pick out a stronger signal that overlays a weaker signal. The RF code
> is about 105ms long. Once a valid code is being sent to the powerline, a
> transceiver is deaf to RF until the PLC cycle completes but a stronger RF
> code can override a weaker one if it starts before the first RF code
> competes.

I really think the behavior above describes the process that creates the
unusual junk people see in their Activehome logs.  I'm pretty sure I can
recreate the situation by going into my box of Hawkeyes and putting some old
RR501's, the Decora HCPRF, my CM11A and a few TW523's on-line responding to
a dozen or PIRs.

I remember the day I was determined to put all the gear I had inherited to
use.  I put a number of lights on modules geared to respond to Hawkeyes so
that anyone walking around at night wouldn't have to fumble for
lightswitches.  Things worked fairly well if only one person was moving
about.  As soon as two people were triggering different PIR's at the same
time, the fun began.  A person walking from the kitchen toward the LR and a
person walking from the bedroom area to the LR at the same time could and
would turn the porch lights on.  Those lights were on an entirely different
housecode than the rest of the house.

> It's a shame that the Power Line Communication Bibliography disappeared.
It
> had links to some excellent white papers. I think all were stored on the
> same server so they probably decided to free up some space. I wish I had
> saved copies of a few key papers.

I've found a number of the originals, but it's very slowly going.  It's too
bad.  The bibliography I got from Wayback looked very interesting.

--
Bobby G.

> "Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:
>
> >"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
> >
> >> Reading the docs, are we? Geesh - no wonder things are so confused. ;)
> >
> >I had to go through a bit of a search to get them, too.  I lost the
little
> >paper insert and then realized that the house and unit code are set via
the
> >programming button.  I didn't remember how to do that. (old age, I
guess).
> >Leviton never replied to support emails but I finally found the PDF
imbedded
> >in one of their catalogs (had to DL 60MB by modem to do it!).  The funny
> >part is that I had finally found a use for HCPRF, but that was based on
the
> >mistaken assumption that it was a old-fashioned relay module like the
TM751
> >and RR501 and not a solid state relay for incandescent loads.  I was
going
> >to use it to control some fluorescent lights!  :-(  No such luck!   The
one
> >thing the module has going for it, as opposed to the TM751 is that it's
> >silent.  My MIL finds the TM751's relay clacking objectionable.
> >
> >> 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.
> >
> >Too bad.  I can afford to experiment on mine and might have taken a whack
at
> >modifying it just out of curiosity.  It's definitely not happy within my
> >current setup.
> >
> >> What unit codes are you seeing the strange behavior on?
> >
> >On a number of different codes.  B13 is the most popular inadvertent turn
on
> >(and off) but others do it as well.  I should add that these units are
> >controlled by the infamous Hawkeye PIRs.  As I wrote that, I realize I
may
> >have blown a couple of 100 bucks on the Lynx.  The collisions may be
> >occurring in the RF portion of the "control sequence."  :-(   I used to
keep
> >the CM11A active, just logging the weird signals but I stopped using it
when
> >it started showing signs of overheating.
> >
> >> www.mbx-usa.com/multiples.htm gives a very brief summary of what you'll
> >see
> >> with multiple transceivers.
> >
> >Yes, I've been spending a lot of time there, sifting through the diagrams
> >and data.
> >
> >Am I right in assuming that there's no error checking like a CRC check of
> >the *complete* X-10 signal?  I see it as a series of 120KHz tones
> >synchronized to the zero crossing.  When a receiver sees 3 or more
tone-free
> >AC cycles it is then "primed" to look for a "start code" of  "1110"
which,
> >for a standard X-10 transmitter, is a series of 9 pulses, total.  Six of
> >those pulses are ignored, as they are for split phase systems zero
> >crossings.  The Powerlinc appears to differ in that it only sends pulses
on
> >one phase, so the scope trace looks a lot like the actual binary string
> >transmitted.
> >
> >My understanding is that whatever error checking occurs, it's in
> >representing a 4 bit binary number like 1001 in 8 bits using a bit's
> >complement to guard against errors.  So 1001 would become 10010110.  The
> >only place this does NOT occur is in the start code, which is just 1110
that
> >follows at least three signal-free AC cycles.
> >
> >FWIW, I can't seem to reach the Power Line Communication Bibliography
> >referenced on http://www.mbx-usa.com/x10-sig.htm
> >I don't know whether it's me or they've disappeared.  I searched the
Wayback
> >machine for it:
> >
>
>http://web.archive.org/web/20040606020312/http://info.iet.unipi.it/~filippo
/
> >documenti/powerlines/PowerLineCom/FrameRIF.html
> >
> >otherwise known as http://tinyurl.com/8ghye
> >
> >and I can retrieve the bibliography list, but the URLs they refer to are
> >gone, too.  I've tried to pull them one at a time out of the Wayback and
> >then tried using Google to see if the site's simply been relocated but I
> >can't seem to find a new version of the site.  :-(
>