JVDE X10 Forum

X10 Powerline Control => X10 Controllers => Topic started by: LouisJr on October 04, 2014, 03:24:48 PM

Title: CM15A new but defective
Post by: LouisJr on October 04, 2014, 03:24:48 PM
I have two CM15A controllers.  About a week ago the primary one died.  The backup was programmed and installed and is working fine.  I ordered and just received a new CM15A from X10 (a third unit counting the two I already owned) and it does not work either.  This makes me wonder if I am missing something.  Both the dead unit I replaced and the new one from X10 appear to download successfully but do not respond to commands.

Anyone else experience dead CM15A units?  Especially brand new ones?  I am about to contact X10 for an exchange.

Title: Re: CM15A new but defective
Post by: Brian H on October 05, 2014, 04:02:41 AM
What version of AHP software are you using?
Was it fully registered before the old X10WTI went bankrupt?
Are any of the problem modules dimmers?
I they are dimmers. Are they soft start {Ramp On or Off not instantly On or Off}?

You may also want to see if anyone in the X10 forums have added ideas.
Title: Re: CM15A new but defective
Post by: Jeff on October 05, 2014, 07:01:56 AM
By "do not respond to commands", do you mean the CM15A stops communicating with the PC, or that X10 devices do not respond to commands sent by the CM15A?  If the latter, you may have a signal strength or powerline noise problem.  I wrote a troubleshooting series that may help:


Title: Re: CM15A new but defective
Post by: LouisJr on October 05, 2014, 02:25:13 PM
Thank you, Brian and Jeff,

To clarify, the CM15A that was originally in service was the "primary" unit.  A second CM15A about ten years younger than the primary was the "spare" or "backup" unit.  The third CM15A that was just received is the "new" unit.

The primary and the new CM15As do not run macros when the on command is sent by a TM751, for example. They do not send out commands based on time, for example, to turn a light on at a give time, or to turn a light on at dusk.  They sometimes appear to be trying to run a micro but turn the wrong switches off or on.  The amount of memory used as indicated by the AHP check of the unit does not change when the required memory is changed by changing the number of days between dawn/dusk updates.

I have tried both the Marmitek 316 and the recent AHP 3.318 using Windows 7.  I have also tried a fully registered pre collapse AHP 3.318 on a Windows XP machine.  Three different program files have been tried - two about a year apart in age but similar in function, and one that was extremely simple and just ran a micro "on" command to a light switch when triggered by a command from an X10 Remote Control HR-12A held about two feet away.

The CM15A normally plugs into an XTB-IIR mounted at the breaker box and plugged into a 220 outlet.  Both the regular XTB-IIR and a backup XTB-IIR have been tried with the same result.  For the simple program test the CM15A was plugged into a duplex outlet on the same branch as the light switch.

The spare or backup CM15A continues to work just fine - better than the primary CM15A was working the last month or so.  I thought there might be a noise problem when the system first started failing with only one or two glitches a day, but the last day or two on the primary CM15A were a total zero.

Some of the modules are dimmers but many are appliance modules.  Continuous monitoring for a couple of days just before the total failure using an XTBM Pro  - X10 Signal Analyzer did not reveal any new noises.

I have tried two different sets of new batteries in each CM15A.  Only one thing was changed each time before rechecking performance.

The concern I am having is not that the primary CM15A failed - it is many years old and has been in almost continuous use.  Putting in the backup CM15A has restored the system to normal operation.  But when the new CM15A arrived Friday and was just as dead as the primary unit - with one or two possible glimmers of life over many trials - I became worried that I was missing something.

The only difference in the three units that I can see is that the primary and the new units have two pin non polarized plugs and the backup unit has a two pin polarized plug.  That suggests to me that the new unit may actually be older than the backup unit.

With complex systems and complex problems it is easy to jump to the wrong simple answer and I am really good at doing that.  Any thoughts are welcome and every question is fair and reasonable.  I look forward to your additional questions, comments and suggestions.  Thanks again.

Title: Re: CM15A new but defective
Post by: Brian H on October 05, 2014, 03:14:08 PM
The polarized AC Pins where only on the real early CM15A controllers.
I have two CM15As with a starting date code of 04. Both have the polarized pins.
My CM15As with date codes starting in 05 and 08 both are not polarized.

