I have repeated a test several times using both ActiveHome and my Commander
X software. Whichever software is in use, the CM11A locks _everytime_ that
both it and the _drained_ LM14A are powered up simultaneously (as they would
be after a power outage of sufficient duration to drain the LM14A).
While this appears to be related to the general lock up problem (at least
those that can be cleared with an X10 signal from another transmitter), it
does not appear to have anything to do with collisions as only the LM14A is
transmitting. The CM11A buffer appears to hold garbled data with two of the
bytes being the same as a successful LM14A "sign in" but I see no way to
attribute this to anything external to the CM11A. It appears that it is the
CM11A that is doing the garbling. I do not know the firmware levels of my
CM11As. I believe there is a way to get this using keyboard combinations in
ActiveHome but think I lost the list of keyboard commands when I installed a
new hard disk a few months back.
I've had _both_ of my CM11As lock on 2-3 occasions after power outages so I
don't think it is a quirk of my particular CM11As. I don't think it's due to
a quirk in my LM14A as it works fine except when the CM11A is also being
powered up when it is 'signing in". I do not see the lock up when both are
powered up after a brief outage - one too short to drain the LM14A.
I need others to confirm my results. You'll need a power strip that can hold
both the CM11A and LM14A and another X10 transmitter that can be used to
clear the lockup. Here's the test...
1. Start with only the CM11A on the power strip. Leave the LM14A unplugged
for two minutes or so to assure it is drained. Apply power to the CM11A and,
using whatever software you normally use, send a command with the CM11A to
one of your other modules to verify that it is working.
2. Plug the LM14A into the power strip - there's no need to have anything
plugged into the LM14A. Send a command with the CM11A to again verify that
all is OK.
3. Kill the power to the power strip. Wait about two minutes to assure the
LM14A is drained. Apply power to the power strip. Send a command with the
CM11A. I expect the command will fail and the CM11A will be locked up.
4. Send a command with another transmitter to clear the lockup. Send a
command with the CM11A to verify it is again OK.
Below is a log from my Commander X software that shows the raw data. I've
added comments bracketed by asterisks.
================================================
***START WITH ONLY CM11A ON POWER STRIP***
2/1/99 09:26:27 Opening DEBUG.LOG - CM11A - 2.22
09:38:41 (0 ms) TX: H4 [4,DA] CS: DE
09:38:41 (54 ms) RX: DE
09:38:41 (494 ms) RX: 55
CM11A interface ready (494 ms)
09:38:41 (0 ms) TX: H OFF [6,D3] CS: D9
09:38:41 (0 ms) RX: D9
09:38:42 (494 ms) RX: 55
CM11A interface ready (494 ms) ***EVERYTHING OK***
***PLUG IN LM14A***
09:39:02 RX: 5A
09:39:02 (0 ms) TX: C3
09:39:02 (55 ms) RX: 5,1,D7,E,10,37
09:39:02 New 2-way unit detected on H2
09:39:02 RX: H2 Extended code [10,37] ***EVERYTHING OK***
***KILLED POWER TO CM11A & LM14A***
***RESTORE POWER TO BOTH CM11A & LM14A***
09:47:36 RX: A5 Power Fail
SetTime: 09:47:36 CS: 84
09:47:36 RX: 84 ***TIME RESET OK***
09:47:51 (0 ms) TX: H4 [4,DA] CS: DE
CM11A interface ready (1099 ms) ***TX TIMEOUT***
09:47:52 (0 ms) TX: H OFF [6,D3] CS: D9
CM11A interface ready (1098 ms) ***TX TIMEOUT***
09:48:02 (0 ms) TX: H4 [4,DA] CS: DE
CM11A interface ready (1098 ms) ***TX TIMEOUT***
09:48:03 (0 ms) TX: H OFF [6,D3] CS: D9
CM11A interface ready (1099 ms) ***TX TIMEOUT***
***CM11A IS LOCKED UP***
***SEND G4 OFF WITH CP290 TO UNLOCK***
09:48:10 (0 ms) RX: 5A
09:48:10 (0 ms) TX: C3
09:48:10 (55 ms) RX: 6,1,0,50,10,37,5A ***CM11A BUFFER CONTENTS***
09:48:10 RX: M All Units Off
09:48:10 RX: E13
09:48:10 RX: K9
09:48:10 RX: G4
09:48:10 (0 ms) RX: 5A
09:48:10 (0 ms) TX: C3
09:48:10 (0 ms) RX: 2,1,53
09:48:10 RX: G Off
***CM11A IS UNLOCKED AND ITS BUFFER IS NOW CLEAR***
09:48:21 (0 ms) TX: H4 [4,DA] CS: DE
09:48:21 (55 ms) RX: DE
09:48:22 (494 ms) RX: 55
CM11A interface ready (494 ms)
09:48:22 (0 ms) TX: H OFF [6,D3] CS: D9
09:48:22 (55 ms) RX: D9
09:48:22 (495 ms) RX: 55
CM11A interface ready (495 ms) ***EVERYTHING OK***
***POWER UP AFTER A BRIEF OUTAGE****
10:26:35 (0 ms) RX: A5
SetTime: 10:26:35 CS: 33 Power fail - reset time
10:26:35 (0 ms) RX: 33
10:26:42 (0 ms) TX: H4 [4,DA] CS: DE
10:26:42 (55 ms) RX: DE
10:26:43 (494 ms) RX: 55
CM11A interface ready (494 ms)
10:26:43 (0 ms) TX: H OFF [6,D3] CS: D9
10:26:43 (55 ms) RX: D9
10:26:43 (494 ms) RX: 55
CM11A interface ready (494 ms)
2/1/99 10:45:24 Closing DEBUG.LOG ***EVERYTHING OK***
Dave Houston
http://Commander-X.com
YMWW
where Y is the last digit of the year of manufacture (i.e., 6 for 1996), M
is the letter A thru L indicating month (i.e., Jan is A, Nov is K), and WW
is the week of manufacture from 1 to 52 (i.e., week 47 is 47).
Walt <Wa...@Early.com> wrote in article <36B5E562...@Early.com>...
|
| I believe it is cntl-R.
|
| Dave Houston wrote:
| >
Either this is not the firmware number, or Dan's post is in error, or I have
a really Neanderthal CM11A (this one is only 6-8 months old).
I guess I'll have to look at the protocol to see how to ask the CM11A to
divulge it's firmware level.
"Mongo" <mo...@stny.lrun.com> wrote:
>Walt is right. It is ctrl-r. This displays the firmware level. Pressing
>the Help key says that the little round label on the back displays info
>about manufacture date according to the following:
>
>YMWW
>where Y is the last digit of the year of manufacture (i.e., 6 for 1996), M
>is the letter A thru L indicating month (i.e., Jan is A, Nov is K), and WW
>is the week of manufacture from 1 to 52 (i.e., week 47 is 47).
>
>Walt <Wa...@Early.com> wrote in article <36B5E562...@Early.com>...
>|
>| I believe it is cntl-R.
>|
>| Dave Houston wrote:
>| >
>| > I do not know the firmware levels of my
>| > CM11As. I believe there is a way to get this using keyboard
>combinations in
>| > ActiveHome but think I lost the list of keyboard commands when I
>installed a
>| > new hard disk a few months back.
>| >
>|
Dave Houston
http://Commander-X.com
[...]
| I need others to confirm my results. You'll need a power strip that can hold
| both the CM11A and LM14A and another X10 transmitter that can be used to
| clear the lockup. Here's the test...
I can confirm your results for firmware version 7. The problem does not
occur for firmware version 8 (which does not hang but does not report
the lamp module's power-up status message).
I also tried with two 2-way modules just for the fun of it. In this case,
version 8 correctly reported both notifications and version 7 did not hang,
but reported garbage. Possibly version 8 simply delays for a while on power
up before listening to the line. This may even be the "lockup fix" they
mentioned for the new version. (It might have been better to actually fix
the hang. :)
Dan Lanciani
ddl@danlan.*com
As I recall, the one time I had Activehome software loaded, it also claimed
version 1.0 for my firmware version 7 module. I don't think I ever tried
it with a version 8 module. In general, I wouldn't trust the Control-R
display...
Dan Lanciani
ddl@danlan.*com
>In article <36b5d12...@nntp.fuse.net>, dhou...@fuse.net (Dave Houston) writes:
>
>[...]
>| I need others to confirm my results. You'll need a power strip that can hold
>| both the CM11A and LM14A and another X10 transmitter that can be used to
>| clear the lockup. Here's the test...
>
>I can confirm your results for firmware version 7. The problem does not
>occur for firmware version 8 (which does not hang but does not report
>the lamp module's power-up status message).
Thanks. I can see why it wouldn't hang if it's merely delaying before
listening to the line.
>I also tried with two 2-way modules just for the fun of it. In this case,
>version 8 correctly reported both notifications and version 7 did not hang,
>but reported garbage. Possibly version 8 simply delays for a while on power
>up before listening to the line. This may even be the "lockup fix" they
>mentioned for the new version. (It might have been better to actually fix
>the hang. :)
I agree on the 'fix'.
It looks to me like version 7 can't walk and chew gum at the same time - at
least it can't seem to reset the clock and listen to the powerline at power
up. I have a second CM11A on another machine that reports the lamp module
correctly at the same time that the other (powering up) CM11A chokes on it.
My guess is that version 7 didn't hang with 2 two-ways because the lamp
modules collision avoidance caused both to back off. Could the garbage be
the result of the collision? I only have 1 two-way and doubt I'll buy
another given the frequency of thunderstorms and power outages during our
summer months.
Dave Houston
http://Commander-X.com
http://www.x10-beta.com/ActiveHome/revision.html
Firmware V8.0 is also release V1.0 date is 9.30.96
Zhe Zhang
But, the dates listed are nonsensical. According to them only 5 days passed
between version 7.0 and 8.0 (Release v1.0).
Zhe Zhang <zhez...@home.com> wrote:
Dave Houston
http://Commander-X.com
Version 8 tested out OK, and became Released version 1.0.
In beta testing, it isn't unusual to have test releases
only 5 days part.
Beta test version 8, which became released version 1.0, is
obviously better.
Dave Houston wrote:
<snip>
I bought both of my CM11As _long_ after the date given for version 8 but
both are version 7. If I use ctrl-r, it says Release 1.0 but if I check the
status string returned by the CM11A (in response to 0x8b) it says version 7
so the explanation that Release 1.0 equates to firmware level 8 does not
hold water. If anyone has firmware level 8, I suspect they bought their
CM11A only in the past few months. Dan Lanciani is the only one I've heard
from who has said they have a CM11A with level 8 firmware.
While you might convince me that I should not be using version 7 firmware,
you will not convince to to waste any more money to replace my two units
with new ones that may or may not work any better. From the results Dan
Lanciani got when he tried my "lock up generator", I'm unconvinced that
version 8 is anything more than a kludge that tries to mask the fundamental
problem.
IMHO, the combination of a CM11A with version 7 firmware (which I suspect is
in the majority of extant CM11As) with a two-way module guarantees frequent
lock ups. The frequency of lock up complaints posted here has certainly
quickened of late.
Oh well, in view of recent discussions on automated flushes and cold frames,
maybe someone can suggest a way to automate candles. ;)
Walt <Wa...@Early.com> wrote:
Dave Houston
http://Commander-X.com
I ran one more test where I powered up the CM11A & LM14A simultaneously but
with the PC powered down. I got the lockup. I expected this because of the
times that the lockups occurred after power outages. I just wanted to make
sure that the timer reset from the PC was not involved.
I don't think there is any way to programmatically clear the lockup as the
CM11A is deaf to the serial port while in the lockup state. But I can detect
it (at least with a high probability) by incrementing a counter with each TX
timeout and resetting the counter to zero on every TX success. If the
counter reaches four, the probability is that the CM11A is locked.
I'm thinking about adding a feature to Commander X, which already supports
several interfaces (but only one at a time), to let those who have multiple
interfaces (and a spare port in some cases) automatically send a command via
a secondary interface to unlock the CM11A. All RX from the powerline would
have to be through a single primary interface - trying to keep track of
multiple input streams would be too complicated and use too much CPU time.
This would let you use the CM11A as a primary interface, taking advantage of
its extended code and full Dim/Bright capabilities but give some immunity
from the lockups. This would not help with those lockups that require
removal of the batteries but my experience has been that those are not as
common as the ones that can be cleared with another X10 transmission.
Specifically, you could use as a secondary...
1. ir-X/TW523 which uses an ISA slot but doesn't require a port or IRQ. It
also does two-way IR and has 2 analog inputs for temperature, etc. This
would cost ~$100-110 including a TW523.
2. CPU-XA/TW523 which would require another serial port. This has lots of
other features as it is a stand-alone SBC (so you can turn the PC/CM11A off)
with two-way IR and an RS485 port. I would consider it as as a primary or
sole interface and just abandon the CM11A if it weren't for extended codes
and Dim/Bright tracking. Although, the only features of the two-way lamp
modules that I like are Dim Memory and Preset Dim (which reduces the need
for Dim/Bright tracking) which do not need a CM11A. This is the most costly
but also the best solution by far. I think it would cost about $180-190
including the TW523. I'm awaiting delivery of one of these.
3. PLIX/TW523 - this needs a parallel port. Adding a parallel port is
usually easier and less costly than adding serial ports. This adds ~$60
including the TW523.
4. CP290 which would require a serial port. I wouldn't buy one for the
purpose but this could be a solution for anyone who already has one.
5. A second CM11A which would require a second serial port. This would be
~$35 exclusive of adding a port (if needed).
ByteRunner has both ISA-bus and PCI-bus 4-8 serial port cards that only need
one IRQ. They are very reasonably priced. I have one of their 4s/2p ISA
cards but am not using it with a single IRQ as I have enough free IRQs on
that machine. I may get one of the PCI 8s cards for my other machine where
I'm out of IRQs. It would let me keep a CM11A, a CPU-XA, a Slink-e, an ir-X,
and more connected at once so it would simplify testing and programming.
Comments?
Dave Houston
http://Commander-X.com
Umm, my version 7 unit was purchased at full retail price. It was not
supposed to be a beta, early or not. It showed "1.0" in Activehome's
version display. If X10 is recycling the beta units into the retail
business then I'm not at all sure it's for the customers to know that
they shouldn't still be using what they bought...
| Beta test version 8, which became released version 1.0, is
| obviously better.
My version 8 came *much* later and was supposed to be a "new"
release, again not a beta.
Dan Lanciani
ddl@danlan.*com
And hope the second didn't hang with the first?
Someone ought to wire up a relay in a DB9F to DB9M cable. Use one of
the modem control outputs to control it. Should be able to sell for
under $25.
I see two ideas... One would have the relay be a DPDT (better yet,
4PDT but I haven't seen those in a small and very low-power format),
and it would switch the TxD and RxD lines between two DB9Ms. Then you
could programatically alternate between two simple serial devices.
The other idea is a simple switched 120VAC. Use the CM11 on the
switched side, then if it was hung, you could programmatically cycle
power to it. But that doesn't cure some hangs, right?
Seems the best approach would be to operate on the CM11 and bring out
the reset line to the processor. Then your program could yank on that
when the CM11 went stupid. Maybe replace the 4pin RJ11 with a 6pin.
Use one extra pin to receive a modem control signal and use that to run
the reset circuitry.
sdb
--
Do NOT send me unsolicited commercial e-mail (UCE)!
Watch out for munged e-mail address.
User should be sylvan and host is cyberhighway.net.
From the last time I saved the ActiveHome revision history:
9.25.96 v7.0
* Extension of acknowledgment time-out to minimize errors during
download.
* Purge of transfer area to remove invalid timers (causing random
lock-ups
after a failed download).
* Lock-out of X-10 reception during memory downloads for up to 4
seconds after the download.
9.30.96 v8.0 (Release v1.0)
* Ensure that multiple scheduled macros with delayed elements are
processed.
* Erroneous EEPROM addresses after fast macros beginning with a delay
removed.
* Correction of time gain during EEPROM reads.
Jeff
>Dave Houston (dhou...@fuse.net) on Tue, 02 Feb 1999 16:32:56 GMT wrote:
>>5. A second CM11A which would require a second serial port. This would be
>>~$35 exclusive of adding a port (if needed).
>
>And hope the second didn't hang with the first?
Ooops - I obviously wrote that too fast - when I get too tired, my brain
disconnects.
And I omitted the LynX-10 as another possibility although I wouldn't
recommend buying one merely to use it to unlock a CM11A. My views are
probably influenced by the fact that I have (2) CM11As, (1) LynX-10, (1)
ir-X, (1) PLIX, (1) CP290, (2) TW523s, and a CPU-XA coming - all for testing
with Commander X. But I suspect there are a lot of people who have both a
CM11A and CP290.
>Someone ought to wire up a relay in a DB9F to DB9M cable. Use one of
>the modem control outputs to control it. Should be able to sell for
>under $25.
>
>I see two ideas... One would have the relay be a DPDT (better yet,
>4PDT but I haven't seen those in a small and very low-power format),
>and it would switch the TxD and RxD lines between two DB9Ms. Then you
>could programatically alternate between two simple serial devices.
I don't want to get into anything that requires anything other than off the
shelf hardware (or at least a kit).
>The other idea is a simple switched 120VAC. Use the CM11 on the
>switched side, then if it was hung, you could programmatically cycle
>power to it. But that doesn't cure some hangs, right?
That doesn't cure _any_ hangs and can, in fact, cause hangs that require
battery removal to cure.
>Seems the best approach would be to operate on the CM11 and bring out
>the reset line to the processor. Then your program could yank on that
>when the CM11 went stupid. Maybe replace the 4pin RJ11 with a 6pin.
>Use one extra pin to receive a modem control signal and use that to run
>the reset circuitry.
I believe someone (Neil Cherry ?) tried the reset with no success.
Again, I'm supplying free software to work with off-the-shelf hardware so
hardware modifications that would merely add to the support burden are not
what I'm looking for.
Dave Houston
http://Commander-X.com
I think Release 1.0 equates to firmware version 7...
| If anyone has firmware level 8, I suspect they bought their
| CM11A only in the past few months. Dan Lanciani is the only one I've heard
| from who has said they have a CM11A with level 8 firmware.
X10 sent me the version 8 unit in November of 97 after I described the
lock-up problems with version 7. They said version 8 had just been released
after changes to make it more compatible with the new 2-way modules. Since
it didn't fix the partial-extended-code-sequence problem, I pretty much
ignored it for quite a while. Then I did the experiments with multiple
2-way modules and identified another version 7 problem (see many previous
postings) which version 8 *did* fix. But of course that fix came at the
price of a new bug in transmission. Sigh.
If the CM14 isn't coming soon, the easiest solution to all of this might
just be to add a deadman timer to the CM11. A simple 555 timer circuit
could sense transitions of the serial out line and reset the processor if
they don't occur at least every few minutes. (My x10 daemon could generate
a status command if the line is ever idle for a minute or so.) I used to
build circuits like this into PCs that were acting as gateways and had to
be up all the time and/or were in hard to reach locations. Naturally you
have to be careful in the CM11 not to breach the line/serial isolation.
Dan Lanciani
ddl@danlan.*com
+----------------------------------+
| Bill Jones, N3JLQ,Sweden, Maine |
| wej...@megalink.net |
| http://www.megalink.net/~wejones |
+----------------------------------+
>X10 sent me the version 8 unit in November of 97 after I described the
>lock-up problems with version 7. They said version 8 had just been released
>after changes to make it more compatible with the new 2-way modules. Since
>it didn't fix the partial-extended-code-sequence problem, I pretty much
>ignored it for quite a while. Then I did the experiments with multiple
>2-way modules and identified another version 7 problem (see many previous
>postings) which version 8 *did* fix. But of course that fix came at the
>price of a new bug in transmission. Sigh.
I bought BOTH of mine at retail (one from HAS; one from X-10) several months
after that and received version 7 in both of them. This is ridiculous.
>If the CM14 isn't coming soon, the easiest solution to all of this might
>just be to add a deadman timer to the CM11. A simple 555 timer circuit
>could sense transitions of the serial out line and reset the processor if
>they don't occur at least every few minutes. (My x10 daemon could generate
>a status command if the line is ever idle for a minute or so.) I used to
>build circuits like this into PCs that were acting as gateways and had to
>be up all the time and/or were in hard to reach locations. Naturally you
>have to be careful in the CM11 not to breach the line/serial isolation.
>
I think a better solution for most people will be the CPU-XA/TW523. I doubt
that I'll be willing to waste any money on the CM14A after learning that my
CM11As were obsolete before I purchased them.
As I'm supplying free software, I really don't want to get involved in
hardware mods. But, I think someone has posted to the NG that they tried the
reset and couldn't clear the lockup.
Dave Houston
http://Commander-X.com
>X10 sent me the version 8 unit in November of 97 after I described the
>lock-up problems with version 7.
I just dug out my receipt. I bought one directly from X-10 on 3/20/98 and
received it in early April 98. It is version 7.
Dave Houston
http://Commander-X.com
>I believe someone (Neil Cherry ?) tried the reset with no success.
>
>Again, I'm supplying free software to work with off-the-shelf hardware so
>hardware modifications that would merely add to the support burden are not
>what I'm looking for.
I have tried it yet, just suggested that it could be done (I guess I
have a new project that needs completion soon.
The biggest shame in all this is that X10 hasn't added a single
comment to all this. It would be nice if they released the PIC code
and then we could fix it for ourselves. I guess I won't hold my
breath. Of course someone could come up with another standard which
would cost less and be like Open Source. Tha would ruin X10's day!
(Sorry I'm just getting a bit fed up bending over backward to fix the
problems that others (X10 in this case) should have fixed) I guess I'm
cranky.
--
Linux Home Automation Neil Cherry nch...@home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
Unit's that eat up an extra house code, units that can only be 1 or 9,
remotes that can only transmit on 1/2 or 5/6. RF Bases that only work
on 1 housecode. A _SINGLE_ device that is capable of
sending/receiving extended x-10 data that is completely unreliable.
If X-10 was truly serious about their technology being used, they'd
have raw PIC's available to hobbiests (like Parallax does with Basic
Stamp PIC's), they'd have extensive protocol and implementation
documentation, they'd allow all devices to be independently
addressable, and they'd allow the end-user to enable/disable features
like AllOn/Off response, Dim/Bri response on individual modules...For
starters.
Instead, we get vague responses, and only easy problems get fixed, and
even the fixes aren't all that impressive (case in point: MS12A). The
automation hackers and users of groups like this should really be
polled for input from X10, of course that might end up in them having
to implement difficult ideas.
At the very least, the X-10 Pro line should have these features...
[] [] n...@dmc.uucp (Neil Cherry) was saying:
>The biggest shame in all this is that X10 hasn't added a single
>comment to all this. It would be nice if they released the PIC code
>and then we could fix it for ourselves. I guess I won't hold my
>breath. Of course someone could come up with another standard which
>would cost less and be like Open Source. Tha would ruin X10's day!
>(Sorry I'm just getting a bit fed up bending over backward to fix the
>problems that others (X10 in this case) should have fixed) I guess I'm
>cranky.
--
Return address munged to prevent SPAM...
Automation and DataComm wiring, FAQ's, supplies, tools, etc:
http://www.FutureStandard.com