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

RMIR: Prototype IR function in RM
Goto page Previous  1, 2, 3 ... , 57, 58, 59  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

PostPosted: Wed Mar 18, 2015 5:43 pm    Post subject: Reply with quote

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


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Mon Mar 23, 2015 2:53 pm    Post subject: Reply with quote

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


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

PostPosted: Tue Mar 24, 2015 8:32 am    Post subject: Reply with quote

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


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Tue Mar 24, 2015 3:02 pm    Post subject: Reply with quote

Funny Sig issue:
Brilliant Smile Smile Smile 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
Back to top
View user's profile Send private message
Thomas



Joined: 16 Feb 2008
Posts: 77

PostPosted: Wed Mar 25, 2015 5:01 am    Post subject: Deactivate/Activate v302 extender Reply with quote

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


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

PostPosted: Wed Mar 25, 2015 9:34 am    Post subject: Reply with quote

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" Rolling Eyes .
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Wed Mar 25, 2015 11:27 am    Post subject: Reply with quote

Thanks, Graham. Makes perfect sense Smile

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
Back to top
View user's profile Send private message
Thomas



Joined: 16 Feb 2008
Posts: 77

PostPosted: Thu Mar 26, 2015 2:27 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Mar 27, 2015 12:04 pm    Post subject: Reply with quote

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


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Fri Mar 27, 2015 9:18 pm    Post subject: Reply with quote

Graham,
Sorry for derailing things Embarassed
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
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sat Mar 28, 2015 10:43 am    Post subject: Reply with quote

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


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Sat Mar 28, 2015 11:35 am    Post subject: Reply with quote

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 Smile

Final release - go for it Smile
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Sat Mar 28, 2015 4:18 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Mar 28, 2015 6:06 pm    Post subject: Reply with quote

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


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Sat Mar 28, 2015 8:50 pm    Post subject: Reply with quote

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
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 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3 ... , 57, 58, 59  Next
Page 58 of 59

 
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