Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[coder since cp290]

I use a Cm15a but down run AHP..  I have an
interface written to run on Linux.

I have noticed something which may be part of
the problem seen my many users however...

It seems, the cm15a doesn't wait for "clear
time" on the power line before xmiting.  For
example, lets say that a a1-on is coming down
the pipe followed by an a2-on, and the a1-on
triggers a macro when send b1-on.  The b1-on
could get lost as it gets sent while the
a2-on is still on the powerline, and can
cause both the b1-on and a2 on to be
corrupted.  Another case of this is c1 coming
in thru RF and being rexmitted to the
powerline, while c1 is already coming in thru
the powerline, due to a second tranciever -
the send and rec get trashed on the powerline...

I'll bet that that the Cm15a had the same
basic logic/code as the the cm11, but if the
processor in the cm11 is slower than that in
the cm15a, powerline collisions may not have
happened as often.

As the Cm15a with AHP is more "module smart"
than many interfaces, things like requesting
module status could induce more colisions,
and could infact cause the module to "hang".
FW wise, the interface could get lost due to
powerline collisions (causing a "hang").
With the Cm15a connected to a PC, part of
it's processor is doing the host interface,
reducing the chance of collisions...

I've seen "collison problems" even in my own
environment, especially if a motion detector
is in the picture.  The Cm15a will send to
the powerline, even if there's other x10
traffic in process...

Anyway, just some thoughts.....

[jj]

coder since cp290,
I wish x10.com would listen to you, you
are right on, in your forums. I've tried to
tell them in lamens terms, their clock is
hoakey.. you explain it a little better in
tech terms. Stay on it, hell, maybe they
should hire you as a consultant.. thanx

[coder since cp290]

JJ..

They don't want to hear it, as it indicates a
problem with the firmware in the cm15a, and
it seems they don't have a way to repair that...

[Brian H]

OH they could fix it if it was a firmware
thing. I just doubt a Recall of all unit
will happen! The thing is reported to have a
collision detector and the wait for clear
logic but the tests you have done shows it
may not work correctly.

[coder since cp290]

Brian H:

"The thing is reported to have a
collision detector and the wait for clear..."


It could be that it's "almost working"..
Detects the collision but doesn't retry.
Down at the PLC level, a "A1-On" is actually
an "A-1" followed by an "A-On", and I'll
often see the "A-1" on the powerline, but not
the "A-On".  Like it's forgetting the second
part..

Up until today I has a 750ms (3/4 sec) before
the program would send these commands and am
now trying it with a 1000ms (1 sec) delay.
You'd think the cm15a would know that it's
busy sending a command and not try to send
another, but who knows!  All I know is I'm
seeing X10 stuff NOT making it to the
powerline, atleast in a way that two other
monitors can see it (or the modules themselves)

[Brian H]

Sounds like you are on to something. Mine
for now is in the box as I don't even use it
as a all house code tranceiver anymore.
Though mine shows slightly less than an
RR501 range. I have seen some reported as 20
feet for keychain remotes. Did find that the
antenna horizontal in my case made it much
better or turning the keychain remote on its
side also helped.

[coder since cp290]

Brian H..

You'll notice that some running AHP also note
that it "runs better" if they insert delays
in macros....

I wonder how well the cm15a queues stuff that
can't be sent right away to the powerline.
Can it queue 1, 2, or 10 pending x10
transmissions if the powerline is busy?

The truth of the matter is when a macro
executes, the Cm15a can generate a big
backlog while waiting for stuff to be sent on
the powerline.

I'll bet that a simple macro which does:

a1-on
a2-on
a3-on
a4-on
a5-on
a6-on
a7-on
a8-on
a9-on
a10-on
a11-on
a12-on
a13-on
a14-on
a15-on
a16-on

could cause problems.....(with no delays)

[roger1818]

Coder:  That sounds like an interesting
experiment though that exact one might not
cause problems as it would probably
translate it to the following in powerline
messages:

A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A_ON

Another experiment to try would be:

a1-on
b1-on
a2-on
b2-on
...
a16-on
b16-on

This should force an ON command after each
address message.

[SteveRF]

There are just some things I do not want the
cm15a to wait for... example..if I walk into
my bathroom, I do not want the cm15a to wait
until it completes 3 macros with ump-teen
dozen delays built into it... I want it to
respond immediately to the motion detector
and send a "light on".. using the bathroom in
the dark is not pleasant..hehe   Pretty soon
we will be asking for unconditional powerline
commands and the ability to set priorities.
..eek...and the list will grow and grow...
should be fun to watch...