Cause of some major X10 problems found

I seem to recall postings that indicated a device like a noisy PS could never generate a signal randomly capable of triggering an X-10 device but your experience seems to indicate that's not so.

I've reluctantly concluded that anything that gets plugged into the house wiring has to be bench tested with the Monterey first. I've been nailed by wall wart-sized switched power supplies before, but mostly by UPS's and PC power supplies. I printed up a whole bunch of small stickers that say either "X10 SAFE" or "X10 FILTER NEEDED" to attach to the bottom of all new equipment so that even if they get separated from the X-10 filter by accident, I remember they need one. I also keep a database of all new purchases that indicates the test date and voltage drop the device causes, as well as if it spews X-10 band noise. Just in case the label falls off. (-:

Regrettably, not all units that pass the bench test behave well in the field. More than once I've discovered that two pieces of equipment that tested well separately showed a signal-sucking effect when plugged into the same power strip.

In the case of noisemakers like the PS you've got, the Monterey spots them pretty quickly because the 190 reading buffer overflows in seconds with BSC's. I've found it overall easier to test new gear than to have to hunt it down later. How strong were the noise signals the Monterey was registering?

There are a number of Ebay vendors selling the X-10 5A filters for about $5 each. A much better price than I was paying at Worthington! ($17+) I just stocked up again because I bought a bunch of small UPS's to handle the DVR's and other devices that tend to lose their programming during power blips. Most of the new switched power supplies I've tested (and nearly all new PS's are switched, it seems) have shown either no degradation of the X-10 signal, or actually a slight improvement! Not sure why the latter is true, except that the Monterey electronics are probably interacting with the components in the gear under test. The improvement is usually never more than a tenth of a volt, so it's just as likely a reading error as it is a true reading.

-- Bobby G.

Any time it sees a 1110 sequence that is not followed by a valid X-10 code it calls it a BSC. You're likely to see that scenario with any mostly continuous noise source as well as with collisions between valid codes.

Are there any WS467 switches in use? Steven Bloom documented how they are directly vulnerable to noise spikes. I've seen more or less the same (rather than randon ONs, OFFs following a manual switching off of an older fluorescent) with the LM14A.

The probability that a noise source will create valid X-10 PLC codes (1110 followed by manchester encoded data synchonized to powerline half-cycles) out of whole cloth is near zero - it ain't gonna happen. However, there are other explanations for the unwanted ONs & OFFs - see the link I cited in my response to Bruce.

As opposed to just junking the X-10 crap entirely?

I think the switches are based on the WS467 although they do have the soft start feature (ramp up/down). They are probably 10 years old by now. I agree that these random on events are not caused by generated codes because my JDS TimeCommander+ log would have shown event. The noise was definitely the culprit though as the problem disappeared with filter installation.

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.

Jeff

How many valid codes were logged by your Ocelot or Leopard?

If I understand you correctly, the majority of such generated codes would be M-13 or J-Status Request as they are the only ones that have alternating 1 and 0 manchester patterns. All others will have some 11 or 00 sequences at the manchester level.

The XTB-IIR was not connected to a controller, so I have no traffic log. However, I did capture a valid data string on the 7D01 logic analyzer. I did not take a photograph of it, but it did look like just a series of 1-0 pairs. I have since modified the XTB-IIR AGC loop to increase the threshold when it sees a number of X10 messages having non-complimentary 1-0 patterns. After that mod, I have never seen it respond to CFL noise. In fact, it can recover a X10 signal riding on top of 1Vpp of pulsating CFL noise.

Jeff

