New to X-10
Doug Hulst
tips? Anything to make startup smooth? Any special ideas of what to
control? Any info at all?
Thanks....
Mark Gilmore
such that it can "lock up" if it receives an X-10 command
(like from an X-10 console) at the same time that it is
sending one. If this occurs, you can usually clear it up
by pushing any button on an X-10 console - The reception
of this second command will cause it to "wake up".
BTW, other X-10 transceivers do NOT have this problem,
as OTHER companies work out such obvious bugs during
development :-). Later.
--
Mark Gilmore
Omnipotence (ECS Home Automation Software)
om...@usit.net
http://www.usit.com/omnip
Dave Houston
>Hi Doug, 1 quick warning: The CM11A has a design flaw
>such that it can "lock up" if it receives an X-10 command
>(like from an X-10 console) at the same time that it is
>sending one. If this occurs, you can usually clear it up
>by pushing any button on an X-10 console - The reception
>of this second command will cause it to "wake up".
>BTW, other X-10 transceivers do NOT have this problem,
>as OTHER companies work out such obvious bugs during
>development :-). Later.
Mark,
What evidence do you have to support this diagnosis?
CM11A lockups appear to come in at least 3 flavors. I've seen no evidence
that collisions are at fault and would think them to be much more frequent
if they are caused by collisions.
One type occurs when a CM11A that has been running standalone is reconnected
to the serial port. This appears to be a port initialization problem and can
usually be cleared by unloading/reloading communications in ActiveHome.
Another type was initially identified by Dan Lanciani who (as I recall)
discovered that a flawed repeater was partially echoing commands and the
CM11A was apparently interpreting these as the beginning of a command and
going into a state where it waited for the balance of the command. This type
can be cleared by sending a command with another transmitter. Maybe this is
related to your 'collisions'.
A third type appears to be related to power outages. Neil Cherry first
reported that he could reliably induce his CM11A to lockup by cycling power
to it. I was unable to duplicate that in terms of the frequency that Neil
reported although I did see one lockup in about 75 tries. But both of my
CM11As have frequently locked up after thunderstorm related, brownout style
power outages. Usually, these can only be cured by unplugging the CM11A and
removing the batteries and waiting for a lengthy period (some have reported
15 minutes - I've found it to be close to 30).
On the lockup issue, X-10 has assumed an ostrich-like stance. At least, I've
seen no official statement from them.
You refer to 'other' X-10 transceivers that do not have this problem. I'm
unaware of ANY X-10 tranceivers that are not manufactured by X-10. What
tranceivers are you talking about? Who makes them? Can they handle the full
set of X-10 codes?
A few weeks back, your web page was claiming that your software could
automagically clear CM11A lockups without human intervention. Have you
changed your mind?
Dave Houston
http://Commander-X.com
Dan Lanciani
| Mark Gilmore <om...@usit.net> wrote:
|
| >Hi Doug, 1 quick warning: The CM11A has a design flaw
| >such that it can "lock up" if it receives an X-10 command
| >(like from an X-10 console) at the same time that it is
| >sending one. If this occurs, you can usually clear it up
| >by pushing any button on an X-10 console - The reception
| >of this second command will cause it to "wake up".
| >BTW, other X-10 transceivers do NOT have this problem,
| >as OTHER companies work out such obvious bugs during
| >development :-). Later.
I'd love to find an X10<->RS232 interface that doesn't have
any bugs... :)
[...]
| Another type was initially identified by Dan Lanciani who (as I recall)
| discovered that a flawed repeater was partially echoing commands and the
| CM11A was apparently interpreting these as the beginning of a command and
| going into a state where it waited for the balance of the command. This type
| can be cleared by sending a command with another transmitter.
Not exactly. When I first got a CM11a I tried sending it an extended
code command (only) from some other random interface. I noticed that
this rendered the CM11a deaf & dumb to the serial interface. On sending
another (any other) command, I found that the CM11a started its upload
poll and told me about an extended code sequence consisting of the bits
associated with two extended code commands and part of the second command.
From this I conclude that the CM11a waits for the total number of bits
required by the current version of the extended code sequence if it sees
the header (i.e., the extended code command). Since the transmitter was
treating the extended code command just like any other command, it had
sent it twice.
Much later I obtained some of the (then) new 2-way modules and found that
they flooded the line when plugged in. After removing them, I saw that
the CM11a was in the same waiting-for-extended-code state as above. My
Leviton repeater, while not "flawed" per se, did pre-date the new extended
code definition and attempted to repeat the initial frame in the normal
way, colliding with the rest of the message. This had the dual effect of
provoking the 2-way module to re-send its power-up signal (forever) and
hanging the CM11a. Any collision (or even line noise) that looks like
the beginning of an extended code sequence will hang the CM11a for the
same reason.
[...]
| You refer to 'other' X-10 transceivers that do not have this problem. I'm
| unaware of ANY X-10 tranceivers that are not manufactured by X-10. What
| tranceivers are you talking about? Who makes them? Can they handle the full
| set of X-10 codes?
I suspect he was talking about other interfaces that go between the TW523
and the host. Unfortunately, extended code sequences have become important
enough that these are almost not worth looking at anymore, even if they are
bug free (which most aren't :). A while back I saw an advertisement for a
TW523 replacement that was supposed to be backwards-compatible but also pass
extended code and DIM/BRI commands correctly. I think it was going to be
from SmartLinc, but I haven't seen it yet...
Dan Lanciani
ddl@danlan.*com
Dave Houston
>In article <36b2b870...@nntp.fuse.net>, dhou...@fuse.net (Dave Houston) writes:
>| Mark Gilmore <om...@usit.net> wrote:
[snip]
>| Another type was initially identified by Dan Lanciani who (as I recall)
>| discovered that a flawed repeater was partially echoing commands and the
>| CM11A was apparently interpreting these as the beginning of a command and
>| going into a state where it waited for the balance of the command. This type
>| can be cleared by sending a command with another transmitter.
>
>Not exactly. When I first got a CM11a I tried sending it an extended
>code command (only) from some other random interface. I noticed that
>this rendered the CM11a deaf & dumb to the serial interface. On sending
>another (any other) command, I found that the CM11a started its upload
>poll and told me about an extended code sequence consisting of the bits
>associated with two extended code commands and part of the second command.
>From this I conclude that the CM11a waits for the total number of bits
>required by the current version of the extended code sequence if it sees
>the header (i.e., the extended code command). Since the transmitter was
>treating the extended code command just like any other command, it had
>sent it twice.
But I saw lockups before I had the LM14A or anything that was sending
extended codes and I'm fairly sure Neil Cherry's reports predated the
release of the 2-way modules.
>Much later I obtained some of the (then) new 2-way modules and found that
>they flooded the line when plugged in. After removing them, I saw that
>the CM11a was in the same waiting-for-extended-code state as above. My
>Leviton repeater, while not "flawed" per se, did pre-date the new extended
>code definition and attempted to repeat the initial frame in the normal
>way, colliding with the rest of the message. This had the dual effect of
>provoking the 2-way module to re-send its power-up signal (forever) and
>hanging the CM11a. Any collision (or even line noise) that looks like
>the beginning of an extended code sequence will hang the CM11a for the
>same reason.
I have only one 2-way module and haven't seen it flood the line. Whenever
it's plugged in, I see it report its presence. However, while I haven't been
able to induce lockups by removing/inserting the LM14A, this might be a
factor in the lockups after power outages. Still, on at least 2 or 3
occasions, I've been in front of one of my PCs when my son replaced a blown
fuse in the basement (I cannot negotiate stairs) caused by a window A/C unit
in the same room as the LM14A and my software has always reported its 'sign
in' code without the CM11A locking up. Hmmmm, I wonder what would happen if
the CM11A and LM14A were both on the same power strip and the power was
cycled?
I can imagine the line flooding if you have multiple 2-way units trying to
'sign in' simultaneously. I think the 'collision avoidance' scheme used by
X-10 in these modules guarantees it.
Robin Mitchell suggested a simple method (so simple and obvious that I never
thought of it) whereby I can force collisions using my two PC/CM11A setup.
It involves having them respond simultaneously to a trigger from a third
transmitter. I've been testing it to see how my software handles CM11A
collisions - but only with standard codes. I've had both respond with the
same transmissions and I've had both respond with different transmissions.
In limited testing, my software handles these collisions gracefully and
neither CM11A locks up.
Specifically...
Both PC/CM11A #1 & #2 respond to G8 OFF from a CP290 by sending D1,D2,D3 ON.
or...
PC/CM11A #1 responds to the trigger with D1,D2,D3 ON while PC/CM11A #2
responds with D4,D5,D6 ON.
Both machines receive the trigger simultaneously from the powerline and both
try to send simultaneously. Whichever sends first gets control while the
second keeps trying to send but is always interrupted by receiving 0x5A
which forces it to handle the incoming signal. Once the first completes, the
second sends its sequence. The end result is always correct.
When I finish the coding I'm in the middle of, I'll try the test using
extended codes. Can you suggest any specific extended codes to use?
>[...]
>| You refer to 'other' X-10 transceivers that do not have this problem. I'm
>| unaware of ANY X-10 tranceivers that are not manufactured by X-10. What
>| tranceivers are you talking about? Who makes them? Can they handle the full
>| set of X-10 codes?
>
>I suspect he was talking about other interfaces that go between the TW523
>and the host. Unfortunately, extended code sequences have become important
>enough that these are almost not worth looking at anymore, even if they are
>bug free (which most aren't :). A while back I saw an advertisement for a
>TW523 replacement that was supposed to be backwards-compatible but also pass
>extended code and DIM/BRI commands correctly. I think it was going to be
>from SmartLinc, but I haven't seen it yet...
I suspect the same but its the TW523 that's the tranceiver in theses cases,
not the other interfaces.
I'd certainly be interested in any new transceiver that can do what the
CM11A does but without the lockups.
Dave Houston
http://Commander-X.com
Dave Houston
[snip]
>Hmmmm, I wonder what would happen if the CM11A and LM14A were both on
>the same power strip and the power was cycled?
To answer my own question - jeez, these lock-ups have me talking to
myself...
I unplugged my LM14A, waited a 'while' and plugged it back in. Both PCs
reported its 'sign in' code. Both CM11As were OK.
I moved it to a power strip along with the CM11A for one PC. I turned off
power to the strip, waited a 'while' and turned the power to the strip on.
The CM11A on the power strip locked up; the CM11A on the second machine (in
another room) merely reported the 'sign in' code of the LM14A. I sent a
command from it to unlock the other.
I removed the LM14A from the power strip, waited a 'while' and put it back
in it's original location. Again both PCs reported it's 'sign in' code; both
CM11As were OK.
So, in my case at least, it seems to require both an extended code from the
LM14A and a power outage for the CM11A. And now, at least, I see why I
couldn't duplicate Dan Lanciani's scenario.
This could explain the lock-ups I've seen after power outages. While I was
able to induce a few lockups by cycling power to a CM11A before I had the
LM14A, most of my spontaneous lockups have occurred after power outages
since I've had the LM14A.
Further testing will have to wait - my spinal cord injury doesn't like all
this walking from room to room.
For those who are still interested, here's a partial log of activity as seen
from the PC that was connected to the test CM11A. I've added some comments
in [brackets].
1/30/99 08:56:49 Opening DEBUG.LOG - CM11A - 0.01
[Here is where I first reinsereted the LM14A]
09:13:26 RX: 5A
09:13:26 TX: C3
09:13:26 RX: 5,1,D7,E,10,37
09:13:26 New 2-way unit detected on H2
09:13:26 RX: H2 Extended Data [10,37]
[Here's where I cycled the power on the power strip]
09:18:58 RX: A5
SetTime: 09:18:58 CS: B9 Power fail - reset time
09:18:58 (0 ms) RX: B9
[The CM11A appears to have reset the time OK - it returns the checksum]
[But when it tries to transmit, Commander X is timing out]
[without seeing 0x55 which indicates a CM11A lock up]
09:19:18 (0 ms) TX: H3 [4,D2] CS: D6
CM11A interface ready (1098 ms)
09:19:19 (0 ms) TX: H OFF [6,D3] CS: D9
CM11A interface ready (1099 ms)
09:19:42 (0 ms) TX: A3 [4,62] CS: 66
CM11A interface ready (1099 ms)
09:19:43 (0 ms) TX: A ON [6,62] CS: 68
CM11A interface ready (1153 ms)
[But it hears the signal transmitted by the other CM11A]
["A3 ON" which clears the lockup - the CM11A buffer contents]
[are a mixture as Dan Lanciani says]
09:20:09 (0 ms) RX: 5A
09:20:09 (0 ms) TX: C3
09:20:09 (55 ms) RX: 6,1,0,50,10,37,62 [CM11A buffer contents]
09:20:09 RX: M All Units Off
09:20:09 RX: E13
09:20:09 RX: K9
09:20:09 RX: A3
09:20:09 (26473 ms) RX: 5A
09:20:09 (0 ms) TX: C3
09:20:09 (55 ms) RX: 2,1,62
09:20:10 RX: A On
09:20:34 (0 ms) TX: A ALL UNITS OFF [6,60] CS: 66
09:20:34 (0 ms) RX: 66
09:20:35 (440 ms) RX: 55
CM11A interface ready (440 ms)
[Here is where I put the LM14A back in its usual spot]
09:46:34 RX: 5A
09:46:34 (0 ms) TX: C3
09:46:34 (55 ms) RX: 5,1,D7,E,10,37
09:46:34 New 2-way unit detected on H2
09:46:34 RX: H2 Extended Data [10,37]
09:47:04 (0 ms) TX: A2 [4,6E] CS: 72
09:47:04 (55 ms) RX: 72
09:47:05 (494 ms) RX: 55
CM11A interface ready (494 ms)
09:47:05 (0 ms) TX: A ON [6,62] CS: 68
09:47:05 (55 ms) RX: 68
09:47:05 (439 ms) RX: 55
CM11A interface ready (439 ms)
09:47:06 RX: 5A
09:47:06 (0 ms) TX: C3
09:47:06 (55 ms) RX: 3,2,6E,63
09:47:06 RX: A2
09:47:07 RX: A Off
1/30/99 09:53:54 Closing DEBUG.LOG
Dave Houston
http://Commander-X.com
Dan Lanciani
| ddl@danlan.*com (Dan Lanciani) wrote:
[...]
| >Not exactly. When I first got a CM11a I tried sending it an extended
| >code command (only) from some other random interface. I noticed that
| >this rendered the CM11a deaf & dumb to the serial interface. On sending
| >another (any other) command, I found that the CM11a started its upload
| >poll and told me about an extended code sequence consisting of the bits
| >associated with two extended code commands and part of the second command.
| >From this I conclude that the CM11a waits for the total number of bits
| >required by the current version of the extended code sequence if it sees
| >the header (i.e., the extended code command). Since the transmitter was
| >treating the extended code command just like any other command, it had
| >sent it twice.
|
| But I saw lockups before I had the LM14A or anything that was sending
| extended codes and I'm fairly sure Neil Cherry's reports predated the
| release of the 2-way modules.
The above does not relate to the LM14a. I found (one of) the hanging problem(s)
with the CM11a immediately after it was released at retail. (I had one on back-
order for months until it was released.) This was before the LM14a existed. I
sent an old-style extended code command from another interface (PLLINK, LynX-10,
whatever). The CM11a hung. It's that simple. You can try it for yourself. Go
to your LynX-10 and send an extended code command. Observe the CM11a hang. Any
noise or collision that creates the same pattern will do the same thing.
| >Much later I obtained some of the (then) new 2-way modules and found that
| >they flooded the line when plugged in. After removing them, I saw that
| >the CM11a was in the same waiting-for-extended-code state as above. My
| >Leviton repeater, while not "flawed" per se, did pre-date the new extended
| >code definition and attempted to repeat the initial frame in the normal
| >way, colliding with the rest of the message. This had the dual effect of
| >provoking the 2-way module to re-send its power-up signal (forever) and
| >hanging the CM11a. Any collision (or even line noise) that looks like
| >the beginning of an extended code sequence will hang the CM11a for the
| >same reason.
|
| I have only one 2-way module and haven't seen it flood the line.
That's because you don't have a Leviton repeater (or any other pre-extended-code
repeater)! The above description is about an interaction between the LM14a and
a repeater. You cannot reproduce it without the repeater. The LM14a will flood
the line only if something (the repeater) stomps on each of its transmissions.
| Whenever
| it's plugged in, I see it report its presence.
That's correct. And if it detects a collision it will try again and again
until it sends the whole report successfully. If you have a pre-extended-code
repeater then the LM14a will see a collision every time it sends. It will
flood the line with infinite retries.
[...]
| I can imagine the line flooding if you have multiple 2-way units trying to
| 'sign in' simultaneously. I think the 'collision avoidance' scheme used by
| X-10 in these modules guarantees it.
No, it doesn't. Recall that I already did this experiment and posted the
results with up to four 2-way modules powering up at the same time. (You
even commented on it.) There are no obvious problems and all four reports
are correctly transmitted. However, if you have firmware version 7 (or
presumably earlier) in your CM11a the actual report to the host gets corrupted
when (about) 3 or more extended code messages are pending. Firmware version 8
fixes this problem, although it introduces some of its own. Again, this is
strictly a CM11a/host communication problem, not a line collision problem.
| Robin Mitchell suggested a simple method (so simple and obvious that I never
| thought of it) whereby I can force collisions using my two PC/CM11A setup.
As I've mentioned before, a *really* easy way is to tap keys on a maxi
(or older mini) controller. Maxi controllers are pretty cheap and are
extremely useful tools if you are serious about this kind of work...
| It involves having them respond simultaneously to a trigger from a third
| transmitter. I've been testing it to see how my software handles CM11A
| collisions - but only with standard codes. I've had both respond with the
| same transmissions and I've had both respond with different transmissions.
| In limited testing, my software handles these collisions gracefully and
| neither CM11A locks up.
|
| Specifically...
|
| Both PC/CM11A #1 & #2 respond to G8 OFF from a CP290 by sending D1,D2,D3 ON.
|
|
| or...
|
| PC/CM11A #1 responds to the trigger with D1,D2,D3 ON while PC/CM11A #2
| responds with D4,D5,D6 ON.
|
| Both machines receive the trigger simultaneously from the powerline and both
| try to send simultaneously. Whichever sends first gets control while the
| second keeps trying to send but is always interrupted by receiving 0x5A
| which forces it to handle the incoming signal.
But which is it? If they try to send simultaneously then both messages
should be corrupted by the resulting collision. But if one "sends first"
and gets control, they probably didn't try to send at the same time in
the first place. You probably need a third device to monitor the interaction
to see what is really going on.
| Once the first completes, the
| second sends its sequence. The end result is always correct.
The CM11a is pretty good about collision *avoidance*. As you noted, it
won't even let you get a command sequence sent while it is busy interrupting
you with upload polls. I suspect (but can't be sure) that your experiment
did not in fact result in any collisions.
There may be a more serious problem with this approach, though. Are you
trying to generate these collisions in order to provoke bugs in the CM11a?
This may not work. Consider that if the CM11a is participating in a collision
then it must, by definition, be sending. If it is sending then (as far as I
can tell) it is not receiving. If it is not receiving then it will not get
hung looking for the rest of an extended code sequence. Thus, for at least
this particular bug, you need two devices other than the target CM11a to
create a collision that is then received by the target CM11a. Of course,
this is not to say that there aren't other CM11a bugs that you might find
this way.
[...]
| >I suspect he was talking about other interfaces that go between the TW523
| >and the host.
[...]
| I suspect the same but its the TW523 that's the tranceiver in theses cases,
| not the other interfaces.
Until the mandatory X10 usage dictionary is published, I think we can be a
little tolerant of the terminology people choose to use, especially when
it is pretty clear what was meant. :)
Dan Lanciani
ddl@danlan.*com
Arman
<<<< SNIP SNIP>>>>
> [...]
> | I can imagine the line flooding if you have multiple 2-way units trying to
> | 'sign in' simultaneously. I think the 'collision avoidance' scheme used by
> | X-10 in these modules guarantees it.
>
> No, it doesn't. Recall that I already did this experiment and posted the
> results with up to four 2-way modules powering up at the same time. (You
> even commented on it.) There are no obvious problems and all four reports
> are correctly transmitted. However, if you have firmware version 7 (or
> presumably earlier) in your CM11a the actual report to the host gets corrupted
> when (about) 3 or more extended code messages are pending. Firmware version 8
> fixes this problem, although it introduces some of its own. Again, this is
> strictly a CM11a/host communication problem, not a line collision problem.
>
<<< SNIP SNIP >>>>
>
> Dan Lanciani
> ddl@danlan.*com
Dan:
You reference Firmware Versions 7 and 8 in the above. How does one
determine the Firmware version of a CM11a?
I have two. One has a sticker with "6L49" on it, the other has "7B09".
Are these numbers usefull for the derermination?
Thanks,
Tom
Neil Cherry
>But I saw lockups before I had the LM14A or anything that was sending
>extended codes and I'm fairly sure Neil Cherry's reports predated the
>release of the 2-way modules.
Gee, I'm famous, I have a CM11A Lockup named after me :-).
Now my apologies for not adding much to your current discussion (I've
saved it and will re-read it later). But I think I'm getting a much
better understanding of what is going on during "my lockup". I believe
that Dan L. stated in the past it is related to brown outs and he is
correct. If I get a momentary loss off power or drop in power (my UPS
kicks in but none of my lights become perceivably dim, still a
brown-out) the CM11A will lockup to the point where it can not be
restarted with out pulling the batteries and letting it sit. I've seen
messages on sci.electronic.* and the PIC list about brown out problems
with the PIC's (the 16C58 doesn't have brown out
protection built in). One remedy to this would be to add a reset
switch to the PIC and adding a Dallas reset chip or other similar
chip. Preferably one which will correctly handle brown-outs. Of course
this would void your warranty.
Now the above takes liberty with the fact that to fix the problem now
we have to pull the batteries and let it sit for a while (capacitors T
(tao) maybe?). And that the PIC has an operating voltage of 2.0v -
6.25v DC. Important facts but I really don't feel like going in the
entire electronics discussion as it requires me to make a lot of
assumptions about the circuit (I have really not worked on the
schematic yet).
--
Linux Home Automation Neil Cherry nch...@home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
Dan Lanciani
| You reference Firmware Versions 7 and 8 in the above. How does one
| determine the Firmware version of a CM11a?
It's returned in one of the fields of a "get general information" type
command described in the protocol document. You can look at my x10 daemon
on www.danlan.com/homeauto.html for an example of reading the version number.
| I have two. One has a sticker with "6L49" on it, the other has "7B09".
|
| Are these numbers usefull for the derermination?
I don't know. They may well mean something, but you'd have to ask X10
how to decode them. :)
Dan Lanciani
ddl@danlan.*com
Bill Jones
> | determine the Firmware version of a CM11a?
>
> It's returned in one of the fields of a "get general information" type
> command described in the protocol document.
The "Protocol" Document I have doesn't mention "get general information"
(I did a search for the word "general" and got nothing). I got my
protocol document from the X10 site. Is your protocol document from some
other source?
The protocol document I have refers to a "Status" request, which returns
the Firmware Version along with dozens of other things. The problem is,
that on MY CM11a, it returns a "2" , which is far away from, 7 or 8 ,
unless there is some translation table somewhere. My CM11a is new,
coming from X10 this past December. I guess one possibility is that I am
looking at the wrong 4 bits, but all the other things I extracted from
the status message looked OK. Anyway, this version 7/8 thing has me a
bit confused also.
BTW, I wrote a small program just for my own purposes that turns on and
off switches (no dimming or timers or macros yet), and the program also
does a status request, showing the raw bytes returned, extracting the
time/day number and version number (possibly an incorrect version
number, but it gives the raw bytes so you can calculate your own if I am
interpreting it wrong). The program also has two buttons which will
cancel the two poll situations that often locks up the CM11a<-->computer
interface, so if the program is beeping at you, you can hit the stop
poll button. If anyone is interested, it is at:
http://www.megalink.net/~wejones/bjx10com.exe
It requires vbrun300.dll which most people have, but is also on my home
page.
Program is very crude, as it was just intended for my own use, so use it
at your own risk. Unfortunately, it assumes that the CM11a is on COM1 .
It is a 16 bit pgm, but I run it on WIN95.
+----------------------------------+
| Bill Jones, N3JLQ,Sweden, Maine |
| wej...@megalink.net |
| http://www.megalink.net/~wejones |
+----------------------------------+
Bill Jones
> the Firmware Version along with dozens of other things. The problem is,
> that on MY CM11a, it returns a "2" , which is far away from, 7 or 8 ,
> unless there is some translation table somewhere. My CM11a is new,
> coming from X10 this past December. I guess one possibility is that I am
> looking at the wrong 4 bits, but all the other things I extracted from
> the status message looked OK. Anyway, this version 7/8 thing has me a
> bit confused also.
I went back and checked my program, and I was grabbing the wrong byte,
however NOW the thing returns "1" instead (I have uploaded corrected
program). Ie I'm still confused. It is possible that the bits of the 4
bit number are reversed, ie 1=8 , 2=4 , 3=12 , etc, but the question is,
which is right. The documentation is ambiguous. Is there any press
release from the manufacturer that tells what the Firmware should be? Is
it possible that my recently purchased CM11a is really version 1? The
byte containing the housecode and Firmware Version is 97, which is
01100001 binary when I monitor housecode A, and it is 225, ie 11100001
binary when I monitor housecode B, which suggests that the 1 bits are to
the right in each 4 bit segment. This would seem to aggree with the
Firmware Version really being "1", and not "8" in my unit.
Any suggestions?
Dan Lanciani
| > | You reference Firmware Versions 7 and 8 in the above. How does one
| > | determine the Firmware version of a CM11a?
| >
| > It's returned in one of the fields of a "get general information" type
| > command described in the protocol document.
|
| The "Protocol" Document I have doesn't mention "get general information"
| (I did a search for the word "general" and got nothing). I got my
| protocol document from the X10 site. Is your protocol document from some
| other source?
|
| the Firmware Version along with dozens of other things.
Yes, that's the "get general information" type command.
| The problem is,
| that on MY CM11a, it returns a "2" , which is far away from, 7 or 8 ,
| unless there is some translation table somewhere.
Nope, no table for the numbers I'm using. Perhaps there *is* a table to
translate 7 to 1.0 or the like.
| My CM11a is new,
| coming from X10 this past December. I guess one possibility is that I am
| looking at the wrong 4 bits, but all the other things I extracted from
| the status message looked OK.
You can look at my code on www.danlan.com/homeauto.html. Perhaps I got
it wrong, but the number did advance nicely from 7 to 8 with the new
version...
Dan Lanciani
ddl@danlan.*com
Dan Lanciani
| > The protocol document I have refers to a "Status" request, which returns
| > that on MY CM11a, it returns a "2" , which is far away from, 7 or 8 ,
| > coming from X10 this past December. I guess one possibility is that I am
| > looking at the wrong 4 bits, but all the other things I extracted from
| > bit confused also.
|
| I went back and checked my program, and I was grabbing the wrong byte,
| however NOW the thing returns "1" instead (I have uploaded corrected
| program).
Hmm, if you were grabbing the wrong byte before, did the housecode just
happen to come out right? (You mentioned that the other data looked good.)
| Ie I'm still confused. It is possible that the bits of the 4
| bit number are reversed, ie 1=8 , 2=4 , 3=12 , etc, but the question is,
| which is right. The documentation is ambiguous.
They do manage to make it look more complicated than it is. I just and the
byte with 0x0f. I don't reverse any bits. I did originally verify that all
the other bits work that way by allowing Activehome to set the date, reading
it back, setting it myself, and reading it back again to make sure I had it
right. But who knows for sure?
Dan Lanciani
ddl@danlan.*com
Bill Jones
> | however NOW the thing returns "1" instead (I have uploaded corrected
> | program).
>
> Hmm, if you were grabbing the wrong byte before, did the housecode just
> happen to come out right? (You mentioned that the other data looked good.)
I wasn't printing out the housecode at the time, but rather just printed
out the raw bytes, and checked them manually. I was only printing out
the date/time info. When I grabbed the version byte, I grabbed the 7th
byte instead of the 8th.
> | Ie I'm still confused. It is possible that the bits of the 4
> | bit number are reversed, ie 1=8 , 2=4 , 3=12 , etc, but the question is,
> | which is right. The documentation is ambiguous.
>
> They do manage to make it look more complicated than it is. I just and the
> byte with 0x0f.
Thats the same thing I did. I must have a different version software in
my module.
Bill Jones
> | coming from X10 this past December. I guess one possibility is that I am
> | looking at the wrong 4 bits, but all the other things I extracted from
> | the status message looked OK.
>
> it wrong, but the number did advance nicely from 7 to 8 with the new
> version...
you mean you bought a new module that had new firmware, or that you
uploaded new firmware to it.
If the latter, perhaps that is my problem, as I've never updated
anything. I just assumed that a new module would have new firmware in
it.
Mark Lloyd
>CM11A lockups appear to come in at least 3 flavors. I've seen no evidence
>that collisions are at fault and would think them to be much more frequent
>if they are caused by collisions.
>
>One type occurs when a CM11A that has been running standalone is
reconnected
>to the serial port. This appears to be a port initialization problem and
can
>usually be cleared by unloading/reloading communications in ActiveHome.
>
98.
www.graphicaldynamics.com
that allows alarms to be set, which can sound a tone, run a program, run a
.WIL program, or reboot the computer. I have one alarm set to reboot the
computer at 5:55 AM (I want to be able to use the computer at 6). Most of
the time my ActiveHome software won't work. To solve this, I set another
alarm for 5:59 AM which runs the .WIL (Windows Interface Language, comes
with CLOCKMAN) program that I have attached. Line 1 checks if the
communications program is present and if so, unloads it. Line 2 gives
Windows time to finish the unload. Line 3 loads communications.
Dave Houston
>>usually be cleared by unloading/reloading communications in ActiveHome.
>>
>I unload/reload communications using the CLOCKMAN program for Windows
>95/98.
>www.graphicaldynamics.com
>that allows alarms to be set, which can sound a tone, run a program, run a
>.WIL program, or reboot the computer. I have one alarm set to reboot the
>computer at 5:55 AM (I want to be able to use the computer at 6). Most of
>the time my ActiveHome software won't work. To solve this, I set another
>alarm for 5:59 AM which runs the .WIL (Windows Interface Language, comes
>with CLOCKMAN) program that I have attached. Line 1 checks if the
>communications program is present and if so, unloads it. Line 2 gives
>Windows time to finish the unload. Line 3 loads communications.
>
I don't use ActiveHome so I don't have the problem. Back when I did have
ActiveHome on my Win95 machine, I almost never saw a problem on a reboot but
then I did not use the burst mode for communications. Unless you have other
reasons for the scheduler, I think you could have saved $80.
Dave Houston
http://Commander-X.com