JP1 Remotes

Now that we're using Barf's decoder program, what is the process to add a new protocol to it?

Here's one that I would like to have added:

TCL AIR CONDITIONER REMOTE GYKQ-03
https://www.hifi-remote.com/forums/viewtopic.php?t=16473

And here's a spreadsheet of all the possible signals in binary format:
https://www.hifi-remote.com/forums/dload ... e_id=25903

It's a 14 byte LSB signal where:
1. The first 5 bytes are fixed (decimal values: 35, 203, 38, 1, 0)
2. The next 5 bytes are variable data
3. The next 3 bytes are always zero
4. The final byte is a checksum, derived by ADDing all the other bytes together.

Note: Keep in mind that the data is LSB, so you can't just ADD the data "as is", you need to reverse it into MSB format first.

I have no idea how you'd present 10 bytes of data as a decode though, so that's a bit of a challenge.

How 'bout
(inserted as a child of the top level element in IrpProtocols.xml). Or just download IrpProtocols.xml.

I have here changed your "5" in #2 to 4, and "3" in #3 to 4.

No idea really if the parametrization is optimal. Would be nice to find out more about the semantics of the parameters.

Rob, to use Barf's entry in RMIR, you need to add it into rmProtocols.xml in your RMIR installation folder. You add it before the last line, which is </irp:protocols>. This is a patch file for IrpProtocols.xml, you don't have direct access to that file in RMIR as it is buried in RemoteMaster.jar.

You will see that rmProtocols.xml currently has no protocol entries, just some header text. So this will be its first entry for this version of RMIR. Every so often Barf rolls this patch file into his official IrpProtocols.xml in IrpTransmogrifier, I use the updated IrpTransmogrifier in RMIR and empty rmProtocols.xml ready for more additions.

If you confirm that this entry works, I will add it to rmProtocols.xml for the next build of RMIR.

Further to my post above, if you import the ict file of these signals into RMIR with the menu item Advanced > Import Ict as Learned, then they decode with this entry as TCL-AC signals. However, they all show an OBC of 0, which is spurious. The OBC value is taken from a protocol parameter F and this protocol has F1,..,F4 so none is identified as the OBC. It might be better to rename F1 (or one of the others) simply as F so that it shows as the OBC. Note that F1 occurs 3 times in the protocol entry and all need to be changed.

If you do this and then want F2,..,F4 to show as OBC2,..,OBC4 just let me know as I can add extra items to the protocol entry to do this.

Thanks for the input guys, I will experiment with this to see how I think the best way to display it is.

Barf wrote:I have here changed your "5" in #2 to 4, and "3" in #3 to 4.

No idea really if the parametrization is optimal. Would be nice to find out more about the semantics of the parameters.

I think you must just have been looking at the more limited sample that Carl provided, rather than the complete info in the spreadsheet from and ict files from the other thread, because that 5th byte of variable data is the 24 hour timer. The spreadsheet decodes the data so it shows the semantics.

Also, while I know it's not relevant to the decoding of the signals, if you're interested in the executor that I wrote for it, note that I did everything backwards. The signal is LSB but the data provided into my executor is in MSB format, so that I could more easily ADD all 13 bytes together for the checksum, plus I have a 14 byte table of data values in the code that I read using a descending index, so that table is backwards too, and finally, as an efficiency, I use LDW (Load Word) to move some of the input data into the table, so those bytes need to be backwards too. I feed the 5 variable bytes into the executor as byte1, byte3, byte2, byte5, byte4, lol.

Rob, will you want the executor included in protocols.ini, or is it too specialized for that? If it is included, then I should be able to add a uei-executor entry into the protocol to enable a device upgrade to be created automatically from learned signals or an ict file.

Rob, I've had a quick look at the spreadsheet and as a non-Excel user I find it pretty incomprehensible to figure out what it is doing. Is there some documentation anywhere on how the Fan, Temp etc parameters relate to the protocol parameters or to the command parameters of your executor? Ideally the command parameters should be the Fan, Temp etc settings and be mapped by command translators to the variable bytes of the executor code, by-passing the spreadsheet entirely, but there is no way I could figure out if that is possible from the spreadsheet itself.

mathdon wrote:Rob, I've had a quick look at the spreadsheet and as a non-Excel user I find it pretty incomprehensible to figure out what it is doing. Is there some documentation anywhere on how the Fan, Temp etc parameters relate to the protocol parameters or to the command parameters of your executor? Ideally the command parameters should be the Fan, Temp etc settings and be mapped by command translators to the variable bytes of the executor code, by-passing the spreadsheet entirely, but there is no way I could figure out if that is possible from the spreadsheet itself.

Sure, there are 14 bytes of data, and the data should be read LSB.

Bytes 1-5 are fixed data with values 35, 203, 38, 1, 0
Byte 6: bits 1-2 always zero
Byte 6: bit 3 is the ON/OFF bit for the MODE shown below
Byte 6: bit 4 is set when the TIMER is on (see also byte 9, bit 7)
Byte 6: bits 5-6 (reading from left to right) fixed at "0010"

Byte 7 is the MODE, where 1=heat,2=dry,3=cool,7=fan,8=feel
Byte 8 is the TEMP, subtract the number from 31 to get the temp in centigrade
Byte 9: bits1-3 are the FAN, where 0=Auto,1=Sleep,2=Low,3=Med,5=High
Byte 9: bits4-6 are the SWING, where 0=off,7=on
Byte 9: bit7 also gets set when the TIMER is on
Byte 9: bit 8 is always 0
Byte 10: is the 24 hour timer, divide the number by 6 to get the hour time
Bytes 11-13 always zero
Byte 14: checksum, ADD all the other bytes

I am surprised you're not an Excel user because it's SO useful with all this remote stuff, I'd be happy to show you the ropes if you're interested.

Rob, many thanks for the descriptions of the bytes in this protocol. With its help I have created protocol entries for protocols.ini and rmProtocols.xml that use these parameters rather than the cryptic F1,..,F4. This is posted in development build 11, see this post for details.