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

New Xsight Color user questions
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> Nevo and Xsight Remotes
View previous topic :: View next topic  
Author Message
nylaw



Joined: 10 Apr 2015
Posts: 28

                    
PostPosted: Fri May 01, 2015 8:29 am    Post subject: Reply with quote

Do you think it's on their end or something in RMIR?
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4498

                    
PostPosted: Fri May 01, 2015 9:01 am    Post subject: Reply with quote

I just think the protocols are different than we expected and honestly not worth the effort to try to figure out. Just use the devices I posted instead. I never use EZ-RC myself except to help others who haven't switched to RMIR yet. EZ-RC development stopped a long time ago, but RMIR continues to be actively developed.

I suspect 3FG may still be trying to track down the differences anyway. We already have a solution which is to use our JP1 files instead.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Fri May 01, 2015 10:52 pm    Post subject: Reply with quote

I'm not working on this. I don't know anything about this kind of Xsight remote, or the way in which RMIR interfaces with them. I also don't understand where the line in the RMIR file
Code:
CustomCode.S3C80=3A 8A 42 8B 15 F8 15 05 07 02 58 01 18 01 2C 01 18 57 D0 04 B0 01 18 08 03 08 76 07 01 EB 16 76 08 01 6B 0E E6 28 F9 E6 12 08 E4 08 01 E0 01 56 01 03 E6 24 05 8D 01 49
came from; as far I can tell those bytes aren't in the E2 image or in protocols.ini.
How does EZRC come up with a setup code of 4107? That's not a standard UEI setup code seen in any JP1 remote.
Back to top
View user's profile Send private message
nylaw



Joined: 10 Apr 2015
Posts: 28

                    
PostPosted: Sat May 02, 2015 3:34 pm    Post subject: Reply with quote

3FG wrote:
I'm not working on this. I don't know anything about this kind of Xsight remote, or the way in which RMIR interfaces with them. I also don't understand where the line in the RMIR file
Code:
CustomCode.S3C80=3A 8A 42 8B 15 F8 15 05 07 02 58 01 18 01 2C 01 18 57 D0 04 B0 01 18 08 03 08 76 07 01 EB 16 76 08 01 6B 0E E6 28 F9 E6 12 08 E4 08 01 E0 01 56 01 03 E6 24 05 8D 01 49
came from; as far I can tell those bytes aren't in the E2 image or in protocols.ini.
How does EZRC come up with a setup code of 4107? That's not a standard UEI setup code seen in any JP1 remote.


If you had to make an educated guess what do you think is going on with it?
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4498

                    
PostPosted: Sun May 03, 2015 3:39 pm    Post subject: Reply with quote

3FG, would downloading segments or raw downloads help? I've still got nylaw's image on one of my remotes.
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Sun May 03, 2015 4:40 pm    Post subject: Reply with quote

The XSight Touch and Color and Nevo equivalents do not use segments. I think I am the only person who could understand the raw download and I don't even know what the issue is that is at stake.

I have read through this thread today to see if there is anything in it that suggests a fix that is needed in build 2 of RMIR v2.03 and have understood very little of it. Can someone explain in a sentence or two what issues are still unresolved?
_________________
Graham
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun May 03, 2015 5:20 pm    Post subject: Reply with quote

The immediate difficulty is that upon loading nylaw's RMIR file (or the RMIR file generated by mdavej from the image he obtained from nylaw's account) the Sony upgrade cannot be edited. Simply opening the DUE and clicking OK yields the message "This device upgrade needs a protocol upgrade and protocol upgrades are not supported by this remotes, so unfortunately this edit is being cancelled."
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon May 04, 2015 7:52 am    Post subject: Reply with quote

3FG wrote:
Simply opening the DUE and clicking OK yields the message "This device upgrade needs a protocol upgrade and protocol upgrades are not supported by this remotes, so unfortunately this edit is being cancelled."

Sorry about that. It was a bug in the conditions for that error message, which is a new message introduced when we were working with the Charter C4000 remote and had not yet supported type 0x0F segments. I've fixed it for v2.03 build 2, which I hope to post in the next few days.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon May 04, 2015 8:12 am    Post subject: Reply with quote

mdavej wrote:
Mathdon, comparing the above RDFs, the 8602 version is missing the line:

Hold=$FE:AllBind+AllFavData+groupHold,

just above the line:

Null=$FF:All

Not sure if that's significant or not.

One other error, though only cosmetic, is that the Nevo C2 description should be 15-device instead of 18-device.

