 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
 Posted: Sun Sep 12, 2010 8:36 am Post subject: |
 |
|
| vickyg2003 wrote: |
I do believe the orignial intent of the external functions was to complete the upgrade for the piece of equipment in question with a helper upgrade. For example we had the Yamaha Gap signals, where most the signals are nec1, but several functions require a different protocol executor.
|
Right - that is what Rob's exampe (b) is. I agree that using it for (a) is a departure from how you would do it with RM and IR, but it can still be done. You can of course still add keymoves within RM-IR's keymoves tab.
xnappo |
|
| Back to top |
|
 |
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Sun Sep 12, 2010 1:05 pm Post subject: |
|
|
6131ext 2K - DSM is in the RDF
[SpecialProtocols]
DSM=01FC
but is not in the dropdown on the SpecialFuntions tab.
Also, will I need to add the TV:1103 device temporarily for editing? and if so, how?
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride  |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Sep 13, 2010 9:53 am Post subject: |
|
|
| ElizabethD wrote: | 6131ext 2K - DSM is in the RDF
[SpecialProtocols]
DSM=01FC
but is not in the dropdown on the SpecialFuntions tab.
Also, will I need to add the TV:1103 device temporarily for editing? and if so, how? |
It's not in the drop-down because the device TV/1103 is not present. You need to change the entry in the RDF to
DSM=TV/1103:-01FC
That tells it the device without the need for it to be present (the minus sign before the PID means that the protocol need not be present, either). This isn't an RMIR issue, this syntax was originally developed for IR.exe.
_________________
Graham |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Sep 13, 2010 9:59 am Post subject: |
|
|
| vickyg2003 wrote: | | *BUG* RMIR is not selecting the same RDF as IR. This was a URC-8811 2k not a 1k. IR selects a different RDF |
When two remotes have the same signature, as with your 1k and 2k versions, IR.exe uses the data in the [FixedData] section of the RDF, if there is one, to distinguish between them. RMIR does not yet do this. There is a fixed data section in these RDFs, so IR.exe can pick the right one without asking. RMIR at present has to ask the user to choose.
_________________
Graham |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Sep 13, 2010 10:46 am Post subject: |
|
|
| mathdon wrote: | | vickyg2003 wrote: | | *BUG* RMIR is not selecting the same RDF as IR. This was a URC-8811 2k not a 1k. IR selects a different RDF |
When two remotes have the same signature, as with your 1k and 2k versions, IR.exe uses the data in the [FixedData] section of the RDF, if there is one, to distinguish between them. RMIR does not yet do this. There is a fixed data section in these RDFs, so IR.exe can pick the right one without asking. RMIR at present has to ask the user to choose. |
Do you need a 981 URC-8811 file image for testing?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Sep 13, 2010 12:00 pm Post subject: |
|
|
| vicky2003 wrote: | | Do you need a 981 URC-8811 file image for testing? |
No, I have files that differ only in fixed data that I can use for testing.
_________________
Graham |
|
| Back to top |
|
|
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Mon Sep 13, 2010 8:37 pm Post subject: |
|
|
| mathdon wrote: | | ElizabethD wrote: | 6131ext 2K - DSM is in the RDF
[SpecialProtocols]
DSM=01FC
but is not in the dropdown on the SpecialFuntions tab.
Also, will I need to add the TV:1103 device temporarily for editing? and if so, how? |
It's not in the drop-down because the device TV/1103 is not present. You need to change the entry in the RDF to
DSM=TV/1103:-01FC
That tells it the device without the need for it to be present (the minus sign before the PID means that the protocol need not be present, either). This isn't an RMIR issue, this syntax was originally developed for IR.exe. |
I remember when you asked for what features IR is to have we discussed it big time, and I remember (almost) this solution to the built in DSM device. I assumed then (a year ago/) the RDFs were modifed.
It was only later, now, that I took a look at the RDF, and as you see, RDF wasn't changed. Thanks for the answer - when I didn't see a change in the RDF I assumed incorrectly that some other mechanism was in the picture.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Mon Sep 13, 2010 9:36 pm Post subject: |
|
|
| ElizabethD wrote: |
It was only later, now, that I took a look at the RDF, and as you see, RDF wasn't changed. Thanks for the answer - when I didn't see a change in the RDF I assumed incorrectly that some other mechanism was in the picture. |
If you fix this, can you please post a reminder of this fix in the RDF thread and the details so I can get it in the next release?
Thanks,
xnappo |
|
| Back to top |
|
|
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Mon Sep 13, 2010 9:59 pm Post subject: |
|
|
Fixed. Works. Added request to the RDF 1.31 thread.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Fri Sep 17, 2010 12:39 pm Post subject: |
|
|
Follow up to item on page 3:
| mathdon wrote: | I have discovered why this is not identified as the Replay TV protocol. That protocol uses 7 fixed bytes. The last of these is considered invariant by protocols.ini, that is, it is the same regardless of the values used for the two device parameters "Device Code" and "Unit Code". In protocols.ini that byte is $00. In your remote it is $83. They don't match, so it is taken to be a different protocol.
Can you shed any light on why this value is $83 in your remote? |
The "Advanced" version of the ReplayTV protocol in KM has some logic in there that lets you assign functions to the FAV/SKIP button on remotes like the 15-1994, which is the remote that I'm using. The version of the executor that's loaded in my remote gets the function code from the last byte of fixed data. I just tried it in KM and I see that it now hard codes the value into the executor itself. I just checked RM and it doesn't appear to offer this functionality.
| vickyg2003 wrote: | Personally I'd me more concerned with the fact that the protocol changed than if it was thought of as manual settings.
Opened from IR and copied from the protocols window
47 93 71 8B 12 87 04 08 04 00 DE 00 00 00 00 00
CA D4 44 05 35 01 A8 58 0A 76 7C 04 6B 0A 56 7C
E3 56 00 DF B0 0D 58 09 6C 26 37 5F 0F 37 5C 11
68 C5 5C 9A 37 66 0A E6 0D 04 5C A1 37 5C 02 6C
27 0C 0A 04 0A 0A 10 09 10 C5 10 0A 20 0A 10 09
0A F1 37 52 07 F6 01 33 58 C6 8B E5 20 29 8D 01 33
As shown in the output window in RMIR
Upgrade protocol 0 = 01 45 (S3C80) Manual Settings: 01 45 (RM v2.00-preview5)
47 93 71 8B 12 87 04 08 04 00 DE 00 00 00 00 00
CA D4 44 05 35 01 A8 58 0A 76 7C 04 6B 0A 56 7C
E3 56 00 DF B0 0D 58 09 6C 26 37 5F 0F 37 5C 11
68 C5 5C 9A 37 66 0A E6 0D 04 5C A1 37 5C 02 6C
27 0C 0A 04 0A 0A 10 09 10 C5 10 0A 20 0A 10 09
0A F1 37 52 07 F6 01 20 58 C6 8B E5 20 29 8D 01 20
End |
I see what it's done, it's reduced the vector address for the IR engine by 0x13. This would be correct if the executor was formatted for an S3C8+ remote and the current remote is S3C8, but in this case, the executor was already formatted for an S3C8 remote (ie, my 15-1994) so changing the vector address would break the executor.
_________________
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 |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Fri Sep 17, 2010 1:40 pm Post subject: |
|
|
| The Robman wrote: |
The "Advanced" version of the ReplayTV protocol in KM has some logic in there that lets you assign functions to the FAV/SKIP button on remotes like the 15-1994, which is the remote that I'm using. The version of the executor that's loaded in my remote gets the function code from the last byte of fixed data. I just tried it in KM and I see that it now hard codes the value into the executor itself. I just checked RM and it doesn't appear to offer this functionality. |
RM/RMIR has the concept of a CodeTranslator, which enables mapping device parameters into executor code. Maybe this could be used to achieve the same result.
| Quote: | | I see what it's done, it's reduced the vector address for the IR engine by 0x13. This would be correct if the executor was formatted for an S3C8+ remote and the current remote is S3C8, but in this case, the executor was already formatted for an S3C8 remote (ie, my 15-1994) so changing the vector address would break the executor. |
Yes, we already figured that out and a fix was include in preview6. This of course would not have happened if RMIR had matched the executor to ReplayTV. Should RMIR ignore differences in that last byte of fixed data when trying to match ReplayTV? That would make sense to me, since neither KM nor RM is encoding anything in that byte.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Fri Sep 17, 2010 2:56 pm Post subject: |
|
|
| gfb107 wrote: | | Should RMIR ignore differences in that last byte of fixed data when trying to match ReplayTV? That would make sense to me, since neither KM nor RM is encoding anything in that byte. |
I don't know. If anybody else is using the KM version of the ReplayTV Advanced protocol, that byte might be controlling which function is assigned to the FAV/SCAN button.
_________________
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 |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Fri Sep 17, 2010 3:41 pm Post subject: |
|
|
How does that work in KM? Is that set as device/protocol parameter, or is it assigned just like any other button and there's code behind the scenes to encode it into the fixed data? If it acceptable to treat it as a protocol parameter, we could probably get RM(IR) to handle it without too much work. On the other hand, we also have to be able to cope with the way KM does it now, which is encode it in the protocol code. Might be a bit trickier to get RM(IR) to accept both schemes transparently.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Fri Sep 17, 2010 4:45 pm Post subject: |
|
|
I tried going back through my archive of old KMs in anticipation of that question, but unfortunately I can't open them as I have Excel 2007 on this box now.
If you don't assign a function to the FAV/SCAN button, you get presented with a simpler protocol upgrade than if you *do* assign a function to that button. Now, the extra code that is added to the executor includes the hex code for the function hard coded.
The extra code is also remote specific, which might be problematic for RM as it would need to derive some of the executor code from the RDF.
The extra code in the current KM executor is: | Code: | 8019: 76 7C 04 TM R7C, #04H
801C: 6B 0A JR EQ, 8028H
801E: 56 7C E3 AND R7C, #E3H
8021: 56 00 DF AND R00, #DFH
8024: B0 0D CLR R0D
8026: 5C 83 LD RC5, #83H |
The R7C register used at address $8019 and $801E comes from the first value in the DevComb entry in the RDF:
DevComb=$7C,$683,$11FC,,$8AEF,$1259
The #83H value at address $8026 is the hex code for the function assigned to the FAV/SCAN button. That line is different in the version in my FromRob.ir file, it's... | Code: | | 8026: 58 09 LD RC5, R09 |
where R09 is the fixed byte in question.
Obviously, when I added the protocol upgrade to my remote, it was getting the value from the last byte of the protocol executor. Either that, or I customized it myself, I don't remember.
I think getting it from the fixed data is a better approach because it allows the user to have multiple upgrades that use the same executor but have different functions assigned to FAV/SCAN. But having said that, I don't expect that many people would take advantage of that.
For RM/RMIR, I imagine you would have to treat the FAV/SCAN function as a "device code" type of parameter, and I'm guessing that you'd need a separate entry in protocols.ini for it (something like "ReplayTV (FAV/SCAN)") where the user would have to specifically select it in order to get the functionality. I think that's OK, given how few remotes are out there that still have the FAV/SCAN issue.
_________________
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 |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Sep 17, 2010 5:12 pm Post subject: |
|
|
I have a feeling that about 80% of the custom protocols that are loaded into remotes are merely minor tweaks to change the repeats in a protocol.
Mostly these tweaks are for one single piece of equipment so that it will play nice in a macro.
Normally these are just dropped in to IR. What is going to be the new method to put these in to the IR so that we can download them and preserve the protocol?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
