Repeater present any problems?
Roger
repeater operation.
I am having trouble locating the transceiver in a good location.
I'm controlling 4 lamps and generally, everywhere I put the transceiver 2
lamps respond OK and the other two occasionally.
Trying a different wall socket, the two sets may switch, the other two
behave nicely and the other two become occasional performers.
For some reason, one particular wall socket seems to control all four lamps
well with the transceiver there, but it is the least desirable place I want
to locate it. All wall sockets and lamps are in the same room.
I'm assuming the lamp pairs are on two separate 110 volt legs of the house
wiring.
I am thinking of buying the latest Leviton coupler/repeater to hopefully
resolve this and make the whole system much more reliable. I hope to add
more devices through out the house later on down the road.
But, I got to thinking, does using a repeater present any problems?
1) Suppose the device I'm transmitting to hears the original signal and the
duplicate from the repeater module. I guess receiving two "ON" commands or
two "OFF" commands would present no problems.
2) But, suppose it is the "DIM" or "BRIGHTEN" command. Would the module
receive twice as many commands and dim or brighten twice as much as
intended?
3) How about when using a CM11A controller. Suppose I send one X-10
command, the CM11A recognizes this as a macro and sends a bunch of X-10
commands out one after the other to perhaps multiple devices. As the
repeater sees one X-10 command and repeats it, could the CM11A be sending
out the next command and collisions start occurring?
4) Are there any other operational problems it may present that you are
aware of?
My apologies if I sent this out after drinking too much coffee and the brain
is in overload mode!
Thanks in advance for any replies.
--------------
Please remove NO_SPAM from my email address if replying directly to me.
Mark Lloyd
NO_SPAMr...@worldnet.att.net says...
> I'm a new user to the X-10 world and will lead up to questions concerning
> repeater operation.
>
> I am having trouble locating the transceiver in a good location.
> I'm controlling 4 lamps and generally, everywhere I put the transceiver 2
> lamps respond OK and the other two occasionally.
> Trying a different wall socket, the two sets may switch, the other two
> behave nicely and the other two become occasional performers.
> For some reason, one particular wall socket seems to control all four lamps
> well with the transceiver there, but it is the least desirable place I want
> to locate it. All wall sockets and lamps are in the same room.
>
> I'm assuming the lamp pairs are on two separate 110 volt legs of the house
> wiring.
>
> I am thinking of buying the latest Leviton coupler/repeater to hopefully
> resolve this and make the whole system much more reliable. I hope to add
> more devices through out the house later on down the road.
>
> But, I got to thinking, does using a repeater present any problems?
>
> 1) Suppose the device I'm transmitting to hears the original signal and the
> duplicate from the repeater module. I guess receiving two "ON" commands or
> two "OFF" commands would present no problems.
>
Every X10 signal is transmitted twice, X10 device know this and don't
react to the second signal. The coupler/repeater receives the first
signal and sends out an amplified version AT THE SAME TIME as the second
signal. This second signal will be used only if the first one was to
weak, so there's no problem.
> 2) But, suppose it is the "DIM" or "BRIGHTEN" command. Would the module
> receive twice as many commands and dim or brighten twice as much as
> intended?
>
It does seem to reduce the number of steps, although that's a function I
seldom use.
> 3) How about when using a CM11A controller. Suppose I send one X-10
> command, the CM11A recognizes this as a macro and sends a bunch of X-10
> commands out one after the other to perhaps multiple devices. As the
> repeater sees one X-10 command and repeats it, could the CM11A be sending
> out the next command and collisions start occurring?
>
The coupler/repeater will not cause collisions since it transmits only
when THE SAME THING (just weaker) is already being sent.
> 4) Are there any other operational problems it may present that you are
> aware of?
I don't know of any, my coupler/repeater (Levition 6201) has solved a lot
of X10 problems.
>
> My apologies if I sent this out after drinking too much coffee and the brain
> is in overload mode!
>
> Thanks in advance for any replies.
> --------------
> Please remove NO_SPAM from my email address if replying directly to me.
>
>
>
--
Mark Lloyd
http://148.75.72.214
http://go.to/notstupid
BruceR
being controlled and there is no adverse result from using one. Buy it.
Install it. It will make you happy. It will resolve all but the worst noise
problems and save you hours of frustration in the years to come.
"Roger" <NO_SPAMr...@worldnet.att.net> wrote in message
news:s5BV6.78996$4f7.6...@bgtnsc06-news.ops.worldnet.att.net...
: I'm a new user to the X-10 world and will lead up to questions concerning
:
:
Eric Townsend
it solved all X10 erratic behavior and is still working fine. A
feature that i particularly like is that it blinks when it receives a
signal so you can tell if something has happened at your preset time
or on command. If (when) you buy it, hook it up to the clothes dryer
leads then stick it (with the included double side tape?) up high
where you, and every body else can see it.
"Roger" <NO_SPAMr...@worldnet.att.net> wrote in message news:<s5BV6.78996$4f7.6...@bgtnsc06-news.ops.worldnet.att.net>...
Bholio
instead of an active repeater. Try turing on your dryer (assuming it's 220v
electric, and assuming you're in the USA, I know nothing about non-USA) and
seeing if everything works. If you get good X10 coverage then try the
passive coupler. When the dryer is on, it does the same thing as a passive
coupler.
A repeater has intelligence to read a signal, decide if it needs to
retransmit it or not and other logic, wheras a passive coupler simply
connects both power legs so the original signal can get to the other 110v
leg of the house. Repeaters are programmed to not get confused by the
issues you raise, but if you can get the original signal from the original
controller to reach everywhere in the house (via passive coupler), that's
the best route.
If you can try things out with the dryer, I'd recommend taking the hour or
so to see if every wall-outlet in the house will respond to a transceiver
plugged into each 110v leg of your house before going for the passive
coupler, to insure that any future expansion of your system will work.
"Roger" <NO_SPAMr...@worldnet.att.net> wrote in message
news:s5BV6.78996$4f7.6...@bgtnsc06-news.ops.worldnet.att.net...
Roger
simple - it's getting more complicated all the time.
I purchased the Leviton HCA02-10E repeater and installed it tonight. I
installed it in the breaker panel through a double pole 15 Amp breaker as
instructed. Good news and bad news.
It has a test mode where it alternates sending code P1 ON then P1 OFF with
about 2 seconds in between each. I set an appliance module to P2 and went
to almost every outlet in my house. All outlets worked. Relay in module
clicks away!
I move my transceiver to an outlet that would control two lamps fine and two
lamps occasionally before the repeater installation. All 4 lamps worked
great just sending ON and OFF commands to individual lamps.
Now the bad news.
I tried the dim function on the first lamp. It was very hard to control and
often would not respond. If you held the dim button down it would do
nothing. If you just tapped and release the dim button, it would dim
various amounts at different times. Three times it seemed to somehow lock
up the transceiver module (IBM, came w/ the home director starter kit). The
green receive light on the repeater would not blink (receiving no codes). I
could hit the test button on the repeater and it would send and control the
module set to code P1. Unplugging the transceiver and replugging it in
would again start things trying to work again. Green light (receive) on
repeater would flash as remote buttons were pushed. Seems to prove
transceiver lockup.
Why the transceiver lockups - I don't know.
Macros from the HD11A (again, IBM home director starter kit) would not
function correctly. Had a macro "When code A7 ON received, turn A1 OFF, A2
ON, A3 ON, A4 OFF" (the four lamps I am controlling). A1 would go off, A2
would come on, A2 would then dim down smoothly and go out, A3 never came on,
and A4 turned on.
It seems that the repeater is hearing the transmitted signals and
retransmitting them causing multiple or no dims to happen when they should,
and collisions I guess screwing up the macro I had programmed.
If I turn off the repeater, things would work as I first reported in my
first post.
I tried the dryer trick, turned it on. Turned repeater off. Things
behaved, all lamps would switch on and off, would dim and brighten properly,
and the macro function (as well as another similar macro) worked just fine.
I didn't feel like going all through the house again to see if codes could
be received by modules all over the house. Looks like I need to do this
again to see if just a passive coupler will do the job.
I turned the dryer off, repeater still off. Back to two lamps work well,
two work ocassionally.
Looks like passive coupler may work at least for this one room w/ lamps.
Whole house? - need to test again.
I'm disappointed in the repeater operation. Thought this would be a well
spent $65 to insure reliability.
Any thoughts?? Any suggestions??
I may try and contact Leviton and ask if any troubles similar to mine have
been reported.
Thanks again!
Roger
--------------
Please remove NO_SPAM from my email address if replying directly to me.
Roger <NO_SPAMr...@worldnet.att.net> wrote in message
news:s5BV6.78996$4f7.6...@bgtnsc06-news.ops.worldnet.att.net...
HolyGrail
home with X-10 stuff throughout (light switches and transceivers
almost exclusively -- a few motion sensors). I usually get things to
work as expected, except for all the stuff on the same circuit as my
office (computer noise, I'm sure -- noise filter is my next planned
purchase), but I have had minor cross-leg problems.
So I, too, broke down and bought the Leviton coupler/repeater since I
was ordering a bunch of other stuff from Worthington at the time. I
have not installed it yet (or even taken it out of the box), and I'm
wondering if I really need to at this point. I DO use the DIM
function quite a bit in several rooms, so I'd hate to be fixing a few
other very minor problems at the cost of having this coupler/repeater
break the DIM feature.
Has anyone else had good/bad experience with the Leviton HCA02-10E
coupler/repeater in homes where the repeater probably isn't required,
but also shouldn't hurt??? I'd like to know before I go buy a few
extra QO breakers and start wiring it in ...
Dave Houston
One transceiver lockup problem is well known. The coupler should not affect
it if its the familiar lockup mode where the transceiver continues to send
dims endlessly. But there was a recent thread dealing with a previously
unreported transceiver lockup mode wherein the transceiver would lock up
when a certain CM11A fast macro was triggered. And there was a thread a few
months back where someone said they fixed their transceiver lockup problem
by putting a filter on some appliance. The latter made no sense if the
lockup was the endless dim type but does make sense if the transceiver was
locking up without sending dims continuously.
I am intrigued by the fact that the repeater is not showing any signal when
the transceiver is locked. My ESM1 shows continuous, good X-10 signal when a
transceiver is in the endless dim lockup mode. You've presented clear
evidence that this transceiver lockup is not the endless dim lockup. The
person who started the other thread about this new lockup mode stopped
posting before there was any resolution - I don't recall if he had the HCA02
(or any coupler/repeater) but it does appear that there is a new way to
lockup the transceivers.
There was a lengthy thread about problems with the HCA02 a few months ago
and there is another current thread on the same subject. I think the
evidence is accumulating that the HCA02 doesn't always play well with
others.
"Roger" <NO_SPAMr...@worldnet.att.net> wrote:
---
BX24-AHT All Housecode Transceiver is at:
http://www.laser.com/dhouston/
Roy L.
and had a response from Damon Bruccoleri from Leviton that Levition
has never had "any reports of problems with HCA02 installations." As
I recall, he also had a bridge to sell me (Brooklyn, not signal) ;)
The HCA02 has had many reports in this newsgroup of causing
retransmission and fatal feedback loop errors. My problems stemmed
from having a PR-511 and a HCA02 enter into endless feedback,
resulting in my eventually shutting down the HCA02 breakers to restore
order.
Unfortunately, no one (after 96 posts on the original thread) could
offer insight into why this repeater SUCKS on occasion. Leviton has
distanced itself from customer support on this product, so we may
never find out what the real issue is. This leaves users having to
either think up alternative solutions (i.e. better repeater, using
Ocelot instead of PR-511 macros, etc.) or get stuck.
Roy.
Gene
one being described here. I don't have the meter to test for a particular
signal, but when this CM11A lockup would occur, no device in the entire
house would respond to any X10 signal from any transceiver. Disconnecting
the CM11A and removing the batteries solved this.
Having spent substantial spousal patience capital getting my wife to use
remote controllers instead of turning appliances and lamps off at the
device, a whole house lockup was a disastrous setback. I do not use a
repeater.
"Dave Houston" <dhou...@fuse.net> wrote in message
news:3b29e1c2....@nntp.fuse.net...
Dave Houston
my web page. This does not appear to be a CM11A lockup because the CM11A is
reporting powerline commands to the logging program. In all of the known
CM11A lockup modes, the CM11A does not communicate anything to the RS-232
port.
John Galvin
Just to add a little here. I have seen the RR501 lockup pretty much as
described here. The one difference was, that I don't have a repeater per se.
What I did have was a HouseLinc controller performing a "repeat" function on
one particular unit code. The HouseLinc was setup to repeat once, all on/off
commands on unit code 2. The purpose of which, was to overcome a SwitchLinc
lite's extremely poor reliability with recieving commands from the RR501, due
to the 3.5 cycle inter-command gap on the RR501 Vs the normal 3 cycle gap on
all wired X-10 controllers. Anyway, that's a whole 'nother thread. The RR501
lockup scenario goes something like this: Using 6-in-1 RF remote, send "2"
"on" (G2 GON). HouseLinc sees G2 GON and repeats it. During the time when
the HouseLinc is repeating the G2 GON, press and hold the CH down (dim) button
on the 6-in-1. A Monterey Instruments PLSA shows that this results in a
collision. That comes as no surprise. What is not expected, is that the
RR501 is completely locked up at that point. The PLSA shows that there is no
activity on the powerline after the initial collision. The on/off button on
the front of the RR501 is not responsive, nor does it respond to RF commands,
at that point. The only solution, is to power cycle the RR501. Then all is
well again. The exact timing to initiate this lockup doesn't seem to be that
critical, just need to press and hold the dim button, during the .8 seconds
that the HouseLinc is repeating the G2 GON command. What is interesting about
this scenario, is that the HouseLinc does not repeat in the same manner as a
real repeater. A real repeater, receives the first part of a given command
and then repeats in phase with the second part. The HouseLinc must receive
the entire G2 GON sequence, before it can begin the retransmission.
J.G.
Dave Houston wrote in message <3b29e1c2....@nntp.fuse.net>...
Dave Houston
Thanks for the details. I should be able to set something up to duplicate
the conditions.
I am surprised I haven't seen it because a standard test, that I ran often,
used an RR501 to interrupt a chain of commands from a CM11A.
t...@worthdist.com
>The HCA02 has had many reports in this newsgroup of causing
>retransmission and fatal feedback loop errors. My problems stemmed
>from having a PR-511 and a HCA02 enter into endless feedback,
>resulting in my eventually shutting down the HCA02 breakers to restore
>order.
This lock up issue I have been chasing since my APEX Destiny 6100 with
3 PR511's got suck in an endless loop (last house). In that
installation was a Leviton 6201. I have often wondered if the finger
pointing is in the wrong direction? I have been working on some
theories without 100% proof and would like some feedback. Could it be
the PR-511 spot lights causing the lockup and not the repeater? I
theorize that the repeater just adds the spark to start the fire. We
all know how X-10 is famous for its 'value engineering'. Has anyone
played with the retry logic in the PR-511? I theorize that the PR511s
are perceiving a collision and endlessly retrying to transmit. In
this house I do not have PR-511's so I have not had an opportunity to
test my theory. One thing is for certian, X-10 is not going to put a
whole lot of smarts in a $38 2-way dimming floodlight with a motion
detector.
Part of my theory was confirmed last week when a dealer told me that
the lockup stopped once the breaker to the spotlights was turned off.
It was the first time that someone had turned the spotlights off, not
the repeater. The lockup ended but returned later. This is confirmed
by the fact that a lockup on a Monterey shows complete signals (along
with a ton of BSC's) and not just repeated signal. That proves the
lockup signal must be originating from somewhere since a repeater can
only send 2nd frames.
Another piece to the puzzle is that every instance that I have helped
troubleshoot has had multiple PR-511's in the same installation. Has
anyone had the infamous lockup with just 1? I ran this theory with
some other installers and a good point was made. Could 2 PR-511's be
trying to transmit at the same time. Both endlessly retry. What is
the spark? Sunset maybe?
This is all theory but has this group investigated the PR-511's
instead of the repeater?
This lockup issue has always bugged me. I would love to know the
exact cause. Your thoughts?
Tom Morgan
Tom Morgan
Director of Worthington Solutions
www.worthingtonsolutions.com
866-844-6223
Dan Lanciani
|
| >The HCA02 has had many reports in this newsgroup of causing
| >retransmission and fatal feedback loop errors. My problems stemmed
| >from having a PR-511 and a HCA02 enter into endless feedback,
| >resulting in my eventually shutting down the HCA02 breakers to restore
| >order.
|
| This lock up issue I have been chasing since my APEX Destiny 6100 with
| 3 PR511's got suck in an endless loop (last house). In that
| installation was a Leviton 6201. I have often wondered if the finger
| pointing is in the wrong direction?
Doubtful, unless you are suggesting an APEX problem.
| I have been working on some
| theories without 100% proof and would like some feedback. Could it be
| the PR-511 spot lights causing the lockup and not the repeater?
No. The PR511 has been around for a long time. I've had half a dozen in
service at all times for years. I've used both Leviton's original repeater
and ACT's consumer repeater. The only interesting thing about the PR511
is that it responds *very* quickly to a status query--so fast that a CM11a
with firmware version 8 or newer will interrupt its transmission sequence
with an input poll for the status response before confirming the transmission
of the query.
As I pointed out when this problem was first reported, it is possible that
Leviton is using CM11a-like firmware in their new repeater and failing to
handle this glitch.
| I
| theorize that the repeater just adds the spark to start the fire.
You can always blame or absolve a component in a multi-component failure
scenario with reasoning like that. But in this case the PR511 has been around
forever and it is for the new kid on the block to accommodate the existing
players. Even if they are doing something odd. Which they aren't...
| We
| all know how X-10 is famous for its 'value engineering'.
Clearly you mean this in a negative way. In fact, X10's value engineering is
quite good. They deliver (mostly) high levels of functionality at low prices.
It is generally the third-party manufacturers of (supposedly) X10 compatible
equipment who engage in the bad sort of value engineering (we used to simply
call it bad engineering) to which you allude. E.g., they will save $0.10 on
a $100 product by using a smaller PIC at the expense of leaving out some
important aspect of the protocol or of allowing spurious operation under
anything less than ideal conditions. Then they will try to blame real X10
components which are obviously inferior because they cost less...
| Has anyone
| played with the retry logic in the PR-511? I theorize that the PR511s
| are perceiving a collision and endlessly retrying to transmit.
I have never had a reason to look closely at this (because the PR511 doesn't
cause the kinds of problems you suggest), but as far as I know they do not
do collision detection. At one time I had a PR511 and another driveway sensor
that would collide for a particular vehicle velocity. There was never a
retransmission.
| One thing is for certian, X-10 is not going to put a
| whole lot of smarts in a $38 2-way dimming floodlight with a motion
| detector.
I'm not sure how much more smarts you could put. The PR511 is pretty
comprehensive as floodlight controllers go. The only interesting thing
missing is the ability to send X10 during the day while suppressing the
light, but I understand how they arrived at the configuration they did.
| Part of my theory was confirmed last week when a dealer told me that
| the lockup stopped once the breaker to the spotlights was turned off.
That's potentially interesting, but it doesn't help assign blame.
| It was the first time that someone had turned the spotlights off, not
| the repeater. The lockup ended but returned later. This is confirmed
| by the fact that a lockup on a Monterey shows complete signals (along
| with a ton of BSC's) and not just repeated signal. That proves the
| lockup signal must be originating from somewhere since a repeater can
| only send 2nd frames.
Your premise is incorrect. Modern repeaters can send in both slots to,
e.g., make DIM/BRI work correctly. Even if this were not the case, the
entire "lockup" situation suggests that something is in an abnormal state.
If that something is the repeater then the repeater may not be behaving as
you think a repeater should. Your "proof" that the signal is originating
elsewhere depends on the assumption that the repeater is working correctly.
That logic is flawed...
| This is all theory but has this group investigated the PR-511's
| instead of the repeater?
Since the PR511s don't cause problems, why investigate them? If they can
be used to tickle the bug in the repeater that's great, but it would be
investigating the repeater...
| This lockup issue has always bugged me. I would love to know the
| exact cause. Your thoughts?
Well, these are my thoughts.
Leviton is in a great position to determine the exact cause. Moreover, I'll
bet that some technician at Leviton already *knows* the exact cause, just as
several other manufacturers of "X10 compatible" equipment know exactly why
their products cause problems. There are several people (including me) who
could debug the repeater problem. But why bother? Over the past few years
I've found that the response of companies to detailed and helpful bug reports
ranges from apethetic to extremely hostile and defensive. The postings of
Leviton's representatives in this group have made it clear that they are not
interested in resolving this problem. Beyond that, they continue to ignore
the reports of users and claim that there are no reported problems with the
product.
Dan Lanciani
ddl@danlan.*com
BruceR
and when they did find a bug a few years ago, they sent me a new chip to
update my repeater.
"Dan Lanciani" <ddl@danlan.*com> wrote in message
news:917...@news1.IPSWITCHS.CMM...
: In article <3b2a9856...@news.rdu.bellsouth.net>, t...@worthdist.com
Gene
using a repeater, but FWIW, my CM11A lockups did (and upon retrying, still
do) lock up the serial port. They lock up the port so badly that accessing
the port will crash the computer so hopelessly that it requires a hard boot.
At one point, I thought I perceived that the serial interface in the
computer would even become warm if I left it on after the lockup began. I
may just have a bad CM11A.
"Dave Houston" <dhou...@fuse.net> wrote in message
news:3b2e0cdd....@nntp.fuse.net...
Claus V.
> Your premise is incorrect. Modern repeaters can send in both slots to,
> e.g., make DIM/BRI work correctly. Even if this were not the case, the
> entire "lockup" situation suggests that something is in an abnormal state.
> If that something is the repeater then the repeater may not be behaving as
> you think a repeater should. Your "proof" that the signal is originating
> elsewhere depends on the assumption that the repeater is working
correctly.
> That logic is flawed...
I finally disconnected my HCA-02. I had a problem with fast macros that I
could not resolve. I could manually turn off all lights using Activehome
and clicking on the control icons. But with the repeater on line some of
the lamps in the macro sequence would not turn off. Removing the repeater
eliminated the problem with the CM11A. The Monterey, curiously, showed the
commands as going through loud and clear at 1.4 volts. There's obviously
something about fast mascros that the HCA-02 doesn't like. I wonder what
version of the firmware they're up to?
Claus V.
Dave Houston
cycles between commands. Perhaps someone with one of the Monterey analyzers
could confirm or refute this.
"Claus V." <claus...@usa.net> wrote:
---
John Galvin
Here's what the Monterey Instruments PLSA showed:
G4 .49V
GON .49V
BBk .52V
BSC .36V
BSC .36V
BSC .36V
BSC .36V
g4 .37V
GON .36V
At that point, the RR501 doesn't accept RF or PLC commands and does not
respond to the on/off switch on the front of the unit.
In the above sequence, the addr/commands with .49V amplitude are from the
RR501. Those from the HouseLinc show up as .36V. The lower case "g" in the
g4 signifies that one of the two addresses was not recognized. BSC = bad
start code. BBk = bad block.
The above sequence is by no means, the only one that results in RR501 lockup,
but it's the first one I grabbed. If I get a chance, I'll capture a few more
of the various flavors.
J.G.
Dave Houston wrote in message <3b2a8049....@nntp.fuse.net>...
John Galvin
_MY_ CM11A does not show BCY (bad 3 cycle gap) on the Monterey Instruments
PLSA, when executing fast macros. I should point out that _MY_ CM11A behaves
very different from what others report, regarding SwitchLinc compatibility.
My CM11A works ___PERFECTLY__ with _MY_ SwitchLinc lites, when executing fast
macros, or via computer control. RR501s and TM751s on the other hand, show a
3.5 cycle gap between commands. You need a 'scope to see this, since the
Monterey PLSA is happy with 3 or more cycles of gap and doesn't report
anything wrong. Anyway, the 3.5 cycle gap wreaks havoc with the SwitchLinc
lites. The SwitchLinc's error rate receiving commands with 3.5 cycle gaps can
be as bad as 50%.
John Galvin
Dave Houston wrote in message <3b2c3158...@nntp.fuse.net>...
Dave Houston
of the opinion that the BSC report from the Monterey is essentially
meaningless. It's impossible to define a "bad start code" without making
several assumptions. A start code is 1110 and that's really all that can be
said about start codes with any certainty. I really hope that Iriave does
build an SMD version of their TR-1A so we can have a diagnostic device to
record each bit for analysis.
But, it is obvious that you're seeing collisions. I'm surprised because I
did a lot of testing with TM751s and RR501s without ever seeing this type of
lockup. That may have been because I was mostly using CM11As that would
avoid collisions and let the transceiver have a clear line. But, I know I
used a LynX-10/TW523 in many of the tests. My RR501 with date code 9A04
always waited for a clear line before sending - I never saw this type
lock-up with it and I did a lot of testing of its collision avoidance.
Dave Houston
at SmartHome who blamed the SwitchLinc Lite problems on non-standard timing
from CM11A fast macros.
My 'scope is an ISA card in my PC. It's super handy but has limitations for
chasing things like this. It's tough to get it to trigger at a time that
will capture the gap.
When I get some time to spend on this, I'll write some BX-24 code to
interface with my sample TR-1A and record some powerline bit patterns.
Dan Lanciani
| RR501s and TM751s on the other hand, show a
| 3.5 cycle gap between commands. You need a 'scope to see this, since the
| Monterey PLSA is happy with 3 or more cycles of gap and doesn't report
| anything wrong.
Just curious: are you suggesting that it should report something wrong, i.e.,
that anything over 3 isn't ok?
| Anyway, the 3.5 cycle gap wreaks havoc with the SwitchLinc
| lites. The SwitchLinc's error rate receiving commands with 3.5 cycle gaps can
| be as bad as 50%.
Interesting. I wonder if the problem is that they don't like an odd number
of zero crossings?
Dan Lanciani
ddl@danlan.*com
Ray Melnik
We installed an xpcp coupler and it did the trick. Inexpensive and easy to
install
In order to install x10 devices in various outlets throughout the house we
had an XPCP passive signal coupler installed. The X-10 Pro passive signal
coupler (XPCP) is designed to couple X-l0 power line carrier signals from
one phase to another. The coupler is installed from one phase to another in
the breaker panel. The unit may be used in single (split-phase) or three
phase installations.
Ray Melnik
http://www.newtechnologyhome.com
"Roger" <NO_SPAMr...@worldnet.att.net> wrote in message
news:s5BV6.78996$4f7.6...@bgtnsc06-news.ops.worldnet.att.net...
John Galvin
Could there have been changes to the CM11A firmware that now make it 3 cycle
compliant? I suppose that the 3.5 cycle gaps on the TM751 and RR501 could be
described as "non-standard", even if not illegal spec-wise. I know that,
using a controller that allows sending discrete addr and command, the
SwitchLinc lites work fine. In that case, the inter-command gap is a lot
longer than 3 cycles.
John Galvin
Dave Houston wrote in message <3b2cf78e...@nntp.fuse.net>...
John Galvin
Dan Lanciani wrote in message <918...@news1.IPSWITCHS.CMM>...
>In article <gzRW6.117562$qv3.36...@nnrp5-w.sbc.net>,
lgalvin...@pacbell.net (John Galvin) writes:
>
>| RR501s and TM751s on the other hand, show a
>| 3.5 cycle gap between commands. You need a 'scope to see this, since the
>| Monterey PLSA is happy with 3 or more cycles of gap and doesn't report
>| anything wrong.
>
>Just curious: are you suggesting that it should report something wrong, i.e.,
>that anything over 3 isn't ok?
>
No, I was just a little dissapointed at not being able to see how many cycles
of gap there is. Even in signal dissect mode, the gaps are ignored.
>| Anyway, the 3.5 cycle gap wreaks havoc with the SwitchLinc
>| lites. The SwitchLinc's error rate receiving commands with 3.5 cycle gaps
can
>| be as bad as 50%.
>
>Interesting. I wonder if the problem is that they don't like an odd number
>of zero crossings?
>
I had thought of that, but 'scoping an IR543's transmissions shows that
addresses and commands start, arbitrarily on positive or negative zero
crossings. That is, sending a discrete "A1" may start on a positive zero
crossing, but when the user gets around to pressing "on", to send the "AON",
that may start on a positive OR negative zero crossing. So, in that case, the
SwitchLinc can see an odd number of zero crossings between addr and command.
The SwitchLincs lites that I have, work very reliably with the IR543. I
suspect that SwitchLinc's firmware is doing something that blinds it to
commands with 3.5 (and maybe other) cycle gaps, but that after enough cycles
of gap, it will behave properly again.
John Galvin
John Galvin
Dave Houston wrote in message <3b2bf0ea...@nntp.fuse.net>...
>It would help to know what's actually happening between the BBk and g4. I'm
>of the opinion that the BSC report from the Monterey is essentially
>meaningless. It's impossible to define a "bad start code" without making
>several assumptions. A start code is 1110 and that's really all that can be
>said about start codes with any certainty. I really hope that Iriave does
>build an SMD version of their TR-1A so we can have a diagnostic device to
>record each bit for analysis.
>
I think that in order to get a BSC, the Monterey must have seen a minimum of 3
cycles of gap, else it would report BCY (bad 3 cycle gap). After that, it's
looking for 1110 and anything else it finds, is labeled as a BSC. The BBk
actually conveys a little more information, as this is described as a good
start code, followed by either the two eleven bit blocks of the code are not
identical, or a true bit and it's complementary bit in a block are not
opposite. Reading through the manual some more, the lower case "g" signifies
that only one good start code and one good block (of the two identical blocks)
was received.
Based on those descriptions, here's what appears to have occurred:
G4 .49V from the RR501
GON .49V from the RR501
BBk .52V the RR501 got the first startcode of a GDIM out, but the HouseLinc
unimpressively clobbered it, with it's own G4. Note the higher amplitude.
BSC .36V here the RR501 recognized the collision and has stopped trying to
transmit. Note the lower amplitude.
BSC .36V only the HouseLinc is sending at this time, but the Monterey is
looking for a
BSC .36V valid start code in the middle of the HouseLinc's "G4"
BSC .36V
g4 .37V the Monterey found the startcode from the second G4 block and
properly recognized "G4"
GON .36V all is well on the powerline, GON received properly by all.
The mystery here, is why the RR501 locked up, upon detecting the collision.
The Monterey does only goes so far, in helping to figure out what all is going
on in these situations. What I really need to do, is to drag home the DSO
that I have at work, in order to shed some real light on what is happening.
That one is 16 megasamples deep.
J.G.
Dave Houston
That's always a possibility but, since I've never measured the gaps with any
of the transmitters, I won't speculate. As soon as I can finalize a few more
things for the BX24-AHT, I'll breadboard a powerline bit recorder and check
the gaps on my assembly of transmitters.
The X-10 documentation only says there "should" be at least a 3 cycle gap to
reset a receiver from Dim to Bright. According to Phil Kingery, X-10 uses a
two cycle gap in some repeaters. And nothing pdohibits more than three.
Dave Houston
You illustrate one of my concerns about what the Monterey defines as a BSC.
If you look at the last screenshot in "Recording the X-10 powerline
bitstream" on my web page, you can see a valid start code preceded by a "1".
And it's easy to imagine 1110 occuring due to noise, collisions, etc.
Calling all of them BSCs is making a lot of assumptions.
In your analysis, it appears that the RR501 was the muggee not the mugger. I
don't know exactly how the RR501 deals with collisions. My tests indicated
that it practiced polite avoidance - waiting for a clear line before sending
but what it would do if it then collided with an impolite transmitter was
unclear. I made a note to test this at some later date. (I have lots of
those kind of notes.) My guess is that it does not have collision detection
once it starts to transmit.
At about the time the current CM11A firmware, the LM14A, and the collision
avoiding RR501 were introduced, Dave Rye wrote an article describing how
collision avoidance was implemented with multiple LM14As. You can find it in
the HomeToys archives. Whether any of it applies to the RR501, I do not
know.
John Galvin
Dave Houston wrote in message <3b2df515....@nntp.fuse.net>...
>John,
>
>You illustrate one of my concerns about what the Monterey defines as a BSC.
>If you look at the last screenshot in "Recording the X-10 powerline
>bitstream" on my web page, you can see a valid start code preceded by a "1".
>And it's easy to imagine 1110 occuring due to noise, collisions, etc.
>Calling all of them BSCs is making a lot of assumptions.
>
Yes, I agree that calling something a BSC is very ambiguous. It takes a
pretty thorough knowledge of the X-10 protocol, to sort out what it really is,
in many cases. Monterey Instruments themselves concede and I concur, that
BSCs are recorded quite often, due to noise. They're saying that the most
common BSCs are due to noise showing up on one zero crossing, but not the
next. If the Monterey was in the idle state and that happens, it records as a
BSC. In the case I cited below, we can infer that those BSCs are not due to
noise.
>In your analysis, it appears that the RR501 was the muggee not the mugger. I
>don't know exactly how the RR501 deals with collisions. My tests indicated
>that it practiced polite avoidance - waiting for a clear line before sending
>but what it would do if it then collided with an impolite transmitter was
>unclear. I made a note to test this at some later date. (I have lots of
>those kind of notes.) My guess is that it does not have collision detection
>once it starts to transmit.
I'm not sure, but I think that it might have collision detection. The reason
I say that, is because, in that test, I held the dim button down. So the
RR501 should have been sending out a continuous stream of GDIM commands. Once
the collision began, the RR501 appears to stop transmitting. From that, I
would think that the RR501 must have seen the collision and reacted to it.
Perhaps there is a firmware bug that locks up the RR501 under certain
collision conditions. The more I think about it, the more plausible that
seems. The RR501 has to keep on receiving the incoming DIMs from the RF
receiver, even once it's had to back off from sending them over the power
line. Somewhere in the firmware, how this special case is handled, may not be
quite right.
>
>At about the time the current CM11A firmware, the LM14A, and the collision
>avoiding RR501 were introduced, Dave Rye wrote an article describing how
>collision avoidance was implemented with multiple LM14As. You can find it in
>the HomeToys archives. Whether any of it applies to the RR501, I do not
>know.
>
Yes, I remember reading that article. I think I'll go back and read it again,
as I don't remember if there was a description of retries upon collision
detection, or not.
J.G.
Dave Houston
I still think a tool to record each powerline bit to a hard disk is needed
(as well as a tool to send exact bit patterns). I have everything needed to
make one - except for time.
Roger
As you might guess, I got nowhere. The instant he found out the it was
controlled by a wireless control, he said contact that company, Leviton
doesn't sell or support wireless controllers.
On the HD11 problem with executing macros, again contact that manufacturer.
He gave no glimmer of any repeater problems. Was very short and offered no
help.
This may not be the proper thread, but it looks like some knowledgeable
people here,
1) What are some internet sites that provide some good technical
descriptions of the X-10 protocols and the like?
2) What type of controllers/micros are used in the transceiver?
I've got a lot of projects in the fire, but would like to investigate this
problem some more.
Roger
--------------
Please remove NO_SPAM from my email address if replying directly to me.
> Leviton is in a great position to determine the exact cause. Moreover,
Dave Houston
>I gave Leviton technical support a call this past Friday.
>As you might guess, I got nowhere. The instant he found out the it was
>controlled by a wireless control, he said contact that company, Leviton
>doesn't sell or support wireless controllers.
>On the HD11 problem with executing macros, again contact that manufacturer.
>He gave no glimmer of any repeater problems. Was very short and offered no
>help.
>
>This may not be the proper thread, but it looks like some knowledgeable
>people here,
>
>1) What are some internet sites that provide some good technical
>descriptions of the X-10 protocols and the like?
I have links to the X-10 documentation on my web page.
>2) What type of controllers/micros are used in the transceiver?
I think all of the current X-10 modules use PICs but I'm not sure what you
mean by "transceiver"? The RR501 & TM751 use a PIC16C54A.
---
Roy L.
PR-511 in my installation and it worked flawlessly until I added the
HCA-02. Shutting off either the repeater or the floodlights will
effectively interrupt the endless feedback loop. Funny, though, the
problem is truly a "tough dog" in that when I want it to happen it
won't.
Roy.
t...@worthdist.com
with just the HCA repeater not with another PR511 through the
repeater. Thanks for the input, every little bit helps.
Tom Morgan
Dave Houston
is an HCA repeater but no PR511?
t...@worthdist.com wrote:
---
t...@worthdist.com
the lockups. If the repeater or PR511's are turned off it stops. A
repeater can not initiate signal except in test mode (this happens
with the 6201 as well and it does not have a test mode). Since it
only repeats, it acts like hitting a tennisball against a backboard.
In all likelihood there is something in the repeater the PR511's does
not like causing a 'perceived' collision. A very poor retry system in
the PR511 endlessly sends the same signal causing the same collision
over and over again. If a design flaw in the PR511's was not involved
it would have a random wait and retry system and a maximum retry.
With X10's 'value engineering' it is not suprising neither of these
are included. When it is determined what causes the PR511/HCA
conflict to occur we may fix the CM11A issue at the same time. Fix
one issue then move to the next.
Attacking the CM11A is more difficult because there are more
variables. Is the issue in the CM11A, HCA, or software? We have far
more issues with ActiveHome software then, say, HomeSeer. When a 3rd
variable is involed is the CM11A still in spec? Who says even the
PR511's are in spec? When reducing the issue down to only 2 items it
makes the job much easier.
On Mon, 18 Jun 2001 15:39:38 GMT, dhou...@fuse.net (Dave Houston)
wrote:
Dave Houston
There have been several scenarios reported with similar symptoms but with
varying hardware where the ONLY common denominator seems to be the HCA02.
AFAIK, the CM11A does NOT automatically retransmit after collisions. There
is NO software involved with CM11A fast macros - only the CM11A firmware.
One individual is using NO controlling software and has NO PR511s. He is
using RF remotes and transceivers. He is only using HomeSeer to log what the
CM11A sees on the powerline. Unfortunately, the CM11A only reports valid
activity so there may be other powerline activity that is being missed.
I do not have a PR511 so cannot be sure but this is the first I've heard
that it has collision detection and automatic retransmission. I would think
we would have seen reported problems between the PR511 and other controllers
if the PR511 was misbehaving.
As for "in spec", I agree with Dan Lanciani who says, "X-10 is as X-10
does." Well, actually, I'm putting words in Dan's fingers but I think he
would agree that this captures the gist of what he writes on the topic of
X-10 specs.
Malcolm Blackhall
Isn't the Leviton 6417 basically a relabelled PR511 or are there differences
in the firmware? If the firmware is the same, then I wouldn't blame X-10
for any problem when the PR511 and HCA02 are used in the same system.
Leviton should have been familiar with the way their own motion detector
worked and made the HCA02 behave properly with it, and therefore the PR511.
Even if the firmware is different, I don't think I would blame X-10. Surely
Leviton knew that many HCA02s would be used in systems with PR511s and could
have tried to designed the HCA02 to work properly with them or at least
noted that they were incompatible with them in their sales literature and
packaging.
I think I would only blame X-10 if they designed and built the HCA02 for
Leviton. Did they?
t...@worthdist.com
<blac...@midtown.net> wrote:
>Assuming there is a problem using the PR511 and HCA02 in the same system...
>
>Isn't the Leviton 6417 basically a reliable PR511 or are there differences
>in the firmware?
They are 100% identical with the exception of the silk screen
If the firmware is the same, then I wouldn't blame X-10
>for any problem when the PR511 and HCA02 are used in the same system.
>Leviton should have been familiar with the way their own motion detector
>worked and made the HCA02 behave properly with it, and therefore the PR511.
Conceptually I agree. Being an OEM product doesn't make it right that
Leviton doesn't know why it happens but it does explain why they don't
know the innards as well as they know the HCA. It is not as if the
lockup issue occurs immediately. It is very random and there are
many, many PR511 installations that don't show the issue at all. If
we determine the cause or at least give some clue as to how to
duplicate it I am certain it would be fixed. Nobody has been able to
do this.
>
>Even if the firmware is different, I don't think I would blame X-10. Surely
>Leviton knew that many HCA02s would be used in systems with PR511s and could
>have tried to designed the HCA02 to work properly with them or at least
>noted that they were incompatible with them in their sales literature and
>packaging.
>
Firmware is the same. You can only fix what you know to be broken. I
don't argue that there is an issue. I don't even think Leviton will
argue there is an issue. You can only fix what you can replicate. I
have not been able to find precisely what it is. Because of the
'randomness' I start to think it is related to timing. As a favor
Damon looked at the timing even closer and it is dead on according to
the X-10 specifications. There have been no studies of the PR511's
that I am aware of. I have asked for 2 units to be sent to be so I
can setup some collision scenarios. Anyone know what pins to short so
it believes motion was detected?
This 'The PR511 was first' argument is a cop out. Unless the 'fun' of
this newsgroup is to complain it is a futile argument. It does
nothing so help cure the issue. Do you think Leviton intentionally
set out to make a repeater that does not like fast macros or PR511's?
Certainly not. At the same time of the 1,000 that were made we have
sold 760. 5 have been returned to Leviton. 2 of which were lighting
strikes. Hard to raise too much hell with engineering when better
then 99% of all customers are happy. That doesn't mean it's right or
that they don't care. It is hard to justify the expense of pulling a
full time engineer to chase a random phantom without any hard evidence
of what the cause is. The HCA is in spec. There may be some issues
with certain devices. These issues are random and occur without
explanation. If we had explanation they would get fixed. This does
not occur with 16400's, Lightolier, ACT transmitters. Why? Doesn't
that bring X-10 'value engineering' into play. Let's focus on the
cause and I am happy to work with Leviton engineering for a solution.
>I think I would only blame X-10 if they designed and built the HCA02 for
>Leviton. Did they?
David Shaw
> On Tue, 19 Jun 2001 15:00:58 -0700, "Malcolm Blackhall"
> <blac...@midtown.net> wrote:
>
> >Assuming there is a problem using the PR511 and HCA02 in the same system...
> >
> >Isn't the Leviton 6417 basically a reliable PR511 or are there differences
> >in the firmware?
>
> They are 100% identical with the exception of the silk screen
I was under the impression the PR511 and 6417 were the same hardware
more or less, but their firmware is definitely different.
The PR511 can send an on/off command for dawn and dusk which the 6417
can't do. The 6417 sends a hail command every few seconds when it
detects motion to trip all the other 6417s on the same house and unit
code, which the PR511 can't do.
David
--
David Shaw | dshaw at jabberwocky dot com | WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
"There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence." - Jeremy S. Anderson
t...@worthdist.com
amazing how looking at this stuff for so long you accept things as
fact that really are not. Glad we did not bet, I probably would have
lost the house.
This raises an awesome question. Has a confirmed lockup ever occurred
with a 6417?
Tom Morgan
Dan Lanciani
| Not overlooked at all. 2 different issues. The PR511 is initiating
| the lockups.
Even if it is initiating the exchange (possibly with a perfectly valid
packet), this is not the same as "initiating the lockups."
| If the repeater or PR511's are turned off it stops. A
| repeater can not initiate signal except in test mode (this happens
| with the 6201 as well and it does not have a test mode).
You are again assuming that the repeater is working correctly in order to
prove that it is working correctly. Since other repeaters (ACT, the _original_
6201) do not exhibit this problem there must be something wrong with the new
repeater. (See, I can do the false logic thing too. :)
| In all likelihood there is something in the repeater the PR511's does
| not like causing a 'perceived' collision.
I agree that the repeater is doing something wrong that the PR511 and other
devices do not like.
| A very poor retry system in
| the PR511 endlessly sends the same signal causing the same collision
| over and over again.
There is no evidence that the PR511 has a poor retry system. I did however
just make some tests and the PR511 (I tried a very old one and a new-in-the-
box one from a few months ago) does wait for a clear line before transmitting.
Combining this with my previous observations about its collision behavior (i.e.,
it doesn't seem to try to do anything stupid to recover) I'd say it has a pretty
good 2-way implementation considering its vintage.
Do note that Leviton has a version of the PR511 with modified firmware that
uses hail acknowledge to keep lights on the same unit code on while any senses
motion. This version has been reported to cause problems with other X10 devices.
| If a design flaw in the PR511's was not involved
| it would have a random wait and retry system and a maximum retry.
This statement doesn't make any sense at all.
| With X10's 'value engineering' it is not suprising neither of these
| are included.
You keep talking about X10's value engineering in a negative tone but there
is ample evidence that X10 has done a pretty good job trading off cost and
functionality. Now if you want to talk about bad value engineering, let's
consider Leviton's previous repeater offering (the new 6201) that requires
a specific power-up sequence(!). They probably saved themselves a buck or
two on production costs at the expense of making a product which cannot be
depended on in any realistic residential environment.
| Attacking the CM11A is more difficult because there are more
| variables. Is the issue in the CM11A, HCA, or software? We have far
| more issues with ActiveHome software then, say, HomeSeer.
Before spending too much time attacking this problem, consider applying
Occam's Razor. You have introduced a new and unknown quantity (the HCA02)
to several environments with various other X10 components. Problems appear
with (at least) any of the PR511, the CM11a, and some unspecified X10 RF
product. Some of these X10 components have been around for more than a decade
and their behaviors, while not always perfect, are reasonably well understood.
The products span a range of implementation technologies with no obviously
common attributes (other than being from X10). The complicated explanation
is that the HCA02 has uncovered a bug or bugs in all of these existing products.
The simple explanation is that the HCA02 has a bug. Occam says to prefer the
simple explanation, and I have found Occam to be right more often than not.
| When a 3rd
| variable is involed is the CM11A still in spec? Who says even the
| PR511's are in spec?
The CM11a and the PR511 are in spec by definition. The X10 protocol is defined
by the behaviors of X10's products. Welcome to the world of proprietary
protocols. There are no standards documents or committees to appeal to. And
even though X10 may have disclosed some aspects of the protocol by telling us
how third-party products should behave, they are not bound to follow those
practices themselves. This is X10's sandbox. If you want to play in it you
have to play by their rules.
Dan Lanciani
ddl@danlan.*com
Dan Lanciani
| On Tue, 19 Jun 2001 15:00:58 -0700, "Malcolm Blackhall"
| <blac...@midtown.net> wrote:
|
| >Assuming there is a problem using the PR511 and HCA02 in the same system...
| >
| >Isn't the Leviton 6417 basically a reliable PR511 or are there differences
| >in the firmware?
|
| They are 100% identical with the exception of the silk screen
This is not true. As I posted previously, Leviton has modified the firmware
to support a multi-unit setup where motion seen by any keeps all on. There
have been reports here of serious problems with the 6417 when it is used with
other X10 components. Hmm, sounds familiar...
| This 'The PR511 was first' argument is a cop out.
How so?
| Unless the 'fun' of
| this newsgroup is to complain it is a futile argument. It does
| nothing so help cure the issue.
But it helps keep to focus on the real problem... Although you say that
you are trying to understand the problem, your posts come across more as a
condemnation of X10's products and an attempt to shift the blame away from
Leviton.
| Do you think Leviton intentionally
| set out to make a repeater that does not like fast macros or PR511's?
No, but like many third-party vendors of supposedly X10-compatible equipment
they didn't bother to do the necessary work to get it right.
| It is hard to justify the expense of pulling a
| full time engineer to chase a random phantom without any hard evidence
| of what the cause is.
As an engineer, I spend a lot of time chasing such things in order to *get*
the hard evidence. Didn't Damon say that Leviton would be happy to fly an
engineer to the site of anybody having a problem with the repeater? Well, we
have several people here with a problem. Are any of you willing to host the
engineer?
| The HCA is in spec.
Can you provide a pointer to this "spec."
Dan Lanciani
ddl@danlan.*com
Dave Houston
>In article <3b2f4189....@news.rdu.bellsouth.net>, t...@worthdist.com writes:
[...]
>| A very poor retry system in
>| the PR511 endlessly sends the same signal causing the same collision
>| over and over again.
>
>There is no evidence that the PR511 has a poor retry system. I did however
>just make some tests and the PR511 (I tried a very old one and a new-in-the-
>box one from a few months ago) does wait for a clear line before transmitting.
>Combining this with my previous observations about its collision behavior (i.e.,
>it doesn't seem to try to do anything stupid to recover) I'd say it has a pretty
>good 2-way implementation considering its vintage.
From this, can we take it that the X-10 PR511 does not automatically
retransmit after a collision? IOW, is there any evidence that the PR511 has
_any_ retry system (whether poor or affluent)? If all it does is wait
politely for a clear line before transmitting, then its even less likely
that it is contributing to any transmission "storm".
I know this is remote but could the HCA02 be confusing the PR511 into
sending a Status response?
Roy L.
I would be very happy to "host" a Leviton engineer to come and figure
out why the HCA02 doesn't like my PR-511. However, when I posted this
same reply to Damon, I never got a response. From my interactions
with Leviton, I would eat my hat if they would "fly an engineer" over
to my house.
(Actually, they would only have to drive over from Long Island, NY, as
I live in Rockland County, NY) ;)
Roy
t...@worthdist.com
wrote:
>ddl@danlan.*com (Dan Lanciani) wrote:
Interesting thought. There is no evidence for or against any type of
collision detection in the PR511's or 6417's. I have not had an
opportunity to try it myself and nobody else seems to know. If the
HCA02 is somehow making the spotlights perceive a status request the
endless loop could be triggered.
The only part that doesn't make sense is why it does not Lightolier,
which responds to hail, and status request. The only though is the
fact that I know Lightolier has 4 wait states before retry when a
collision is detected.
Now that I think of it, does anyone have any transmission logs from
during a lockup. I have only witnessed one with a Monterey and I
didn't think to run the log at the time (3 years ago with a 6201).
Monterey shows endless streams of BSC's and BBK's if I remember
correctly. A TW523 or CM11A would act as a filter to see what actual
traffic appears. Thanks for the input
>
>---
>BX24-AHT All Housecode Transceiver is at:
>http://www.laser.com/dhouston/
Tom Morgan
t...@worthdist.com
>
>This is not true. As I posted previously, Leviton has modified the firmware
>to support a multi-unit setup where motion seen by any keeps all on. There
>have been reports here of serious problems with the 6417 when it is used with
>other X10 components. Hmm, sounds familiar...
You are correct; they are not the same (boy Crow tastes horrible!).
They are both made by X10. The Leviton version does have a different
feature set. Not a surprise at all that issues are reported because
the designs are certainly similar.
>
>| This 'The PR511 was first' argument is a cop out.
>
>How so?
Just because it is first does not make it good or well designed. A
coupler repeater is the most difficult item to design in the entire
transmission chain. Because of the critical timing it is imperative
that every other item in the system have the same timing. Just
because it was first does not make it a good product and certainly
does not make it a quality product.
>
>| Unless the 'fun' of
>| this newsgroup is to complain it is a futile argument. It does
>| nothing so help cure the issue.
>
>But it helps keep to focus on the real problem... Although you say that
>you are trying to understand the problem, your posts come across more as a
>condemnation of X10's products and an attempt to shift the blame away from
>Leviton.
Honestly, I could care less who is to blame. It is a complete waist
of everyone's time to point fingers. Finding a solution is worth the
effort. There is no attempt to shift blame, only present other
possibilities.
>| Do you think Leviton intentionally
>| set out to make a repeater that does not like fast macros or PR511's?
>
>No, but like many third-party vendors of supposedly X10-compatible equipment
>they didn't bother to do the necessary work to get it right.
"Didn't bother" tad harsh? Yes they did "bother" to test for
compatibility. That is why 99% of all HCA repeaters are in the field
today providing reliable, stable X-10 installations. We are not
talking about issues like other products on this newsgroup that have a
complete disregard for the way X10 transmissions are sent. We are
talking about a highly intermittent issue with a select few products.
Does that mean it is ok that there are issues with those products?
No, not at all but it is ridiculous to say they did not bother to
test. How many X-10 based products are there in existence?
>| It is hard to justify the expense of pulling a
>| full time engineer to chase a random phantom without any hard evidence
>| of what the cause is.
>
>As an engineer, I spend a lot of time chasing such things in order to *get*
>the hard evidence. Didn't Damon say that Leviton would be happy to fly an
>engineer to the site of anybody having a problem with the repeater? Well, we
>have several people here with a problem. Are any of you willing to host the
>engineer?
Unless the lockup can be duplicated it is a big waist of time and
expense. If it can be duplicated I think the response would be
different. And by the way, Damon has been out in the field evaluating
troublesome installations. The performance has been excellent.
Dave Houston
[...]
>
>Now that I think of it, does anyone have any transmission logs from
>during a lockup. I have only witnessed one with a Monterey and I
>didn't think to run the log at the time (3 years ago with a 6201).
>Monterey shows endless streams of BSC's and BBK's if I remember
>correctly. A TW523 or CM11A would act as a filter to see what actual
>traffic appears. Thanks for the input
Don't get me started on Monterey BSCs! ;) I regard them as disinformation.
The TW523 will not report all traffic. And the CM11A will only report
"valid" X-10 commands. Neither are a good candidate for this type of
troubleshooting where you really need to see the full powerline bitstream.
The PowerLinc allows sending arbitrary bitstreams but does has no mode to
report the full powerline bitstream. If SmartHome would add such a mode, it
could be used to troubleshoot problems like this.
I have just heard from Iriave Electronics. They are going to offer a TR-2A
which will be like their TR-1A but with a 120KHz generator and demodulator
built-in. This will allow for a simple, digital interface with a Stamp,
BX-24, or even a PC. It will pass ALL bits and, if it honors its TR-1A
heritage, have 5mV sensitivity & 5V output. I've asked them to add an ADC
output proportional to received powerline signal level. They did not say
when it will be available or what it will cost. If no HA distributor will
stock them, I'll find a way to stock them for the DIY crowd. It will make
troubleshooting this type of problem a piece of cake.
t...@worthdist.com
>| the lockups.
>
>Even if it is initiating the exchange (possibly with a perfectly valid
>packet), this is not the same as "initiating the lockups."
If it is in a constant retry mode it is initiating the lockup. Or, as
suggested it could be responding to a status request. Either way it
is a message based issue where both components need each other for the
lockup to continue. It is not a case of the repeater going to sleep
or sending endless junk. It is an interaction between the two
devices.
>
>| If the repeater or PR511's are turned off it stops. A
>| repeater can not initiate signal except in test mode (this happens
>| with the 6201 as well and it does not have a test mode).
>
>You are again assuming that the repeater is working correctly in order to
>prove that it is working correctly. Since other repeaters (ACT, the _original_
>6201) do not exhibit this problem there must be something wrong with the new
>repeater. (See, I can do the false logic thing too. :)
Actually, the 6201 does it to. My last house had it happen and it
nearly effected the sale of the house. I have a strong interest in
seeing this issue squashed.
>
>| In all likelihood there is something in the repeater the PR511's does
>| not like causing a 'perceived' collision.
>
I agree that the repeater is doing something that the PR511 and other
devices do not like. That leaves 3 possibilites. Defective devices,
defective HCA, or an incompatibility caused by both items and how they
interact. I do not believe the HCA is ruled out as the culprit in any
way. I want to make certian that all items are suspect.
>
>| A very poor retry system in
>| the PR511 endlessly sends the same signal causing the same collision
>| over and over again.
>
>There is no evidence that the PR511 has a poor retry system. I did however
>just make some tests and the PR511 (I tried a very old one and a new-in-the-
>box one from a few months ago) does wait for a clear line before transmitting.
>Combining this with my previous observations about its collision behavior (i.e.,
>it doesn't seem to try to do anything stupid to recover) I'd say it has a pretty
>good 2-way implementation considering its vintage.
Here is the $1,000,000 question. Does it have a retry system at all?
If not, can we assume then the PR511's must think they are being asked
for status? How else could the loop start?
>
edit..
>
>You keep talking about X10's value engineering in a negative tone but there
>is ample evidence that X10 has done a pretty good job trading off cost and
>functionality.
I do not agree. False tripping for 22 years is long enough to get it
corrected. That is just one example of 'value engineering' that gives
X-10 a bad name. No need to dwell on this further.
Now if you want to talk about bad value engineering, let's
>consider Leviton's previous repeater offering (the new 6201) that requires
>a specific power-up sequence(!). They probably saved themselves a buck or
>two on production costs at the expense of making a product which cannot be
>depended on in any realistic residential environment.
And guess who made that power suppy design.... X10. That is why
Leviton now makes many items themselves and expect to see more self
manufactured Leviton DHC items.
>
>| Attacking the CM11A is more difficult because there are more
>| variables. Is the issue in the CM11A, HCA, or software? We have far
>| more issues with ActiveHome software then, say, HomeSeer.
>
>Before spending too much time attacking this problem, consider applying
>Occam's Razor. You have introduced a new and unknown quantity (the HCA02)
>to several environments with various other X10 components. Problems appear
>with (at least) any of the PR511, the CM11a, and some unspecified X10 RF
>product. Some of these X10 components have been around for more than a decade
>and their behaviors, while not always perfect, are reasonably well understood.
>The products span a range of implementation technologies with no obviously
>common attributes (other than being from X10). The complicated explanation
>is that the HCA02 has uncovered a bug or bugs in all of these existing products.
>The simple explanation is that the HCA02 has a bug. Occam says to prefer the
>simple explanation, and I have found Occam to be right more often than not.
Fine, explain the bug and we have a simple solution.
>
>| When a 3rd
>| variable is involed is the CM11A still in spec? Who says even the
>| PR511's are in spec?
>
>The CM11a and the PR511 are in spec by definition. The X10 protocol is defined
>by the behaviors of X10's products. Welcome to the world of proprietary
>protocols. There are no standards documents or committees to appeal to. And
>even though X10 may have disclosed some aspects of the protocol by telling us
>how third-party products should behave, they are not bound to follow those
>practices themselves. This is X10's sandbox. If you want to play in it you
>have to play by their rules.
X10's 'sandbox' contains products with no direct dim, false tripping,
no scenes, and a coupler repeater with power on sequence problems. I
choose to use professional soultions. When X10 hobbiest items are
avoided the technology is rock solid. With very few exceptions X10
does not offer professional soultions. It is a hobbiest company with
hobbiest solutions. They are value engineered for maximum sales
numbers and the philosphy that most people will not bother to return
and item if it does not work or it fails after a year. It was only
$10 anyways. I am certian this is a sound, profitible business plan.
That I can defend, there engineering I can't.
>
> Dan Lanciani
> ddl@danlan.*com
t...@worthdist.com
BSC's do appear to occur without any such issue being acknowleged in
the system. In other words Monterey says BSC's but everything works
great. (were they really there?).
Extended code is not properly supported. The signal strength of the
original signal is shown, not the strength to the repeated signal.
Repeated dim commands show as BSC. Take the idential transmission but
plug in where original and repeated signal can be sampled and it works
fine.
It is darn good but certianally not perfect.
>
>Don't get me started on Monterey BSCs! ;) I regard them as disinformation.
>
>The TW523 will not report all traffic. And the CM11A will only report
>"valid" X-10 commands. Neither are a good candidate for this type of
>troubleshooting where you really need to see the full powerline bitstream.
>The PowerLinc allows sending arbitrary bitstreams but does has no mode to
>report the full powerline bitstream. If SmartHome would add such a mode, it
>could be used to troubleshoot problems like this.
>
>I have just heard from Iriave Electronics. They are going to offer a TR-2A
>which will be like their TR-1A but with a 120KHz generator and demodulator
>built-in. This will allow for a simple, digital interface with a Stamp,
>BX-24, or even a PC. It will pass ALL bits and, if it honors its TR-1A
>heritage, have 5mV sensitivity & 5V output. I've asked them to add an ADC
>output proportional to received powerline signal level. They did not say
>when it will be available or what it will cost. If no HA distributor will
>stock them, I'll find a way to stock them for the DIY crowd. It will make
>troubleshooting this type of problem a piece of cake.
>---
>BX24-AHT All Housecode Transceiver is at:
>http://www.laser.com/dhouston/
Tom Morgan
John Galvin
t...@worthdist.com wrote in message
<3b30b442....@news.rdu.bellsouth.net>...
>Funny you should mention the Monterey. I have found several issues:
>
>BSC's do appear to occur without any such issue being acknowleged in
>the system. In other words Monterey says BSC's but everything works
>great. (were they really there?).
>
I don't know what you mean by "without any such issue being acknowledged in
the system". To what system are you referring? I don't really see any reason
why the typical HA controller should report a BSC. The only action that
should be taken, is for the controller to continue to look for a legitimate
start code.
As I stated previously from the Monterey's manual, a BSC simply means that
while in the idle state, a "1" was detected on one zero crossing, but not on
the following cycle. This is commonly caused by noise (look at the
amplitude). The Monterey will apparently, enter the "idle" state following a
BBk or other such problem condition and does not look for the required 3 cycle
gap, before looking for a start code. This is a reasonable design decision.
If there is a collision on the first 11 bit frame that results in BBk or
whatever, you don't want to revert to looking for a 3 cycle gap, else you will
miss the second 11 bit frame that may very well have a perfectly clean signal.
While the Monterey is wading through the collision, it has no choice but to
report BSCs even though it has not recognized a proper 3 cycle gap.
>Extended code is not properly supported. The signal strength of the
>original signal is shown, not the strength to the repeated signal.
>
>Repeated dim commands show as BSC. Take the idential transmission but
>plug in where original and repeated signal can be sampled and it works
>fine.
>
Perhaps the Monterey is confused by the 2 cycle gap between dims that occur
when an X-10 designed repeater is repeating dims. Although I would have
expected this to show up as BCYs and not BSCs. This points out a significant
diagnostic weakness in the Monterey. That is, it does not directly tell the
user much of anything about the gaps, not even in signal dissect mode.
J.G.
Dan Lanciani
| ddl@danlan.*com (Dan Lanciani) wrote:
|
| >In article <3b2f4189....@news.rdu.bellsouth.net>, t...@worthdist.com writes:
|
| [...]
|
| >| A very poor retry system in
| >| the PR511 endlessly sends the same signal causing the same collision
| >| over and over again.
| >
| >There is no evidence that the PR511 has a poor retry system. I did however
| >just make some tests and the PR511 (I tried a very old one and a new-in-the-
| >box one from a few months ago) does wait for a clear line before transmitting.
| >Combining this with my previous observations about its collision behavior (i.e.,
| >it doesn't seem to try to do anything stupid to recover) I'd say it has a pretty
| >good 2-way implementation considering its vintage.
|
| From this, can we take it that the X-10 PR511 does not automatically
| retransmit after a collision?
I'm not prepared to say for sure without making some more difficult tests.
On the other hand, I'm not sure I see the point of making such tests by
themselves. If I find that the PR511 does retransmit in any kind of
collision situation that will be taken as proof that it is at fault. I
might consider looking at it as part of a test of the HCA.
| IOW, is there any evidence that the PR511 has
| _any_ retry system (whether poor or affluent)? If all it does is wait
| politely for a clear line before transmitting, then its even less likely
| that it is contributing to any transmission "storm".
That would be my expectation based on my uneventful use of a number of PR511s
for years. As you know, I tend to notice these kinds of problems quickly and
post about them loudly and in great detail. :) Most manufacturers (with the
notable exception of ACT) lack the confidence in their products required to
want me to test them. :( Unfortunately for them I still buy some of their
products that I actually need and find the bugs in those. :)
| I know this is remote but could the HCA02 be confusing the PR511 into
| sending a Status response?
I guess anything is possible. It certainly wouldn't be hard to find out.
Even with only high-level monitoring equipment logging good packets you should
see the final status response in the log after you kill the power to the
repeater. (I assume that anyone who is serious about X10 testing logs
everything all the time as I do. But even if you don't, you can always start
the logging process before you kill the power.) Of course, all this speculation
is great fun, but the obvious way to get to the bottom of the problem is to
ask one of us here to analyze the effect.
Dan Lanciani
ddl@danlan.*com
Dan Lanciani
| >| They are 100% identical with the exception of the silk screen
| >
| >This is not true. As I posted previously, Leviton has modified the firmware
| >to support a multi-unit setup where motion seen by any keeps all on. There
| >have been reports here of serious problems with the 6417 when it is used with
| >other X10 components. Hmm, sounds familiar...
|
| You are correct; they are not the same (boy Crow tastes horrible!).
| They are both made by X10. The Leviton version does have a different
| feature set. Not a surprise at all that issues are reported because
| the designs are certainly similar.
No, you misunderstood. The reported problems are unique to the version with
Leviton's modified firmware. Obviously I don't know who exactly made the
changes (and I have no doubt that X10's plant builds all the hardware) but
the problem is with the Leviton-branded version.
| >| This 'The PR511 was first' argument is a cop out.
| >
| >How so?
|
| Just because it is first does not make it good or well designed.
I agree (though in this case it happens to be pretty good). But being
first and being from the vendor that owned the protocol does make it
definitive.
| A
| coupler repeater is the most difficult item to design in the entire
| transmission chain. Because of the critical timing it is imperative
| that every other item in the system have the same timing.
Exactly what timing are you talking about? Please be specific and
explain how differences in this timing interact.
| Honestly, I could care less who is to blame. It is a complete waist
| of everyone's time to point fingers. Finding a solution is worth the
| effort.
Well, how much effort is it worth? Translate to dollars and I might take you
up on an offer.
|There is no attempt to shift blame, only present other
| possibilities.
But you are really reaching for the explanation that is least plausible.
| >| Do you think Leviton intentionally
| >| set out to make a repeater that does not like fast macros or PR511's?
| >
| >No, but like many third-party vendors of supposedly X10-compatible equipment
| >they didn't bother to do the necessary work to get it right.
|
| "Didn't bother" tad harsh?
No, it seems like an appropriate description to distinguish them from,
e.g., ACT who did bother and seems to have gotten it right. (But I'm
the first to complain that they don't have a UL listing.)
| Yes they did "bother" to test for
| compatibility.
I'd be interested to see the records of that testing. Seriously. Because
I've found that different companies have vastly different ideas about what
constitutes sufficient testing. Did they set up a test house with a variety
of X10 products and monitor interactions carefully for a few months? Did
they do beta tests and listen to the results? Or did they just do some bench
tests against a signal generator?
| That is why 99% of all HCA repeaters are in the field
| today providing reliable, stable X-10 installations.
You can't know that. One of the problems with X10 (as you have pointed out)
is that it can exhibit false triggering and other behavior that tends to
condition the user to expect less than 100% reliability. They do not always
notice (or dismiss as normal) incremental problems that appear to be lumped
into the "it's flakey" category." Even if they do notice, not all users are
as technical as those who post here and might not be equipped to realize that
the source of the increased "flakeyness" is their new repeater. And even if
they do realize and think to ask, manufacturers take advantage of their lack
of certainty by claiming (as Leviton has) that there are no reported problems.
And since there are no reported problems, the current report doesn't count as
a problem. :) This is enough to convince many, many users that they must be
doing something else wrong.
| We are not
| talking about issues like other products on this newsgroup that have a
| complete disregard for the way X10 transmissions are sent. We are
| talking about a highly intermittent issue with a select few products.
Don't be silly. We haven't seen anything with a "complete disregard"
for the protocol. The "other products" have various subtle bugs that
interact in often unexpected (and bad) ways with real X10, but which
are not obvious on casual observation. The only reason that these problems
now seem so obvious and serious is that I went to a lot of trouble to
completely analyze and document them. I'm sure that the problem with the
HCA is on the same level.
| Does that mean it is ok that there are issues with those products?
| No, not at all but it is ridiculous to say they did not bother to
| test. How many X-10 based products are there in existence?
Not so many that Leviton couldn't easily afford to buy a couple of each
if they didn't already have them. But we both know that they could have
selected a subset that was both interesting and in use. The PR511 is very
interesting because it was one of the first two 2-way modules and it is still
the only floodlight controller.
| >| It is hard to justify the expense of pulling a
| >| full time engineer to chase a random phantom without any hard evidence
| >| of what the cause is.
| >
| >As an engineer, I spend a lot of time chasing such things in order to *get*
| >the hard evidence. Didn't Damon say that Leviton would be happy to fly an
| >engineer to the site of anybody having a problem with the repeater? Well, we
| >have several people here with a problem. Are any of you willing to host the
| >engineer?
|
| Unless the lockup can be duplicated it is a big waist of time and
| expense. If it can be duplicated I think the response would be
| different.
Clearly it can be duplicated or else it would not be causing ongoing problems.
If you are saying that it can't be duplicated quickly enough, well, that's
the nature of these subtle interactions. You can't have everything served on
a platter. Sometimes you have to wait around for a while. Of course, you
don't need to worry about sending an engineer to the site until you have
concluded that you can't duplicate the problem in house. As I recall, Damon
said that his technician said that he had seen the problem and was blaming
the X10 product without further explanation. If they really want an answer
they might do well to examine this in more detail.
And you deleted my question:
>>>| The HCA is in spec.
>>>
>>>Can you provide a pointer to this "spec?"
So, where's the spec? I want to see the spec.
Dan Lanciani
ddl@danlan.*com
t...@worthdist.com
>| today providing reliable, stable X-10 installations.
>
>You can't know that. One of the problems with X10 (as you have pointed out)
>is that it can exhibit false triggering and other behavior that tends to
>condition the user to expect less than 100% reliability. They do not always
>notice (or dismiss as normal) incremental problems that appear to be lumped
>into the "it's flakey" category." Even if they do notice, not all users are
>as technical as those who post here and might not be equipped to realize that
>the source of the increased "flakeyness" is their new repeater. And even if
>they do realize and think to ask, manufacturers take advantage of their lack
>of certainty by claiming (as Leviton has) that there are no reported problems.
>And since there are no reported problems, the current report doesn't count as
>a problem. :) This is enough to convince many, many users that they must be
>doing something else wrong.
>
If we were talking about 95% vs. 99% I would agree but we are talking
about better then 99% on a significant sample size. We know from
experience that if a product does not work we get pounded with
returns. Such items in the hall of shame are SmartLinc, the 3 wire
6201, batch 1 and 3 of the 16400's. The buying public is not shy when
something does not work. A large portion of Worthington customers
know us personally and they are not bashful to ask why something does
not work. We support the products we sell often better then the
manufacturers.
I do think there is another explanation similar to your thinking.
Like you said, most installers are not as technical as those that
frequent the newsgroup. The systems they install are not as elaborate
either. The more plausible explanation is that our customer base is
primarily professional installers using controllers (HAI, JDS,
HomeVision, Adicon). They are not using PR511's, 6417's and CM11A's
or X10 RF products. We classify all of these as hobbiest. A large
reason (I am going to take some heat for this) is that Rich and I will
never recommend PLC spotlights, CM11A's, X10 RF or any style of X10
toggle to a professional. Solutions include Optex outdoor motion
detectors, and StreetSmart wireless attached to controllers for the
same functionality. They may be more expensive solutions but they
keep the powerline free of traffic, have increased range, and are
professional soultions.
This does not excuse any compatibility issues that the HCA may have
with current products, it only helps explain the high number of
successful HCA installations.
>>>>Can you provide a pointer to this "spec?"
X-10 Technical note for the PL513 and TW523 revision 2.4, pages 2-4
shows pulse duration and timing for PLC transmissions.
http://www.x10.com/support/support_manuals.htm
t...@worthdist.com
>In article <3b307743....@nntp.fuse.net>, dhou...@fuse.net (Dave Houston) writes:
>| ddl@danlan.*com (Dan Lanciani) wrote:
>|
>| >In article <3b2f4189....@news.rdu.bellsouth.net>, t...@worthdist.com writes:
>|
>| [...]
>|
>| >| A very poor retry system in
>| >| the PR511 endlessly sends the same signal causing the same collision
>| >| over and over again.
>| >
>| >There is no evidence that the PR511 has a poor retry system. I did however
>| >just make some tests and the PR511 (I tried a very old one and a new-in-the-
>| >box one from a few months ago) does wait for a clear line before transmitting.
>| >Combining this with my previous observations about its collision behavior (i.e.,
>| >it doesn't seem to try to do anything stupid to recover) I'd say it has a pretty
>| >good 2-way implementation considering its vintage.
>|
>| From this, can we take it that the X-10 PR511 does not automatically
>| retransmit after a collision?
>
>I'm not prepared to say for sure without making some more difficult tests.
>On the other hand, I'm not sure I see the point of making such tests by
>themselves. If I find that the PR511 does retransmit in any kind of
>collision situation that will be taken as proof that it is at fault. I
>might consider looking at it as part of a test of the HCA.
Who cares if it is at fault? If the HCA is causing the PR511's to
perceive a collision then what is the HCA doing wrong? If it does not
have collision retry, then what is the HCA doing to make it think it
is being polled? If it is not either of these what is causing the
loop? If we find the elements of the loop we stand a much greater
chance of duplicating the issue in a lab setting.
>| IOW, is there any evidence that the PR511 has
>| _any_ retry system (whether poor or affluent)? If all it does is wait
>| politely for a clear line before transmitting, then its even less likely
>| that it is contributing to any transmission "storm".
>
>That would be my expectation based on my uneventful use of a number of PR511s
>for years. As you know, I tend to notice these kinds of problems quickly and
>post about them loudly and in great detail. :) Most manufacturers (with the
>notable exception of ACT) lack the confidence in their products required to
>want me to test them. :( Unfortunately for them I still buy some of their
>products that I actually need and find the bugs in those. :)
I understand the desire to be taken seriously by manufacture's.
Unfortunately the newsgroup has a tendency to jump on soap boxes to be
heard and forget that companies are in this business to make money.
Running them out on a rail is not a good technique (please don't argue
this point, the group can be merciless). I know just about every
major player in the industry and they all casually watch, how many
post? These days, close to zero. The only reason I hang out is it is
fun and there are some damn smart people with great ideas. I have
thick skin and everyone keeps me on my toes. Defending X-10 products
to the max is not a good way to gain respect of manufacturers. They
are the laughing stock of the industry in terms of engineering. Damn
smart marketing company but hobbyist engineering.
>
>| I know this is remote but could the HCA02 be confusing the PR511 into
>| sending a Status response?
>
>I guess anything is possible. It certainly wouldn't be hard to find out.
>Even with only high-level monitoring equipment logging good packets you should
>see the final status response in the log after you kill the power to the
>repeater. (I assume that anyone who is serious about X10 testing logs
>everything all the time as I do. But even if you don't, you can always start
>the logging process before you kill the power.) Of course, all this speculation
>is great fun, but the obvious way to get to the bottom of the problem is to
>ask one of us here to analyze the effect.
Ding, ding, ding! It is the only way it is going to happen. I am not
an engineer and do not pretend to be one. I don't have the ability to
look any deeper then a Monterey dissect mode. And even that I am
self-taught. If we find the bug I have the connections to get it
fixed. Should Leviton do it on there own? Hell yes, will they; hell
no. There just is not enough negative feedback to justify the
engineering resource. If we figure it out I will make certain my
Leviton rep sends you a thank you present. That is how to get
manufactures attention. We both want the same thing, a UL listed $60
repeater that works. The HCA fits the bill minus one bug.
>
> Dan Lanciani
> ddl@danlan.*com
t...@worthdist.com
>I don't know what you mean by "without any such issue being acknowledged in
>the system". To what system are you referring?
A poor way of saying everything works fine.
I don't really see any reason
>why the typical HA controller should report a BSC. The only action that
>should be taken, is for the controller to continue to look for a legitimate
>start code.
>
>As I stated previously from the Monterey's manual, a BSC simply means that
>while in the idle state, a "1" was detected on one zero crossing, but not on
>the following cycle. This is commonly caused by noise (look at the
>amplitude). The Monterey will apparently, enter the "idle" state following a
>BBk or other such problem condition and does not look for the required 3 cycle
>gap, before looking for a start code. This is a reasonable design decision.
>If there is a collision on the first 11 bit frame that results in BBk or
>whatever, you don't want to revert to looking for a 3 cycle gap, else you will
>miss the second 11 bit frame that may very well have a perfectly clean signal.
>While the Monterey is wading through the collision, it has no choice but to
>report BSCs even though it has not recognized a proper 3 cycle gap.
I must have missed the post, that explains the extreme sensitivity for
BSC's.
>
>>Extended code is not properly supported. The signal strength of the
>>original signal is shown, not the strength to the repeated signal.
>>
>>Repeated dim commands show as BSC. Take the idential transmission but
>>plug in where original and repeated signal can be sampled and it works
>>fine.
>>
>
>
>Perhaps the Monterey is confused by the 2 cycle gap between dims that occur
>when an X-10 designed repeater is repeating dims. Although I would have
>expected this to show up as BCYs and not BSCs. This points out a significant
>diagnostic weakness in the Monterey. That is, it does not directly tell the
>user much of anything about the gaps, not even in signal dissect mode.
>
>J.G.
Good point. In addition true time stamp, a way of exporting data, and
proper display of Preset Dim0 vs Preset Dim1 would all be welcome
additions. We have tried to temp several engineering firms into
making an even better solution but have not been successful.
Dan Lanciani
|>| the lockups.
|>
|>Even if it is initiating the exchange (possibly with a perfectly valid
|>packet), this is not the same as "initiating the lockups."
|
|If it is in a constant retry mode it is initiating the lockup. Or, as
|suggested it could be responding to a status request. Either way it
|is a message based issue where both components need each other for the
|lockup to continue. It is not a case of the repeater going to sleep
|or sending endless junk. It is an interaction between the two
|devices.
Sure, it's an interaction. But you don't know that the PR511 is initiating
the interaction let alone initiating the lockup.
|>| If the repeater or PR511's are turned off it stops. A
|>| repeater can not initiate signal except in test mode (this happens
|>| with the 6201 as well and it does not have a test mode).
|>
|>You are again assuming that the repeater is working correctly in order to
|>prove that it is working correctly. Since other repeaters (ACT, the _original_
|>6201) do not exhibit this problem there must be something wrong with the new
|>repeater. (See, I can do the false logic thing too. :)
|
|Actually, the 6201 does it to. My last house had it happen and it
|nearly effected the sale of the house.
Did you have an _original_ 6201 (no red wire; no power-up sequence requirement)
or the current model? The former is extremely reliable but does not support
extended codes. The latter has problems.
|I have a strong interest in
|seeing this issue squashed.
As a purely practical matter, you must know that the only resolution will
have to be to change the HCA. Even if you could prove that in some obscure
sense the PR511 and the CM11a and whichever RF transceiver are "wrong" while
the HCA is "right" there are way too many PR511s, CM11as, and transceivers to
change--and X10 is unlikely to change them.
|>| A very poor retry system in
|>| the PR511 endlessly sends the same signal causing the same collision
|>| over and over again.
|>
|>There is no evidence that the PR511 has a poor retry system. I did however
|>just make some tests and the PR511 (I tried a very old one and a new-in-the-
|>box one from a few months ago) does wait for a clear line before transmitting.
|>Combining this with my previous observations about its collision behavior (i.e.,
|>it doesn't seem to try to do anything stupid to recover) I'd say it has a pretty
|>good 2-way implementation considering its vintage.
|
|Here is the $1,000,000 question. Does it have a retry system at all?
Well, I could certainly construct a test to find out. But why is this the
$1,000,000 question? If I found that the PR511 does retry then you would
probably say that that proves it is at fault. If I found that it did not
then you would probably say that it is at fault for some other reason. But
in either case I'd say that the HCA still needs to work with the PR511.
Wouldn't it make more sense to examine the HCA's behavior?
|If not, can we assume then the PR511's must think they are being asked
|for status?
No, we can't assume that.
|How else could the loop start?
The HCA could see some noise on the line, fail to properly verify the validity
of the packet's complement bits, and send out a version with correct complement
bits. Thus it could turn noise that would otherwise be ignored by correct
receivers into a valid version of almost any command. That's just a random
example and it's a bit far fetched (Occam wouldn't approve), but it's no more
of a reach than your possible explanations. And it's consistent with the kinds
of mistakes other third parties have made.
|>You keep talking about X10's value engineering in a negative tone but there
|>is ample evidence that X10 has done a pretty good job trading off cost and
|>functionality.
|
|I do not agree. False tripping for 22 years is long enough to get it
|corrected. That is just one example of 'value engineering' that gives
|X-10 a bad name. No need to dwell on this further.
What false tripping? The only false tripping I've ever had involved third
party products that got some aspect of the protocol wrong. In all cases
it was possible to specifically identify where they screwed up. As far as
I can tell, X10's own receivers do about the best job possible validating
received codes. They check all (or in some cases all but one--fortunately
not an important one) of the complement bits and they correctly skip packets
with errors rather than looking for additional (false) start codes within.
They are repeater-friendly in that they operate correctly in a bad-frame/
good-frame back-to-back environment. They consistently implement the address
selection state machine so that controllers don't get out of sync with slaves.
Now of course there are problems inherent in what was originally a one-way
protocol. The effects of collisions are minimized by X10's robust error
checking but they cannot be eliminated by X10 or any third party without making
every transmitter 2-way, and that's a paradigm shift. In no case can they be
eliminated by any receiver-only improvement. (N.B. I recognize that many
users can't distinguish inevitable collision problems from "real" false
tripping, so I allow for their belief that X10 is flakey in this respect.)
Can you please explain _specifically_ what you think is wrong with X10's
products that causes false tripping and that is fixed by other vendors?
| Now if you want to talk about bad value engineering, let's
|>consider Leviton's previous repeater offering (the new 6201) that requires
|>a specific power-up sequence(!). They probably saved themselves a buck or
|>two on production costs at the expense of making a product which cannot be
|>depended on in any realistic residential environment.
|
|And guess who made that power suppy design.... X10.
I'll take your word for this as I have no way of knowing who designed the
power supply. But it doesn't change anything. Even if Leviton bought that
portion of the design from X10 it is still bad value engineering on Leviton's
part. Selecting components is just another part of the engineering process.
|That is why
|Leviton now makes many items themselves and expect to see more self
|manufactured Leviton DHC items.
So is the HCA based on the parts of the new 6201 that Leviton got from X10
or is it a new design?
|>| Attacking the CM11A is more difficult because there are more
|>| variables. Is the issue in the CM11A, HCA, or software? We have far
|>| more issues with ActiveHome software then, say, HomeSeer.
|>
|>Before spending too much time attacking this problem, consider applying
|>Occam's Razor. You have introduced a new and unknown quantity (the HCA02)
|>to several environments with various other X10 components. Problems appear
|>with (at least) any of the PR511, the CM11a, and some unspecified X10 RF
|>product. Some of these X10 components have been around for more than a decade
|>and their behaviors, while not always perfect, are reasonably well understood.
|>The products span a range of implementation technologies with no obviously
|>common attributes (other than being from X10). The complicated explanation
|>is that the HCA02 has uncovered a bug or bugs in all of these existing products.
|>The simple explanation is that the HCA02 has a bug. Occam says to prefer the
|>simple explanation, and I have found Occam to be right more often than not.
|
|Fine, explain the bug and we have a simple solution.
Make it worth my while and I'll be happy to debug the HCA02 for you. But
even if I identify the bug for you there won't be a solution (simple or
otherwise) unless Leviton fixes said bug...
|>
|>| When a 3rd
|>| variable is involed is the CM11A still in spec? Who says even the
|>| PR511's are in spec?
|>
|>The CM11a and the PR511 are in spec by definition. The X10 protocol is defined
|>by the behaviors of X10's products. Welcome to the world of proprietary
|>protocols. There are no standards documents or committees to appeal to. And
|>even though X10 may have disclosed some aspects of the protocol by telling us
|>how third-party products should behave, they are not bound to follow those
|>practices themselves. This is X10's sandbox. If you want to play in it you
|>have to play by their rules.
|
|X10's 'sandbox' contains products with no direct dim, false tripping,
|no scenes, and a coupler repeater with power on sequence problems. I
|choose to use professional soultions. When X10 hobbiest items are
|avoided the technology is rock solid. With very few exceptions X10
|does not offer professional soultions. It is a hobbiest company with
|hobbiest solutions. They are value engineered for maximum sales
|numbers and the philosphy that most people will not bother to return
|and item if it does not work or it fails after a year. It was only
|$10 anyways. I am certian this is a sound, profitible business plan.
|That I can defend, there engineering I can't.
Wow. I didn't realize you felt that strongly about X10. I guess that X10
just built the protocol and the market by selling all their junk so that
third parties could hype "professional solutions" that cost ten times as
much and aren't compatible. But the technology that they copied from X10
is rock solid as long as you don't use it with X10's own "hobbiest items."
Uh, huh. If those third parties are so clever they could have invented
their own protocol rather than perverting X10's... Someday you might want
to compare the wonderfully complete 2-way command set that X10 designed for
the LM14a (and friends) with the crude attempts by Smartlinc and Lightolier
to shoehorn minimal 2-way functionality into the cheapest possible PIC. Then
we can talk about value engineering...
Dan Lanciani
ddl@danlan.*com
Dan Lanciani
| >>>>Can you provide a pointer to this "spec?"
|
| X-10 Technical note for the PL513 and TW523 revision 2.4, pages 2-4
| shows pulse duration and timing for PLC transmissions.
|
| http://www.x10.com/support/support_manuals.htm
That's pretty funny. But I get the feeling you didn't mean it as a joke,
and that suggests that further discussion is not likely to yield anything
of technical substance...
Dan Lanciani
ddl@danlan.*com
Mike McMonagle
isn't compatible with X-10 devices from other manufacturers and that's
what's causing your problems. Great way to sell more Decora, crappy
way to try to engender customer support and actually figure out what's
happening. I remember reading the thread regarding possible HCA02
problems back in March, a Leviton defender (employee) said they'd fly
someone out in a heartbeat to investigate problems with their
products. I guess that's if Leviton actually had a heart....
Mike
"Roger" <NO_SPAMr...@worldnet.att.net> wrote in message news:<CfgW6.82397$4f7.6...@bgtnsc06-news.ops.worldnet.att.net>...
> Thanks for all the replies. I thought implementing my X-10 devices would be
> simple - it's getting more complicated all the time.
>
> I purchased the Leviton HCA02-10E repeater and installed it tonight. I
> installed it in the breaker panel through a double pole 15 Amp breaker as
> instructed. Good news and bad news.
>
> It has a test mode where it alternates sending code P1 ON then P1 OFF with
> about 2 seconds in between each. I set an appliance module to P2 and went
> to almost every outlet in my house. All outlets worked. Relay in module
> clicks away!
>
> I move my transceiver to an outlet that would control two lamps fine and two
> lamps occasionally before the repeater installation. All 4 lamps worked
> great just sending ON and OFF commands to individual lamps.
>
> Now the bad news.
>
> I tried the dim function on the first lamp. It was very hard to control and
> often would not respond. If you held the dim button down it would do
> nothing. If you just tapped and release the dim button, it would dim
> various amounts at different times. Three times it seemed to somehow lock
> up the transceiver module (IBM, came w/ the home director starter kit). The
> green receive light on the repeater would not blink (receiving no codes). I
> could hit the test button on the repeater and it would send and control the
> module set to code P1. Unplugging the transceiver and replugging it in
> would again start things trying to work again. Green light (receive) on
> repeater would flash as remote buttons were pushed. Seems to prove
> transceiver lockup.
>
> Why the transceiver lockups - I don't know.
>
> Macros from the HD11A (again, IBM home director starter kit) would not
> function correctly. Had a macro "When code A7 ON received, turn A1 OFF, A2
> ON, A3 ON, A4 OFF" (the four lamps I am controlling). A1 would go off, A2
> would come on, A2 would then dim down smoothly and go out, A3 never came on,
> and A4 turned on.
>
> It seems that the repeater is hearing the transmitted signals and
> retransmitting them causing multiple or no dims to happen when they should,
> and collisions I guess screwing up the macro I had programmed.
>
> If I turn off the repeater, things would work as I first reported in my
> first post.
>
> I tried the dryer trick, turned it on. Turned repeater off. Things
> behaved, all lamps would switch on and off, would dim and brighten properly,
> and the macro function (as well as another similar macro) worked just fine.
> I didn't feel like going all through the house again to see if codes could
> be received by modules all over the house. Looks like I need to do this
> again to see if just a passive coupler will do the job.
>
> I turned the dryer off, repeater still off. Back to two lamps work well,
> two work ocassionally.
>
> Looks like passive coupler may work at least for this one room w/ lamps.
> Whole house? - need to test again.
>
> I'm disappointed in the repeater operation. Thought this would be a well
> spent $65 to insure reliability.
>
> Any thoughts?? Any suggestions??
>
> I may try and contact Leviton and ask if any troubles similar to mine have
> been reported.
>
> Thanks again!
> Roger
> --------------
> Please remove NO_SPAM from my email address if replying directly to me.
>
>
> Roger <NO_SPAMr...@worldnet.att.net> wrote in message
> news:s5BV6.78996$4f7.6...@bgtnsc06-news.ops.worldnet.att.net...
> > I'm a new user to the X-10 world and will lead up to questions concerning
> > repeater operation.
> >
> > I am having trouble locating the transceiver in a good location.
> > I'm controlling 4 lamps and generally, everywhere I put the transceiver 2
> > lamps respond OK and the other two occasionally.
> > Trying a different wall socket, the two sets may switch, the other two
> > behave nicely and the other two become occasional performers.
> > For some reason, one particular wall socket seems to control all four
> lamps
> > well with the transceiver there, but it is the least desirable place I
> want
> > to locate it. All wall sockets and lamps are in the same room.
> >
> > I'm assuming the lamp pairs are on two separate 110 volt legs of the house
> > wiring.
> >
> > I am thinking of buying the latest Leviton coupler/repeater to hopefully
> > resolve this and make the whole system much more reliable. I hope to add
> > more devices through out the house later on down the road.
> >
> > But, I got to thinking, does using a repeater present any problems?
> >
> > 1) Suppose the device I'm transmitting to hears the original signal and
> the
> > duplicate from the repeater module. I guess receiving two "ON" commands
> or
> > two "OFF" commands would present no problems.
> >
> > 2) But, suppose it is the "DIM" or "BRIGHTEN" command. Would the module
> > receive twice as many commands and dim or brighten twice as much as
> > intended?
> >
> > 3) How about when using a CM11A controller. Suppose I send one X-10
> > command, the CM11A recognizes this as a macro and sends a bunch of X-10
> > commands out one after the other to perhaps multiple devices. As the
> > repeater sees one X-10 command and repeats it, could the CM11A be sending
> > out the next command and collisions start occurring?
> >
> > 4) Are there any other operational problems it may present that you are
> > aware of?
> >
> > My apologies if I sent this out after drinking too much coffee and the
> brain
> > is in overload mode!
> >
> > Thanks in advance for any replies.
> > --------------
> > Please remove NO_SPAM from my email address if replying directly to me.
> >
> >
Malcolm Blackhall
Decora Home Control Products." If this is Leviton's position, they out to
note in their sales literature the incompatibility with other X-10 devices.
Dan Lanciani
|>On the other hand, I'm not sure I see the point of making such tests by
|>themselves. If I find that the PR511 does retransmit in any kind of
|>collision situation that will be taken as proof that it is at fault. I
|>might consider looking at it as part of a test of the HCA.
|
|Who cares if it is at fault?
Well, based on your previous posts you seem to care a great deal.
|If the HCA is causing the PR511's to
|perceive a collision then what is the HCA doing wrong? If it does not
|have collision retry, then what is the HCA doing to make it think it
|is being polled? If it is not either of these what is causing the
|loop? If we find the elements of the loop we stand a much greater
|chance of duplicating the issue in a lab setting.
According to Damon they ALREADY duplicated the problem in a lab. (I
believe it was the CM11a variant.) But instead of fixing it (or even
explaining in detail what they observed), they simply declared it to be
X10's fault. Rather than repeatedly asking what might be wrong with the
X10 products in the name of helping to reproduce the problem in the lab,
why don't you just ask your contact at Leviton what they have observed?
Or, if you can't do that, tell us what efforts you have made so far to
duplicate the issue in a lab and we might be able to tell you how to adjust
your procedures.
|>| IOW, is there any evidence that the PR511 has
|>| _any_ retry system (whether poor or affluent)? If all it does is wait
|>| politely for a clear line before transmitting, then its even less likely
|>| that it is contributing to any transmission "storm".
|>
|>That would be my expectation based on my uneventful use of a number of PR511s
|>for years. As you know, I tend to notice these kinds of problems quickly and
|>post about them loudly and in great detail. :) Most manufacturers (with the
|>notable exception of ACT) lack the confidence in their products required to
|>want me to test them. :( Unfortunately for them I still buy some of their
|>products that I actually need and find the bugs in those. :)
|
|I understand the desire to be taken seriously by manufacture's.
I don't know about you, but I find that manufacturers take me quite seriously.
Sometimes to the point of requesting that I sign NDAs so they can stop me from
revealing their mistakes. N.B., I'm not saying that they *like* me, but they
certainly take me seriously. Some of them positively hate me...
|Unfortunately the newsgroup has a tendency to jump on soap boxes to be
|heard and forget that companies are in this business to make money.
This newsgroup (like the rest of USENET and the internet in general) is a
great way to spread information (good and bad) about products. We do not
forget that companies are in business to make money. It is exactly because
they are in business to make money that they tend to bend the truth a bit
when they tell customers that there are "no reported problems" report after
report. I realize that it makes many companies uncomfortable to know that
any random customer can type their product's name into a search engine and
see for herself if there are really "no reported problems." This is a good
thing. Eventually companies will have to adjust their policies if they do
not want to be seen as blatant liars rather than truth-benders.
|Running them out on a rail is not a good technique (please don't argue
|this point, the group can be merciless).
This would seem to conflict with what you say below.
|I know just about every
|major player in the industry and they all casually watch, how many
|post? These days, close to zero.
This is not true in my experience. On one occasion I actually received a
call (imagine that--they called me) from a company that had been stonewalling
within hours after posting a few of the details of their product's problems.
In another case a company put out a little press release to (not really) refute
my comments. The funny thing about the latter is that I didn't see it until
someone else scanned it and posted it. Unfortunately, it is true that some
companies react to the disclosure of their products' problems by sending
representatives to try to divert the blame to the competition with FUD and
vague references to technical details that somehow are never available.
|Defending X-10 products
|to the max is not a good way to gain respect of manufacturers.
I call them like I see them. When X10 products have problems I'm the
first to complain. I reported on the disastrous TM751 years before
it became fashionable to criticize it. I bashed the serial protocol (if
you can call it that) used by the CM11a when it first appeared. These
are _specific_ issues. You merely assert that X10 products are bad and
reason from that to a hypothetical problem with (a) specific product(s)
that has/have not in fact exhibited such problems before.
|They
|are the laughing stock of the industry in terms of engineering.
That's news to me.
|Damn
|smart marketing company but hobbyist engineering.
I really think you are confusing mass-market engineering with hobbyist
engineering.
|If we find the bug I have the connections to get it
|fixed. Should Leviton do it on there own? Hell yes, will they; hell
|no. There just is not enough negative feedback to justify the
|engineering resource.
This would seem to conflict with your comment above about not "running
them out on a rail." If the only thing that justifies engineering resources
to fix the problem is negative feedback then we need more rather than less
negative feedback, right?
|We both want the same thing, a UL listed $60
|repeater that works. The HCA fits the bill minus one bug.
That's a pretty big minus. Personally, I'm betting ACT gets the UL listing
before Leviton fixes their bug. (I should also note that I don't care about
the price point, but that's just me.)
Dan Lanciani
ddl@danlan.*com
Claus V.
> Firmware is the same. You can only fix what you know to be broken. I
> don't argue that there is an issue. I don't even think Leviton will
> argue there is an issue.
You were away at a show when it occurred but Damon clearly argued here that
there were no issues, no trouble reports and that when he reported the
issues raised here he was told by the Leviton techies "not to waste their
time." He had some less-than-flattering words for me, too, for raising
questions about the HCA-02. All in all it was not the high point of
Leviton's public relations work . . .
Claus V. - who wonders whether there was an even more troublesome HCA-01.
Claus V.
news:fcd3e0b7.0106...@posting.google.com...
> Dan:
>
> I would be very happy to "host" a Leviton engineer to come and figure
> out why the HCA02 doesn't like my PR-511. However, when I posted this
> same reply to Damon, I never got a response. From my interactions
> with Leviton, I would eat my hat if they would "fly an engineer" over
> to my house.
I recall that exhange vividly and laughing my butt off that after denying
any problems existed that they would then fly an engineer out to your site.
Not bloody likely!
> (Actually, they would only have to drive over from Long Island, NY, as
> I live in Rockland County, NY) ;)
That's not even a very long drive, is it?
Claus V.
Claus V.
> As I stated previously from the Monterey's manual, a BSC simply means that
> while in the idle state, a "1" was detected on one zero crossing, but not
on
> the following cycle. This is commonly caused by noise (look at the
> amplitude). The Monterey will apparently, enter the "idle" state
following a
> BBk or other such problem condition and does not look for the required 3
cycle
> gap, before looking for a start code. This is a reasonable design
decision.
> If there is a collision on the first 11 bit frame that results in BBk or
> whatever, you don't want to revert to looking for a 3 cycle gap, else you
will
> miss the second 11 bit frame that may very well have a perfectly clean
signal.
> While the Monterey is wading through the collision, it has no choice but
to
> report BSCs even though it has not recognized a proper 3 cycle gap.
Well put. They had to cover that situation somehow and to name it a BSC at
least clues you into the fact that there may be signals on the line that
other devices may wrongly interpret as X-10 traffic. In my experience when
the Monterey starts showing BSC's there's usually something wrong somewhere.
And when I mix and match troublesome TM-751's and RR-501's the meter shows
goes wild showing frequent BSC's and the response time of the units being
controlled slows noticeably. Looking at the signal dissect mode when
colliding devices are on line shows each with a different strength which
clearly indicates that transmissions from each unit are combining to create
new, unwanted codes.
It's certainly a far better indicator of potential trouble than the much
cheaper bar code meters that have no way to look at each individual bit and
the signal strength thereof. Clearly it could be improved but it's already
priced out of the range of most users. Adding more features would raise the
price even more.
Claus V.
Claus V.
> |X10's 'sandbox' contains products with no direct dim, false tripping,
> |no scenes, and a coupler repeater with power on sequence problems. I
> |choose to use professional soultions. When X10 hobbiest items are
> |avoided the technology is rock solid.
I must disagree. I've got brown BSR controllers still working as well as
the day they were made. The Leviton was the first non-X-10 product I have
purchased (even my Ocelot uses an X-10 designed interface) and it's given me
problems with my CM11A which was clearly on the market long before the
HCA-02 arrived. The horror stories of Switchlinc lead me to believe that
the technology *outside* of the X-10 product line is flaky, exactly the
reverse conclusion that you have arrived at. I am *very* satisified with
the bang for the buck (well, at least before X-10 appears to have shifted QC
off on the end user!)
> |With very few exceptions X10
> |does not offer professional soultions.
But they invented the technology upon which all the "pro" gear is based and
it seems that the "pro" gear builders just can't help fixing things that
aren't broken. My advice to newbies in the HA field is to avoid mixing and
matching items from different manufacturers like the plague, especially
after I dabbled in the Leviton line myself. After following many of Dan's
comments it's clear that shops like Leviton test with their own equipment
first and other maker's equipment a far second (if they even test other
maker's equipment at all).
> |It is a hobbiest company with
> |hobbiest solutions. They are value engineered for maximum sales
> |numbers and the philosphy that most people will not bother to return
> |and item if it does not work or it fails after a year.
Careful - the same return rule might apply to a $60 repeater. (-: Many may
feel that it's not worth the trouble or think the problem is coming from
elsewhere.
> third parties could hype "professional solutions" that cost ten times as
> much and aren't compatible.
I agree with Dan here. There have been some pretty pissed off posters that
have spent oodles on "professional" (read expensive) solutions like
Switchlinc to find they have built an electronic house of horrors.
Claus V.
Claus V.
> Unfortunately the newsgroup has a tendency to jump on soap boxes to be
> heard and forget that companies are in this business to make money.
Yeah, our money. I've heard a lot of manufacturers claim "it's not our
fault" but one merely has to check the Ford/Firestone fiasco on the evening
news to know that 200 dead people really "got taken to the cleaners" on that
one. It reminds me very much of the current dilemma. Leviton blames X-10
and no doubt, vice-versa. Leviton's Damon turned such a stone-deaf ear to
any possible problems that almost any reasonable person in the world could
expect that something was amiss. I've got a Monterey and a cheap o'scope
but I don't have the time to do Leviton's beta testing for them. As for the
lack of returns being a measure of product viability just remember it took a
long time for Ford to rack up 200 dead drivers. If 760 people posted that
they loved their HCA-02 I might be able to overlook the reports we've seen
here indicating problems. But I haven't so I can't.
The problem is now compounded because we know there are at least two
firmware revisions out there for the HCA-02 (and maybe more). How do we
know that? Not from Worthington or Leviton but by end users on this NG
opening and comparing the actual shipping product. Sadly the firmware
appears not to be upgradeable by the end user. This likely means that early
adopters of the technology take the biggest hit as Leviton works out the
"non-existent" <grin> bugs by upgrading firmware in newer models. Want to
really impress us? Find out from Leviton why there was a firmware revision
in what appears to be less than three months after it hit the market. I'll
bet you couldn't get it out of them with a jar of Vaseline and a crowbar.
But I'd love to know what bug they felt the need to fix so quickly. I asked
Damon but he subsequently vanished after admitting they could duplicate the
problem with the CM11A. That firmware upgrade alone convinces me that
Leviton knows more than they are telling end users and maybe even you big 1K
unit distributors.
Claus V.
Roy L.
end-user about what kind of interaction is occurring between the
PR-511 and HCA-02. Dan has come the closest, but obviously without
the help of the manufacturers (Leviton, X10), all of this is
speculation. Without an ability to upgrade my HCA-02 in any event,
either I throw it out or take Tom Morgan up on his offer to return it
to Worthington. This is the last time that I buy a Leviton product
without waiting about 6 months for all the bugs to shake out.
Sheesh...if Leviton's other products behaved this badly, I can't
imagine them staying in business for long...imagine if one out of
every thousand mechanical light switches they sell could not be turned
off every so often. I suspect Leviton products would be quickly
substituted for Eagle.
Roy.
Mike McMonagle
Tom up on his offer and will go back to a passive (but commercial, not
homebrew) coupler. My 2000sq. house was working well with my homebrew
passive, but I though that the HCA would make things UL/legal and
improve an already good system I had in place.
I am using those 'hobbyist' X-10 modules, and price does matter to me
at this point which is why a $60 HCA looked great. And all my hobbyist
'crap' worked 99% reliable until the HCA came into the equation and
gave me a house possessed.
I have 16 lights upstairs/downstairs on a single housecode (1 on
Hawkeye), another 8 in garage and outdoors on another housecode (2 on
Hawkeyes), 6 in son's room on another code (1 on Hawkeye), 4 in
daughter's room on another code(1 on Hawkeye). X-10 wall switches for
local control, Palmpads and Slimline Stickup Switches for remote
control. No PR511s in the equation at all. All played well together
until the HCA02 arrived. Then the fun began:
- J Status Requests repeating over and over at random periods,
sometimes for 20 minutes. The repeats can be as fast as 2 per second.
I have nothing on this housecode. What's a status request?
- F Hail Ack occasionally, I have nothing on this housecode. What's a
hail ack?
- Occasional multicommand strings like J14+J2+N13+J14+J2+J13+J16J
Status Request.
- Occasional G7+G7+G7+G7+G7+C13 C On. I have nothing on housecode G. I
have things on C.
- N16+N2+N16+F16+P9 B All Lights On. Nothing on N or P, but B is a
working housecode. The wife is not pleased to have 16 lights all come
on at once. Or go off all at once. This has also happened on the 2
housecodes in the children's rooms.
- Random variety of strange codes & commands on almost all housecodes.
- Turning off a light on one housecode via Slimline switch turns off
all lights in son's room occasionally.
Based on the speed and variety of mixed codes and commands, this
doesn't look like another X-10 user slopping into my house. After
monitoring for a few days, I ended up with about 4 housecodes that
seemed to not have any major ghost commands. I have had to switch
everything to these codes to minimize problems, but still see
occasional things happen on those codes as well.
Just for giggles and grins, I contacted Leviton Tech Support and
explained the issues I felt were occurring due to a inherent problem
with the HCA02, using the above as examples. Here's some of their
replys verbatim in quotations, with my subtle observations in
parentheses:
"The HCA02-10E has a built-in test signal generator for easy signal
strength verification. Are you sure the test signal generation is not
being misinterpreted as errant command signals."
(Does this guy think I'm an idiot, or is he? Gee, didja leave the test
button pushed in, huh Wally?)
"Is our coupler/repeater being used in conjunction with non-Leviton
devices?"
(And why do you ask? I told him in with first email that my entire
install was 'original' X-10. Maybe I need to type slower.)
"If so it may be a matter of incompatibility between manufacturers."
(Aah, now we're getting somewhere, though I don't like where we're
going. So you're not compatible with the defacto protocol standard
from the original manufacturer?)
"There is no way that Leviton can assure compatibility with devices
from other manufacturers."
(So much for Tom's statement that "Yes they did 'bother' to test for
compatibility." You'd think they'd test 'em with the manufacturer of
the largest installed user base. Oh yeah, I forgot we're just
hobbyists.)
"Our home automation products do not utilize any type of pc
interface."
(Oh, it must be that naughty CM11 got mad after it saw the HCA move in
and it started misbehaving. Not.)
"Why didn't you use an X-10 coupler/repeater to assure compatibility?"
(Well, golly, I thought Leviton had made a great product with good
support for a fair price. I'm sorry, I won't let it happen again. I
won't bother you busy folks, I'll just go back to my hobbyist ways.)
So it seems that Leviton needs to remark the HCA from 'For use with
Decora products' to 'For use ONLY with Decora products'. I did point
out in my final email that this should be clearly stated in all
advertising and promotional material, and that Worthington's
description on the webpage mentions 'Compatible with X-10 standard,
pre-set dim and extended code command sets'.
There's no question that X-10 makes a lower quality product, primarily
in finish and feel. But the price vs. usability can't be beat for
anyone looking to get their feet wet in HA. And sooner or later, most
of us will slowly upgrade wall switches and such as cost permits with
better products. But Leviton can kiss off any future business from me
based on their handling of this, I'll be looking elsewhere when I get
ready to start to move up. And I'll happily share this experience with
anyone who asks me about HA products and brands. Leviton is lucky they
have someone like Tom trying to keep customers happy, I hope they take
these issues seriously. Funny though, Damon hasn't called me to pick
him up at the airport yet.
I feel better now (kinda sorta)....
Mike
"Claus V." <claus...@usa.net> wrote in message news:<9guu3h$rgd$1...@bob.news.rcn.net>...
Dan Lanciani
| No PR511s in the equation at all. All played well together
| until the HCA02 arrived. Then the fun began:
|
| - J Status Requests repeating over and over at random periods,
| sometimes for 20 minutes. The repeats can be as fast as 2 per second.
| I have nothing on this housecode. What's a status request?
A status request is a query to a module to tell you whether it is on or off.
One of the few older modules that responds to this request is the PR511. It
has been suggested that a PR511 somehow "initiates" a lockup with the HCA02
because it and the the HCA02 have appeared to be active round-robin. Your
observation suggests that the HCA02 can create a status request all by itself.
If you had a PR511 on the appropriate code it could have responded to the
request, and possibly that would have encouraged the HCA02 to make another
request.
Possibly it isn't even the PR511's response that causes the HCA02 to generate
another round of spurious signals. Although it has been noted that shutting
off the circuit breaker to either the PR511 or the HCA02 breaks what was
believed to be a loop of some kind, it may be instead that turning off the
PR511's breaker merely changes the characteristics of the network enough that
the HCA02 stops falsing for a while. I'm beginning to like my noise theory
better and better. The HCA02 could see noise (or the result of collisions)
and fail to check the signal format (in particular the complement bits),
rebroadcasting a "corrected" version of the false signal to which other modules
would be forced to respond.
| - F Hail Ack occasionally, I have nothing on this housecode. What's a
| hail ack?
Originally a hail ack was a response to a hail. The theory was that a
controller could check for other controllers on its house code and maybe
pick a different house code in some sort of autoconfiguration procedure.
Nobody ever implemented this, though. Later Leviton reused the hail ack
code to make their special version of the PR511 firmware. This version
allows multiple units to act in unison. I suppose it's possible that their
repeater does something special to work with their version of the PR511,
but more likely this is just another random synthesis from noise.
| - Occasional multicommand strings like J14+J2+N13+J14+J2+J13+J16J
| Status Request.
| - Occasional G7+G7+G7+G7+G7+C13 C On. I have nothing on housecode G. I
| have things on C.
| - N16+N2+N16+F16+P9 B All Lights On. Nothing on N or P, but B is a
| working housecode. The wife is not pleased to have 16 lights all come
| on at once. Or go off all at once. This has also happened on the 2
| housecodes in the children's rooms.
| - Random variety of strange codes & commands on almost all housecodes.
These all suggest the transforming of noise into valid commands.
| - Turning off a light on one housecode via Slimline switch turns off
| all lights in son's room occasionally.
This is probably because the HCA02 had previously generated false selection
codes for all the lights (as above) and pressing the switch triggered them
in addition to the unit it selected.
| Based on the speed and variety of mixed codes and commands, this
| doesn't look like another X-10 user slopping into my house. After
| monitoring for a few days, I ended up with about 4 housecodes that
| seemed to not have any major ghost commands. I have had to switch
| everything to these codes to minimize problems, but still see
| occasional things happen on those codes as well.
Failing to check some of the complement bits can create a bias towards
particular commands or command fragments (housecodes, etc.) being accepted
when they are not valid. We could probably infer something from the specific
details, but at this point it would be easier to make the obvious test...
| Just for giggles and grins, I contacted Leviton Tech Support and
| explained the issues I felt were occurring due to a inherent problem
| with the HCA02, using the above as examples. Here's some of their
| replys verbatim in quotations, with my subtle observations in
| parentheses:
|
| "The HCA02-10E has a built-in test signal generator for easy signal
| strength verification. Are you sure the test signal generation is not
| being misinterpreted as errant command signals."
| (Does this guy think I'm an idiot, or is he? Gee, didja leave the test
| button pushed in, huh Wally?)
Maybe he knows something we don't, e.g., that the test signal generator
sometimes goes crazy and sends signals on its own.
In any case, you have provided the most useful data so far. There is now
ample information for anyone truely motivated to find the problem to make
some tests.
Dan Lanciani
ddl@danlan.*com
Malcolm Blackhall
coupler. And everything is still working well after installing the HCA02.
With the exception of the HCA02, all my gear is X-10, including 4 of the
infamous PR511s. All of my gear has been purchased within the last year.
I know there isn't enough histroy with my system to infer anything yet.
Time will tell.
When I first installed X-10, I had occasional strange things happen, like
various lights coming on simultaneously in the middle of the night. After
doing a bit of work on my electrical system, including replacing 35 year old
outlets with hospital grade outlets, tightening connections, etc, I haven't
had anything strange happen for quite a while now.
My gut feeling after reading the posts on this topic is that, in some cases
anyway, the unexplainable problems in a system with an HCA02 may be due to
the HCA02 repeating noise. This is not to say that other possible causes
advanced so far are not also valid in some cases. Systems with different
components, different hardware or firmware revisions of the same component,
different device configuration (particularly the PR511 which has so many
configuration possibilities), etc. may very well have similar symptoms
caused by different problems.
It could be that the HCA02 is repeating at an amplified level noise that
looks like a valid X-10 signal but is too low level for X-10 devices to hear
unless it is amplified or repeated. If so, the problem is not with the
HCA02, but the environment in which it is installed.
Or it could be that the HCA02 is doing a less than super job of validating
the X-10 command and repeating noise that does not look like a valid X-10
command, transforming it into a valid looking one.
If so, there is a problem with the HCA02's firmware, but it may be possible
to resolve the symptoms by improving the environment in which the HCA02
operates.
If the test signal generator is sending signals on its own, shouldn't we be
seeing P1 ON and P1 OFF codes when they are not stepping on commands from
other devices?
The idea of Leviton knowing of a problem and not letting on that there is
one is interesting. I do not know if this is the case or not. But, this
type of reaction is not unheard of in the electronics world. Some years
ago, I was working for a computer company. We were having trouble caused by
what at first looked like a software problem, but turned out to be a problem
with the chipset supplied by another manufacturer. When I called them and
asked if there was a problem with the chipset I needed to know about, they
said there were none. When I described exactly what the chipset was doing
wrong, they responded with "Oh, you know about that one" and gave me the
workaround.
Dave Houston
[...]
>It could be that the HCA02 is repeating at an amplified level noise that
>looks like a valid X-10 signal but is too low level for X-10 devices to hear
>unless it is amplified or repeated. If so, the problem is not with the
>HCA02, but the environment in which it is installed.
It is highly unlikely that random noise will look like an X-10 signal with
1110 followed by alternating "1" and "0" half-bits of the Manchester
encoding. It may be that the HCA02 is amplifying very low level X-10 signals
coming from outside but I think even this is unlikely given the variety of
hardware that seems to have problems with the HCA02.
Gert Muller
> strength verification. Are you sure the test signal generation is not
> being misinterpreted as errant command signals."
> (Does this guy think I'm an idiot, or is he? Gee, didja leave the test
> button pushed in, huh Wally?)
No joke, my HCA went sometimes into test mode by itself and then locked up
after a while...
Decomissioned now, back to the lousy 6201! :-((
Gert
Mike McMonagle
Thanks for the answers and observations, but Leviton apparently thinks
we're all a buncha crackpot hobbyists that don't know well enough to
outfit our entire house with their high quality product line to get
things to work properly.
You said that the Hail Ack command has never been utilized by anyone
other than Leviton's version of the PR511 firmware. I don't have any
511's, Leviton or otherwise. So about the only thing that could
generate this Hail Ack (even based on noise alone) would be something
with a PIC with Leviton firmware? Hmmm, the only Leviton device I have
is the HCA02, curious.
I'm going to send Tom copies of my older HomeSeer logs with all the
bogus commands highlighted as soon as they issue an RMA for my HCA02.
Maybe he can get someone at Leviton interested, but I still don't
think Damon's on a plane to my place in Houston yet....
Thanks again,
Mike
ddl@danlan.*com (Dan Lanciani) wrote in message news:<919...@news1.IPSWITCHS.CMM>...
Malcolm Blackhall
> 1110 followed by alternating "1" and "0" half-bits of the Manchester
>encoding
It may be unlikely. But it happens often enough. In fact it happens at
signal levels that don't even have to be repeated to cause problems. How do
you explain random lights occasionally turning on or off simultaneously, or
better yet all devices on a given house code turning on or off
simultaneously, at random times in an environment where there is little or
no likelihood of a valid X-10 signal from a neighbor and no coupler or
repeater installed? That was my situation before I did some work on my
electrical system. And similar problems have been reported by others.
I have always understood that the main advantage of Machester encoding is
that the clock is combined with the signal, making it simple to determine
whether there is any data on the line and where one bit ends and another
starts. Downside is that data takes twice as much bandwidth as NRZ. Data
encoded with it is certainly not imune to corruption from noise. That is
why other technologies using it, like 10BaseT, use a cyclic redundancy check
or frame check sum to validate the frame.
I don't claim that noise is the cause of all problems reported, just that it
may be the cause of some.
John Galvin
Mike McMonagle wrote in message
<426d88f0.01062...@posting.google.com>...
>Dan,
>
>Thanks for the answers and observations, but Leviton apparently thinks
>we're all a buncha crackpot hobbyists that don't know well enough to
>outfit our entire house with their high quality product line to get
>things to work properly.
>
>You said that the Hail Ack command has never been utilized by anyone
>other than Leviton's version of the PR511 firmware. I don't have any
>511's, Leviton or otherwise. So about the only thing that could
>generate this Hail Ack (even based on noise alone) would be something
>with a PIC with Leviton firmware? Hmmm, the only Leviton device I have
>is the HCA02, curious.
>
Since a CM11A can send out a "hail request" when attempting to locate other
CM11As, it's not really a stretch, to imagine a CM11A sending out a "hail ack"
in response to a "hail request". I don't have 2 CM11As to test this out, but
it seems perfectly plausible. I realize that this doesn't help shed much
light on the problem at hand.
J.G.
Dave Houston
It's a very, very, very, BIG stretch as the CM11A does nothing on its own. I
do not recall for certain but I do not believe the ActiveHome software even
responds to a Hail Request.
Dave Houston
What is the probability of random noise initiating a valid X-10 signal?
Eons before you can finish the calculation, the weight of the ink needed to
print the leading zeros will have affected the Earth's orbit and sent it
plunging into the Sun. :(
What is the probability of random noise altering a legitimate X-10 signal?
Your guess is as good as any. Sh*t happens.
What is the probability that random noise will repeatedly randomly generate
lengthy sequences of valid X-10 signals? Not even Bob Barker knows!
Dennis Heidner
signal, but instead wait until the second or third valid signal arrived.
If so, the odds that noise would repeat exactly the same - over the next
two power cycles is VERY small.
However if modules are not verifying that the signal is indeed a valid X-10
pattern AND repeated exactly at least one additional time... then yes you
could expect all kinds of strange actions.
Dan Lanciani
| I thought modules were not supposed to take action on the FIRST valid X-10
| signal, but instead wait until the second or third valid signal arrived.
No, that's not how it works. Modules must act on the first valid command.
Remember that in a repeater environment the module may be able to hear only
the repeated command. Since a command may be (and usually is) sent only twice
the module may well hear only the second copy.
| If so, the odds that noise would repeat exactly the same - over the next
| two power cycles is VERY small.
(I'm assuming that by cycles here you mean entire command sequences.)
Remember that all the data bits are already sent twice, once true and once
complemented. If the noise has managed to generate a valid set of complement
bits it isn't at all clear that the odds would be significantly worse for it to
repeat the whole sequence. Or putting it differently, the odds of either are
probably pretty slim. So even if you had the option to wait and compare it
likely wouldn't help as much as you think. But since you don't have the option
is isn't worth worrying about.
| However if modules are not verifying that the signal is indeed a valid X-10
| pattern AND repeated exactly at least one additional time... then yes you
| could expect all kinds of strange actions.
Well, they don't do the latter and I don't expect all kinds of strange
actions. Failing to verify the format (even missing one or two complement
bits--especially late ones) can indeed cause all sorts of disturbing behavior
as we have seen.
Dan Lanciani
ddl@danlan.*com
Malcolm Blackhall
Dave Houston
>Now you are getting ridiculous!
If you mean me, no I'm not being ridiculous - only exagerating a bit. You do
not understand the X-10 powerline protocol. The powerline supplies the
timing information, the phase changes of the Manchester encoding provide
inherent error checking with each bit being send as complementary half-bits.
Look at the pictures in the "Recording the Powerline Bitstream" link on my
web page and tell us how randomly generated noise is going to repeatedly
create patterns like that - it ain't gonna happen.
Dennis Heidner
more like an "X-10" module that accepts signals which appear similar to but
are actually invalid X-10 patterns. If I remember correctly we had a very
long discussion about this earlier last winter on problems for some
Switchlinc modules....
Dave Houston
I think there may be another, simpler explanation for "phantom" events -
those that occur without a valid signal being logged.
If you look at the mod for the overheating CM11A on Ido's page, a noise
spike at just the right time sets the output to ON. My analysis of the
endless dim phenomena indicates a similar mechanism although there it's RF
noise at certain times that appears to trigger the extra dims. Receivers are
possibly subject to the same thing with a noise spike at just the right time
causing them to turn on or off even in the absence of any X-10 command.
I have a fluorescent in one bathroom that frequently turns off a lamp in the
LR when I turn off the bathroom light. So far, I've not been able to catch
any indication of any X-10 signal. Until I loaned it out, I had a PowerLinc
on my laptop monitoring it and never saw an X-10 command at the time of the
event. But, like a watched pot, the frequency of the events seemed to
decrease once I started monitoring. Once I get a chance to create a
powerline recorder, I'll set it to watching this - if I don't move first
which now looks like a probability.
John Galvin
Dave Houston wrote in message <3b366cd9...@nntp.fuse.net>...
>>>
>>
>>
>>Since a CM11A can send out a "hail request" when attempting to locate other
>>CM11As, it's not really a stretch, to imagine a CM11A sending out a "hail
ack"
>>in response to a "hail request". I don't have 2 CM11As to test this out,
but
>>it seems perfectly plausible. I realize that this doesn't help shed much
>>light on the problem at hand.
>
>It's a very, very, very, BIG stretch as the CM11A does nothing on its own. I
>do not recall for certain but I do not believe the ActiveHome software even
>responds to a Hail Request.
>---
I can't dispute what you're saying, but doesn't it seem a bit ridiculous for
the ActiveHome software to be sending out "hail requests", in an effort to
locate other computers, when it doesn't even respond to such requests itself?
It's quite clear that the ActiveHome software DOES indeed send out "hail
requests". What exactly, is the ActiveHome software expecting to respond to
the "hail request"?
J.G.
Malcolm Blackhall
exagerating.
I understand how X-10 signals are encoded on the powerline. And I have read
everything on your site. Thank you for the reference and for sharing the
information with the rest of us.
Not sure what you meant by phase changes with Manchester encoding. Perhaps
you meant state changes on alternate half cycles?
Yes, the way Manchester encoding is used with X-10 does provide some
inherent error checking at the bit level. But this is a very basic error
check and although it will significantly reduce errors, it will not provide
complete immunity.
I agree with you that a continuous 120 kHz signal superimposed on the
powerline should not cause false triggers of devices, at least unless
something else does not interact with it the signal. But that is very
different from the kind of noise one sees in a real world system.
Its pretty obvious that a 0 can be turned into a 1. It is also possible to
turn a 1 into a 0. If two X-10 devices are transmitting at the same time,
it is quite possible that instead of seeing the OR of their 1s you would see
the XOR of their 1s. This is because their 120 kHz oscillators will almost
never be exactly on frequency or in sync with each other and will beat
against each other resulting in a very different wave form that what was
transmitted by either device. Ever listen to a radio when two people are
transmitting on the same frequency simultaneously?
I agree that noise is not likely to create a waveform like the one pictured
in your scope capture. It doesn't have to look like a perfect X-10 signal
for the device to treat it as a valid command. All that is the relevant is
what is on the powerline during 1 msec immediately after the zero crossing,
the input filters do to that signal, how that signal is integrated to a
digital 0 or 1, when and how many times in the 1 msec window the digital
value is sampled, and what the firmware does with the sample to decide
whether is is a 0 or 1.
OT I am following your all house code transmorgrifier with interest and wish
you luck with it. Only comment on it I have is that it probably would have
been easier in the long run to use a microcontroller you can program in
assembly language. More work but fewer limitations. I see you are having
some issues getting the functionality you want out of the BasicX-24.
Neil Cherry
As a side note, my ESM1 had been sitting for 2 weeks with a .1v signal
(the first LED) constantly lit. I thought I may have damaged the
unit. The other day while tearing systems a part I move it (left the
plug still in) and the signal went away. I moved it back and the
signal was back. Seems my modem has an external power supply which
generated a field capable of being detected by the ESM1 (the ESM1 was
sitting right on the power supply). Electronic fields can be generated
and things can be affect even though the controlling device didn't
actuate. This would be in line with Dave's statements above.
--
Linux Home Automation Neil Cherry nch...@home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
http://linuxha.sourceforge.net/ (SourceForge)
Dave Houston
When I first got the ESM1, I found a continuous "bad" signal coming from a
LynX-10/TW523. (The CM11A that was online never detected anything since it
will only report "good" signals.) It turned out that the PC was plugged into
a different circuit than the TW523. There must have been a ground loop. I
wonder if some of the erratic behaviors reported for CM11As might have a
similar cause.
And, the two PowerLincs that exhibited problems both started acting up when
connected to a laptop that went from running on the AC adapter plugged into
the same circuit as the PowerLinc to running on battery. Since the PowerLinc
decides whether it is in TTL mode (TW523 emulation) or RS-232 ASCII mode
based on one pin either being grounded or not grounded, I wonder if the
absence of a common ground between the PowerLinc and laptop might be a
factor.
Dave Houston
>Forgot the smiley face at the end of the sentence. I know you were just
>exagerating.
>
>I understand how X-10 signals are encoded on the powerline. And I have read
>everything on your site. Thank you for the reference and for sharing the
>information with the rest of us.
>
>Not sure what you meant by phase changes with Manchester encoding. Perhaps
>you meant state changes on alternate half cycles?
Yeah, being an old fart trained in Economics instead of an EE, I don't
always use the appropriate jargon.
>Yes, the way Manchester encoding is used with X-10 does provide some
>inherent error checking at the bit level. But this is a very basic error
>check and although it will significantly reduce errors, it will not provide
>complete immunity.
>
>I agree with you that a continuous 120 kHz signal superimposed on the
>powerline should not cause false triggers of devices, at least unless
>something else does not interact with it the signal. But that is very
>different from the kind of noise one sees in a real world system.
>
>Its pretty obvious that a 0 can be turned into a 1. It is also possible to
>turn a 1 into a 0. If two X-10 devices are transmitting at the same time,
>it is quite possible that instead of seeing the OR of their 1s you would see
>the XOR of their 1s. This is because their 120 kHz oscillators will almost
>never be exactly on frequency or in sync with each other and will beat
>against each other resulting in a very different wave form that what was
>transmitted by either device. Ever listen to a radio when two people are
>transmitting on the same frequency simultaneously?
But...
Not only does there have to be a noise source that is 120KHz - if it changes
a 0 into a 1, it has to also turn the 1 that either follows or precedes the
0 into a 0. Otherwise, it will be an invalid X-10 signal.
>I agree that noise is not likely to create a waveform like the one pictured
>in your scope capture. It doesn't have to look like a perfect X-10 signal
>for the device to treat it as a valid command. All that is the relevant is
>what is on the powerline during 1 msec immediately after the zero crossing,
>the input filters do to that signal, how that signal is integrated to a
>digital 0 or 1, when and how many times in the 1 msec window the digital
>value is sampled, and what the firmware does with the sample to decide
>whether is is a 0 or 1.
I still think you do not fully understand. After the 4 bits (1110) of the
startcode, each powerline half-cycle only represents a half-bit. Each
half-bit is always paired with a half-bit that is its complement. For noise
to change a bit, it must flip both half-bits. 10=1 and 01=0. To change a
full bit, 10 must be changed to 01. It requires noise that can change a 1 to
0 on one half cycle and then do just the opposite on the next half cycle.
>OT I am following your all house code transmorgrifier with interest and wish
>you luck with it. Only comment on it I have is that it probably would have
>been easier in the long run to use a microcontroller you can program in
>assembly language. More work but fewer limitations. I see you are having
>some issues getting the functionality you want out of the BasicX-24.
I'm old and in very poor health. It would have taken me longer to learn to
program a microcontroller in assembler than I may have so I decided to work
with what I already knew. And I can only spend an hour or so a day
writing/testing code before I get too fatigued to think clearly. It's easier
for me to set small tasks that fit that schedule working in Basic than it
would be in assembler. The main advantage of the BX-24 is that it is easy to
work with and can be upgraded just by loading new firmware. And users will
not need any programing borads to load the firmware. I'm trying to push its
limits a bit and what I'm trying to do with the bit-banged serial ports was
not anticipated in the BX-24 design. I've had five serial ports running -
it's just that I can't find a way to do that and capture the RF. I can do
two serial ports and capture the RF which will probably be adequate for 95%
of the users but I want more.
I actually bought a Rabbit2000 first but decided it would be easier for me
to work with the BX-24. And, everything that I do is done with a view
towards teaching some of my grandkids about microcontrollers and
programming. They can grasp the BX-24 rather easily and see the results
immediately.
Malcolm Blackhall
beats with the signal, it is quite possible that it will change 01 to 10 and
10 to 01:
01 XOR 11 = 10
10 XOR 11 = 01
But, I think we have gone far enough off the original repeater topic.
To summarize and conclude. X-10 receivers are looking for a signal amidst
the noise which is always there on the powerline. The receivers are very
good at distinguishing X-10 signal from noise when there is plenty of
headroom and not so good when there is little. Most of the time when the
receiver fails to distinguish signal from noise, it misses the valid
command. But some times, maybe not frequently, but some times, it
misinterprets noise as a valid command. And if the device happens to be a
repeater, it makes sure every other device on the system sees it as a valid
command, possibly causing problems where there were none before the repeater
was added to the system. This may explain some of the complaints people
have made about the HCA02.
This misinterpretation happens because the receiver is using just a subset
of the information available riding on the powerline carrier. It is not
enough information to reliably distinguish signal from noise under all
circumstances. How the receiver is implemented will determine the
circumstances under which the receiver will err. So, it is entirely
possible that an HCA02 may cause problems where a 6201 did not. Using the
appropriate signal processing hardware and algorithms, it is possible to
reliably detect a valid signal even well below the noise threshold and
virtually eliminate false triggers. But X-10 technology is not there yet as
far as I know.
Dave Houston
that follows.
"Malcolm Blackhall" <blac...@midtown.net> wrote:
---
Neil Cherry
>Actually, if the same noise is there on both half cycles, and the noise
>beats with the signal, it is quite possible that it will change 01 to 10 and
>10 to 01:
>
>01 XOR 11 = 10
>10 XOR 11 = 01
HUH?! That is not possible, noise cannot change a 1 to a 0. It can
change a 0 to a 1. So you get a 11, something that looks like a ...
BSC (sorry Dave just kidding :-).
Neil Cherry
>When I first got the ESM1, I found a continuous "bad" signal coming from a
>LynX-10/TW523. (The CM11A that was online never detected anything since it
>will only report "good" signals.) It turned out that the PC was plugged into
>a different circuit than the TW523. There must have been a ground loop. I
>wonder if some of the erratic behaviors reported for CM11As might have a
>similar cause.
That shouldn't have cause a problem as the TW-523 is opto isolated.
The ground reference it's device uses is from the device. Since the
Lynx uses a transformer it's ground is linked to the PC's ground. So
everything looks kosher, but this section of electronics is not
speciality.
>And, the two PowerLincs that exhibited problems both started acting up when
>connected to a laptop that went from running on the AC adapter plugged into
>the same circuit as the PowerLinc to running on battery. Since the PowerLinc
>decides whether it is in TTL mode (TW523 emulation) or RS-232 ASCII mode
>based on one pin either being grounded or not grounded, I wonder if the
>absence of a common ground between the PowerLinc and laptop might be a
>factor.
>---
>BX24-AHT All Housecode Transceiver is at:
>http://www.laser.com/dhouston/
This sounds possible, I may have to get me one of the PowerLincs just
to see what it is.
John Galvin
I think what he was trying to say, was that if there was 120khz "noise" on the
line that just so happened to be 180 degrees out of phase and of the same
amplitude as the desired signal, then the "noise" would cancel the signal and
that would turn a "1" into a "0". I don't really see this as being likely at
all, but it is theoretically possible.
I don't know what X-10 transmitters do, but if I were designing one, I might
think about sync'ing the 120kHz generator to the incoming line frequency (50
or 60 hz). In that case, whenever there were collisions, the result would be
predictable.
J.G.
Neil Cherry wrote in message ...
Gert Muller
> Look at the pictures in the "Recording the Powerline Bitstream" link on my
> web page and tell us how randomly generated noise is going to repeatedly
> create patterns like that - it ain't gonna happen.
Dave, I second this! At least not in our lifetime (or the life of an X10
module)...
Neil Cherry
>Neil,
>
>I think what he was trying to say, was that if there was 120khz "noise" on the
>line that just so happened to be 180 degrees out of phase and of the same
>amplitude as the desired signal, then the "noise" would cancel the signal and
>that would turn a "1" into a "0". I don't really see this as being likely at
>all, but it is theoretically possible.
Yikes, I'm thinking digitally in an analog world! In other words, your
absolutely correct, sorry.
>I don't know what X-10 transmitters do, but if I were designing one, I might
>think about sync'ing the 120kHz generator to the incoming line frequency (50
>or 60 hz). In that case, whenever there were collisions, the result would be
>predictable.
I'm not exactly sure I'm following your thoughts.
Malcolm Blackhall
is not always the case.
Malcolm Blackhall
even have to be 180 degrees out to look like a zero to the device. At any
other phase relationship the product is a complex wave form that may look
very different than a 120 kHz sine wave.
If you look at the schematics of the RR501 and the TM751 on Ido Bartana's
site, you will see that any two oscillators of the simple types used in
these devices will virtually never be on the exact same frequency or in sync
with each other.
Malcolm Blackhall
at one time or another. Unfortunately, it isn't digital until the
microcontroller on the device decides whatever it is being fed by the
circuitry in front of it is a 0 or 1.