Preventing Random X-10 Code interference...

I just got my Monterey analyzer today and the first thing I did was test a

15A AF120 ACT against a 5A Leviton 6288 filter.

The sending source was a BSR Maxi controller and it read at 4+ volts unfiltered when plugged into an outlet on the same power strip as the analyzer. When I plugged the maxicontroller into the 15 amp ACT filter, I could still see a signal when sent by the BSR. The signal was weak - 30mv - but it was there. When I plugged the Maxi controller into the 5 amp Leviton, there was no evidence of any X-10 signal.

So my conclusion is that the larger filters do not filter as well as the smaller, 5A ones. Since your LCD's only draw 1A, why not go with the smaller, not larger filter? The Leviton 6288's are under $20 at Worthington and other vendors. I have some CTX LCD's whose switching power supplies disturb the X-10 signal really badly and the Leviton's (and their cousins in the X-10 pro line whose model # escapes me) have fixed those as well as a number of other problems. It was helpful to have a wattmeter (the Kill-o-watt) to determine the maximum draw of a device to be protected. The ACTs have a nice, built-in circuit breaker - but they are huge, too.

I got the ACTs for a space heater that uses IR to control it that causes X-10 voltage drop and to filter an HP5 laserjet. They've worked pretty well to control X-10 sucker problems but I don't believe they behave well with noise problems. I have a set of felonious CF bulbs that generate enough noise for even my ELK meter to see. As soon as I figure out how to use the noise analysis mode of the meter, I can evaluate both filters for noise rejection from a device like a compact fluorescent.

-- Bobby G.

What brand switches and modules are you using? Do you have any *Linc two-way devices?

The filters are designed for 120kHz so they should be most efficient at that frequency. All should be better at controlling signal suckers since, in this case, they need to block 120kHz from reaching the signal sucker. They may be less efficient at blocking noise since the noise may not be 120kHz but may still cause trouble for X-10 receivers.

In this particular case, the monitors may be putting noise on the line directly (from their power supplies) or indirectly via RFI.

Most, if not all, X-10 _brand_ PLC receivers (i.e. switches, lamp and appliance modules) count the number of cycles in the "acceptance window" between ZC+250µS and ZC+900µS. Noise that is greater than ~80kHz can cause a receiver to think it's seeing X-10 carrier while noise lower than ~80kHz might mask the carrier. So far, nobody has determined the upper/lower frequency/amplitude limits although Dan Lanciani has documented a case where a weak +200kHz was jamming X-10 signals.

The problem gets more complicated now that other manufacturers are making devices that use the X-10 PLC protocol but may or may not use cycle counting to determine carrier presence/absence. There are schematics available for many X-10 made devices but not for those made by SmartHome, Leviton, ACT and others.

Some X-10 made devices are vulnerable to spikes and brownouts which can result in unwanted on/off events but will not cause valid X-10 PLC signals that will be sensed/recorded by PLC interfaces.

BTW, most X-10 made PLC interfaces like the TW523, CM11A, CM15A, etc. do not use cycle counting but sample the demodulated data envelope. They might not react exactly the same as those that count cycles.

When there are valid X-10 PLC signals on the powerline, the source must be something that's capable of sending X-10 PLC signals - they are not going to be created out of whole cloth by a noise source. A likely source is the SmartHome two-way switches and modules but your guess is as good as mine as to the exact mechanism whereby "noise" triggers them to transmit.

Receiver sensitivity is another factor. Older X-10 devices needed ~100mVpp but newer devices and those made by others may respond to much lower signal (or noise) levels.

The Monterey has a noise analysis mode. It has a two line display of noise at the .5ms point and then an average (I assume) from the range of .2ms to ..9ms. It reads in both millivolts and volts, since a press on a nearby Maxicontroller button will show up on both lines as "4.+" since, as you know, it has a top-end limit of 4 volts. I've moved it around the house and see general "background" levels of 5-10 mV in both ranges. I have not yet tested the evil CF - I wanted to get a feel for what might be generating noise. While it varies around the house, I suspect without filters I recently installed I would see a lot of noise. Something got the Elk up to one segment before I began applying filters. I'm so far behind on my honeydew list I'm due retribution so I have to "time slice" my hobbywork. :-( So that and a few other experiments have to wait their turn.

I thought about asking the OP if he had any X-10 gear near any of the new equipment.

Ah ha! THAT'S what the .2mS to .9mS is looking at. I assume that if there a voltage above a certain range in that window, it means the X-10 signal is being "stepped on." Is that correct? What are they looking at the .5mV range? It that where the 120kHz X-10 burst is optimally supposed to be found?

The documentation says they are looking for noise greater than 110kHz. Is it reasonable to conclude that since their lower range is 10kHz lower than the target value that their upper range might be 10kHz over, namely 130kHz? Or would it be just as likely that they are looking well above 120kHz?

Those obscurationist bastards! :-)