As far as I can tell, the Hold entry in the RDFs is now redundant, a hangover from an earlier stage in developing XSight support for RMIR. It does no harm in the RDFs where it is present, but can be safely omitted from newer ones. I will, however, make the cosmetic change to 15 device.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon May 04, 2015 9:30 am    Post subject: Reply with quote

mdavej wrote:
That's just how it works - add new, delete old. They can't be edited except in EZ-RC. Not sure if Mathdon can change that kind of thing or not.

Mathdon can do most things Very Happy . For the forthcoming build 2, I have added a Replace button to the Macro dialog box for XSight remotes. So select the entry to edit in the right-hand box, make any required changes in the left-hand box and press Replace.

There seems little point in having a Replace button for other remotes, as macro items for these are just a button name. It is only the XSight remotes where each item is a composite structure in which it may be desired to change just one field.
_________________
Graham
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4498

                    
PostPosted: Mon May 04, 2015 9:56 am    Post subject: Reply with quote

mathdon wrote:
Mathdon can do most things Very Happy
Yes he can! Thanks!
Back to top
View user's profile Send private message
nylaw



Joined: 10 Apr 2015
Posts: 28

                    
PostPosted: Mon May 04, 2015 12:00 pm    Post subject: Reply with quote

mathdon wrote:
mdavej wrote:
That's just how it works - add new, delete old. They can't be edited except in EZ-RC. Not sure if Mathdon can change that kind of thing or not.

Mathdon can do most things Very Happy . For the forthcoming build 2, I have added a Replace button to the Macro dialog box for XSight remotes. So select the entry to edit in the right-hand box, make any required changes in the left-hand box and press Replace.

There seems little point in having a Replace button for other remotes, as macro items for these are just a button name. It is only the XSight remotes where each item is a composite structure in which it may be desired to change just one field.




There is one other bug. My Samsung BD player reports protocol: pid:01 BD

It should be Samsung36. It looks like for some reason the Protocol: is copying the the Protocol ID:

Thank you so much for this wonderful piece of software. I read your entire build thread your effort and attention to detail was truly amazing!
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon May 04, 2015 12:23 pm    Post subject: Reply with quote

nylaw wrote:
There is one other bug. My Samsung BD player reports protocol: pid:01 BD. It should be Samsung36.

I will look into this, but it has just missed build 2. I have just posted RMIR v2.03 build 2 here. It is available both as a full installation and as an upgrade from build 1.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon May 04, 2015 1:09 pm    Post subject: Reply with quote

OK, this was quick to look into, probably quicker than writing this post Smile . There is no bug in RMIR. There may be an omission in protocols.ini. Here is the explanation, but it is very technical and is aimed at 3FG, who is the expert on protocols.ini, rather than at you, nylaw.

The fixed data from the remote is 04 00 E1. According to the protocols.ini entry for Samsung36, the last four bits of the third byte are not used and so are expected to be 0. RMIR decodes this data into device parameters according to the protocols.ini entry and then checks if it has the right protocol by encoding the result back again to fixed data values. It gets 04 00 E0. This doesn't match the original, so RMIR says it isn't Samsung36 but is instead something like it. It therefore creates what it calls a "derived protocol" whose name is "pid: " followed by the PID of the original, i.e. of Samsung36. The derived protocol uses all the bits of the third byte and so reconstructs 04 00 E1, which matches.

What is going on? Possibly UEI have created a new version of the Samsung36 protocol in which the last 4 bits of the third fixed data byte have some effect. Possibly the last bit being 1 has no significance at all. I suspect only time will tell, but 3FG may know more than I do about this protocol.

With our present knowledge I think the sensible action is to make RMIR ignore that last bit. You do this by editing the [Samsung36] entry in protocols.ini and adding a FixedDataMask entry after the FixedData entry thus:

Code:
FixedData=20 00 00
FixedDataMask=FF FF F0

You have to download the remote afresh, as the .rmir file has the protocol name "pid: 01 B5" hard coded. Downloading again forces RMIR to identify the protocol afresh with the new protocols.ini entry. It will then be identified as Samsung36.
_________________
Graham
Back to top
View user's profile Send private message
nylaw



Joined: 10 Apr 2015
Posts: 28

                    
PostPosted: Mon May 04, 2015 2:45 pm    Post subject: Reply with quote

I made the edit and can happily report both devices are behaving as they should. Thank you again!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> Nevo and Xsight Remotes All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5  Next
Page 4 of 5

 
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