Maybe the devices were made by the same 50 monkeys and typewriters that are claimed to be able to reproduce the works of Shakespeare if given sufficient time. (-:

There could be a number of reasons for the Stargate not seeing anything. The power supplies' noise signal could be too weak to activate anything except nearby lights. Certain lights nearby would be affected, but the Stargate would not be within range. Since Bruce uses an XTB, one might suspect that weak signals don't propagate far in his house. There's not enough info to know for sure.

Also, the PS's noise could have collided with a legitimate command the Stargate was issuing at the time of occurrence and corrupted it. We don't know much about exactly which lights came on and off and when they did it. AFAIK, the Stargate can't transmit and receive a command simultaneously. While I believe that generating whole commands out of random line noise is rare, I believe that a continuous noise source corrupting valid X-10 transmissions is far more likely. That might show up if the random "turn ons" turned out to occur precisely when some other X-10 activity that was supposed to occur at that time didn't. We don't know if that's the case, either.

We also don't know whether the Stargate considers a valid command to consist of a valid first and second copy embedded in the single X-10 message or either one being valid. More correctly said, at least *I* don't. I suspect it does, but whenever repeaters are present, both "data frames" within an X-10 need to be considered.

I do know that the Monterey analyzer is able to distinguish between codes that are complete (containing two frames) versus ones that have only one valid 11 cycle frame, which it reports using a lower case housecode A light switch appears to trigger with either code, from what I've seen. One might ask why they duplicate the frame if Manchester encoding provided enough error checking, but there are plenty of other reasons to duplicate frames, and repeater designers can testify to them all. (-: I'll absolutely agree it's impossible to duplicate a complete double frame transmission of X-10 data under these circumstances, but a single, 11 cycle frame is a different animal.

Since I don't have a Stargate, I can't make any guesses about how it reads commands with only a single frame or whether it sees them at all, particularly with an XTB and a SignalLinc repeater thrown into the mix for good measure. FWIW, I doubt the XTB is involved in any way. Its presence, though, strengthens my belief that the JDS unit just didn't read the "created command" because it was too far away from the source of the noise generation. Bruce did say the effects appeared to be local one area in the house.

What I don't understand about the Bloom theory as it might apply here is why aren't the lights flashing off and on rapidly in response to the apparently continuous noise? I'm assuming it's fairly constant in amplitude so if the switches are truly that susceptible, they should be going on and off like crazy, shouldn't they? If, however, they're responding to a single 11 cycle signal they see as valid generated out of random noise, one would expect a very much more infrequent activation. That latter case sounds more like what we're seeing. Activations that occur after 10's of thousands of random bits have been thrown onto the line.

From what Bruce described, these switches, if X-10, are the two-way model because the regular WS-467 doesn't have the "soft ramp" feature he was describing. Without a make and model number though, we really don't have good information as to whether those switches are similar enough to the ones Bloom tested to know if they're triggering as a result of line noise. Without pulling a susceptible switch and bench testing it against the powersupply, we've got less than enough facts to reach an unimpeachable conclusion.

Too bad the Monterey doesn't log events because someone might be able to catch a a valid single frame transmission among all the BSC's if it were possible to capture the reams of data the Monterey produces under such conditions. I wonder if I can put a macrocam on the display and feed the image into an optical scanner with OCR. It should be able to see each update of the display and then I'd just text search the resulting document for letters other than BSC. Oh great, another damn project. If only I had grad students slaves! (-:

If the funky power supply can trick the Monterey into reporting bad strings of X-10 signals to the point of differentiating such noise as X-10 1 or 0 bits, it's already half-way to the point of creating something that can trick a much dumber lightswitch to activate.

I understand that there's error-checking built-in the X-10 protocol, but it's pretty primitive. I also understand that there are plenty of impossible things that happen all the time. Who would have thought light pieces of foam could do enough damage to the shuttle to bring it down? Until they ran the tests and they saw the pictures and examined the damage very closely, there were plenty of engineers and rocket scientists who went on record with great conviction to say it was impossible.

I guess the only person who can make the determination of why those lights lit for certain is Bruce, since he's got the magic power supply, the light switches in question and a means to further analyze the situation: the Monterey.

Sadly, most threads about bad X-10 devices usually end here with the application of a filter because most people just want to get their system back to working order. I doubt many people would want to sit around in a dark house next to a Monterey analyzer waiting for a light to turn on randomly so they could freeze the display when it happened to see what was coming down the wire at the time.

Maybe Bruce will buy a replacement and send the magic supply to you for further analysis so you can see on the scope what's happening. It would be nice to know for sure because reports like this seem to turn up with regularity. Maybe he'll give us the exact model number of the PS so anyone so inclined to investigate further could buy their own.

So I guess these are all "questions for the ages." I'm still troubled by why the activations are so infrequent if the noise level is constant. Perhaps the power supply produces noise irregularly at different points in its operation cycle. Or maybe by saying "random" Bruce did imply that they were activating incorrectly fairly rapidly. Knowing the switch make/model, the rate of activation, the PS's proximity to the affected switches, the noise level at those switches and the strength of the noise emanating from the PS would all be very useful items in determining the true nature of the interaction.

As far as I can tell, no one claims that Manchester encoding is highly resistant to errors. AFAIK, it was used by X-10's designers mainly to save bandwidth. At least that's how ACT's Phil Kingery describes it:

Without parity bits or CRC checking, I'm not sure how error-resistant the X-10 protocol truly is, especially when "attacked" by 5 million random bits* per day.

The bottom line is still "get a meter and a box of X-10 filters" if you want to keep your X-10 running smoothly. I'm a little surprised that the noise overwhelmed the XTB, but I assume the PS was located fairly far from the XTB. I also never realized how difficult a good repeater is to design until I read the Kingery article about preset dims and the changes X-10 made to the protocol in midstream.

-- Bobby G.

*5,184,000 bit at 60Hz times 60 seconds times 60 minutes times 24 hours. Granted, that has to be divided by eleven for a sequence of bits to constitute a single, valid X-10 frame, so the number drops to 471272.

half-cycles)