Interestingly enough, and I am not sure why this happens, but when I plug and unplug certain equipment, particularly things identified as signal suckers, the Monterey often indicates BSC. There's clearly something the Monterey "sees" as these items are plugged and unplugged. I have not tried this same experiment with the Elk, but as soon as I remember where I left it, I'm going to try that.

Every human endeavor has its "UFO"s - but I think a lot of phantom X-10 activity is related to short powerline blips. It's a guess as to which stock X-10 modules I have that are going to snap on after a few flicks from a thunderstorm, but it's a guarantee that some will. I'd guess it's probably "current sensing" at work.

I'll finally be able to measure that threshold when I find branches that read about .05v of X-10 signal. I've got some AGC equipment that's supposedly more sensitive than stock X-10 and now I can see for myself!

I've seen some other interesting readings, BTW. Sometimes the bathroom light (on a Hawkeye) command reads in lower case, which the documentation says "one good start code and one good message block (of the two identical ones) has been received ." Does that mean the code was mangled but not badly enough to prohibit firing? Would this explain why people report a slight delay in when the bathroom light fires?

Thanks again for the detailed explanation!

-- Bobby G.

Hi guys! I just love these discussions.. they start off so easy to understand an then go right over my head.

Dave, I do have one two-way device, but I shut down that circuit breaker, and the problem still continued.

One thing I just noticed was that my old 17" Viewsonic CRT seems to be wreaking havoc with the system, too. It's as if it somehow multiplies the problem with the LCD monitors.

Now, I put AF120's on everything.

This almost solved the problem. Now I am getting stray codes about every 30 minutes (not every 2 minutes like before!) but you guys won't believe the pattern I am seeing. You have to see my X10 Code Usage Grid to believe it!

Maybe you can lead me in the right direction, because I noticed a VERY interesting pattern.

When I look at X-10 Activehome's Historical Code Usage, as you may have seen, it lights up red for each stray code it receives.

Instead of being red almost ALL over, as it was before I put AF120s everywhere, now, I am getting ONLY stray codes that are on numbers one or three!!

In red, I see A1, A3, B1, B3, C1, C3, D1, D3, F1, G1, G3, G1, J1, K1, K3 etc.

There were two others, actually, K6 and I8, but that's it.

It's remarkable!

Aside from those two stray codes, over the entire day, ONLY 1's and 3's have been broadcast!!

What do you think about that?

Is that indicative of something?

It can't be a coincidence..

At least I have an idea for a workaround...!

On my three housecodes, M,N,O, I will leave 1 and 3 EMPTY!

Silly workaround... I'd love to solve this!

Any ideas?

And thanks for the advice about the 6288 5A filters being more effective than these 15A ones. Like my girlfriends always say, I just thought bigger was better......!

These 1 and 3 codes are strange! Any ideas? Have you seen that before?

Thanks,

Mike

| BTW, most X-10 made PLC interfaces like the TW523, CM11A, CM15A, etc. do not | use cycle counting but sample the demodulated data envelope.

The CM11A uses cycle counting. I've never found any documentation on the ASIC in the TW523, but given that the input conditioning circuit is very similar to those found in most of the other pre-PIC X10 receivers I suspect that the TW523 uses cycle counting as well.

Dan Lanciani ddl@danlan.*com

X-10 devices vary in sensitivity. Some need 100mV, others respond to less.

0.5mV is probably much lower than any can distinguish. From memory (which may be foggy) I think most of the studies (from that now gone web site) saw 20-50mV backgound noise.

There's no way to guess what range they look at. X-10 says 48 cycles within the "acceptance window" make a 1. That a very low level ~200kHz noise was blocking a receiver is evidence that the receiver probably does not try to calculate the frequency of any perceived signal so any frequency that will result in 48 or more counts within the 0.65 window might be seen as a 1.

74kHz and higher will give 48 or more counts but even lower frequencies might mask the presence of 120kHz.

It may mean that there was a powerline collision but one transmitter backed off allowing the second copy of the other to go through. Most X-10 receivers will respond to a single copy of the code.

I was assuming the CM11A was like the CM15A - I've never seen a full schematic.

As for the TW523, I was thinking more of its output than what it might do internally but using cycle counting would explain why it gives a time delayed output.

Sorry for the confusion but I try to generate in depth discussions on topics like this in order to build a record that others can search when they encounter the same thing.

You can help run this down by answering the specific questions.

1. Do you have any SmartHome *Linc two-way switches or modules?

