X10 Extended Commands?

[cauer29]

One final thought: I wonder if the 10 bits that the IR543 puts out following the XTC cmd are somehow related to the extra junk that the UEI X10 IR protocol puts out prior to the normal X10 IR protocol? I'll have to dig out a real X10 IR remote and see what I get on the powerline.

The real X10 remotes send the same signal as my simple upgrade. The UEI executor puts that extra junk in there to make the signal hard to learn. If you find out that the 20 bit version of the protocol has some value, let me know and I'll write an executor for it.

Well, I did learn something new. The OP's macro stacked unit numbers then the following command worked on all of them. For example "unit 1, unit 2, unit 3, unit 4, on" turned on all four. I never knew you could do that.

That's what I suspected he was doing.

It's been an interesting pursuit but it was all for naught. It seems that the extra 10 bits that are sent, are actually just a failed attempt to repeat the XTC cmd itself, but the IR543 butchers the start code for the repeat frame. In the X10 PLC scheme, alternate half cycles are '01' for a 0 and '10' for a 1 and the sequence '11' followed by '10' is a special sequence meaning that this is the start of a frame. For the usual X10 cmds, the IR543 repeats the whole frame and the repeat is preceeded by the '11' '10' start of frame marker, but when the IR543 tries to repeat the XTC cmd, it does a '01' '10' preceeding the repeat. That confused the protocol analyzer to no end, but I sorted it out the old fashioned way......with pencil and paper, writing out the 1s and 0s and that's when I recognized the repeat pattern with the butchered start of frame marker. I guess I shouldn't be too surprised at the IR543's behavior here, since it was designed some 30 years ago and I'll bet hasn't gone through any actual bug fixes in the years since.

In the end, the list of "there but not useful" cmds supported by the IR543 are:

HRQ hail request. the IR543 can send this, but who would be listening to the response?

XTD extended data. Same problem as XTC outlined above.

PD0 preset dim 0. This one will work, but it uses the housecode as the dim level and the IR543 can't change that on the fly. If you don't mind the dim level tied to the fixed housecode, then it will work.

STF status off. It would be a bizarre setup that could respond to an X10 SRQ that it received via some means, by sending out an STF response via IR, but technically it would work.

HAK hail acknowledge. Same as STF above.

STO status on. Same as STF and HAK above.

PD1 preset dim 1. Same as PD0 but the houscode becomes a dim level in the other half of the dim range. Still, it technically works. I suppose with judicious choice of housecode, you could get something useful out of it.

XTC extended code. The subject of this investigation and apparently useless, as the IR543 corrupts the start code on the repeat and there isn't an obvious way to extend the data.

SRQ status request. Same as HRQ.

All that said, I have used all 16 function codes and all 16 unit codes for a total of 32 codes via the IR543 to trigger complex macros on the Ocelot. The Ocelot doesn't actually care what X10 intended these codes to do, it simply recognizes reception of these codes over the powerline and that triggers a very complex sequence of things, some IR output, some RS232 control.

As for the UEI X10 protocol, I hadn't heard that it was meant to make it hard to learn. The extra stuff doesn't seem to bother the IR543, I guess because the repeat is formed correctly and it's able to recognize that ok.


A.A.

[The Robman]

Thanks for your efforts, even if you didn't find anything useful, at least we know now, so someone else doesn't have to spend their time looking.

Hey, do you know anything about the security system that the HOME/0167 code is supposed to support? There are a bunch of EFCs for it, but I've never heard of anyone actually using it to work anything, and I've never heard of an actual system that can be controlled using it.

[cauer29]

Thanks for your efforts, even if you didn't find anything useful, at least we know now, so someone else doesn't have to spend their time looking.

Hey, do you know anything about the security system that the HOME/0167 code is supposed to support? There are a bunch of EFCs for it, but I've never heard of anyone actually using it to work anything, and I've never heard of an actual system that can be controlled using it.

I'm still gonna take a shot at extending the X10 IR protocol by another 20 bits, but I'm not hopeful. I changed the original:

Function=0..31