It does sound like the new CM15A you received may have issues.
As your backup functioned correctly.
Title: Re: CM15A new but defective
Post by: LouisJr on October 05, 2014, 05:12:39 PM

Thanks again.

I did not know they had date codes.  Is the date code on the round stick on label about 0.3 inches in diameter?  The primary unit has printed on it "07K46."  The backup has "04J44."  The new unit has "13F24."  So the backup would be the oldest and the new unit the youngest, with a nine year spread.  That agrees with your observations about age and plug polarizations.  Then the oldest unit is still working and the younger two units have died.  Maybe I should look for an old one  :D

Title: Re: CM15A new but defective
Post by: Jeff on October 05, 2014, 10:23:02 PM
So you have ruled out weak signals and powerline noise.  It does sound like the "new" CM15A is indeed not working correctly.

Since you are using the X10 Boost input on the XTB-IIR, you might try moving the CM15A to a nearby AC outlet, and use the XTB-IIR strictly as a repeater.  In some installations even weak powerline noise passing through the XTB-IIR return signal bandpass amplifier can look enough like X10 traffic to cause a CM15A to delay or inhibit transmissions.  The new CM15A may be more sensitive to this effect than the older units.

If you have XTB-IIR firmware 1.20 or newer, there is a mode option to reduce the gain of the return signal bandpass amplifier to reduce the effect too.  The downside is that it also reduces sensitivity to valid commands sent from remote transmitters.

Title: Re: CM15A new but defective
Post by: Brian H on October 06, 2014, 03:38:20 AM
Theory here the suffix letter on the controller IC. Maybe a firmware indication.

I have a 04J44 CM15A. If my theory is correct. It has an older firmware than the present ones.

From my opening the units:
04J41: P10792E
04J44: P10792F
05C10 & 05D18: P10792M In an IC Socket.
08B09: P10792M
Title: Re: CM15A new but defective
Post by: LouisJr on October 06, 2014, 01:58:49 PM
Brian and Jeff,

Thanks for staying with me on this.  There is good news and bad news!  First, following Jeff's advice I moved the CM15As to several different locations (from next to the breaker box to at the end of a long branch circuit) instead of plugged in to the XTB-IIR.  The backup unit, the primary unit, and the new unit all work that way!  I do not understand why the XTB-IIR might now be inhibiting what we think are the newer two CM15As when plugged directly in to it.  It is probably not a failure in the XTB-IIR since the backup XTB-IIR does exactly the same thing.  The noise level must have changed (Duke smart meter again?).  I have not had time to chase this problem.

The bad news is that the primary CM15A does not appear to receive RF signals any more.  I have tried a variety of settings and locations and nothing so far has brought the RF receiver in this unit back to life.  Using all the same settings the other two units receive any house code I send them.

At this time the primary unit is out of service, the backup unit is living happily at the end of a 60 foot branch circuit to my office (where I can connect the USB cable to a computer without moving anything - very handy for program changes and monitoring) and the new unit is on the shelf as the new spare.  The primary unit could be used as an emergency backup if necessary, but I hate to trust it knowing that at least part of it does not seem to be working.

Brian, in answer to your observations, the firmware in the primary unit is P10792M.  The date code on this unit is 07K46.  I have not opened the other two units up so I do not know the firmware codes in them.

Jeff, the XTB-IIR unit in service now has PIC 1.20 and the backup XTB-IIR now has PIC 1.21.  My XTB-IIR instruction book is dated 4-3-11 so it probably does not cover the current PICs!  In any case changing the mode programming options may be beyond me since I do not have a Maxi Controller, I have not used a TW523, I do not know enough yet about the digital port to use it, and if I put much more time on the X10 right now I will be sleeping in the barn.

Gentlemen, I apologize for not thinking to try moving the CM15A to a location other than the XTB-IIR socket.  The fact that the backup unit worked in the socket let me astray, especially since I thought it was the newest unit.  Without your help I would still be wandering through the wilderness.  Thank you again!