That's fascinating. Do you remember the strength of the signal the CFL's generated? Was it low enough so that something like a Stargate located at a distance might not even record it but a nearby light switch would?

You've touched on two things that could shed a little more light on the problem (and that I touched on my in previous screed). Noise generators can act differently depending on their operational cycle. Bruce's charger could easily emit three different types of noise depending on whether the charger had nothing in it to recharge, whether it was loaded but the batteries were dead or whether they were fully charged.

More importantly you've actually observed the ivory billed woodpecker of the X-10 world in the wild. We've seen repeated reports of ghost commands in this group for a long time now. While sightings don't necessarily prove the existence of the ivory bill, in this case there's relatively little motivation for people to repeatedly report seeing bizarre codes coming out of nowhere. The woodpecker's at least brought in the tourist trade and stands at the cusp of important environmental issues, so phony sightings could be made by folks with an agenda.

The random code generation reports seem to imply (some do, anyway) the bad codes come at an interval that would more in line with the random good code generation theory than the Bloom theory. It doesn't mean the Bloom theory is invalid, it's just that it might not be sufficient to explain all cases of random turn ons. The issue gets even more complicated when you realize that light turned on by the Bloom method may indeed be swamped by 1,000s of spikes that trigger false ON's, but since it's ON, it shows no further influence until you turn it OFF again.