Protocol=X10IR
Frequency=40000
Time Base=650
One=7,-7
Zero=2,-13
Form=;*,F:5,~F:5,_
Prefix=8,-8
suffix=23,-8

to:

Function=0..31
Define A=573513
Protocol=X10IR
Frequency=40000
Time Base=650
One=7,-7
Zero=2,-13
Form=;*,F:5,~F:5,A:20,~A:20,_
Prefix=8,-8
suffix=23,-8

A is just a fixed value that I captured when I sent a Leviton extended preset dim command from the Ocelot. Now I just need to find the time to test it.

As for the security stuff in the X10 protocol, I've never run across any equipment that uses those codes. All of the security X10 stuff I've seen uses the X10 RF protocol.

A.A.

[The Robman]

I'm still gonna take a shot at extending the X10 IR protocol by another 20 bits, but I'm not hopeful.

If you have a need for it, I'll do it for you, as it's easy for me. So, you want it in exactly the same format as the regular X10 signal, except you want an extra 20 bits before the final lead out pair? And should the whole thing repeat if the button is held?

[The Robman]

Form=;*,F:5,~F:5,A:20,~A:20,_

I just noticed this, is this really how you want it formatted? You want the normal 5-bit OBC to be followed by it's complement, then the new 20-bit stream followed by it's complement? Are there any fixed bits in the 20-bit stream, or do you need to be able to vary all of them?

[The Robman]

I went ahead and put together a protocol and upgrade to create these signals.

The first 5-bit code is still derived from the OBC as before.

The new 20-bit signal is formatted using 4 bytes of hex in KM's "byte2" column. Only the first 5 bits are used in each byte, like this...

XXXXX000 XXXXX000 XXXXX000 XXXXX000

where X is data and 0 is ignored.

http://www.hifi-remote.com/forums/dload ... le_id=8970

Here's the IRP format:
{40.8k,565}<2,-12|7,-7>(7,-7,F:5,~F:5,F:20,~F:20,21,-7)+

[cauer29]

I went ahead and put together a protocol and upgrade to create these signals.

The first 5-bit code is still derived from the OBC as before.

The new 20-bit signal is formatted using 4 bytes of hex in KM's "byte2" column. Only the first 5 bits are used in each byte, like this...

XXXXX000 XXXXX000 XXXXX000 XXXXX000

where X is data and 0 is ignored.

http://www.hifi-remote.com/forums/dload ... le_id=8970

Here's the IRP format:
{40.8k,565}<2,-12|7,-7>(7,-7,F:5,~F:5,F:20,~F:20,21,-7)+

At this point, I'm just making a wild guess that the 20 bits follow the normal X10 stuff and then the complement after that. I have no special knowledge there. That said, it didn't work. The IR543 did not respond to the longer signal. I do need to verify that the IR came out as expected. Assuming it did, then I don't know where to go from here. I could keep trying to guess what format is the right one. Of course there is always the possibility that there isn't a format that will work.

Edit: Ok the IR came out exactly as expected. The IR543 just wasn't impressed with it, so it ignored it completely, refusing to put out so much as a blip on the powerline.

A.A.

[The Robman]

Do you think it's worth trying all 25 bits followed by a 25 bit complement?

[cauer29]

Do you think it's worth trying all 25 bits followed by a 25 bit complement?

I suppose so. I'll give it a try, but first I was thinking based on reading the oldest info available that refers to a byte or bytes following the basic 9 bits on the powerline (4 bit housecode + 5 bit function) that sending a single byte might be the ticket. Something like this:

Form=;*,F:5,~F:5,D:8,~D:8,_

where D is the byte following the function code.

Looks like I won't get a chance to test this before tonight.

A.A.

[The Robman]

Looking at the extended code format, this is how the standard and extended codes appear to be formatted (on the power line).

Standard:

1110;
4-bit house code,
4-bit unit/func code,
1-bit unit/func switch,
0000

(when the 1-bit switch is 0, the preceding code is a "unit code")
(when the 1-bit switch is 1, the preceding code is a "function code")

