JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Help me with creating device update
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Beginners
View previous topic :: View next topic  
Author Message
loft



Joined: 01 Dec 2015
Posts: 51
Location: Stuttgart, DE

                    
PostPosted: Thu Jun 10, 2021 12:50 pm    Post subject: Help me with creating device update Reply with quote

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
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Thu Jun 10, 2021 1:08 pm    Post subject: Reply with quote

Uploading your actual RMIR file here is much more valuable than screen shots:
http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=35

Pleas post a link back to the uploaded file.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Jun 10, 2021 1:17 pm    Post subject: Re: Help me with creating device update Reply with quote

loft wrote:
I transferred the robot's remote to my URC-7890 and came up with this list of codes: https://www.imagebam.com/view/GAJCN

If you don't know how to post images, read this:
http://www.hifi-remote.com/forums/viewtopic.php?t=6557

loft wrote:
(I'm not sure where I can safely upload the resulting file here).

If you don't know how to load a file, read this:
http://www.hifi-remote.com/forums/viewtopic.php?t=102759
_________________
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
View user's profile Send private message Visit poster's website
loft



Joined: 01 Dec 2015
Posts: 51
Location: Stuttgart, DE

                    
PostPosted: Thu Jun 10, 2021 1:18 pm    Post subject: Reply with quote

Thanks for the prompt answer.
Here is the file: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26337
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Jun 10, 2021 4:59 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
loft



Joined: 01 Dec 2015
Posts: 51
Location: Stuttgart, DE

                    
PostPosted: Fri Jun 11, 2021 3:38 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Fri Jun 11, 2021 3:41 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Fri Jun 11, 2021 6:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Jun 12, 2021 12:46 am    Post subject: Reply with quote

Looks like the check sum byte is 2nd plus 4th bytes plus 0x2E. Or all 5 bytes plus 4.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Sat Jun 12, 2021 9:56 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Jun 12, 2021 8:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Jun 13, 2021 7:33 am    Post subject: Reply with quote

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
View user's profile Send private message
chileboy



Joined: 26 Aug 2020
Posts: 83
Location: NJ

                    
PostPosted: Sun Jun 13, 2021 8:28 am    Post subject: Reply with quote

Read through all of this, understood maybe 2% of it.

You folks are amazing.

That is all.
_________________
- Mark
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Sun Jun 13, 2021 9:25 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun Jun 13, 2021 11:35 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Beginners All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control