X10 AGC and Insteon

I would sample outside the X-10 and Insteon windows. Any noise that's likely to be troublesome is likely to be present outside these windows. Basing your threshold on the general background noise level makes more sense to me than the "gated AGC" that others use.

However, it might be a problem should someone encounter another system using the powerlines outside of the X-10 & Insteon windows.

If you haven't already done so, you might explore how X-10 does it with the CM15A.

"Jeff Volp" wrote:

snipped-for-privacy@yahoogroups.com

Hello Jeff,

Doesn't Insteon use 131kHz? If that is the case you might consider a

120kHz LC filter with high enough Q to sufficiently suppress 131kHz but not so high as to let X10 devices with sloppy alignment fall too far down the slope.

Of course one could devise a steep elliptic bandpass that goes from

115-125kHz but that would probably be over the top here. One or too loosely coupled LC should be fine. This will also greatly improve your SNR except in cases where a switcher harmonic or other noise falls smack onto 120kHz.

Thanks for your input Dave,

Monitoring line noise here with a scope, most noise does not occur in the X10 sample window. The most significant noise is from large transients that occur near the waveform peak. Then there is a 200mV glitch that periodically walks its way through the 60 Hz waveform. Finally, I see an occasional high frequency burst that seems to be about one cycle long. It is not periodic, so I just see it for one scan. That signal is well down in amplitude from the X10 signals. Only one line transient comes in the middle of the X10 signal window. It is about 100mV, but certainly causes a few pulses to be counted with the XTB-II's high sensitivity.

Now I am using just the X10 sample window, and reducing the sensitivity if there are a series of counts above 12 cycles on multiple sequential half cycles. It seems to work pretty well for the type of noise I see here except for the random high frequency burst.

If I did open up the AGC to sample the full cycle, those large transients near the peak would reduce the sensitivity more than necessary. I'm also not sure how to deal with that random high frequency burst if it really is only there for a cycle at random times. At maximum sensitivity it could look like a collision if its frequency is in the X10 range. I'm thinking about a fast attack AGC loop sampling outside the Insteon/X10 transmission window, but after the glitches that occur near the waveform peaks.

Jeff

The XTB-II does include a 120KHz LC filter, but it has sufficient bandwidth to pass both "sloppy" X10 and Insteon signals. The XTB has been used to boost Insteon signals, and I didn't want to eliminate that possibility. Most of the noise isn't coming through that path anyway. Line transients come through the 60Hz AC path that powers X10 transmitters plugged into the X10 input receptacle.

Jeff

Both X-10 and Insteon chose the area around ZC on the theory there is less transient noise there but, if you are counting transitions (or looking for a carrier phase difference) to determine logic 1 or 0, transients should not be that big a problem. As you say, it only causes a few pulses to be counted which is unlikely to change a logic 0 into a logic 1. The problem comes from continuous signals that should be present most of the time and without being limited to the area around ZC.

The CM15A which uses gated AGC does not count transiti>Thanks for your input Dave,

snipped-for-privacy@yahoogroups.com

I agree. The problem isn't glitches, which only contribute a few counts.

The apparent sensitivity of the XTB-II can be varied by changing the threshold of the comparator. Default at power on is zero threshold, which can detect very low signal levels. That works well here, but I don't have any continuous noise. Increasing the threshold turns it into an envelope detector, perhaps similar to the CM15A.

The XTB-II only "listens" to the powerline during the 650 uS reception window defined by X10. Applying AGC, it would take a burst with sufficient amplitude in that window to be detected as a "1".

The conflict I have is what to monitor to set the threshold level. The various methods all have their advantages and disadvantages. Monitoring everything outside the Insteon/X10 window may be the best approach as long as I ignore a few high-level transients.

As you said earlier, the real problem is continuous background noise. All the methods will deal with that.

Thanks again for your input.

Jeff

transmission

It turns out that wasn't as simple as it first appeared.

It was easy to sample between zero-crossing Insteon/X10 windows, and that worked perfectly for X10 data from the Ocelot. However, nothing was received from a palm pad.

It turns out the extraneous 3-phase transmissions from the RR501 appear as noise in the AGC window, and the AGC dutifully reduces sensitivity so that X10 signal is ignored. I guess that shows the AGC is working.

The solution may be to just sample during the first half of the Insteon window for each half cycle. If the XTB-II tunes out any Insteon "noise", it might even be able to receive a strong X10 signal occurring at the same time. If the Insteon signal is as strong as the X10 signal, the message would be rejected anyway due to collisions.

Jeff

snipped-for-privacy@yahoogroups.com

There isn't really much time between the 3rd burst and the Insteon window, but I did consider the other slots. X10 shows the 3 phase transmissions being precisely timed. I wonder how closely X10 transmitters actually match those numbers. The important thing is to hit their 650 uS reception window on the other phases. I would allow tolerance on both sides, reducing the possible sample window. It also gets the sample up near the peak where most of my line glitches occur.

I coded this up last night using the first mS of the Insteon window (just before the zero crossing). It worked very well. It turns out I have an excellent source of continuous noise from the 4 ceiling CFs in my workshop. These are not on an X10 circuit, and are unfiltered. After amplification, they generated a couple hundred mV of high frequency noise, and my weakest X10 test signal was not much stronger. The AGC knocked out the noise but allowed the X10 signal through.

Unlike my earlier version, this works independently on each half cycle. So in the presence of an Insteon signal, the sensitivity will return to normal as soon as the Insteon transmission ends. This looks like a workable solution.

Jeff

Hello Jeff,

Well, since you said that Insteon signals mess with the threshold of the X10 side I assume that the uC can't keep them apart. If they come in concurrently and on the same line it really can't.

Unless you can gate time slots the only other option I see is to provide a 120kHz filter plus demodulator and feed that into one port, then a

131kHz (or whatever Insteon uses) filter plus demodulator and feed it into another port.

In a system with both types of devices, my concern was to recover sensitivity quickly enough following an Insteon transmission so that a tailgating low-level X10 message could be detected. Rather than averaging the signal level over many X10 windows, each cycle is now processed independently. So sensitivity recovers immediately. Overlapping messages will most likely be logged as a collision.

Jeff

snipped-for-privacy@yahoogroups.com