Using a CM11A to monitor dims (brights) on the power line, I notice that most X10 transmitters, e.g., CM11A, Mini/Maxi-controllers, RR501, send dims (brights) according to the formula: dims = 11*N + X where N >= 0 and X varies randomly - usually 2 or 3, sometimes 4. The CM11A reports a maximum of 210 dims.
The variation in X does not appear to be an imprecision in the monitoring interface circuitry - two CM11As on line simultaneously always report identical received values.
A strange thing about X is that a value of 3 or 4 produces _less_ actual dimming than 2. The effect is difficult to see with a standard X10 lamp module (and digital RMS multimeter) because of short term fluctuations in line voltage, but is very dramatic with X10's LM14A 2-way lamp module. With the LM14A, a plot of either extended level (0-63) or output voltage versus received dims (2-210 dims from the fully ON state) looks like a sawtooth curve with "tooth height" of as many as 6 extended levels or almost 10 percent. (There's a similar sawtooth curve from the fully OFF state when brights are received.)
Can any of the X10 hardware/firmware gurus on this newsgroup explain the reason for the variability of X in the transmitted dims and the strange retro effect of X = 3,4 versus X = 2 on X10 modules? Thanks for your help.
Robert, Thanks for your response. Yes, Dave's post is clear, but it doesn't answer my questions.
I can direct the CM11A to send the same dims multiple times (with a few seconds delay in between) but the dims reported by another CM11A (looking at the actual byte reported, not converting to a percentage) vary by 1/210, occasionally 2/210. Why the variation? And what exactly is being sent over the PL which accounts for the "retro" effect of the higher (by 1 or 2) dim value, which is most noticeable with the LM14A but also observable with a standard X10 lamp module.
I was hoping that someone who had monitored the power line with something other than a CM11A, or who had knowledge of the hardware/firmware with regard to dims, could provide some insight into what's happening.
I have noticed anomolies in what the CM11A reports but I haven't determined that there is any pattern (which doesn't mean there is none).
When sending, the CM11A only uses 5 bits for the Dim/Bright value which, according to X-10 documentation, can only be 0-22. Other PLC interfaces send N+1 contiguous DIM/BRT as I explained in the post that was quoted. I don't think the variations you see are meaningful because none of the transmitters have that kind of resolution but I've never tried measuring the voltage from a lamp module. AFAIK the only way to get finer resolution at the receiver is with a series of microsteps and that takes a great deal of time.
I have a CM15A and have made a ribbon cable extension so I could move the MCU to a breadboard and expose all of the signal lines. I've used it with my scope card to record the powerline signals when sending dim levels 0-22 with a CM11A. I cannot convert them to GIFs and publish them because of the need to scroll the scope display - 22 contiguous dims needs 22*11=242 half cycles. It's easy to count the number of contiguous dims by just counting the start codes. The number of contiguous dims is equal to the same 0-22 sent by the CM11A. Another CM11A that was reporting the same bitstream has to be fudging the extra bits of resolution it reports as they are not on the powerline.
Neil Cherry has modified a TW523 to report the powerl>Robert,
I guess I'm wondering why, if this is supposed to be a digital protocol, the CM11A (or other transmitter) doesn't send exactly the same PL dim signal every time. Unless there's some sort of analog timing controlling the number of dims sent, the only other things I can think of are noise on the powerline, AC voltage fluctuations, or possibly starting at the zero on the rising vs falling side of the AC waveform.
I haven't observed any obvious pattern in hundreds of trials - the variation seems to be random.
Plugging in 0 seems to send the same thing as 2, at least insofar as the CM11A report. 5 bits allows programming as high as
The elapsed time for the CM11A to transmit and return "ready" when 31 is programmed is approximately proportionately longer, however a (separate) CM11A monitor maxes out at 210 so it's unknown whether there are actually additional dims being send.
While the older transmitters like CM11A and Mini/Maxi-controller are limited to either the microdims or the 6% steps, the CM15A can apparently send an almost continuous range from 3/210 through
210/210. If you have the ActiveHomePro Software Development Kit, try entering the following in a command line window: ahcmd sendrawplc 06 64 XX where XX varies from 01 through D0 (all 2 digit hex).
You'll need a CM11A monitor on a separate PC to see the dims received (which also exhibit the random variation of 1). Of course it's possible the CM15A is actually sending a combination of the
6% dims and microdims to get the finer resolution.
Well there's _something_ extra on the power line. Here's the data I took with the LM14A 2-way lamp module. (First set extended preset level 63; wait a few seconds; send ordinary dims (1 though about 19 with a CM11A); wait a few seconds; send extended status request to get the new extended level; records dims and extended level reported by a second CM11A. Repeat 5 or 10 times at each programmed dim level to observe the random variation in received dims.) You can run the data through GNUPLOT or other plotting program to see the sawtooth curve.
I recall this was a real pain to see. Unlike the LM14A, the output voltage difference on a standard X10 lamp module is small with a difference of only 1 in the dims. And I was constantly seeing AC line voltage fluctuations close to the same size. It would have helped to have a 2-channel RMS voltmeter with a serial port output.
Sorry it didn't help. I thought what you had been describing was that if you had a pause in the stream, the CM11A now thinks you're sending microdims so DIM_DIM without a gap gives a 6% dim whereas a DIM DIM with a gap is read as a two microdims which are 2/210 or 1.2%. Apparently I'm not following what you mean by a delay of a few seconds. Are you programmatically delaying the interval between DIM commands?
Well, if I understood more clearly what you were looking for, perhaps my Monterey PLSA in the signal dissect mode would give the raw data you're looking for. I'd be happy to run some simple tests if you can set them up for me. I have a CM11A in the junk box but it hasn't been used for years.
Explains how the Monterey works in the signal dissection mode:
Sample Screen DISSECT: 1 0 CYCLE 02 1.4 03m
DISSECT THE ENTIRE X10 SIGNAL: Each X10 code is transmitted twice using 22 AC power line cycles. Each true bit of code information is transmitted at the zero-crossing point with a complement bit transmitted on alternate half cycles. All 22 true bits of the X10 code and their complements can be viewed. In this example, cycle #2 is dissected to show the true bit as a Binary 1 with a signal strength of 1.4 volts, and it's complementary bit (Binary 0) with signal strength of 3 millivolts. This is useful for seeing the effects on the X10 signal after installing repeater/amplifiers and for viewing additional codes or data after extended code/data/preset dim commands.
All I can suggest is that you find a way to see what's actually on the powerline (or, in this case, not on the powerline) either by capturing the bitstream with something like Neil's modified TW523 or with a scope. Trying to divine what's on the powerline from the CM11A output is akin to predicting the future by reading chicken entrails.
The CM15A makes an excellent platform for use with a scope as its MCU gets a baseband PLC input and a ZC input.
A few months back, using the CM15A, I captured scope data sets for all of the DIM levels that a CM11A can send with my Protek 220 DSO Scope Card. Some selected screenshots are shown at...
You need a way to capture about 5 seconds of activity and then a way to expand the horizontal axis and see further detail by scrolling. My scope card provides that. In the expanded views, you can count the cycles in the ZC signal to verify the total time. The scroll bar at the bottom shows the relationship between the current view and the big picture.
All of the other DIMxx levels show a clean PLC line after the function just like the DIM01 view.
As a very rough indicator, you can measure the width of the function in the unexpanded views. You'll find Dim22 is twenty-two times the width of Dim01. The relationship holds for Dim02 through Dim21.
The CM11A does send the same thing each time. It's the receiving CM11A (and LM14A?) that are reporting phantom differences and implying greater resolution than the system truly has.
Here's some additional data that may help.
CM11A.EXE can be downloaded from
There are no dlls, etc. It is a stand-alone executable.
Using CM11A.EXE, LM14A & 60W bulb...
Set Extended to 63 & click LEVEL. Set Standard Dim to 16 & click DIM. Set Extended to 1 & click LEVEL. The lamp will dim one more step.
Repeat but using 17 standard dims. There will be no further dimming when Extended Dim 1 is transmitted.
Set Extended to 63 and click LEVEL. Set microSteps to 152 and click µDIM. When the sequence completes, set Extended to 1 & click LEVEL. The lamp will dim one more step.
Repeat but using 153 µDims. There will be no further dimming when Extended Dim 1 is transmitted.
Using CM11A.EXE, LM465 & 60W bulb...
Set Standard Bright to 22 & click BRT 2-3 times to ensure full on. Set Standard Dim to 20 & click DIM There will still be a very dim glow looking directly at the filament.
Repeat but use 21 standard dims. There will be no more glow.
It's a bit harder using µDims because it's difficult to judge just when the faint glow disappears from the filament (which may also be influenced by ambient light) but my best judgement is somewhere between 145 & 150 µDims.
NOTE: Kill-A-Watt only has 1W resolution in Watts mode.
| > I can direct the CM11A to send the same dims multiple times | > (with a few seconds delay in between) but the dims reported by | > another CM11A (looking at the actual byte reported, not converting | > to a percentage) vary by 1/210, occasionally 2/210. Why the | > variation? | | Sorry it didn't help. I thought what you had been describing was that if | you had a pause in the stream, the CM11A now thinks you're sending microdims | so DIM_DIM without a gap gives a 6% dim whereas a DIM DIM with a gap is read | as a two microdims which are 2/210 or 1.2%.
Although a lot of references use this description I do not believe that it is correct. I think the initial DIM or BRI always results in a micro step regardless of whether it is followed without a gap by additional commands. See:
So the original poster's '+ X' would always be at least + 1.
I don't recall seeing the post you cited but I can confirm (at least partially) your insight. See my earlier post to this thread which gave a quick and dirty analysis.
I think that any Dim/Bright _preceded_ by a gap is interpreted as a microstep. That agrees with what I observe on the powerline with a scope and also with the watt readings using my Kill-A-Watt. It doesn't explain the apparently random 'noise' reported by the CM11A. I don't understand why the CM11A docs use 0-22 when transmitting and say there are 210 possible steps when describing what it reports when receiving. Actual lamp modules only respond with about 150 steps. I think it was PCS who said 180. Uncle Phil said 128. X-10 says 210. My measurements say ~150.
I would refine my initial analysis to say...
The LM465 seems to respond differently to contiguous dims sent by the CM11A in a single command and the same number of dims sent as doublets (2 standard dims with no gap) followed by gaps.
A single CM11A command requires 21 dims to go from full bright to full dim. This is borne out by the Kill-A-Watt reading which only reaches minimum after 21 contiguous dims.
Doublets require 18 dims to go from full bright to full dim. This is borne out by the Kill-A-Watt reading which only reaches minimum after 18 doublets. However, to the naked eye, the typical lamp will appear off after 17 doublets. You have to look right at the filament to see the faint glow after
This is probably why most experts have said there are 16 standard dim levels.
Assuming the first 4% of each half cycle is always chopped and the first dim after any gap is interpreted as a microstep...
96/150=0.64 (approximate microstep)
95.36/20=4.768 (approximate standard step) 1st of 21 contiguous is a microstep.
18 doublets: 18*0.64+18*4.768=97.344
21 contiguous: 0.64+20*4.768=96.000
That could explain both the PLC o'scope screenhots and the Kill-A-Watt readings.
It would be nice to have a wattmeter with 1/10W resolution which might further refine the analysis.
The analysis holds up for triplets, quads, quints & sextuplets but there are a few points that might be further refined.
Using the Kill-A-Watt & LM465 w/60W, I measure 145 microsteps to go from max to min. This gives a 0.662% value for a microstep with the LM465. Other lamp modules and switches may differ - the LM14A takes about 10 more microsteps to go from max to min and it's min is far from full dim - my SmartHome lamp modules do not respond to microsteps. The exact value for a microstep has minimal impact as its effect is overwhelmed by that of the standard step.
The 96% figure is taken from various documentation - most from the same experts who were off on the number of microsteps, off on the number of standard dims and off on the explanation of how dims work. Someone more able-bodied than am I with a Kill-A-Watt might be able to refine this figure using a 300W load and measuring with and without the LM465 at max. I'm using a small clamp-on gooseneck which is limited to 60W.
To add to the record (and confusion), the SmartHome 2000STW goes from max to min brightness with 14 contiguous dims, 32 singlets or 32 µdims.
Like I said in the post that was quoted at the beginning of the thread, you really need to know the exact sequence on the powerline. And you also need to know exactly how the target receiver(s) react to that sequence. I don't think the CM11A gives you enough information about received dim/bright signals so it's kinda like playing "pin the tail on the donkey". The CM15A MCU has access to the raw data but I have no idea how well X-10's CM15A firmware digests it as my only interest is in replacing their MCU to allow access to it's full capabilities.
Of course, nothing that uses the TW523 can even come close to reporting dim/bright accurately.
I have no idea how well SmartHome's PowerLinc deals with this. I suspect it handles their own modules and switches OK but errs on others.
As manufacturers of X-10 compatible devices proliferate, the c>The analysis holds up for triplets, quads, quints & sextuplets but there are