Re: Understanding X10 Dims???

[nobody@xxxxxxxxxxxx (Dave Houston)]

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

     http://www.mbx-usa.com/dims.htm

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.

I don't think the Monterey Analyzer will help here as you really need to see
all PLC activity (or lack thereof) for nearly 5 seconds.

Charles Sullivan <cwsulliv@xxxxxxxxxxxx> wrote:

>On Tue, 09 Aug 2005 00:49:21 +0000, Dave Houston wrote:
>
>> I'm not sure I understand your question.
>
>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 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).
>
>I haven't observed any obvious pattern in hundreds of trials - the
>variation seems to be random.
>
>> When sending, the CM11A only uses 5 bits for the Dim/Bright value which,
>> according to X-10 documentation, can only be 0-22.
>
>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
>31.  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.
>
>>                                                    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.
>
>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.
>
>> 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.
>
>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.
>
># LM14A extended level (0-63) versus received Dims (0-210)
># from fully on state.
># Dims  Level
>  2     62
>  3     62
> 13     58
> 14     59
> 24     54
> 25     55
> 35     49
> 36     51
> 37     51
> 46     45
> 47     47
> 48     47
> 57     41
> 58     43
> 68     36
> 69     39
> 79     32
> 80     35
> 90     27
> 91     31
>101     23
>102     27
>112     19
>113     23
>123     14
>124     19
>125     19
>134     10
>135     15
>145      5
>146     11
>147     11
>156      1
>157      7
>167      1
>168      3
>178      1
>179      1
>180      1
>190      1
>200      1
>201      1
>
>> Neil Cherry has modified a TW523 to report the powerline bitstream.
>> Maybe he could record some sequences for you.
>
>Thanks - I'll ask Neil about this.
>
>> If I remember, I'll try to connect a meter to the output side of a lamp
>> module and see whether I can plot voltage vs. microsteps as well as
>> voltage vs. 1-22 brights.
>
>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.
>
>Regards,
>Charles Sullivan
>
>> Charles Sullivan <cwsulliv@xxxxxxxxxxxx> wrote:
>>
>>>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.
>>>
>>>Regards,
>>>Charles Sullivan
>>>
>>>On Mon, 08 Aug 2005 14:49:03 -0400, Robert Green wrote:
>>>
>>>> I am going to take the liberty of repeating a Dave Houston post from a
>>>> while back to hopefully free a little more time for him to design the
>>>> "killer" powerline analyzer.  :-)
>>>>
>>>> ----------------------------------------------------------------------------
>>>> ----
>>>>
>>>> Re: CM11A Protocol Question -- Posted by Dave Houston on 09-06-04
>>>> 06:03
>>>>
>>>> It's been several years since I worked on this so the details are a
>>>> bit hazy and it's early AM (I'm only on my first dose of caffiene) so
>>>> you might want to look at my VB source code (cm11a.zip) for the CM11A
>>>> at...
>>>>
>>>> http://www.mbx-usa.com/files.htm
>>>>
>>>> You cannot dim TO a specific value (unless you track the level of each
>>>> address). You can only dim BY a specific increment.
>>>>
>>>> Standard dim & bright use approximately 6% steps (i.e. 16 steps
>>>> between min & max). The CM11A documentation says there are 210
>>>> discrete levels. (It's hard to discern more than about 150.) As best I
>>>> recall, I used a little trial and error to decide on the increments to
>>>> use with the CM11A as the CM11A converts them to standard steps. If
>>>> you send an increment less than 3-4% to the CM11A, you'll get a
>>>> microstep (also demonstrated in the VB source) of about 0.6% (i.e.
>>>> 1/210).
>>>>
>>>> You really need to study the PLC documentation to understand what's
>>>> actually sent to the powerline for Dim/Bright - noting the fact that
>>>> there's no gap between multiple commands. Phil Kingery's articles (see
>>>> the Home Toys archives) also help but I never fully understood them
>>>> (if I FULLY understand them now) until Dan Lanciani explained them
>>>> using the following simple notation.
>>>>
>>>> DIM = 1 PLC dim command (Bright works the same)
>>>>
>>>> Sending a single DIM results in a microstep. Sending n contiguous DIMs
>>>> results in n-1 standard 6% steps. Below, I use _ to represent no GAP
>>>> between PLC commands.
>>>>
>>>> DIM_DIM = 6%
>>>> DIM_DIM_DIM = 12%
>>>> DIM_DIM_DIM_DIM = 18%
>>>> ...
>>>> 17 gapless DIMs = 100%
>>>>
>>>> But, using a space to indicate more than 3 idle cycles...
>>>>
>>>> DIM DIM = two microdims
>>>>
>>>> This is further complicated by the fact that a GAP is defined as 3 or
>>>> more idle cycles (6 or more idle half cycles) so a smaller gap between
>>>> DIMs is still seen as a contiguous stream.
>>>>
>>>> Another complication (for grasping the details) is that the CM11A only
>>>> reports the cumulative result for Dim/Bright - it doesn't report the
>>>> number of PLC commands. Those with the latest firmware wait for the
>>>> end of the stream (or until it's seen 100% worth) to report. You
>>>> really need something that gives you each bit at the PLC level to
>>>> understand.
>>>>
>>>> Clear? ;)
>>>>
>>>>
>>>> "Charles Sullivan" <cwsulliv@xxxxxxxxxxxx> wrote in message
>>>> news:pan.2005.08.08.15.46.56.590079@xxxxxxxxxxxxxxx
>>>>> 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.
>>>>>
>>>>> Regards,
>>>>> Charles Sullivan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>