Title: Re: CM15A new but defective
Post by: Jeff on October 06, 2014, 04:18:05 PM
The return signal bandpass amplifier in the XTB-IIR makes up for signal loss in the coupling networks, and provides some gain to pick up weaker signals.  That amplifier feeds both the XTB-IIR and whatever is plugged into the X10 Boost input.  Noise with content near the X10 bandpass will be amplified, and so will transients that induce damped ringing in the tuned coupling networks.

Since the bandpass amplifier only passes noise near 120KHz, that can look like X10 traffic.  The XTB-IIR has AGC to ignore the amplified noise but the CM15A (and CM11A) do not.  Since the CM15A is a polite transmitter, it will delay or inhibit transmissions if it thinks there is already X10 traffic on the powerline.  My guess is that the newer CM15A's have slightly more gain, making them more susceptible to powerline noise.

If you (or anyone else) want to experiment with mode options. I modified a utility originally written by another customer to support the mode options available in the latest firmware.  It should work with either the CM11A and CM15A.  I tested it with the X10 SDK, using the XTB-232 for a powerline interface.  Contact me directly if you would like a beta copy.

Also, since you have 1.20 and 1.21, there was a free upgrade to 1.22 (or 1.23) that fixed a bug that was discovered in 1.20.  Again, contact me directly if you would like the upgrade.  The latest mode option document can be downloaded from our website:


FYI, I took out the RF receiver in a RR501 several years ago with an accidental static zap to the antenna.

Title: Re: CM15A new but defective
Post by: x10Tim on January 03, 2015, 07:41:52 AM
I am currently going down this same path.  Just completed assembly of the XTB-IIR with 1.23 firmware (awesome kit!).  I am bench testing and first tested with the Maxi Controller and everything worked perfectly.  I then plugged in my CM15A and timed events worked perfectly.  I then tried RF commands and they did not work.  I then plugged the CM15A directly in to the outlet and RF commands worked again.  Seeing this thread, I turned off high gain (9-8-2-6-Off), command accepted, but RF still did not work (No command being sent as the LED remains in DIM mode).  I could use the XTB-IIR as a repeater as suggested or use a TM751 in the area, but the engineer in me wants to know why the RF section in the CM15A stops working when plugged into the XTB-IIR.
Title: Re: CM15A new but defective
Post by: Jeff on January 04, 2015, 07:19:45 AM
The only idea I have on CM15A RF reception not working when plugged into the XTB-IIR is there would be a big power transformer and several large inductors just under the CM15A.  The metal those components may be blocking RF reception from that direction.  Nothing in the XTB-IIR runs anywhere near the X10 RF frequency to cause interference.  The highest frequency is the 16MHz PIC internal clock, but that doesn't even come out of the chip.  As I recall, X10 RF is around 310MHz.

Title: Re: CM15A new but defective
Post by: joesam on January 04, 2015, 08:15:02 AM
An easy way to test any potential "physical" impact of that socket, would be a short extension cord between the CM15A and the repeater.  That would also help eliminate a very nearby source of RF interference that is coincidentally near the repeater.
Title: Re: CM15A new but defective
Post by: x10Tim on January 04, 2015, 02:40:51 PM
Great suggestion.  Tried an extension cord and still no RF commands but everything else works.
Title: Re: CM15A new but defective
Post by: Jeff on January 04, 2015, 04:58:24 PM
The XTB-IIR checks the X10 Boost input from 190uS to 260uS after each zero crossing.  It must receive 4 pulses over 2V during that window to recognize the input.  The X10 spec says transmitters should begin within 100uS after the zero crossing, so it should be on well before the X10 Boost input is sampled.

Since the XTB-IIR does recognize the RF commands when working as a repeater, but not through the Boost input, it might be that the CM15A does not meet the X10 spec when functioning as a transceiver.  If the CM15A transmission begins later than 230uS after the zero crossing, 4 pulses of 120KHz would not be received by the end of the window, and that input would be ignored.  (The XTB-IIR switches to monitoring the powerline at 260uS after the zero crossing.)

I can't think of anything else that might cause the CM15A input to be ignored.

Title: Re: CM15A new but defective
Post by: x10Tim on January 19, 2015, 06:04:46 PM
I wanted to follow up that I never figured it out but it does not matter as the XTB-IIR is functioning very well as a repeater and with the CM15A in a house outlet, the RF is functioning.  Thanks for the replies.