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

CyberLink Remote Problem
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
kevjs1982



Joined: 05 Apr 2008
Posts: 43
Location: East Midlands, UK

PostPosted: Sun Jul 05, 2009 9:38 am    Post subject: CyberLink Remote Problem Reply with quote

1. Device: CyberLink MCE Remote
2. Type of device: MCE Remote IR Sensor
3. Year: circa 2005
4. JP1/UEI Remote model: URC-7880
5. Do you have a JP1 cable? Yes
6. Still have original remote? Yes
7. Checked the file section? Yes
8. Checked Pronto file section (at R/C)? n/a
9. Partially working setup code? Yes
10. Learning remote question? No

I am trying to get this to work with my URC-7880 and it's not playing ball.

First I took http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2178 - this appears to work, although most of the buttons are on the wrong key - but I have a problem - whatever change I make to certain buttons doesn't result in the output changing correctly - i.e.

If I create an upgrade when every button has the Hex of 20 (i.e. "3" on the original remote) and export from Remote Master and Import in IR.exe all the buttons show "HEX : 20" EXCEPT "0" which is HEX : 006.

Furthermore if you then change "Fwd" and "Rwd" to HEX : 21 and load into IR it shows that Fwd and STOP have now changed - this time to HEX: 21 as you would expect - but the wrong buttons!

I've not had this problem before - my dozen or so previous upgrades have gone fine - however this is the first one I have done where a new protocol has been needed - I'm guessing something is going wrong here.

Anyone any ideas on how to get it working correctly?
_________________
URC-7780 OneForAll Digital 12 and URC-7556 OneForAll Digital 5
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Sun Jul 05, 2009 11:41 am    Post subject: Reply with quote

I couldn't find a URC-7880 on my machine, but I do know from experience that many of the newer remotes have a keyboard setting that causes upgrade buttons to scramble. The problem usually shows up when someone does a File.>New instead of working from a downloaded file.


The fix for this is an RDF setting. Check the RDF area to see if there is a newer RDF for your remote.

If you can't find a newer RDF with a keyboard setting, you could try

uploading an IR image that was started from a download or if you don't have a good IR image a manufacturer's reset should reset the flag too.
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

PostPosted: Sun Jul 05, 2009 2:24 pm    Post subject: Reply with quote

Vicky, if you check kevjs1982's signature line you'll see that his URC-7880 is a misprint, it's really a URC-7780. The latest RDF for this is mine, which you can find here. I am not aware of any errors or problems with it. There are several RDFs for this remote in the RDF file section, however, and I think some of the earlier ones have mis-assigned keys. If you are not already doing so, I suggest that you use my RDF with IR 8.00 (or IR 8.01 Beta 2 if you prefer).

I don't think the problem can be that a new protocol is needed - an error there might stop the remote from sending the right signals but the data would look OK in IR.exe. Have you checked that you have set RM to the correct remote before exporting? If you have RDFs in more than one directory, are you sure that RM is using the RDF from the correct directory?

For this remote, the "scrambling" Vicky mentions is controlled by the byte at EC25 in the Raw Data panel. Scrambling occurs if bit 5 is SET (i.e. is 1). You should find the high nibble of this byte to be 4 (low nibble is irrelevant). If it is 6 then scrambling is turned on.
________________
Graham
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Sun Jul 05, 2009 3:17 pm    Post subject: Reply with quote

Oops, I didn't read as far as the signature. Since this remote has the "scrambling feature", the RDF really ought to allow the user to fix it without knowing HEX.

Usually we allow the user's to manipulate this from the RDF. Right now EC25 defaults to FF giving scrambling.

In the settings tab we should see something like this.

KeyMap=$025.5.1.0.0 (Standard;Alternate)

What does byte, 6 of EC25 control? If we want this to default to 40, we need to have another line for to turn on bit 6.

Mystery=$025.6.1.1.0 (on;Off)
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

