|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Tue Apr 20, 2021 6:52 am Post subject: |
|
|
The Robman wrote: | Regarding the IR543H house codes, there is a file over at Remote Central that lists them, so the format is known. ... I have copied the file here and have included a spreadsheet that shows them all decoded |
I don't understand the spreadsheet. It lists OBC1, OBC2 and OBC, but for what prococol? And what does the column "JP1 Upgrade" mean, which lists just a name? The Pronto codes do not decode as either X10 or X10.n when copied as learned signals into RMIR. I am confused. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Tue Apr 20, 2021 7:29 am Post subject: |
|
|
OK, I think I have got it. The reason none of the Pronto codes did not decode as X10 when I imported them as learned signals into RMIR was that I had selected a remote whose processor did not have an X10 executor, only an X10.n one. With that sorted, the Pronto signals other than the house codes do decode as X10. The house codes do not decode as learned signals, but they do decode in IrScrutinizer as X10_8, an X10 variant that Bengt has in IrpTransmogrifier but which is not recognised by RMIR. I still don't understand the spreadsheet, but that is no longer a significant issue. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21453 Location: Chicago, IL |
Posted: Tue Apr 20, 2021 8:52 am Post subject: |
|
|
When I decoded the pronto code, I found 2 occurrences of data, each with a leadin and leadout pair, for most of the signals. I didn't know at first that they were going to be clones of each other.
Once I had determined the OBCs for all of the decoded data, I opened the official X10 JP1 Upgrade, that I linked to earlier, to get the commands and OBCs from that, just to verify that they matched.
Column A = the name of the signal as given in the text file
Column B = the first data string converted to binary
Column C = the second data string converted to binary
Column E = the first 4 or 5 bits of the first string converted to decimal
Column F = the next 4 or 5 bits of the first string converted to decimal and comp'd
Column G = the first 4 or 5 bits of the second string converted to decimal
Column H = the next 4 or 5 bits of the second string converted to decimal and comp'd
Column J = the name of the function in the official JP1 upgrade
Column K = the OBC from the JP1 upgrade _________________ 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: 4571 Location: Cambridge, UK |
Posted: Tue Apr 20, 2021 10:00 am Post subject: |
|
|
Rob, thanks for the explanation. I have created modified versions of the X10 executors to send the 4-bit house code version that IrpTransmogrifier calls X10_8 and will add them to protocols.ini with PID 01FF:JP1X10H. I think X10H, the H for House Code, is a better name than X10_8 now we know what it is for.
I presume that the IR543AH box is sent three different signals, one to set the house code, one the device (unit) code and one the actual command for the device, and that the first two are persistent until changed so that consecutive commands can be sent for the same device without repeating the house and unit codes. Do you know enough about X10 to confirm or refute this? I think you may have an unextended IR543 box. Is there a way of presetting the house code in that so that only X10 and not X10H signals are required? _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21453 Location: Chicago, IL |
Posted: Tue Apr 20, 2021 1:11 pm Post subject: |
|
|
I do have a regular IR543 box, I don't have the IR543H.
My understanding of what is needed is in alignment with what you described.
I was thinking of modifying my simple X10 protocol so that it supports the house codes too. Given that X10 has a 5-bit command code, that leaves 3 extra bits that could be used to indicate that the 4-bit signal is needed. _________________ 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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1429 Location: Munich, Germany |
Posted: Tue Apr 20, 2021 3:41 pm Post subject: |
|
|
The Robman wrote: | And I agree with you, I was just adding additional context in case it helped Bengt or anyone else. |
Actually, it was clear for me too...
mathdon wrote: | they do decode in IrScrutinizer as X10_8, an X10 variant that Bengt has in IrpTransmogrifier |
I am not 100% sure, but I think that the blaime/praise belongs do Dave (3FG), I probably just snarfed it from his Teaser.
I fooled around a bit with the RemoteCentral signals using IrpTransmogrifier, and I came up with the following protocols:
Code: |
<irp:protocol name="X10-house">
<irp:irp><![CDATA[
{38.5k,1152}<1,-6281u|3,-3>(1:1,H:4,~H:4,10,-3,1:1,H:4,~H:4,10,-104m)*[H:0..15]
]]></irp:irp>
</irp:protocol>
<irp:protocol name="X10-device">
<irp:irp><![CDATA[
{38.7k,1187}<1,-6557u|3,-3>(1:1,D:4,0:1,~D:4,1:1,10,-3,1:1,D:4,0:1,~D:4,1:1,10,-92m)*[D:0..15]
]]></irp:irp>
</irp:protocol>
<irp:protocol name="X10-command">
<irp:irp><![CDATA[
{38.7k,1187}<1,-6557u|3,-3>(1:1,C:4,1:1,~C:4,0:1,10,-92m)*[C:0..15]
]]></irp:irp>
</irp:protocol>
|
(the timing looks funny, I just took what IrpTransmogrifier gave me). Saving these protocols to a file X10Protocols.xml (ok, need to make it a complete XML file first) and the codes decodes:
Code: |
$ irptransmogrifier -c X10Protocols.xml decode --named codes.txt
HOUSE CODE A: X10-house: {H=6}, beg=0, end=39, reps=1
HOUSE CODE B: X10-house: {H=7}, beg=0, end=39, reps=1
HOUSE CODE C: X10-house: {H=4}, beg=0, end=39, reps=1
HOUSE CODE D: X10-house: {H=5}, beg=0, end=39, reps=1
HOUSE CODE E: X10-house: {H=8}, beg=0, end=39, reps=1
HOUSE CODE F: X10-house: {H=9}, beg=0, end=39, reps=1
HOUSE CODE G: X10-house: {H=10}, beg=0, end=39, reps=1
HOUSE CODE H: X10-house: {H=11}, beg=0, end=39, reps=1
HOUSE CODE I: X10-house: {H=14}, beg=0, end=39, reps=1
HOUSE CODE J: X10-house: {H=15}, beg=0, end=39, reps=1
HOUSE CODE K: X10-house: {H=12}, beg=0, end=39, reps=1
HOUSE CODE L: X10-house: {H=13}, beg=0, end=39, reps=1
HOUSE CODE M: X10-house: {H=13}, beg=0, end=39, reps=1
HOUSE CODE N: X10-house: {H=1}, beg=0, end=39, reps=1
HOUSE CODE O: X10-house: {H=2}, beg=0, end=39, reps=1
HOUSE CODE P: X10-house: {H=3}, beg=0, end=39, reps=1
DEVICE CODE 1: X10-device: {D=6}, beg=0, end=47, reps=1
DEVICE CODE 2: X10-device: {D=7}, beg=0, end=47, reps=1
DEVICE CODE 3: X10-device: {D=4}, beg=0, end=47, reps=1
DEVICE CODE 4: X10-device: {D=5}, beg=0, end=47, reps=1
DEVICE CODE 5: X10-device: {D=8}, beg=0, end=47, reps=1
DEVICE CODE 6: X10-device: {D=9}, beg=0, end=47, reps=1
DEVICE CODE 7: X10-device: {D=10}, beg=0, end=47, reps=1
DEVICE CODE 8: X10-device: {D=11}, beg=0, end=47, reps=1
DEVICE CODE 9: X10-device: {D=14}, beg=0, end=47, reps=1
DEVICE CODE 10: X10-device: {D=15}, beg=0, end=47, reps=1
DEVICE CODE 11: X10-device: {D=12}, beg=0, end=47, reps=1
DEVICE CODE 12: X10-device: {D=13}, beg=0, end=47, reps=1
DEVICE CODE 13: X10-device: {D=0}, beg=0, end=47, reps=1
DEVICE CODE 14: X10-device: {D=1}, beg=0, end=47, reps=1
DEVICE CODE 15: X10-device: {D=2}, beg=0, end=47, reps=1
DEVICE CODE 16: X10-device: {D=3}, beg=0, end=47, reps=1
X10 All Lights On: X10-command: {C=8}, beg=0, end=23, reps=1
X10 All Lights Off: X10-command: {C=6}, beg=0, end=23, reps=1
X10 All Units Off - (including appliance modules): X10-command: {C=0}, beg=0, end=23, reps=1
X10 On - Turns an individual device on: X10-command: {C=4}, beg=0, end=23, reps=1
X10 Off - Turns an individual device off: X10-command: {C=12}, beg=0, end=23, reps=1
X10 Bright - Individual Device - Set as repeated key: X10-command: {C=10}, beg=0, end=23, reps=1
X10 Dim - Individual Device - Set as Repeated Key: X10-command: {C=2}, beg=0, end=23, reps=1
|
|
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Wed Apr 21, 2021 5:32 am Post subject: |
|
|
@Barf
If you really want to change the timings from those in the existing IRPs, I suggest you use the actual values taken from the document 3FG references, which would give <1200u,-6800u|400u,-4000u>. But the existing {38.4k,565}<2,-12|7,-7> is equivalent to <1130u,-6780u|3955u,-3955u> is very close and neater, and {38.4k,570}<2,-12|7,-7> is even better at <1140u,-6840u|3990u,-3990u>. I think these are preferable. However, I see little wrong with the IRPs currently in IrpProtocols.xml apart from the frequency. The only reason that the Pronto codes mostly do not decode in IrScrutinizer is the frequency, as 38.4k or 38.7k are outside the default tolerance of 2000Hz from the 40.8k frequency in the existing IRPs, which is why I have used 38.4k above. I presume the use of 40.8k was another deliberate obfuscation by UEI, since their later 01DF executor uses 38.4k. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Wed Apr 21, 2021 9:35 am Post subject: |
|
|
@Barf
I have put your X10-house, X10-device and X10-command protocols into IrpProtocols.xml instead of X10 and X10_8 and tried to decode signals from the PID=01DF X10 executor. Most of the time they do not decode. An X10 command decodes only if the keypress is very brief, an X10 device code decodes only on a very slightly longer keypress. I believe this corresponds to exactly one frame being sent for an X10 command and exactly two frames being sent for an X10 device code. A modified 01DF executor that sends house codes behaves like the X10 command, being decoded as X10-house only if exactly two frames are sent.
I cannot believe this is your intention. Separately I have changed the frequency in the existing X10 and X10_8 IRPs to 38.4k and then all the signals decode. That is far preferable. If you want to split X10 into two to have separate protocols for device and command codes then that is fine, as is re-naming X10_8 as X10-house, but please do not use IRPs that require an exact number of frames to be sent for the signal to be recognised. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1429 Location: Munich, Germany |
Posted: Thu Apr 22, 2021 4:17 am Post subject: |
|
|
mathdon wrote: | If you really want to change the timings from those in the existing IRPs |
No, I don't,
I wrote: | I just took what IrpTransmogrifier gave me |
understanding that work was needed to "canonicalize" the timings, but I wanted to spend the rest of the evening doing something else.
I do not consider myself a stake holder in this issue. Whatever is fine with you is fine with me too. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Wed Apr 28, 2021 6:09 am Post subject: |
|
|
I have now posted development build RMIR v2.12.17 in the RMIR Development folder on SourceForge. This build updates the entries for the X10 protocol so that signals are set or decoded by descriptive name rather than by cryptic OBC values, so "Dev 3" or "all lights on" for example for device numbers and command functions and as A through P for house code values. In order for the choice lists that show in the Functions tab of the Device Upgrade Editor to list house codes in alphabetical order A-P, device numbers in order 1-16 and command names in a sensible order, I have created an X10Translator that unscrambles the rather strange order in which the OBCs are allocated.
These changes concern the X10 (PID=01DF) and X10H (PID=01FF:JP1X10H) protocols. For backward compatibility the X10.n (PID=003F) protocol has been left unchanged, except for an update to the Notes entry. It has become clear that the only remotes that send the X10.n signal are UEI remotes with the 003F executor. Automated conversion of learned signals to a device upgrade will, by default, only use the X10 and X10H protocols. This applies even to learned X10.n signals which will be converted to their X10 equivalents. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1429 Location: Munich, Germany |
Posted: Thu Apr 29, 2021 5:57 am Post subject: |
|
|
Graham,
I have checked rmProtocols.xml. What strikes me is that you have removed "X10" and "X10_8" without replacements. Is this intended, and if so, what is the rationale? (Sorry, right now I am too laze to read all the preceding posts...) IIRC, the X10_8 was introduced by 3FG; Dave, I would very much like your comment on this. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Thu Apr 29, 2021 8:57 am Post subject: |
|
|
Barf wrote: | What strikes me is that you have removed "X10" and "X10_8" without replacements. |
I do not understand. X10_8 is replaced by X10-house with an identical IRP, X10 is replaced by X10-device for F values 0-15 and by X10-command for F values 16-31. I took these three replacements from your proposal, with only minor changes to timings. Whatever would be the point of retaining X10 and X10_8 in addition to these? _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1429 Location: Munich, Germany |
Posted: Fri Apr 30, 2021 2:28 am Post subject: |
|
|
Ok, that is the rationale I was looking for. Thank you. There is one caveat though: the frequency. I generated a signal with the old X10 protocol, and tried decoding it, which failed.
(For comman line geeks: Here is fancy command line:
Code: | irptransmogrifier render --name F=1 --pronto X10 | \
irptransmogrifier --config harctoolbox/IrpTransmogrifier/src/main/resources/IrpProtocols.xml \
--config jp1/rmir/src/main/config/rmProtocols.xml decode --input - | if anyone cares....)
Moreover, the documentation of X10-device says that D is between 1 and 16, while the IRP says 0 to 15. Please have a look at how this is handled in "my" protocol arctech, which lets the user enter D=1..16, while the protocol proper uses D-1. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4571 Location: Cambridge, UK |
Posted: Fri Apr 30, 2021 7:07 am Post subject: |
|
|
I believe that rmProtocols.xml is correct. Here are my responses to your comments.
1. All the evidence is that the frequency in the X10 IRP in the current IrpProtocols.xml is wrong. I believe you took the value of 40.8kHz from DecodeIR, which looks as if it took the value from X10.n. X10.n is an invention of UEI which apparently has a frequency that, like the deliberate junk first frame, is accepted by X10 equipment but which differs from the behaviour of real X10 IR remotes. Even the newer UEI protocol with PID 01DF, which sends the true X10 signal without a first frame, uses a frequency of 38.4kHz, as do all the IR signals that Rob discovered in RemoteCentral. So I do not believe there is any equipment that sends a true X10 signal (without junk first frame) with a frequency of 40.8kHz. If you really want 40.8kHz to be acceptable to X10-device and X10-command then set a frequency tolerance of 3000 instead of 2000 in the protocol but leave the IRP at the correct value of 38.4kHz.
2. The device number is indeed between 1 and 16 and the D range in the IRP of X10-device is 0 to 15, but the device number is not D+1. The same situation occurs in X10-house, where the IRP has an H parameter with range 0-15 and house codes A through P. The correspondence is not 0->A, 1->B, etc. If you look at the spreadsheet Rob posted, you will see that the device codes 1,2,3,4,5,... correspond to D values 6,7,4,5,8,... and house codes A,B,C,D,E,... similarly correspond to H values in this same order. That is why I have needed to write an X10Translator and have corresponding definition sections in the uei-executor. The D and H values 6,7,4,5,8,... are mapped by the definition sections into G values 0,1,2,3,4,... which are in turn translated by the rm:translator entries into 1,2,3,4,5,... for device number and A,B,C,D,E,... for house code. The G value is an intermediary that is not displayed in either IrpTransmogrifier or RMIR, so the fact that the device number is G+1 is irrelevant. In RMIR, users select House codes A,B,C,... and devices Dev 1, Dev 2, Dev 3 from choice lists, as they do commands all off, all lights on, ... .
3. If the definition sections in uei-executor look unnecessarily complicated, this is because they need to be reversible. An X10 (PID 01DF) upgrade in RMIR can be exported as a Girr file and the entries are correctly converted to X10-device or X10-command as appropriate with the correct D and C parameter values.
4. I do not know what "my" protocol arctech is. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1429 Location: Munich, Germany |
Posted: Fri Apr 30, 2021 7:35 am Post subject: |
|
|
4. The protocol arctech is as found in IrpProtocols.xml. The IRP is written by myself on basis of miscellaneous information on the Internet + my own experiences. Therefore the "my". |
|
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
|