[no subject]

Multiple transceivers with multiple motion sensors will likely lead to
cacophony. I still think the approach I took with the BX24-AHT was the best
solution. One central RF receiver with a good antenna gives adequate range.
With a CM11A as its X10 interface, it avoided collisions because the CM11A
stops sending PLC whenever it sees a 1 when it sent a 0. It did not
retransmit (probability is very high that any collisions are with a second
transceiver) so it can coexist with one other transceiver. Initially, I
planned to support two CM11As (one on each phase) but it's software UART
wasn't capable of that. I still hope to design a brain transplant for the
CM15A that will incorporate most of the BX24-AHT features but my health now
makes it tougher to handle lengthy projects like this.

The Powerline Communications papers were mostly pitched towards BPL but
several did give excellent descriptions of the types of noise encountered.
It was also a little more European oriented and their electrical grid is
quite different with 100s of residences sharing a stepdown transformer. You
can find some of the same data from companies like Intellon who are building
the BPL chipsets. There are also several academic theses that cover the same
ground.

I don't recall whether the LynX-10 PLC can measure signal strength. Even if
it does, it may give an average or peak reading so it may not be useful for
seeing the CM11A signal degradation. A scope is the easiest way to detect
that.

I plan to have a raw diagnostic mode in my rebraining of the CM15A but it
will not be able to measure amplitude or PLC frequency just output all of
the 1 and 0 half-bits.

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:

>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.