# CM15A & receiving dim

• posted

I'm not sure if anyone has resolved this but I'm trying to decode simple dim commands being sent from the ti103 and received by the CM15A. If I send 1 DIM (\$>28001N01ND40ND40F8# or N1 NDIM - note these are continous dims for a single command) I see:

5a020086 5a03020b84

As far as I can tell (no X10 doc still) the first line is 5A (received from the power line) 02 (2 bytes follow) 00 (it's an address) and 86 (X10 address - N1). The second line is 5A (power line), 03 (3 bytes follow), 02 (either 2 more bytes of an ID for DIM/BRIGHT), 0B (Dim % - still need to figure out the math) and 84 (NDIM).

I've also sent multiple dims:

1 DIM = 5a03020b84 2 DIM = 5a03020b84 3 DIM = 5a03021684 4 DIM = 5a03022184 5 DIM = 5a03022c84

Not sure what the math is on these. I'm guessing value/256 * 100 but that's just a guess. Any ideas?

• posted

It depends on the receiver (and manufacturer) but I worked out the math for an LM465 using a 100W lamp and my Kill A Watt meter. See...

See the CM11A documentation for an explanation of the bytes from the CM15A. The third byte (02 in all but your first example) is a bit map that indicates which of the following bytes are addresses and which are functions.

All of my switches are Insteon ToggleLinc relay types (controlling old fluorescents) so I'm unable to test this for an X-10 dimmer switch. You would have to temporarily wire the dimmer switch to an outlet and then use the Kill A Watt and 100W lamp in the outlet.

Note that the CM11A documentation says 22 DIMs equals 100% but the lamp module never goes to 100%. The maximum is 96%. There's no measureable difference between 21 & 22 contiguous steps using both the Kill A Watt and a true RMS voltmeter.

Earlier versions of the CM11A firmware output after each dim/bright command rather than sending the cumulative total. I haven't confirmed this but I think there was no way to accurately estimate the actual level because you couldn't tell whether the dim/brights were contiguous.

Charles Sullivan has indicated he sees a difference depending on whether the DIM starts on a ZC rising edge or falling edge but I haven't verified that. (It is on my lengthy ToDo list.)

snipped-for-privacy@yahoogroups.com

• posted

I think my first answer was not germane to your specific question.

In all the above, the 4th byte is the dim amount. The CM11A documentation says it's worth n/210*100 so...

0b = 11/210*100 = 5.2% (5.4) 16 = 22/210*100 = 10.5% (10.2) 21 = 33/210*100 = 15.7% (15) 2c = 44/210*100 = 21% (19.7)

It looks like the TI103 promotes 1 DIM to 2 DIM to avoid micro-steps. The numbers in parentheses are the values calculated based on the Kill A Watt measurements.

snipped-for-privacy@yahoogroups.com

• posted

Dang, you solve that one! This is good, so it goes:

5a - A 'What' (RF, Power Line, Macro, ACK, etc) 03 - Byte count 02 - ID (00 X10 Addr, 01 X10 Command, 02 X10 Dim/Bright, 08 Extended code?) 0b - reported intensity of Dim/Bright 84 - House Code/Function code

I saw the 210 in the CM11A documentation. With the TI103 22 continuous dims reports back 0xD2 intensity as does 24 dims.

I've not seen anything but cumulative with the CM15A. I don't really need accurate just a general 'what it means'. This is so Mr. House can use the CM15A.

Dave thanks this goes a long way towards getting the CM15A up and running with Mr. House. Next up is translating:

5a0508313f0667

The CM11A and Mr. House reports it as brighten A 1 to 100% (I think it's a preset bright command). I have to sit down and decode the middle 2 bytes. Here's what I've got so far:

5A - Power Lince 05 - 5 bytes 08 - Extended 31 - ASCII 1 3f - 06 - 67 - HC = A FC = Extended code

I'll have to sit down with the xtc797 doc to see if I can decode this.

Thanks!

• posted
[snip]

Look at XTC798.TXT on my webpage. It's just the X-10 DOC reformatted to make it readable.

N1 Extended Dim 63 (100%) gives 5A 05 01 87 06 3F 31 with the CM11A.

It looks like they changed the order of some of the bytes from the CM11A protocol.

One thing that might be worth checking is whether the 11, 22, 33, 44 seen when you convert your first 4 DIM levels to decimal holds for higher DIM levels.

snipped-for-privacy@yahoogroups.com

• posted

This might help. It's the bits on the powerline for H3 Extended Dim 31 (~50%). Only the first copy is shown. View in a fixed font.

H Fn 3 31 49 D 7 2 1 F 3 1 ssssh h h h k k k k f u u u u d d d d d d d d c c c c c c c c

01234567890123456789012345678901234567890123456789012345678901 (62 PLC bits) ....1 1 0 1 0 1 1 1 1 0 0 1 0 0 0 0 1 1 1 1 1 0 0 1 1 0 0 0 1 11101010011001101010100101100101010110101010100101101001010110

s=start h=housecode k=key f=function flag u=unit d=data c=code

snipped-for-privacy@yahoogroups.com

• posted

Neil..

Here's my spec on interfacing with the cm15a. I've not updated it in a bit.

If that doesn't help, let me know and I'll send you my dim code offline.

-woody (woody at usandthem dot com)

Neil Cherry wrote:

• posted

Thanks, that will be very helpful! It looks like the have the following format (using the previous example):

5A - The what (Power line, RF, Macro, etc) 05 - Byte that follow 08 - Bit map type of data that follows 31 - data 3f - data 06 - data 67 - House code (high nibble) key code (low nibble)

The last byte seems to be the House code/Function code or House code/Address code is all the commands such as in the simple a1aoff:

(5a020066) A1 (5a020163) AOff

Easy enough to check, I can run a script adding dims to the end of the command issued. Here's the script:

(T="n1" ; for i in \$(seq 1 23); do T="\${T}nm"; echo \$T; sudo perl ti103.pl \$T; sleep 5; done; )

Basically it says run the script 23 time and send the string to the TI103. Each time the script loops it add an 'nm' (N Dim) to the end of the string. This will send from 1 to 23 dims. The output shows up in a Mr. House log. After I've cleaned it up and removed the redundant information (each dim burst is preceded by an N1 (5a020086)). It looks like this:

) 1 dims = 0b (11) (5a03020b84) 2 dims = 0b (11) (5a03021684) 3 dims = 16 (22) (5a03022184) 4 dims = 21 (33) (5a03022c84) 5 dims = 2c (44) (5a03023784) 6 dims = 37 (55) (5a03024284) 7 dims = 42 (66) (5a03024d84) 8 dims = 4d (77) (5a03025884) 9 dims = 58 (88) (5a03026384) 10 dims = 63 (99) (5a03026e84) 11 dims = 6e (110) (5a03027984) 12 dims = 79 (121) (5a03028484) 13 dims = 84 (132) (5a03028f84) 14 dims = 8f (143) (5a03029a84) 15 dims = 9a (154) (5a0302a584) 16 dims = a5 (165) (5a0302b084) 17 dims = b0 (176) (5a0302bb84) 18 dims = bb (187) (5a0302c684) 19 dims = c6 (198) (5a0302d184) 20 dims = d1 (209) (5a0302d284) 21 dims = d2 (210) (5a0302d284) 22 dims = d2 (210) (5a0302d284) 23 dims = d2 (210)

BTW, I did the 20 dims twice and that's the odd number (0xD1 / 209) I came up with both times.

• posted

sleep 5; done; )

Neat!

The numbers you get equal (DIMs-1)*11 through 209. So the CM15A is reporting the actual number of contiguous DIMs, making it much easier to calculate the actual level (using the figures I developed empirically). The small difference between 209 and MAX (210) is approximately what you see with actual measurements. (You can't discern it with the naked eye.)

However, since the LM14A and LM465 respond differently while Smarthome uses

32 levels tends to negate the benefit of knowing the actual number of contiguous DIMs.

snipped-for-privacy@yahoogroups.com

• posted

This is related to one of the CM11A lock-up causes.

Prior to the LM14A & CM11A, Function 7 was defined as Extended Code but X-10 made nothing that did anything with it. With the LM14A, they converted it to always have the Unit, Data & Code ID follow the House & Function and a CM11A lock-up occurs when it sees the first part without the second following. The first 22 powerline bits are the same as in the older method.

snipped-for-privacy@yahoogroups.com

• posted

This should be interpreted as follows: 5A Incoming data 05 Bytes that follow 08 Function bitmap 00001000 => 4th byte following (i.e., 67) is a function byte. 31 Extended Type/Function 31 => Extended Preset. 3F Preset value = 0x3F = 63 (scale 0-63) 06 X10 encoded Unit code for Unit 1. 67 Hi = 6 = House code A, Lo = 7 = Extended code

• posted

I'm not sure this holds up, an address has a bit map of 00 (binary), a function has a bit map of 01, a dim/bright a bitmap of 11 and then this odd command:

5A 07 15 F2 FE F2 FE F2 FE

We haven't figured out what this is yet. They're bit maped but they don't indicate where the function byte is. That generally seems to be the last byte though I doubt that's true in this command.

Thanks, the last part also helps.

• posted

If interpreted as I suggested, the F2 would be functions (J On) and the FE would be addresses (J 2). This makes sense if the bytes are reported in reverse order (from the CM11A order) as the Extended Code commands are. But I think you indicated on another occasion that you weren't using housecode J, so who knows. (The CM15A has enough bugs that it wouldn't surprise me if that byte sequence turned out to be just garbage generated by RF pickup.)

What does the CM15A report if you send it several PLC commands in a row with the minimum gap between them, e.g., (A 1), (A On), (A 2), (A Off)? Do you get multiple reports (each beginning with 5A) or a single report?

Regards, Charles Sullivan

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.