PostPosted: Sun Jul 05, 2009 5:36 pm    Post subject: Reply with quote

Vicky, my RDF creates the Manufacturing Reset state (981 reset) of the remote and certainly sets the appropriate values for the byte concerned. I just thought that Kevjs might like to look to check that it was OK. Since there is no rational reason ever to set "Alternate Keymap" (as it is there purely as a UEI anti-piracy measure) I don't let the user change this setting. It is read-only (read-only settings were introduced in IR 8.00).

If EC25 defaults to $FF then you don't have my RDF, in which it is set to $40. Bit 6 controls whether anti-piracy is on or off. I have not interfered with the UEI default setting, in which anti-piracy is ON. It is possible to turn it OFF through the remote's user interface (though it is not advertised!).
_________________
Graham
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Sun Jul 05, 2009 6:00 pm    Post subject: Reply with quote

Quote:
Vicky, my RDF creates the Manufacturing Reset state (981 reset) of the remote and certainly sets the appropriate values for the byte concerned.


Then I must have the wrong RDF, and Kevjs probably does too. He should definately look for the latest and greatest RDF.
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Sun Jul 05, 2009 6:12 pm    Post subject: Reply with quote

After downloading the latest RDF from Graham, this is acting the way it should on reset. So Kev, make sure you have the RDF that Graham pointed out.
Back to top
View user's profile Send private message Visit poster's website
kevjs1982



Joined: 05 Apr 2008
Posts: 43
Location: East Midlands, UK

PostPosted: Mon Jul 06, 2009 3:31 pm    Post subject: Reply with quote

mathdon wrote:
Vicky, if you check kevjs1982's signature line you'll see that his URC-7880 is a misprint, it's really a URC-7780. The latest RDF for this is mine, which you can find here. I am not aware of any errors or problems with it. There are several RDFs for this remote in the RDF file section, however, and I think some of the earlier ones have mis-assigned keys.


Well spotted, reading the readme of the linked RDF shows "This version is intended to supersede Version 1.2 of all three files dated Jul 27, 2007 by Aldaweb and Version 1.0 of the MAP and RDF files dated Apr 09, 2008 by Kev Swindells (kevis1982). The changes are as follows." - I was still using this one, at least the buttons were in the correct place Laughing


Quote:
If you are not already doing so, I suggest that you use my RDF with IR 8.00 (or IR 8.01 Beta 2 if you prefer).

Currently using 8.01 Dev 0 - Have updated to Beta 2

Quote:
Have you checked that you have set RM to the correct remote before exporting?


That's one thing I always double check - that has bitten me before!

Quote:
If you have RDFs in more than one directory, are you sure that RM is using the RDF from the correct directory?


Single directory here "C:\Scripts\RemoteMasterImages\application_data\images" - tried removing some unneeded ones and they remove from the list in both RM and IR


So now with an upgraded IR I try again, seams to be working now but everything is one button out, so to keep things simple if you unassign everything from all the buttons and add "1" (Hex 1E) to button 1, then export to IR it shows

Key = HEX
0 = 06
1 = 00
2 = 1E
3 = 00
...
9 = 00
Everything Else = Not Mapped

If you then add "0" (Hex = 27) to Key "0" the result is

Key = HEX
0 = 06
1 = 27
2 = 1E
3 = 00
...
9 = 00
Everything Else = Not Mapped


However changing the export from

"FF 00 81 06 06 27 1E 00 00 00 00 00 00 00 00"

to

"FF 00 81 06 27 1E 00 00 00 00 00 00 00 00"

Results in them being imported correctly - this even scales up as it grows
Code:

FF 00 FE FE FE FE E1 06 06 27 1E 1F 20 21 22 23
 24 25 26 C5 C6 C4 C8 C9 B1 FA 52 51 50 4F 28 CA
 4C F1 F7 F0 F3 F4 F5 D6 D7 D2 D3 CC C7 C0 C1 C2
 F9 D1 FE FB