1. Are you using ActiveHome (CM11A) or ActiveHomePro (CM15A)?

The fact that you see repeating patterns is evidence that the codes are not random. That means they are probably coming from some X-10 transmitter although the transmitter(s) may themselves be reacting to random noise.

Filters will not be effective aga>Hi guys!

Thanks Dave!

I do enjoy reading the in-depth discussions, even if 85% of them are over my head!

To answer your questions, yes, I do have a 2-way module, but it's not causing the problem, since I did turn off that breaker during my tests.

And yes, I do have a CM15A. That was my first thought right off the bat. Needless to say, when I unplugged the CM15A, I still had the problems with the random codes.

The 1/3 pattern is quite bizarre.

What I just noticed is that these 1 and 3's do NOT show up in my Active Home's Activity Monitor. The only occasional stray code I see is "STATUS REQUEST" (whatever that is).

The 1 and 3's lighting up are only within the Historical Usage Grid.

That leads me to believe that perhaps my stray codes have stopped, and this is now exclusively a software issue...

Weird!

They are often over my head, too. ;)

Do you have a Leviton phase coupler?

STATUS REQUEST is usually sent by software as opposed to being generated automatically by a module or interface. Two-way modules respond to it with the specific response depending on the capabilities (and manufacturer) of the two-way module.

It might also be sent by a misbehaving interface such as a CM11A with a dangling serial cable. "J STATUS REQUEST" is often seen in that scenario.

Could they have been coming from the two-way module?

I'm not really familiar with the ActiveHomePro (or ActiveHome) software as I always write my own. Can you clear the Historical Usage Grid? How about the Activity Monitor? These noise events are really confusing and difficult to sort out so its best to start with a clean slate and keep things as simple as possible until the cause is identified.

Do you have any macros stored in the CM15A?

Hi Dave,

Thanks again for your assistance.

Yes, I do have about four macros stored in the interface, but they don't seem to be affecting anything at all. When my monitor would spit out a code in which I store a macro, it would simply activate that macro.

On the evening that I did my most major test, I turned off about 75% of the breakers in my house(!), leaving only my office connected (since I was working).

I even unplugged all my tranceivers, too.

Lo and behold, when I saw dozens of stray codes, that's when I knew it was something in my office.

And yes, I am VERY familiar with J STATUS REQUESTS(!).

I very often clear the grid, which also clears the scrolling activity monitor at the same time.

That's how I troubleshoot.

I cleared my history at 3:24 this afternoon.

There have been 480 events since then in the scrolling history window (Some are shown on two lines). Most of these events are the Active Eyes, which track movement.

When I look at the grid, I now see the following in Red: E13, G1, H1, P3.

That's four stray codes in 8 hours. Heck, that's not bad. I was getting 10 stray codes a minute before.

Now, when I examine that list of 480 in the Activity monitor, I see the following gremlins:

3:30:51 RECEIVE ExtendedDataTransfer 3:30:53 RECEIVE H Dim 0% 3:31:51 RECEIVE E13

So, it looks to me like 3 of my 4 stray codes happened within one second, and the other one, a P3 is nowhere to be found on my scrolling activity monitor.

It's so odd.

I have entirely unplugged the noisy old monitor, but have left my two LGs plugged in all day.

I think I will clear the history. Unplug the LG's, too. And see what happens in the AM.

At least I have not walked by to see my kitchen lit up, my pool nice and bright, or my disco ball spinning.

Things are getting better..... (But still not good enough to risk hooking up a garage door or coffee maker to my system!)

We shall see!

MG

Just a quick follow up..

After resetting my history, I seee NO stray codes in the Activity Monitor for the past hour.

However, my grid is red in two places: B1, G3.

.....Those ones and threes...

Interestingly enough, when I hover over the red squares, the times of these phantom codes pop up.

They coincide with my Active Eye sending off a signal to turn on my office lights.

.....I have an idea...

In addition to my regular transceiver set for my office housecode (O)... my CM15A ALSO receives on this housecode.

I wonder if they are both causing some kind of collision.

I am going to ensure my CM15 doesn's receive any codes...

See you in the morning!

MG

Hi Dave,

Very interesting...

This morning I woke up to find everything clear in the Historical Grid, except for: A1, B1, C1, D1, C3, G3.

I didn't see anything in my Activity Monitor.

Upon some further investigation, I enabled the Activity Monitor to also display codes it received via RF (as opposed to the home wiring)

Lo and behold, I found:

Receive RF B Mute (two at the same time) Receive RF G Autofocus (two at the same time) Receive RF A Five (2 at the same time, and yes FIVE was spelled out!) Receive RF C Iris Down (two at the same time) Receive RF D Iris Down (two at the same time) Receive RF N CamGoPosition1

