|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
loft
Joined: 01 Dec 2015 Posts: 51 Location: Stuttgart, DE |
Posted: Thu Jun 10, 2021 12:50 pm Post subject: Help me with creating device update |
|
|
Hello,
Since I haven't found it around, I've decided to create myself a device update for a Eufy 11s robot vacuum.
So I transferred the robot's remote to my URC-7890 and came up with this list of codes: https://www.imagebam.com/view/GAJCN (I'm not sure where I can safely upload the resulting file here).
I tried to create the update file myself, but I got stuck at the fact that my codes don't have a protocol and other details.
What could I do?
Thanks! |
|
Back to top |
|
|
mdavej Expert
Joined: 08 Oct 2003 Posts: 4501
|
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
|
Back to top |
|
|
loft
Joined: 01 Dec 2015 Posts: 51 Location: Stuttgart, DE |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Thu Jun 10, 2021 4:59 pm Post subject: |
|
|
I don't have the ability to write custom executors for your particular remote, but I can describe the signal (specifics below). There are 6 bytes of data where the odd bytes are fixed and the even bytes are variable. The 2nd byte appears to be the OBC byte and the 6th byte appears to be a checksum. There's only 1 bit that changes in the 4th byte.
freq: 38k
lead-in: +3000 -3000
leadout: +500 -20000
one : +500 -500
zero: +500 -1500
10010111 00010000 11101001 11110010 10101010 00110000 - 9
10010111 01010011 11101001 11110010 10101010 01110011 - 6
10010111 01100011 11101001 11110010 10101010 10000011 - 5
10010111 01110011 11101001 11110010 10101010 10010011 - 4
10010111 10000000 11101001 11110010 10101010 10100000 - Down
10010111 10010000 11101001 11110011 10101010 10110001 - Right
10010111 10110000 11101001 11110010 10101010 11010000 - OK
10010111 11000000 11101001 11110011 10101010 11100001 - Left
10010111 11010000 11101001 11110011 10101010 11110001 - Up
10010111 11100011 11101001 11110010 10101010 00000011 - 3
10010111 11110010 11101001 11110010 10101010 00010010 - 1 _________________ 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 |
|
|
loft
Joined: 01 Dec 2015 Posts: 51 Location: Stuttgart, DE |
Posted: Fri Jun 11, 2021 3:38 pm Post subject: |
|
|
So no device upgrade can be created?
I only asked for help since I wanted to potentially help others. But if it is not possible, what can I do?
Thanks for all the time! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Fri Jun 11, 2021 3:41 pm Post subject: |
|
|
If you had a remote with an S3C8 processor, I could create an upgrade for you, but your remote has the TI processor, so you'd need one of the other experts to help with that. I think only Graham and Dave know how to write them. _________________ 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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Fri Jun 11, 2021 6:39 pm Post subject: |
|
|
I will work on an executor this weekend. Rob, you mentioned that the 6th byte may be a check sum. Do you have a formula in mind? Unless it is describable in protocols.ini, I think we should just enter it as an additional OBC. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sat Jun 12, 2021 12:46 am Post subject: |
|
|
Looks like the check sum byte is 2nd plus 4th bytes plus 0x2E. Or all 5 bytes plus 4. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Sat Jun 12, 2021 9:56 am Post subject: |
|
|
Dave, there's an efficiency that you might want to consider for your executor, bits 2 and 3 of the 2nd byte are always zero, and for the 4th byte, only bit 0 changes, so it might be worth using one of the zero bits from the OBC byte to populate that bit in the 4th byte. If you can do it with less than 11 bytes of assembler code, it would be worth it.
(For anyone confused by the numbering scheme, I am counting the BYTES from 1 to 6 going from left to right, but am counting the BITS from 0 to 7 going from right to left). _________________ 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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sat Jun 12, 2021 8:56 pm Post subject: |
|
|
Here's an entry for protocols.ini Code: | [Eufy 11s]
PID=01 FF
DevParms=Device:8=151,Sub Device:8=170, Chk Offset Lo:4=4, Chk Offset Hi:4=1
DeviceTranslator=Translator(0,8,0) FieldCopier(0,8,8,lsb) Translator(1,8,16) Translator(3,4,24) Translator(2,4,28) NibbleSumChk(AAAA,24,0) NibbleSumChk(5555,28,0)
FixedData=97 AA E9 00
CmdParms=OBC1:8=0,OBC2:8=0
CmdTranslator=Translator(0,8,0) Translator(1,8,8)
DefaultCmd=00 00
Code.TI2541=01 07 01 21 42 0E 13 00 13 00 13 00 39 00 F8 02 72 00 72 00 00 80 08 03 05 05 06 03 05 05 07 42 54 06 70 74 71 75 72 73
Code.MAXQ610=34 68 42 0E 13 00 13 00 13 00 39 00 F8 02 72 00 72 00 00 80 08 03 D3 D3 D4 03 D3 D3 D5 42 54 06 70 74 71 75 72 73 | The 3rd byte is the 1st byte bit reversed, and that is the FieldCopier part. The check sum for the bytes 1, 3 and 5 is computed by RMIR using the NibbleSumChk translators. The lo offset is by default set to 4 as needed by the assumed checksum format. The hi offset is actually the carry from summing the low nibbles, and could have values of 0, 1 or 3. With these learns, the hi offset is 1: 0x7 + 0xA + 0xE + 0x4= 0x1E.
The upgrade will need to have appropriate function names and button assignments, maybe a different PID, etc. I tested it with a URC7980.
Here's a couple of comments on the executor Code: | Modulation On/Off: 8.77uS/17.53uS; Total: 26.30uS; Frequency: 38.02 KHz
Number of Fixed/Variable Bytes: 4/2
TD_00-TD_03 13 00 13 00 Data1 On/Off: 500uS/500uS //in units of 26.30us
TD_04-TD_07 13 00 39 00 Data0 On/Off: 500uS/1499uS
TD_08-TD_09 F8 02 LO Off: 19988uS
TD_0A-TD_0D 72 00 72 00 LI On/Off: 2998uS/2998uS
Protocol Timing Bytes: 14
03 05 05 06 ADD DCbuf3 DCbuf3 DCbuf4 //On entry, DCbuf3 contains the partial checksum computed by RMIR. OBC1 and OBC2 are added to it here
03 05 05 07 ADD DCbuf3 DCbuf3 DCbuf5
End Protocol Code Block
Signal Block
PF0: 42 [4..0]: 3 PF bytes
PF1: 54 [7..6]: Lead-in Every Frm; [4]: Repeat at least 0 times; [2]: On burst before LO;
PF2: 06 [7..5]: Executor Flow: Terminate execution; [4..0]: 6 TX bytes in first signal spec
Signal Spec DCbytesIdx/NumTXBits: 0/8, 4/8, 1/8, 5/8, 2/8, 3/8
|
|
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sun Jun 13, 2021 7:33 am Post subject: |
|
|
I have added this entry to protocols.ini and given it a variant name JP1Eufy, so it is 01FF:JP1Eufy. It will be in the next release of RMIR, which will be issued shortly. _________________ Graham |
|
Back to top |
|
|
chileboy
Joined: 26 Aug 2020 Posts: 83 Location: NJ |
Posted: Sun Jun 13, 2021 8:28 am Post subject: |
|
|
Read through all of this, understood maybe 2% of it.
You folks are amazing.
That is all. _________________ - Mark |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Sun Jun 13, 2021 9:25 am Post subject: |
|
|
3FG wrote: | The 3rd byte is the 1st byte bit reversed, and that is the FieldCopier part. |
What does "FieldCopier" mean?
3FG wrote: | The check sum for the bytes 1, 3 and 5 is computed by RMIR using the NibbleSumChk translators. The lo offset is by default set to 4 as needed by the assumed checksum format. The hi offset is actually the carry from summing the low nibbles, and could have values of 0, 1 or 3. With these learns, the hi offset is 1: 0x7 + 0xA + 0xE + 0x4= 0x1E. |
You lost me here. I confirmed that the checksum is a SUM of the 5 data bytes, in MSB format, plus 4, as you stated earlier, so what's all this hi and lo offset all about? _________________ 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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sun Jun 13, 2021 11:35 am Post subject: |
|
|
Rob,
Pretty much every function available for use in protocols.ini is described in the header. From line 100 of protociols.ini: Code: | FieldCopier(srcOffset,destOffset,bits)
Used to copy bitfields from one location to another in the hex data
-- srcOffset is the msbOffset of the first bit of the field to copy
-- destOffset is the msbOffset where field should be copied to
-- bits is the bit length of the field
-- lsb means bits should be reversed when copied
-- comp means bits should be complemented when copied |
So I used FieldCopier to copy the 1st byte to the location of the 3rd byte, but with the bit order reversed.
Note that we have a sample of only 11 IR signals. Perhaps other models of this vacuum, for example, or other equipment uses the same IR protocol. If so, it may turn out that the 3rd byte is not really supposed to be a bit reversed copy of the 1st byte, but it was just a coincidence. Computing the 3rd byte in RMIR rather than the executor not only saves memory, but also retains the flexibility to just change the protocols.ini entry and not the executor to handle such an event.
Similarly, we can find a relation among the 1st 5 bytes for the checksum, but a lot of other possibilities exist. I chose to have RMIR compute the check sum for the 1st three fixed bytes plus the offset of 4, and to have the executor add that partial check sum with the two variable bytes. It's more flexible than simply adding them all up in the executor, and yields a shorter executor. RMIR/protocols.ini doesn't provide a translator to sum whole bytes, so I used the translator which sums over nibbles (this translator was written to handle XMP and related protocols). This translator can sum nibbles in either the fixed data or the variable (command) data, but not both. As I explained in the earlier post, the low offset is in this case just 4, and the high offset needs to be manually filled with the carry from the sum over the low nibbles. This arrangement is less than optimal, but does provide more flexibility.
Graham,
I chose the order of the bytes in the fixed and variable data arbitrarily. For this TI2541/MAXQ executor, these byte orders are not important. However, perhaps a S3C80 executor would need a different order, which we can easily change now but once it has been published in the next release we should avoid further changes. Of course a S3C80 executor can revise the byte order as needed, but it would add length and many S3C80 and S3F80 remotes are memory constrained. Or perhaps the byte order is already satisfactory for these S3x80 remotes. |
|
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
|