|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Sun Apr 11, 2021 7:40 am Post subject: |
|
|
@Rob and 3FG
If the two of you can agree on a change to protocols.ini then I will include it, otherwise I will leave it unchanged. It seems to be a supremely unimportant issue, since this is the first time in over 10 years that the issue has arisen, so it is likely to be a long time before it crops up again. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1439 Location: Munich, Germany |
Posted: Sun Apr 11, 2021 8:13 am Post subject: |
|
|
@3FG: Thank you for the informative posting.
I am considering changing IrpProtocols.xml (for IrpTransmogrifier) to read:
Code: |
<irp:protocol name="X10">
<irp:irp>
<![CDATA[{40.8k,565}<2,-12|7,-7>(1:1,F:5,~F:5,21,-7)*[F:0..31]]]>
</irp:irp>
<irp:documentation xml:space="preserve">
IR version of the legacy home automation protocol <a href="https://en.wikipedia.org/wiki/X10_(industry_standard)">X10</a>.
This version does not contain a house number, as opposed to the version <a href="#X10.n">X10.n</a>, which contains a house number.
<a href="https://www.laser.com/dhouston/ir.html">Reference by Dave Houston</a>.
</irp:documentation>
<irp:parameter name="uei-executor">01DF</irp:parameter>
</irp:protocol>
<irp:protocol name="X10.n">
<irp:parameter name="alt_name">X10-IR543</irp:parameter>
<irp:irp>
<![CDATA[{40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(1:1,F:5,~F:5,21,-7)+)[F:0..31,N:0..15=0]]]>
</irp:irp>
<irp:documentation xml:space="preserve">
IR version of the legacy home automation protocol <a href="https://en.wikipedia.org/wiki/X10_(industry_standard)">X10</a>,
containing a house number ("N") (as opposed to the simpler version <a href="#X10">X10</a>).
</irp:documentation>
<irp:parameter name="uei-executor">003F</irp:parameter>
<irp:parameter name="reject-repeatless">true</irp:parameter>
</irp:protocol>
|
to remove the funny "toggling" of N. As far as I understand 003F, it does no such thing.
I really hate the silly name "X10.n", but it is probably easier just to keep it. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Sun Apr 11, 2021 12:29 pm Post subject: |
|
|
Barf wrote: | I am considering changing IrpProtocols.xml (for IrpTransmogrifier) ... to remove the funny "toggling" of N. As far as I understand 003F, it does no such thing.
|
I do not know what the "official" X10 specification mandates, but the S3F80 executor for PID=003F certainly toggles. Here is a screenshot of IRScope with 15 consecutive presses of the same button with a 003F upgrade on a URC7145:
You will see that N cycles from 0 to 14, then for some reason starts again at 1 rather than 0. There is no mechanism in the 003F executor to enter a value for N. _________________ Graham |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3377
|
Posted: Sun Apr 11, 2021 12:51 pm Post subject: |
|
|
The MAXQ and TI 003F executors are much shorter than executors in the older processors and do not toggle. I suppose that means they should be described as something like 003F:2.
I am not trying to promote any name changes; I think it is too late for that. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Mon Apr 12, 2021 9:38 am Post subject: |
|
|
3FG wrote: | The MAXQ and TI 003F executors are much shorter than executors in the older processors and do not toggle. |
I have just tried the MAXQ 003F executor in my URC6440 and found that not only do they not toggle, they do not in fact send an X10.n signal matching the IRP specification given in the DecodeIR or IrpTransmogrifier documentation. Here is the IRScope reading of three signals:
Each signal shows as two entries, as the first frame has a different OBC from the repeat frames, the repeats showing as a separate X10 signal. I thought this was a decoding error or a bad signal till I found it happened consistently. I have examined the MAXQ code and now understand what is happening.
The X10.n IRP from IrpTransmogrifier documentation is
Code: | {40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(7,-7,F:5,~F:5,21,-7)+,N=(N+1)%16)[F:0..31,N@:0..15=0] |
and here are the IRP analyses from IRScope of the two entries of the first signal:
Code: | X10.14 signal: {40.8k,564,msb}<2,-12|7,-7>(A:9,21,-7){A=0b111011110}
X10 signal : {40.9k,564,msb}<2,-12|7,-7>(A:11,21,-7)+{A=0b11101000101} |
In the MAXQ code, all data bits are generated from OBC=11, the value shown in the second entry. The value A=0b11101000101 in that entry is 1 followed by the 5-bit OBC in lsb form followed by its complement, in complete agreement with the X10.n IRP. However, the value A=0b111011110 from the first frame analysis is 1 followed by four bits of the 5-bit OBC in lsb form, another 1 then three bits of the 5-bit OBC in lsb form. The X10.n IRP interprets these as a 5-bit OBC in lsb form followed by a 4-bit N value in msb form.
Here is how this works for the other two signals. OBC=16 has 5-bit binary form 10000, or in lsb form 00001. So the first frame data is 10000 1000. Reading the first 5 bits as lsb and the remaining 4 bits as msb gives OBC=1, N=8, as the image indeed shows. OBC=19 has 5-bit lsb form 11001 which gives first frame data of 11100 1110 from which OBC=7, N=14, again as the image shows.
I don't know what to make of this, or how it should be reflected in protocols.ini or IrpTransmogrifier, but I felt it worth pointing out that the MAXQ and TI executors for 003F send a very different signal from those of the earlier processors. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21529 Location: Chicago, IL |
Posted: Mon Apr 12, 2021 12:46 pm Post subject: |
|
|
The UEI implementation of the X10 protocol (ie, the 003F executor) was designed to make it deliberately hard for folks to capture and replicate, so IIRC that's why they added that extra code in front of the true X10 signal. That's why I wrote an S3C8 executor years back that just produces the simple X10 signal. I assume the new 01DF executor also produces this simple signal.
I wasn't aware that John had programmed DecodeIR to fully document the UEI version of the signal and had called it X10.n. While I'm sure this is very interesting to us remote nerds, all the general public wants to know is "how do I program my remote to control my X10 IR543 box?" (assuming anyone is left, apart from me, who's still using an IR543 box). So all they need to know are the codes needed to plug into RM to either create or update an upgrade. They won't care if their remote sends the X10.n version of the pure X10 version, nor will they care with PID is used. So my vote would be to do whatever keeps it simple.
As for the question of creating an S3C8 version of 01DF, we already have it:
Code.S3C80=42 89 01 8B 12 85 21 06 05 07 67 07 74 02 62 0C AF 00 00 16 C8 07 74 20 10 E4 03 04 90 04 60 04 8D 01 46 _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Tue Apr 13, 2021 7:33 am Post subject: |
|
|
@Rob
So the first frame sent by 003F is junk. That makes sense, since the S3C80 and MAXQ610 executors for it send completely different first frames and neither agrees with the "house number" concept in the description that 3FG referenced.
The simplest option appears to be to do very little: add the known executors for 01DF into protocols.ini, keeping both 003F and 01DF named X10. This is essentially what you proposed earlier, except the control entries for 01DF need to be copied from those of 003F as the existing ones are wrong. As I pointed out earlier, doing this means that one of the executors gets hidden. Specifically, it is not possible to create a 003F upgrade for processors that have 01DF code but it appears that no longer matters, the 01DF code is preferable. DecodeIR and IrpTransmogrifier need to keep the names X10.n and X10 as for decoding purposes they are different, but RMIR already shows both decodes as X10 (when IrpTransmogrifier is the decoder) and with a minor addition to rmProtocols.xml, Convert to Device Upgrade can be made to use 01DF when code is available and 003F otherwise, regardless of whether the decoder actually gave X10 or X10.n.
I take it that the S3C80 executor you have posted for 01DF is "home-made". Since 01DF is a built-in protocol for at least one remote with a Samsung processor, we should have access to the official code. Is there any way of finding it, or is your post actually the official one? _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21529 Location: Chicago, IL |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Sun Apr 18, 2021 9:57 am Post subject: |
|
|
Barf wrote: | I am considering changing IrpProtocols.xml (for IrpTransmogrifier) ... to remove the funny "toggling" of N. As far as I understand 003F, it does no such thing. |
Are you sure that the proposed entry for the X10.n protocol properly describes the X10 version that includes a house number? As far as I can tell, that entry is based on the S3C80 executor (or earlier) for PID=003F. That does not have the house number N as an input parameter, and the 003F executors for the MAXQ and TI processors have a completely different first frame. I am inclined to believe Rob's explanation that the first frame in the 003F executor is irrelevant junk and so can see no reason why it should agree with the official protocol that includes a house number. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1439 Location: Munich, Germany |
Posted: Sun Apr 18, 2021 11:23 am Post subject: |
|
|
Quote: | Are you sure that the proposed entry for the X10.n protocol properly describes the X10 version that includes a house number |
No. (That is why I wrote "am considering" instead of "have decided to...")
Right now I do not feel that motivated to do "archeology"... Feel free tell me how you want it. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Mon Apr 19, 2021 9:35 am Post subject: |
|
|
@Barf
It seems clear to me that the "n" value in the X10.n protocol is not the house number. Since the S3C80 executor for PID=003F cycles n through 15 values, if it were the house number then it would send the correct house number only once in every 15 signals. I think someone would have noticed that their remote worked only once in every 15 keypresses. I see that the document 3FG referenced says
Quote: | The IR543AH is a modified IR543. It was developed by Laser Systems and uses a proprietary extension to the X-10 IR protocol. The IR543AH can handle all 16 housecodes and adds Preset Dim and Extended codes to the functions supported. |
It seems that they are keeping the specification of that extension secret. We have no information on how the house number is encoded in it, but for the reason I have just given I do not believe that extension is what we are calling X10.n. Why UEI would want to put a junk initial frame into X10 but not do so with any other protocol is beyond my comprehension, but I agree with Rob that that is what they have done.
So what do I think you should do? Ideally I would delete the X10.n entry entirely and not have any mention of house numbers or of the existence of an extended protocol in the description of the remaining X10 entry. My hope would be that IrScrutinizer would then ignore the junk initial frame in an X10.n signal and show it as X10. However, I have tried that and it doesn't work. Deleting X10.n from IrpProtocols.xml makes the X10.n signal not decode. So my alternative suggestion would be to make the change you propose to the IRP for X10.n and to document that this is an X10 signal with a non-functional first frame. Development version 2.12.16 of RMIR has a modified rmProtocols.xml which makes both X10 and X10.n show in the Learned Signals tab simply as X10, and if the decode was actually X10.n then it adds a note "Has non-functional first frame" in line with what I have suggested. Convert to Device Upgrade will convert both forms to PID 01DF if there is an executor for the processor concerned, otherwise to PID 003F. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21529 Location: Chicago, IL |
Posted: Mon Apr 19, 2021 10:32 am Post subject: |
|
|
As we all already know, UEI does a lot of tricks to try and protect their IR database, as they view this as their intellectual property, but given that they don't own the copyright on most of the IR protocols, it's hard for them to protect it legally. So, they put in tricks like, they will scramble the buttons if you change setup codes too often, they include fake brand names and fake codes in their code lists, so that they can see if they pop up in other company's code lists, etc etc.
I seem to recall having a conversation with them where they admitted making the X10 protocol more complicated than it needed to be as a way of making it harder to learn properly. So I still believe that any differences between what 003F shoots and the official X10 format are not needed. As for what the decoders should display, it's fine for them to let us know that the additional frame is there, but as far as displaying codes goes, the idea is that the casual user who sees them should know to select the X10 protocol when building an upgrade. Having the protocol display as x10.n would likely confuse them. But having said that, very few people are still using X10, so I don't think is something that requires urgent attention. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4592 Location: Cambridge, UK |
Posted: Mon Apr 19, 2021 11:37 am Post subject: |
|
|
The Robman wrote: | So I still believe that any differences between what 003F shoots and the official X10 format are not needed. As for what the decoders should display, it's fine for them to let us know that the additional frame is there, but as far as displaying codes goes, the idea is that the casual user who sees them should know to select the X10 protocol when building an upgrade. Having the protocol display as x10.n would likely confuse them. |
Rob, in case I was not clear, I was trying to say exactly this. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21529 Location: Chicago, IL |
Posted: Mon Apr 19, 2021 1:31 pm Post subject: |
|
|
And I agree with you, I was just adding additional context in case it helped Bengt or anyone else. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21529 Location: Chicago, IL |
Posted: Mon Apr 19, 2021 5:54 pm Post subject: |
|
|
Regarding the IR543H house codes, there is a file over at Remote Central that lists them, so the format is known.
Here is the file:
http://files.remotecentral.com/view/5579-14375-1/x-10_ir543ah_lighting.html
I have copied the file here and have included a spreadsheet that shows them all decoded:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26310
The format is very similar to the standard X10 format, the main difference being that it has a 4-bit code, rather than a 5-bit code.
Here are the OBCs for everything. I've also included the regular X10 OBCs, including the Home Security codes that were pulled from a UEI codesheet, but I've never known anyone to actually have one of these devices.
X10 HOUSE CODES
06 - HOUSE CODE A
07 - HOUSE CODE B
04 - HOUSE CODE C
05 - HOUSE CODE D
08 - HOUSE CODE E
09 - HOUSE CODE F
10 - HOUSE CODE G
11 - HOUSE CODE H
14 - HOUSE CODE I
15 - HOUSE CODE J
12 - HOUSE CODE K
13 - HOUSE CODE L
00 - HOUSE CODE M
01 - HOUSE CODE N
02 - HOUSE CODE O
03 - HOUSE CODE P
X10 DEVICE CODES CODES
06 - DEVICE CODE 1
07 - DEVICE CODE 2
04 - DEVICE CODE 3
05 - DEVICE CODE 4
08 - DEVICE CODE 5
09 - DEVICE CODE 6
10 - DEVICE CODE 7
11 - DEVICE CODE 8
14 - DEVICE CODE 9
15 - DEVICE CODE 10
12 - DEVICE CODE 11
13 - DEVICE CODE 12
00 - DEVICE CODE 13
01 - DEVICE CODE 14
02 - DEVICE CODE 15
03 - DEVICE CODE 16
X10 COMMAND CODES
22 - X10 All Lights Off
24 - X10 All Lights On
16 - X10 All Units Off
26 - X10 Bright
18 - X10 Dim
28 - X10 Off
20 - X10 On
Home Security Codes
00 - Arm (Max) / Delay Away Arm
16 - Arm (Min) / Inst Away Arm
12 - Delay Home Arm
08 - Disarm
28 - Home Arm (Min)
02 - Medic Alarm
20 - Panic
04 - Sec Light Off
24 - Sec Light On
18 - Silent Alarm _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|