Re: Understanding X10 Dims???

[Charles Sullivan <cwsulliv@xxxxxxxxxxxx>]

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