- Change the "06 06" to "06" and it works - this happens to be the "Fixed Data" underneath protocol parameters....
_________________
URC-7780 OneForAll Digital 12 and URC-7556 OneForAll Digital 5
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Mon Jul 06, 2009 3:48 pm    Post subject: Reply with quote

So in IR's RAW DATA Tab, does EC25 = 40? Or was that already correct?
Back to top
View user's profile Send private message Visit poster's website
kevjs1982



Joined: 05 Apr 2008
Posts: 43
Location: East Midlands, UK

PostPosted: Mon Jul 06, 2009 4:11 pm    Post subject: Reply with quote

It's neither "FF" nor "40", but "45" at present Surprised

This is the download of a previous remote config though.

However if you create a "new" remote from the RDF it does indeed reset to 40, but the behaviour is identical
_________________
URC-7780 OneForAll Digital 12 and URC-7556 OneForAll Digital 5
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Mon Jul 06, 2009 4:16 pm    Post subject: Reply with quote

If you change the deviceID, does the scrambling change?
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

PostPosted: Mon Jul 06, 2009 4:37 pm    Post subject: Reply with quote

In the EC25 byte, only the high nibble affects scrambling. The low nibble is the index of the last device type that you set through the UI of the remote. So $45 and $40 are equivalent.

kevjs1982 wrote:
This version is intended to supersede Version 1.2 of all three files dated Jul 27, 2007 by Aldaweb and Version 1.0 of the MAP and RDF files dated Apr 09, 2008 by Kev Swindells (kevis1982).
Sorry, Kev, for not recognising you as the author of that earlier RDF. I knew I knew that username from somewhere! Smile

kevjs1982 wrote:
However changing the export from

"FF 00 81 06 06 27 1E 00 00 00 00 00 00 00 00"

to

"FF 00 81 06 27 1E 00 00 00 00 00 00 00 00"

Results in them being imported correctly - this even scales up as it grows

I think this is the clue to whether the problem is with RM or IR, so we seem to be nearly there. I'll look into this in more detail tomorrow.
____________________
Graham
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7047
Location: Florida

PostPosted: Mon Jul 06, 2009 5:07 pm    Post subject: Reply with quote

Okay when you open the upgrade for a JP1.2 remote in KM, and the fixed data is 06 but if you open the upgrade in RM, the fixed data is coming up as 06 06.

So it seems you've found a problem with RM, since removing the second 06 helps clear things up. I'm using RM 1.93, how about you?
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

PostPosted: Tue Jul 07, 2009 11:13 am    Post subject: Reply with quote

I am now completely mystified as to what is going on. I've looked at the device and protocol upgrades in the file Kev references in his first posting and have no idea where this double 06 has come from.

Just looking at the file data, without software, the protocol ID is 01FF and the protocol has 1 fixed byte and 1 command byte (these values are the high and low nibbles of the 5th protocol byte in the HCS08 listing).

The upgrade code is interpreted as:
FF low byte of PID
00 no number table
FE FE FE 44 F9 keymap data (this starts at 3rd byte and continues up to the first byte with bit 0 set)
06 fixed data (number of bytes is taken from the protocol data)
27 1E 1F ... these are the command bytes in order, for the keys determined by the keymap data

I don't understand where 06 06 comes from, or even how RM enters into it at all. There's no rmdu file involved, that I can see.

Can someone tell me about the 06 06, please? Smile
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Tue Jul 07, 2009 11:27 am    Post subject: Reply with quote

Apologies for that - I've just discovered you can open the .txt file in RM Embarassed I've never used KM so didn't know that it produces .txt files or that they could be opened in RM. Now I see the 06 06 appearing. Yes, definitely an RM problem. I know RM has translation to do when you change the device, but the double 06 seems to appear even with the original remote selected.
_________________
Graham
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 - General Forum 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
Get Smart! the band's official homepage Rockabilly Central