X10 AGC and Insteon
Jeff Volp
fully error checks all incoming messages, and sufficient noise can cause
messages to be rejected. Since the XTB-II can recognize X10 signals down to
the sub 10 mV region, continuous background noise can be a problem.
All X10 data is transmitted with its compliment. Only half the sample
windows should contain a X10 signal burst (neglecting the 1110 start
pattern). So a simple means of detecting noise is to look for pulses in
every sample window. More than a couple of counts (caused by random
glitches) in every window would mean the presence of background noise, and
the sample threshold should be increased.
This appears to work well in an X10 environment. However, Insteon
transmissions will cause a problem. They appear as noise to X10 because
they appear in every X10 sample window. Once the Insteon signal goes away,
the threshold will recover. However, a low-level X10 command closely
following an Insteon command could be missed.
There are a couple of ways to deal with this, and I'd like your opinions.
One is to speed up the recovery rate so the threshold decreases more
rapidly. Another is to sample for noise at a position other than where the
Insteon signal can appear. Unfortunately, that means noise appearing in the
X10 sample window would be ignored. Or, maybe this won't be a problem at
all, and can be ignored. Comments?
Jeff
Dave Houston
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" <Jeff...@msn.com> wrote:
http://www.davehouston.net
http://tech.groups.yahoo.com/group/roZetta/
roZetta-...@yahoogroups.com
Joerg
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.
--
Regards, Joerg
Jeff Volp
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
"Dave Houston" <nob...@whocares.com> wrote in message
news:453cd54d....@nntp.fuse.net...
Jeff Volp
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
"Joerg" <notthis...@removethispacbell.net> wrote in message
news:dMa%g.16993$vJ2....@newssvr12.news.prodigy.com...
Dave Houston
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 transitions. It uses a
low-pass filter, "listens" to the powerline only during the 1mS after ZC and
its AGC Reset line goes low for 1/2 cycle at the end of each 22 bits (or 62
bits for extended codes), draining the AGC capacitor. That approach makes
sense when looking at the data envelope but not when counting transitions. I
don't know whether Leviton, who introduced "gated" AGC counts transitions
but suspect not.
"Jeff Volp" <Jeff...@msn.com> wrote:
Jeff Volp
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
"Dave Houston" <nob...@whocares.com> wrote in message
news:453ee9db....@nntp.fuse.net...
Jeff Volp
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
Dave Houston
window? Or the time between the other 120kHz bursts?
"Jeff Volp" <Jeff...@msn.com> wrote:
Jeff Volp
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
"Dave Houston" <nob...@whocares.com> wrote in message
news:453f3987....@nntp.fuse.net...
Joerg
> 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.
>
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.
Jeff Volp
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
"Joerg" <notthis...@removethispacbell.net> wrote in message
news:vBO%g.16009$GR.1...@newssvr29.news.prodigy.net...
Dave Houston
receivers so I think you have hit the sweet spot.
"Jeff Volp" <Jeff...@msn.com> wrote:
>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.