Isn't this interesting... So it looks like it's sensing phantom RF signals, and not signals over the home wiring.

That's reassuring!

Today I will leave my LG monitors turned on. Let's see if I get non-RF phantom codes.

At least we know my house lines are clear. This is good news.

Sorry that I forgot to answer your question before -- I have two couplers.

I made one myself which I stuck in my circuit breaker box. I just attached the recommended capacitor between two breakers.

And I also purchased that heavy-duty one with a booster that plugs into my dryer outlet.

That particular device was a lifesaver!

I was never able to control my front hallway/foyer lights when my outdoor fluorescents were on, nor was I able to control my kitchen lights (ever), and once I installed that unit, everything worked perfectly.

(As an aside, when I was doing those tests to isolate the noise, I forgot to turn back on my dryer's breaker the next morning. A third of my modules weren't working. I was so upset! I couldn't figure it out. Until my partner said, "The Light in dryer isn't working!!!!!!!!!" Aha! Solved it!)

So, at least at this point, my house wiring seems 100% clear with these monitors off. Now I'll leave them on.

Then we'll have to see what's up with these RF commands my CM15A is picking up.

Interestingly, I completely removed the antenna from the unit (remember my eggbeater woes!??), so I wonder if it's 'making up' signals, or if it's really picking up stray garage door openers, etc. etc.

Interestingly, from bedtime at 3:00 until wakup at 9:00, there were no phantom RF codes received.

Maybe there's something in the house that we are using that's causing it...

We shall see!

OK. Can we conclude that the filters solved any noise related problems and what remains is related to actual events triggered by motion sensors and multiple transceivers?

One other contributing factor may be the AHP software. It might be creating phantom events by being overly aggressive in trying to make sense of what it sees after a collision.

Both the RR501 and CM15A _should_ sense collisions, stop, wait for a pseudo-random number of clear powerline cycles, and retry. In this case one should sense a collision, allowing the other to complete it's transmission - then the one that paused will transmit. You should see multiple codes rather than garbled codes. I tested briefly with the CM15A & RR501 combo and saw no unusual behavior _BUT_ I was using a CM11A to report what was on the powerline and never looked at the AHP software.

Do you have a phase coupler?

"Michael G." wrote:

Hi Dave,

Yes, it would make sense that the coupler/booster would potentially fire off some extra signals.

I have now been gone from 10:15 to 1:45.

Once again, there were no stray codes coming off the house wiring,

But I do see a "B Mute" via RF, which arrived .3 of a second after the Active Eye in my office sent an RF command, and that's it.

By the way, my LG monitors were on.

My really noisy Viewsonic 17" (that spit out codes every 3 seconds) is still unplugged.

I wonder if the sheer fact that my CM15A, which is 15 feet from my office Active Eye is misreporting these RF codes because the antenna is cut off. Maybe it's just picking up small pieces of the transmission.

This is way over my head, but when I took a basic computer class, we learned binary, so I know 0001 is "1". I am not sure what "3" is. 0011 perhaps?

So I wonder if all these stray 1's and 3's are because it's just picking up the tail end of the Active Eye transmission.

Luckily, it's not rebroadcasting anything throughout the house, because I set it to not transceive any housecodes.

I'll see what happens throughout the day, and I'll see if more of these stray RF codes coincide with any other events...

The reason I asked about a coupler is to identify all of the devices that are capable of PLC transmission (e.g. the coupler/booster in the laundry room). One Leviton coupler has come to be "a usual suspect" in mystery events and powerline storms.

Can you tell what time the RF events were logged? This might be a case of X-10 trying to do a little too much, leading to misinterpretation of RF collisions which will occur if two or more motion sensors see the same motion at nearly the same instance in time. Earlier devices (e.g. RR501, MR26A) would ignore these unless they can discern a valid code (rare) but the CM15A may be trying to do more.

The prose descripti>Hi Dave,

No, it's not likely that the lack of an antenna is responsible although a weak signal is more likely to be misinterpreted than a strong one. I suspect this is more a matter of the CM15A still being a "work in progress".

It's quite a bit more complicated than you've surmised. On the powerline "1" becomes "10" and "0" becomes "01". And the RF codes do not directly correspond to the equivalent PLC codes.

TVs, monitors, plasma screens, etc. can radiate RF interference. This might directly affect a nearby RF receiver or it might be picked up by the household wiring and cause problems both for RF receivers (through reradiation) and for PLC devices. Filters cannot block radiated RF. It can also get to the powerline by conduction which is what a filter should block. But, the filters are probably rather narrowly tuned for 120kHz while the PLC devices may have wider bandwidth.

Can more than >Hi Dave,