![JP1 Remotes Forum Index](templates/subSilver/images/logo_phpBB.gif) |
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Wed Mar 18, 2015 5:43 pm Post subject: |
|
|
ElizabethD wrote: | Graham, I did some comparisons as well, and came up with 21 to rollback to build 14 state, I think, and keep 5 with the March 6 changes to $C0. |
Yes, that agrees with what I have done. _________________ Graham |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Mon Mar 23, 2015 2:53 pm Post subject: |
|
|
on Build 18 and, if I recall, some/all previous ones:
(1) Would it be possible for RMIR to tell me that the reason SAVE doesn't work, loops forever, is because the .rmir was Read Only (which I've made so a month ago)?
(2) Something is wrong and I don't know what it is.
About a month ago I successfuly uploaded a file for Atlas OCAP 1056 under the common extender 3.02. All sorts of tests and edits went through just fine.
Today I wanted to upload with an extra keymove and an extra macro and RMIR is complaining that the signatures don't match.
I downloaded the current contents, and the sigs are identical. And on all these files in RawData, Signature says "Copy" rather than 3X333X33. I don't think it did that before.
Edit few hours later:
6131 extended and Atlas under 2.11 extension can upload through build 18 and show correct signature on RawData tab.
For Atlas 3.02 extended I went back to build 15 or 16 and 17. They, too fail upload. I'll have to go back to build 12 which was last before my successful uploads Feb.26. Will report if I really do it.
I wonder what I've messed up or what changed here, if anything relevant.
That's how it looks
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13276 _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Tue Mar 24, 2015 8:32 am Post subject: |
|
|
Liz, I'll look into (1) but no promises. It depends whether or not Java can test whether or not a file is read-only.
On (2), I've looked into the code to see how this might be caused, and come up with only one possibility. I have tested that possibility and been able to reproduce this behaviour. So I think that in some testing of yours, you have created a copy of the RDF file named
3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
and named it
Copy (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
If both RDFs are present in your RDF folder then it will cause this behaviour.
Edit: I have looked into (1) and found it easy, so next build will tell you if file is read-only. But in testing it, I found a peculiarity about extender v3.02 for the OCAP URC-1056. There is a Settings entry for LongPress with the values "BL Toggle" and "Deactivate". If you set it to Deactivate, then whenever you load the .rmir file, you get a message saying that the Fixed Data doesn't match, do you want to replace it with the values in the RDF? If you say Yes and save it, you get it again the next time you open it. Changing the setting to "BL Toggle" is the only way to stop this message.
This happens as both Fixed Data and this setting change the same data byte, but Fixed Data does it first and the setting overwrites any change it makes. You can get round this by replacing the first line in the [Fixed Data] section of the RDF, currently
Code: | $0014=$01,$00,$01,$FF,$00,$00,$00,$0F,$0F |
by the two lines
Code: | $0014=$01
$0016=$01,$FF,$00,$00,$00,$0F,$0F |
so it doesn't include the byte concerned. Should we make that change in the official RDF? Are other extender RDFs similarly affected? _________________ Graham |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Tue Mar 24, 2015 3:02 pm Post subject: |
|
|
Funny Sig issue:
Brilliant Thank you!
Sloppy of me for not changing .rdf to .txt or just adding .txt.
How on earth did you figure this one out? And how come RMIR didn't see the normal file
3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
and instead picked
Copy of 3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
I suppose Copy (2) of ... would've resulted in the same funny signature?
Does RMIR remember few things about what it was working with? The reason I ask, is that what became "Copy" was likely the file I used in the first place to make the original .rmir. I see nothing in the .properties regarding RDFs.
ReadOnly files - Thank you, it'll be useful.
Deactivate on LKP Setup:
Several recent posts indicate some people use it on Atlas, so making a change is probably desireable.
I don't like that setting since it's a slightly dangerous one and it's all too easy to do long press instead of short. I make a keymove on a pressable shift key instead. With no PIP on TVs, I use shift-pip-ch- to deactivate. Before Bill added it to the other settings, his extender had a deactivate button# and a keymove already coded. Now it doesn't. I just took a quick look through 3.02 rdfs looking for "deactivate", and so far only see it in Atlas OCAP 3X33, and RS 3X60 files and they're with different keys or settings. Hmmm, I thought these 3.02extenders were identical. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Thomas
Joined: 16 Feb 2008 Posts: 87
|
Posted: Wed Mar 25, 2015 5:01 am Post subject: Deactivate/Activate v302 extender |
|
|
I believe the answer to 'deactivate' is mentioned in the readme file.
For RS15-100 and RCRP05B, press and hold the 'setup' key until you see the activity LED blink four times.
To 'activate' select the TV mode and press OK, wait for four LED blinks.
I no longer have an OCAP, but I think it's the same procedure for that remote. All this is hard coded in the extender, no need to assign any key.
Tom _________________ Tom Carlson |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Wed Mar 25, 2015 9:34 am Post subject: |
|
|
ElizabethD wrote: | How on earth did you figure this one out? And how come RMIR didn't see the normal file
3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
and instead picked
Copy of 3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
I suppose Copy (2) of ... would've resulted in the same funny signature? |
I figured it out by looking at the code to see how a signature of "Copy" could possibly be displayed, and the only way is from an RDF with a signature of "Copy" in the name.
When RMIR reads the filenames in the RDF folder, the signature is the part of the name up to the first space, and the name of the remote is what is in the first set of round brackets (with some special treatment of underscores). It builds two cross-reference maps from this data. One maps signatures to remote names, and this supports multiple names for the same signature as this actually occurs. The other maps remote names to signatures and allows only one signature per name, as again this reflects reality. So when it came across your Copy entry with a name it had already come across, it overwrote the original signature with the new one, "Copy".
When RMIR downloads a remote or reads a .ir file, it finds the signature and looks up the remote's name from the first map. When it reads a .rmir file, it gets the remote's name from that file as that is unambiguous, and looks up the signature in the second map. So it found "Copy".
Curiously, Copy (2) of ... would have been OK, as that would be read as a remote with signature "Copy" and name "2" . _________________ Graham |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Wed Mar 25, 2015 11:27 am Post subject: |
|
|
Thanks, Graham. Makes perfect sense
Thomas made me reread things, so here is the history relevant to those fixed bytes (4 posts back):
From AtlasOCAP 2.13 ReadMe
Quote: | Activation of this extender is very different than previous JP1 extenders. Once activated, this extender will remain active until it is deactivated by the user. (activation will survive removal of the batteries, resets, etc) Two keymoves are provided in the default IR and HEX configurations to activate and deactivate the extender. | and Quote: | This extender has two methods for deactivation.
First, a keymove is included with the extender that is bound to a key "Deactivate" that will deactivate the extender. Move this keymove to a physical key and upload this configuration to your remote and use that key to deactivate.
Second, the extender can also be deactivated using a long-press of the "setup" key on the remote. There is a setting in the IR settings panel that determines if a long-press of setup will deactivate the extender or will allow the user to set the clock. To enable deactivation ensure that "Deactivate" is selected, upload to the remote and press-hold the setup button (or whichever button you have defined as the shift key) | set the clock??
From 3.02, the newest, common, extender ReadMe:
Quote: | On most of the JP1.3 remotes a long press of the setup button will deactivate the extender. However, on the Atlas OCAP/1056 remote and the Radio Shack 15-100 the long press of setup will allow you to set other options in the remote.See the general screen in IR or RMIR for more information on what functions can be enabled with a long press of setup. |
_________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Thomas
Joined: 16 Feb 2008 Posts: 87
|
Posted: Thu Mar 26, 2015 2:27 pm Post subject: |
|
|
Liz,
Now, I have had to reread the readme --- the following only applies to the two remotes that I have which are in the v302 extender group, RS15-100 (clock) and RCRP05B.
The LKP of setup works without any key assignment. Device 1 80 is in the device list, but I don't know whether assigning a key to that device disables the default setup LKP. Being somewhat lazy, I have not bothered with it nor walked through the code.
IIRC, in RMIR, changing the setting for RS15-100 did not enable a clock-setting mode; you could choose to have the clock automatically set/reset whenever you uploaded to the remote. On RCRP05B the clock issue is moot.
In any case, I do know that your FIRST LKP deactivates the extender, and you must LKP the setup key a SECOND time to make it enter the options/configuration mode. The options are only available when the extender is deactivated. _________________ Tom Carlson |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Fri Mar 27, 2015 12:04 pm Post subject: |
|
|
I asked above whether we should edit the RDF for the Atlas OCAP URC-1056, and possibly others, to remove the conflict between the fixed bytes and the LongPress setting. As I don't have this remote, or any related one, I can't really follow the discussion that it has provoked. But since it has caused discussion, it seems safer not to mess with this in the RDFs so I will make no change. _________________ Graham |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Fri Mar 27, 2015 9:18 pm Post subject: |
|
|
Graham,
Sorry for derailing things
I just went through the exercise you started. Got the alert, changed RDF. I went back and forth between changing the LKP setting, saving, opening, uploading with either backlight or deactivation and your proposed fix is solid.
Default Atlas extender 3.02 initially sets LKP=Backlight ($0) at $615. So the only people who will be annoyed by the fixed data mismatch are those who change it to Deactivate ($80) and try to reopen their new .rmir file.
Your call, but I vote to change the RDF for Atlas 3X33 file, and plan to use mine edited your way, in case I chose to set LKP=Deactivate in the future.
Bill mentioned someplace that he might be adding more options. I won't be surprised if he stuffs few more into $15. That really will require preservation of that byte in Atlas. And see my quote about ext.3.02 for RS and Atlas, above, regarding options. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Mar 28, 2015 10:43 am Post subject: |
|
|
ElizabethD wrote: | Your call, but I vote to change the RDF for Atlas 3X33 file, and plan to use mine edited your way, in case I chose to set LKP=Deactivate in the future. |
When I looked into doing this, I realised that the situation is more complicated than it first seemed. The fixed data sets all the bits of the byte, in this case the byte at address $615, but the setting only affects the top bit. I don't know if the other bits in the fixed data value are relevant, as in this case they are all 0, but in another of the Common Extender RDFs there is a fixed data byte with value $0C in which only the top bit is changed by a setting.
To handle this, I have changed RMIR so that if the same byte is set by Fixed Data and a Setting then the Fixed Data only applies to the bits that are not set by the setting. This is not a trivial change, so there will be a new Alpha version for it to be tested. I am hoping, however, to move to a final release of v2.03 very soon. _________________ Graham |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sat Mar 28, 2015 11:35 am Post subject: |
|
|
mathdon wrote: | To handle this, I have changed RMIR so that if the same byte is set by Fixed Data and a Setting then the Fixed Data only applies to the bits that are not set by the setting. This is not a trivial change, so there will be a new Alpha version for it to be tested. I am hoping, however, to move to a final release of v2.03 very soon. | Yes. I see that also. And for a similar reason, I think, I mentioned that more options might go into such byte. I didn't think there might be a need to not preserve certain bits. Nothing is simple in this world
Final release - go for it ![Smile](images/smiles/icon_smile.gif) _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sat Mar 28, 2015 4:18 pm Post subject: |
|
|
Graham,
Would it be possible to ignore certain protocol conflicts?
On 6131 I have a case of an existing device (Sangean tuner) using Aiwa protocol 005E hacked by Rob, but I retained its PID (used paste into .rmir file after RMIR objected to it). Works fine.
Now I want to add an Aiwa device which normally uses a standard Aiwa protocol.
I can find no way in RMIR to add this device without messing with changing PIDs and parameters.
But IR allowed me to add it long ago, and still does.
I know that the second device will be, and as far as I know does, use the hacked protocol, and causes no issues whatsoever.
Both devices show up as "00 5E*" on the Devices sheet.
I'd love RMIR to allow us to do some illegal things with a warning that it might not be the wisest thing to do. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Mar 28, 2015 6:06 pm Post subject: |
|
|
Liz, I don't understand what it is that you cannot do. Can you please post the .rmir file to which you want to add the new device, and the .rmdu file of the new device, and tell me what you cannot do? _________________ Graham |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sat Mar 28, 2015 8:50 pm Post subject: |
|
|
Here you go
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13282
I included .rmir, both devices which share a protocol, and IRscope evidence. Aiwa radio doesn't mind all those repeats that Sangean had to have.
I just made .rmdu file for you since I was using a KM file before. Makes no difference. Same problem: Aiwa device cannot be added.
IRscope says that AiwaRadio used the same protocol as the Sangean box, which is what I figured will happen when I added the file by IR.
RDF I use is PVR0PVx1 ... 2K).rdf, common for old and new 6131 except few button locations.
Graham, I know both of these devices are against PID rules. But since it works in IR on XP and for my gear, would be nice if RMIR would issue a waiver (e.g. Are you really, really sure you want to do this?). _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|