Maybe Bruce will donate his noisy PS to you in the name of science so that you can examine it on your logic analyzer. Do you give XTB factory tours? (-: I'd love to see the analyzer in action. It sounds far superior to both the O'scope and the Monterey for getting detailed information about the X-10 signal.

The more I read at the ACT site, the more respect I have for all the cases the XTB-IIR has to recognize and deal with (and fast enough to be useful!). Especially as I piddle along with my lowly 6 input/two clock BSD. When you around to designing the XTB-IIIR please add an auto-configure mode like my LCD TV. It figures out what I plugged into it and sets its mode accordingly. (-: At least I understand why repeating preset dims (PK calls them Direct Dims, more intuitively) is next to impossible and why X-10 abandoned them.

-- Bobby G.

The SG uses a TW523 which reports powerline commands on a delayed basis, after validating them. When transmitting, it reports the first copy of the code 22 half-cycles later during the transmission of the second copy so it can send and receive at the same time. A controller using it can detect collisions by comparing the received copy with the earlier transmitted code. It only reports valid codes so it does not report anything that doesn't have valid manchester coding following the 1110.

While there is no way to disprove your wildly imaginative theories, I can report, based on watching with an oscilloscope, that there was absolutely nothing on the powerline that in anyway resembled X-10 activity when my living room lamp would turn off following a manual switching off of the non-X10 controlled fluorescent in one of my bathrooms. (I have since replaced the LM14A with an Icon dimmer module and replaced the manual switch on the bathroom fluorescent with an Icon switch and no longer have any problem.)

Most of the anecdotal reports are like Bruce's, repeated random ONs of multiple addresses on multiple housecodes (usually in the middle of the night) and there are seldom any logged commands (logged commands usually point to a traceable source). Noise spikes acting directly on the switches and modules explain these episodes with no need to "monkey" with the laws of probability.

Ignoring the address, any ON code requires the sequence 0101100110 at the manchester level. A noise source is not going to generate that sequence repeatedly. And no X10 PLC code will affect multiple housecodes simultaneously.

IMO, the only thing dumber than the Monterey is all the people who spent $300+ for it!

This does happen, and is not rare. Here we have four Ocelot macros that turn on/off all interior or exterior lights. Those are the ONLY commands that can cause the Ocelot to issue a long series of X10 commands.

While developing the XTB-II a year ago, there were numerous occasions when my CFL "noise source" morphed another X10 command into triggering one of those macros. At first I didn't understand what was going on, but capturing the data strings on the logic analyzer showed the imbedded extended commands used for the Leviton dimmers. I was triggering remote commands from a palmpad via a RR501. The CFL noise apparently morphed the RR501 output into one of the macros when it was received by the PSC05 feeding the Ocelot.

I haven't seen this recently while working on the XTB-IIR - possibly due to my now using a XTB-II as the powerline interface for the Ocelot.

Jeff

I measure the CFL noise after the X10 bandpass filter because that removes all the 60Hz. At that point it averages about 1Vpp, but the peaks can get as high as 1.5Vpp when they all sum constructively.

(stuff snipped)

Actually, it is a real OLD Tektronix logic analyzer. It dates back to the

6800 era. I bought it from the lab when I retired. They were probably glad to get it off the inventory list because I was probably the only one who still used it.

I think the XTB-IIR is probably the end of the line. Yes, repeating extended commands is asking for trouble, so the XTB-IIR does not do that. However, it will certainly transmit and receive them.

Jeff

replacement)

You just made me spit my coffee on the screen. My bifocals elided the letter "a" in your first line so I saw "as soon as I get my wife replacement." (-: I thought "boy is this guy tough. His wife plugs in a signal sucker and she's out the door!"

I'm sure other X-10 diehards like me appreciate your contribution to science. I'd be interested to know if the same power supply effects Insteon transmissions, so if you can, you might want to wait to send the gear to Jeff or Dave after you've tested it against Insteon. That would really give us some insight into the X-10 v. Insteon debate. The unit certainly sounds as if it would be a great item for Jeff to check his noise rejection circuitry against, as well.

-- Bobby G.

You're reaching for something that's not there. There were no reports of random OFFs with the WS467 only random ONs. In my case (which was actually with a screw-in lamp module) there were OFFs but never any ONs. Without having the source code for the firmware one can only speculate about the "why" but the facts that grounding the pin cured that case while replacing the lamp module with a different model cured mine is overwhelming evidence that those models were susceptible to direct noise effects. Even X-10 has noted that spikes can cause problems in one of their FAQs.

Anybody who had ever conducted (or seen or heard about) tests on front fans for jet engines would know that high velocity styfofoam can do lots of damage. I spent a few years (early '70s) in R&D at GE's Large Jet Engine Department during the time they were developing their first commercial engines with front fans. Since the engines had trouble digesting birds, one of the tests used live duckings (about the size of a seagull). They were asphyxiated and their warm body stuffed into a styrofoam cartridge that was fired from an air cannon at a titanium fan blade while filming with a high speed movie camera. The styrofoam could do nearly as much damage as the birds.

Bob! you are a home automation guru and you don't have a Stepford model?