The 4-bit unit/func code and 1-bit unit/func switch are concatenated to become the 5-bit "OBC" code that we use with the IR543 box.

Extended Code 1:

1110;
4-bit house code,
4-bit func code (value 0111),
1-bit unit/func switch (value 1),
4-bit unit code,
8-bit data byte,
4-bit type code (see below),
4-bit command code,
0000

type code
0 = Shutters and Sunshades
1 = Sensors
2 = Reserved for Security
3 = Control Modules (Dimmers and Appliances)
4 = Extended Secure Addressing
5 = Extended Secure Addressing for Groups

The PDF doesn't describe the other two extended message formats, but this page does.

It appears that the "Pre Set Dim" function can be used in conjunction with the house code to come up with two pre-set dim levels, and this looks like something we could test with the IR543 using the standard protocol.

However, as for testing the extended codes, the more I think about it, I don't imagine that the IR543 is capable of generating the extended X10 signal on the power line. After all, it was invented so that people could send the regular X10 commands. It requires the 5-bit command code to be followed by it's complement just as an internal validation process so it can be sure that it's receiving a valid signal, it obviously doesn't send the complement down the power line. So, in order for it to be able to handle the extended format, the developer would have to have added special logic to do that, and if that were the case, somebody would have documented it before now.

This page documents the IR543 infrared protocol format and that seems to confirm that it can just handle the standard 5-bit commands.

[Kevin Timmerman]

This page documents the IR543 infrared protocol format and that seems to confirm that it can just handle the standard 5-bit commands.

It also says the IR543AH and IR7243W can do extended codes.

[-Matt-]

Hello, I am new here.

I found this thread while searching for more information about the X10 extended commands.

I have just ordered some x10 lamp dimmer modules:
http://www.uk-automation.co.uk/x10-lamp ... -1216.html

..and an IR7243W:
http://www.letsautomate.com/10863.cfm


I hope to be able to create some lighting scene presets in a manner similar to this: i.e. Movie-Mode, Evening ... etc.
http://www.csi3.com/scenes.htm


Eventually I would like to control all of this using my logitech harmony IR remote.


I believe that the modules I have ordered support scene/group commands and hopefully also "direct to level" dimming commands.

However, the logitech database does not contain the IR commands needed to send the extended x10 commands from the IR7243W.

I found the "X10_Hacked.txt" file in the yahoo group but so far I have not figured out the syntax or how to use makehex to generate the hex files. If I can get the pronto Hex files then I should be able to load these onto my harmony remote.


Anyway, I just thought I would give you a bit of encouragement to continue the good work. It would be very useful for me and no doubt for others if you can figure out how to get the IR7243 to send extended commands.

Cheers

Matt

[cauer29]

Looking at the extended code format, this is how the standard and extended codes appear to be formatted (on the power line).

Standard:

1110;
4-bit house code,
4-bit unit/func code,
1-bit unit/func switch,
0000

(when the 1-bit switch is 0, the preceding code is a "unit code")
(when the 1-bit switch is 1, the preceding code is a "function code")

The 4-bit unit/func code and 1-bit unit/func switch are concatenated to become the 5-bit "OBC" code that we use with the IR543 box.

Extended Code 1:

1110;
4-bit house code,
4-bit func code (value 0111),
1-bit unit/func switch (value 1),
4-bit unit code,
8-bit data byte,
4-bit type code (see below),
4-bit command code,
0000

type code
0 = Shutters and Sunshades
1 = Sensors
2 = Reserved for Security
3 = Control Modules (Dimmers and Appliances)
4 = Extended Secure Addressing
5 = Extended Secure Addressing for Groups

The PDF doesn't describe the other two extended message formats, but this page does.

It appears that the "Pre Set Dim" function can be used in conjunction with the house code to come up with two pre-set dim levels, and this looks like something we could test with the IR543 using the standard protocol.

However, as for testing the extended codes, the more I think about it, I don't imagine that the IR543 is capable of generating the extended X10 signal on the power line. After all, it was invented so that people could send the regular X10 commands. It requires the 5-bit command code to be followed by it's complement just as an internal validation process so it can be sure that it's receiving a valid signal, it obviously doesn't send the complement down the power line. So, in order for it to be able to handle the extended format, the developer would have to have added special logic to do that, and if that were the case, somebody would have documented it before now.

