[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]
Re: Understanding X10 Dims???
One more thing to chew on...
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 to full dim. Doublets require
18 dims to go to full dim.
100/21=4.76 (approximate standard step)
100/150=0.67 (approximate microstep)
If the first dim/bright after _any_ gap is interpreted as a microstep...
18 doublets: 18*0.67+18*4.76=97.68
21 contiguous: 21*4.76+0.67=100.67
Anything less than ~96 will leave a faint filament glow.
That _might_ explain the difference.
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
comp.home.automation Main Index |
comp.home.automation Thread Index |
comp.home.automation Home |
Archives Home