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.....