This page documents the IR543 infrared protocol format and that seems to confirm that it can just handle the standard 5-bit commands.

I'm beginning to believe that the IR543 cannot generate extended codes. I was hoping that it would work more or less by accident just due to the basic logic implemented, but it does not appear to be the case. At the time the IR543 was designed, X10 did know that they had reserved 2 codes for XTD and XTC and they knew basically what they wanted to do with the extended codes and data, though they hadn't fully fleshed it out at the time. They made a concious decision to either support all 16 cmd codes blindly, or they might've specifically intended to include XTC and XTD in which case, we'd be in business.

I could go on testing more ideas but it's getting to be a little boring. F:5,A:20,~F:5,~A:20 did not work, nor did F:5, ~F:5, A:8, ~A:8 nor did F:5, A:8, ~F:5, ~A8. Even if it doesn't work no matter what, I'm still intrigued that the start code for the repeat of both the XTC and XTD commands is wrong. All 14 other cmd codes send the proper start code for the repeat. That made me think that there was special handling of the XTC and XTD commands.

As for the legacy preset dim, this is probably one of the most unusual commands from the original X10 protocol in that a controller must first send out a house code unit code combo ie K5 and then send the preset dim value as the house code with the preset dim function. Example:

K5

MPD0

That's housecode M combined with the preset dim 0 function code. A module listening on K5 will respond by interpreting the housecode as the preset dim level. Preset dim 0 maps 16 dim levels to the 16 house codes and preset dim 1 maps the other 16 dim levels to the 16 house codes. That's all well and good, but the IR543 uses a fixed housecode set by the code wheel. There's no way to change it via IR. So, if you choose the housecode via the codewheel judiciously to correspond with 2 useful dim levels in the upper and lower halves, you can get 2 useful preset dims out of the IR543. You will have to set the module's address to that same house code, else you could never get the module to listen to the IR543 for normal unit code addressing. So, with the IR543 you'd see:

K5

KPD0 or KPD1

An X10 system controller is not limited to matching housecode of the preset dim commands with the housecode of the housecode/unitcode that preceeds it. So they can send the full set of 32 dim levels.

A.A.

[cauer29]

Hello, I am new here.

I found this thread while searching for more information about the X10 extended commands.

I have just ordered some x10 lamp dimmer modules:
http://www.uk-automation.co.uk/x10-lamp ... -1216.html

..and an IR7243W:
http://www.letsautomate.com/10863.cfm


I hope to be able to create some lighting scene presets in a manner similar to this: i.e. Movie-Mode, Evening ... etc.
http://www.csi3.com/scenes.htm


Eventually I would like to control all of this using my logitech harmony IR remote.


I believe that the modules I have ordered support scene/group commands and hopefully also "direct to level" dimming commands.

However, the logitech database does not contain the IR commands needed to send the extended x10 commands from the IR7243W.

I found the "X10_Hacked.txt" file in the yahoo group but so far I have not figured out the syntax or how to use makehex to generate the hex files. If I can get the pronto Hex files then I should be able to load these onto my harmony remote.


Anyway, I just thought I would give you a bit of encouragement to continue the good work. It would be very useful for me and no doubt for others if you can figure out how to get the IR7243 to send extended commands.

Cheers

Matt

Supposedly the IR7243 is using the same command set as the IR543AH. The IR543AH info is available at:

http://www.laser.com/files/ir543ah.zip

That includes the full info on the extended commands and the pronto ccf file.

To me the price of the standard IR543 is awfully good at ~$15 vs the IR543AH at 6x the price for the slight increase in capability.


A.A.

[The Robman]

re: the preset dim function.

Assuming it even works (has it been tested) I was thinking that people could use the two EFCs to see if either of the preset dim levels are useful to them (given the house code that they have already decided to use).

I suppose that most people are not tied to a specific house code, so they could try changing it to see if they get better preset dim levels.