X10 - the answer

[mathdon]

I said elsewhere that the X10 discussion in this thread was closed, but in looking for info about IRP notation on the old Yahoo forum, by chance I came across the answer and so for the record I would like to report it.

Rob, your X10 Simple just adds to the intrigue. It largely agrees with John's original IRP, ie all frames identical and the first burst a bit longer than the others. It is decoded by my Beta9, but of course without the counter N since that frame is missing. But John got the distinctive start frame from somewhere, carrying the N value, and it is in the UEI executor (though as I said before, not quite the same), so I presume that is actually present in a real X10 signal. Conclusion - not much further ahead. It gives me no reason to change my Beta9 decoding.

I can't speak to where John got that frame from, and I bet he doesn't remember, but if it's not in my Simple upgrade, it's not in the real X10 signals. Like I said, there's a ton of junk in the UEI signal, which is there on purpose to cause problems.

Your decode needs to allow for the junk, because people might learn from a UEI remote, but it should by no means *require* it.

If you want proof, take a look at the X10 files at Remote Central. You can run the CCF files through John's DecodeCCF program which uses DecodeIR to see how they decode.

In the Yahoo forum I came across the following exchange dated March 19, 2003 between Rob and Jon Armstrong:

-------- Rob wrote: ------------

Just FYI, there is a counter in the X10 signal produced by UEI remotes, that's probably the "checksum" that you can't figure out. I can't imagine what purpose the counter serves except to make sure that that portion of the signal is different every time, kinda like the toggle bit in RC-5. To see what I mean, learn the same X10 button (as generated by a UEI remote) several times and you'll see the counter portion increment.

Rob

--------- Jon wrote: --------------

Right you are, here are the first nine bits of the numeral 1 command
pressed repeatedly:
5-bits 4-bits
06 12
06 02
06 10
06 06
06 14
06 00
06 08
06 04
06 12
06 02
06 10
06 06
06 14
06 00
06 08

There does look like a pattern. All the 4-bit numbers converted to decimal so far for ANY command are even numbers. I tried an x10 remote (not an OFA remote) using its IR feature and those IR commands do not have this first 9-bits. It just has the ten-bits as John defined x10 in MakeHex. So I do think that these are the burgler alarm system IR commands (made by x10) that uses different protocols (IR, RF, and Powerline) from the regular x10 protocols that control lighting etc.

-Jon
----------------------

So as I thought, there are X10 devices that do not have the counter frame (lighting etc) and devices that do (burglar alarm).
________________
Graham

[The Robman]

So as I thought, there are X10 devices that do not have the counter frame (lighting etc) and devices that do (burglar alarm).

We have no evidence of any sort that such devices exist (ie, the burglar alarms, etc) that use the counter frame.

I have explained elsewhere why the frame was added.

[The Robman]

I just got confirmation that the 9-bit counter portion of UEI's version of the X10 protocol was never used for anything. Further more, UEI has replaced that executor with a new one, called $01DF, where it has been removed.