Cause of some major X10 problems found

Just to set the record straight, Bill's a Lutron Radio RA user. They're "the higher priced spread" and would likely be immune to Chinese switch-mode power supplies. The RA system is radio based and is susceptible to - you guessed it! - RF interference. The protocol they use has far superior error detection to the RF used in X-10 and they also are very conservative when estimating the operating range of their transceivers. If you're mostly into ultra-reliable lighting control and you have big $, the RA way sounds like the way to go. So far RF interference hasn't been a problem for anyone outside of NYC, but the RF band is always getting more crowded, so when it reaches the relative age of X-10, it may be in much the same situation. I doubt how either protocol fares 30 years from now will be of interest to my cremated remains, unless eternal life is invented before then. (-:

-- Bobby G.

You have me confused with one of the real experts here. I have a wife that asks "why are you too damned lazy to turn off a light when you leave a room?" (-: I did have one heck of a crush on Katherine Ross from the first version of the film ever since I first saw her as Etta in "Butch Cassidy." She was still looking pretty good thirty years later in "Donnie Darko." Nicole K's not too hard on the eyes, either. But we digress.

-- Bobby G.

half-cycles)

Are we certain that Bruce's setup actually uses the TW523? I thought he was using the XTB-II in the TW523 emulation mode. I don't think it's relevant, though because I don't believe it's the culprit in any way. What does the TW523 report to the log when it only sees a single frame of the two in each X-10 command? That could have some bearing on whether a noise-created command is ever logged. Distance to the source of the signal could also effect that. Jeff can probably explain how the XTB-II reacts to orphaned single frame commands.

That doesn't prohibit a lamp module from reacting to something that wouldn't be "accepted" as a valid command by the TW523 or an emulator. A lot of how a device reacts to non-standard or corrupted X-10 signals, at least according to Jeff's explanation of how he rejects noise, would seem to depend on the smarts embedded in the firmware.

I would hesitate to say "no way" because that's what we're talking about here: Very unlikely, but still non-zero probabilities. Since Jeff has actually observed such beasts in the wild, I'd say we're closer now to "way" then we were to "no way" before he made his observations. It's only until he gets his hands on Bruce's Bad Boy PS that I would feel comfortable in concluding there's "no way" such a supply could not generate a noise that an X-10 switch would react to as good code. I'm even more certain that such a flakey PS could seriously corrupt any valid X-10 codes transmitted while it's putting noise on the line.

When doing PC tech support work for several hundred very technically inclined users I would often find myself saying "There's no way for what you are describing to happen" when responding to the trouble call only to go to their offices and find out that their PC was indeed displaying an upside image or whatever other bizarre condition they were reporting. That's why I am reluctant to discount the numerous reports we've seen over the years of phantom activations.

You know that one case does not an ironclad proof make, particularly when you're saying that random code creation is impossible. However, the converse is not true. All it takes to disprove the hypothesis that random noise can't create a valid code is one exception. (-: I'm inclined to believe that Jeff's already proved that noisemakers can create valid X-10 codes, but it would be nice to have it in irrefutable black and white screen shots. The case you describe above could indeed fall under the "Bloom Theory" of spike induced activations. But that doesn't mean all cases are so caused.

Actually, I believe that the laws of probability are being very accurately represented by what we're seeing. The odds of creating lots of simply random noise are quite high. The odds of creating noise that the Monterey reports as BSC's - the right start pattern followed by garbage - are much lower. The odds of creating a valid code out of random bits are very, very much lower. But I don't believe they equal zero and that's based on the reports we see of lone activations in the middle of the night. Based on the X-10 propagation speed, and the length of a day, the occurrence rate might be one in 10,000 or even 100,000. I feel that sort of "once a day" probablity lines up better with the random code generation theory than the Bloom theory, which should have lights turning on faster than one could turn them off.

BTW, I don't agree that these commands are never logged because I've found more than a few "spirit codes" that have shown up in user's logs. Oddly enough, they're the codes that you postulated (M and J status requests) could be created at random by the nature of the Manchester bit patterns. I'll try to search Google and post a few of the messages where people reported seeing random codes appear in the Activehome or other controller logs.

Maybe the light switches that are misbehaving don't know the theory of one's complements. (-: It will be interesting to see what happens when Bruce sends his PS out to you guys for analysis.

-- Bobby G.

Boy, this thread certainly generated a lot more than I thought it would! Here's a review of what I have: A wife (I'm keeping her!); her errant phone charger; a JDS TimeCommander+ with a TW523 plugged into an XTB (NOT II); and some old X-10 Pro Leviton switches with soft start.

As for the comment on scrapping X10, agreed. We will be moving to a new house here in Houston in 8 months that will be Insteon equipped. As for the charger vs. Insteon, my wife reports that she uses the same charger all the time at our other house that is Insteon equipped and I have no problems there.

The lights that were coming on randomly, did so around 4-6am. However, all OFF transmissions from a Leviton wall keypad to lights in the area with the charger were also blocked by the charger.

If anyone wants to run tests on the charger let me know.

Yes, Bruce is using a TW523. The TW523 doesn't log anything but merely outputs the codes on a delayed basis and with gaps when there are contiguous codes. The controller has to do the logging. The controller can only work with what the TW523 gives it.

Jeff said he observed one such beast. He did not indicate the nature of the beast (i.e. what code).

If you mean once every 100,000 years, I agree.

The fact that grounding the pin fixed the problem rules out that the switch was reacting to some aberrant PLC pattern that would not be reported by an X-10 interface. Nor is there any reason to believe that X-10 would have designed switches and modules that responded to patterns that would not be reported by interfaces designed by the same people.

Analyze away but count me out - I haven't been on a snipe hunt in over 60 years.

My intent was to have the XTB-II respond similar to a TW523. Like the TW523, it normally receives the first half of a command, and then returns that in sync with the second half after being error checked. It does not return the command if there is a mismatch in the number of "1" and "0" bits. The XTB-IIR goes further and verifies that each bit pair is complimentary as they are received.

Since the XTB-II does not need a gap to separate commands, it can accept either half of a command as long as it contains a valid start pattern and the correct number of complimentary bits before the next gap or start pattern. The goal is to pass any valid X10 command to the automation controller.

Jeff

That is true. I only captured it once with an early version of the AGC loop. Since my logic analyzer dates from before the PC, it has no means to output the waveform for storage. I can only analyze the bits looking at the traces on the screen. That is not something I do unless the data pattern is very important.

Jeff

| It may be near zero, but I have documented on my logic analyzer that it can | happen. You may remember an earlier post regarding beating compact | fluorescent lights producing peaks and valleys similar to a X10 | transmission. I found that about 2 minutes after I switch on my CFL "noise | generator" the beat frequency between a couple of the bulbs gets low enough | that the peaks and valleys occur on alternate half cycles. If the receiving | module just happens to catch enough noise 3 times in a row to recognize a | start pattern, the remainder of the message with alternating 1-0's does get | through as a valid command. Even with the enhanced error detection | requiring complimentary 1-0's, I did capture one squeaking through.

Also, traditional X10 (brand) modules fail to check (IIRC) one slot for correct complementary coding and third-party products may fail to check even more (original Switchlincs missed two). So there is a little wiggle room.

Dan Lanciani snipped-for-privacy@danlan.com

I had similar problems in my last X-10 home and never found the culprit. Congratulations

I may have missed it, but I don't see how the "Bloom Theory" can account for the repeated posts we've seen about stray codes in the middle of the night or even explain Bruce's situation. What mechanism would cause a relative stable source of noise like the PS to flare up at 4AM, as Bruce reported his "turn ons" occurred, after apparently being unaffected for many hours before that? The Bloom theory seems to imply that soon after being exposed to noise, the susceptible switches would activate. But that's not what we see. Previous phantom activation reports tend to match Bruce's, often reporting that sometime, late at night, random lights come on.

The word "random" was in Bruce's post and a number of others. That, in my mind, implies that various switches activate at odd hours in the middle of the night. I can't help but believe that reflects the noise source finally spitting out a code that a switch will react to after spitting out 10s or

100s of thousands of noise bits. It's the M and J status codes that are reported most often and, as you point out, those are constructed on the binary level to be the most likely created by noise bits. Add to that Dan Lanciani's comment about some switches not parsing the ones' complement bits in the right way and those stray activations look more and more like a reaction to a single code and not some noise spike.

The Bloom model seems to fail when it comes to explaining why it would take a spike susceptible module 4 or 8 hours to finally succumb to a spike and turn on. The "Green" model of random noise finally creating a signal a switch responds to after 100,000 attempts fits much better with the observed data. It's also bolstered by Jeff's observation of two CFL's interacting in such a way that an X-10 switch could be activated by the bit pattern they created.

As I said before, the Bloom model can explain some abhorrent aberrant switch behavior like your case, but it fails quite fully to explain why switches would "wait" four or more hours to finally give into the noise that the bad power supply has been emanating for all that time. That "magic spike" scenario sounds even stranger than the "magic created code" one because it so clearly fails to account for the long delays.

The "Green" theory, on the other hand, explains it nicely because good codes emanating from a noisy power supply happen very rarely, as one might expect. Not so rare that they never happen, but rare enough that it takes quite some time for the noisy PS to create them.

There may be no reason to believe it, but I believe Dan L's discovered that existing switches don't execute the one's complement function for every slot. I believe that's your main objection to the possible existence of these generated codes. If so, a failure in the error correction detection HW could allow bad bits to trigger the device anyway.

I can understand why. If you did happen to find the snipe, you'd have to eat another avian dish, namely crow. (-: No one likes having to do that. I just watched a program about the man who had captured all the data required to prove the existence of other planets, but failed to interpret it correctly before another researcher, looking at the data the first had posted, was able to make sense of it and prove the existence of other solar systems with planetary bodies. Needless to say, he was not a happy camper.

Hopefully Jeff will take up the hunt. It would be another feather in his cap to demonstrate that his new XTB-IIR could take such devices in stride without missing a beat. He also has the smarts and the analytical hardware to capture any code the power supply might create. Besides, it would be nice to prove or disprove the "created code" issue for once and for all, and in practice, where it counts, rather in theory. The fact that he's seen such created codes already when not really looking for them leads to me to believe that he'll have little problem finding them when that's what he's searching for specifically.

If Jeff declines, and Bruce agrees, I'll take up the hunt. If I put the PS behind a filter with a Monterey and a CM11A so both can log the output AND add a video camera to record all of the Monterey's readings, I think we'll see that devices like PS's can indeed create codes that X-10 devices respond to. The only potential problem I see is that the PS may have been interacting with another device in Bruce's house much the same way that Jeff described the two CFL's interacting to create X-10 like signals and its behavior will be different on my test bench as a result. Even if that's the case, I have some very noisy CFL's that might be used to "beat" against the noise signal from the power supply.

-- Bobby G.

That's funny. I was about to say the same thing. (-:

No reports from who about which WS467s where? Just on general principles I would be reluctant to make a claim of "no reports" about *anything* because all it takes is one case to shoot it down. Maybe you'd like to rephrase that so I know precisely what you're referring to.

And if you go back and re-read what I said, you'll find I don't dispute the units' susceptibility to noise, exactly as you describe. What I do dispute is how this particular flaw explains why lights would sit for hours without reacting to the constant outpouring of noise from the bad power supply and then suddenly, at 4AM, decide "that spike looks particularly juicy, I think I'll respond to it."

The Bloom theory certainly can explain your case, but that model fails when applied to the larger universe of inadvertent activations. It doesn't explain Bruce's situation at all. The lights sat off for hours (apparently) and then activated in the middle of the night.

IIRC, whenever you turned on your culprit fixture, the lamp module fired up. Bruce's situation appears to have no fluorescent lamp in the other room that turns on and spikes the WS467 into life. Many other reports I recall were absent an event like the one that precipitated your inadvertent "turn on." They occurred, apparently, late at night long after activity in the house had ceased. That seems to be the mode of failure in Bruce's house as well.

No one is disputing that. As I've said before, the fact that the units respond to spikes (or power blips) in no way prevents them from responding to OTHER forms of uncommanded activation as well. My contention is that the spike from a noisy PS theory fails badly when examined against cases like Bruce's. Why would a susceptible switch sit in the OFF state for hours when exposed to a noise generator?

In your case, the errant lamp module appears to fire when you first activate the noise generating fixture. In these other cases the noise generation is apparently constant and yet somehow the constant noise (I assume it's constant) fails to fire the lights immediately, as the Bloom model and your bad light suggest it should. The Bloom model may explain a lot of inadvertent activations, but it doesn't work for all of them. That seems to be a fairly reasonable conclusion to me. I don't know why it's giving you so much heartache.

You don't want to believe that a "magic code" could be created from 100's of thousands of noise bits bombarding the powerline, yet you appear to be positing some sort of "magic spike" that reaches crescendo hours and hours after the noise source comes on line. It just doesn't fit the observed facts. Not to these old eyes. Maybe you can explain why Miss Switch can sit for hours, resisting Spike's relentless advances ("No, no, a thousand times no!") and then suddenly cave in to them hours later? That's the part that gives *me* heartache. (-:

-- Bobby G.

RG> > Also, the PS's noise could have collided with a legitimate command the

JV> This does happen, and is not rare. Here we have four Ocelot macros that

Corrupted commands are another reason why I like the Monterey (sorry for the brief excursion but your comment brought it to mind and I'm too lazy to start another message!) Sometimes, in the midst of BSC's streams I'll see a lower case letter of a housecode I don't use. I assume that's a collision creating a valid *single* frame of X-10 data. While I believe it would take a very long time indeed for random noise to generate a double data frame with a perfect second copy, I think the creation of the single frame has a far greater probability of occurrence.

Am I correct in assuming these Frankensteinian combined codes work because the X-10 error protocol is a single bit one and does not provide any method of knowing if all the transmitted characters came from the same source or arrived without corruption or substitution? That might have been done using the second copy of the frame against the first, but it seems the 2nd frame was there mostly for redundancy.

I wish this had all come up when I still had the Marrick Lynx and could see the raw data bits and what the Lynx interpreted them to be. Since it showed data at the one's complement level, you could see what the receiver saw without any further processing (unless you asked it to do that).

This behavior, IMHO, explains at least a few of the reports of strange housecodes and commands showing up in the file. I think Dave suggested that some created commands are more likely than others. I wonder if I could deliberately set up two minicontrollers on different housecodes, lock them in to transmit forever and then process the resulting huge log from the CM11A.EXE program to extract a distribution of the randomly created "fused" commands. After a while, it should tell us something about which valid commands are more likely to be synthesized via collisions. Especially if I stepped through each house code and unit code for an hour each for a few days. God, I wish I had ten grad students!

I'm not sure how useful such information would be to anyone, or even how germane it is to the noise issue, but it would be nice to know if something like J Status request really did appear far more often than any other code. Particularly in helping people who post questions about seeing command "X" in their logs, when they're sure they didn't send it.

Something tells me yours might be the better of the two designs considering in all their 20+ years of designing X-10 gear, they never thought of the XTB. (-:

-- Bobby G.

You're distorting things and making claims that are not supported by fact.

1. Jeff has not "seen such created codes already when not really looking for them". He has seen _one_ instance where the noise resulted in a

1010101010101... sequence and has postulated that if a receiver saw a transition from 111111111111... to 1010101010... it would act on it. Such a code would represent "M-13" and would turn nothing on.

1. I did not "point out, those are constructed on the binary level to be the most likely created by noise bits." I said that the _single_ occurence reported by Jeff could only be "M-13" or "J-Status Request". After further review, it can only be "M-13". What's most likely to result from a constant noise source is 111111111111111111111111111111.... Whether a Monterey will report that as BSC I don't know as I never wasted 0+ on one but I suspect it will.

2. Most of the reports of logged streams of "M-13" and/or "J-Status Request" involve a CM11A and/or Leviton repeater. Disabling the CM11A and/or the repeater stops the storm.

1. Dan's suggestion that "some" switches don't check one slot for complementarity is insufficient as more slots need to evade the censor to create an "ON". If there were several such slots we would have had many reports of switches that had multiple mysterious maladies.

2. If my memory is reliable, (I've been taking statins for a few years which seem to have adversely affected my memory.) Dan Wright reported a repeated, specific logged code of unknown origin which is different from this. I'm afraid that, on this issue, I'm not a "creationist" but believe in "intelligent design". Random noise is not going to create repeated, valid codes - that requires some type of (at least semi-)intelligent X-10 transmitter.

One caveat, however. I've forgotten who it was but someone sent all possible combinations of X-10 RF codes and found a few that were not included in the CM17A documentation from X-10. I later learned of yet another but it turned out to only work with certain transceivers. I have no idea whether those were intended or merely due to programmer error. It may well be that "some" PLC receivers will respond to non-documented patterns but if this were common I think we would have heard about them long ago. Also, they probably would act the same at 4PM as they would at 4AM.

Sure, I would be happy to test it as a noise source. If you don't have my address, it's on the XTB ordering page. I'll send it back after I test it.

Jeff

The Marrick device used a TW523 and thus saw only the valid codes that the TW523 could report. It would never see a code that contained 111 (except for the startcode) or 000 sequences as the TW523 would not report them.

I've never tried crow but did acquire a taste for pressed duck.

Since I only saw it visually on the logic analyzer, I cannot be certain there wasn't a "1-1" imbedded somewhere in the string. That would cause it to be decoded differently.

I do have a Wavetek that can do AM, and will see if I can get something repeatable. But, I'll have to go back to an early version of the AGC to allow that signal to make it to the decoder.

If you watch the beating CFL's you would see how it would be possible for different sequences of 1's and 0's to be created randomly. Before I changed the AGC to increase the threshold when receiving unmatched complimentary pairs, there was a constant stream of random ones when the beating would peak over the threshold. Once and a while that could hit a valid X10 code. I captured one on the logic analyzer. I'll bet that if I go back to the earlier AGC, I could capture more.

Jeff

OK, I'll send it to you as soon as I get a replacement. Give me a couple of weeks.