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, 4, 5 ... 57, 58, 59  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2306

PostPosted: Mon Aug 28, 2006 10:07 am    Post subject: Reply with quote

OK, which IR file opens issue is a non-issue. No files dragged in, it was just description text from IR Sad I got myself confused. I haven't yet tried saving as .rmir file. Next stage.

Regarding Panasonic to Denon-K translation,
gfb107 wrote:
The "import raw upgrade" function is not perfect. It won't always pick the right protocol, because there isn't enough information to uniquely identify it in all cases.
I don't think I understand why there isn't enough information to id the protocol when a functioning IR file is opened, but perhaps I don't need to IF this really is because we're in a prototype. Maybe it's in the meaning of "import raw upgrade" or "all cases".
_________________
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
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Mon Aug 28, 2006 11:42 am    Post subject: Reply with quote

ElizabethD wrote:
I don't think I understand why there isn't enough information to id the protocol when a functioning IR file is opened,


1) A given PID (protocol ID) may represent multiple executors.

On importing a raw upgrade, there is no info in the device upgrade to tell which varient of the PID is used. If it is a whole .IR file and/or includes a protocol upgrade, then there is enough info to identify the varient, but I have no idea whether or how well RM identifies varients.

2) A given executor (PID:varient) can be used to generate more than one protocol.

Denon-K and a combo version of Panasonic vary the same bits and use the same check-byte computation. So the same exact executor could be used. The fixed data would be different (which could help RM distinguish). The rules for translating OBC etc. into hex commands are different, but THAT can't help RM in this case, because it only has the hex cmds, not the OBCs.

The basic approach to distinguishing protocols in such cases is to translate from fixed data to setup parameters and then translate back. If something is lost along the way then it is probably the wrong translation, meaning the wrong protocols.ini entry, generally meaning the wrong protocol.

But often the main protocol entry (which would be the Panasonic Combo entry in this case) has some extra setup parameters to allow the user to override portions of the fixed data that normally wouldn't vary. So you could translate a Denon-K upgrade to Panasonic combo with those upgrades and not lose anything translating back.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3402
Location: Cary, NC

PostPosted: Mon Aug 28, 2006 12:17 pm    Post subject: Reply with quote

Panasonic Combo and Denon-K are actually the same protocol. They have the same PID and the same protocol code.
They use and compute fixed data the same way. The difference lies only in the command hex.

When more than one protocol with a given PID is able to regenerate the fixed data cirrectly, RM simply uses the first match. In this case it used the wrong one.
_________________
-- 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
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Mon Aug 28, 2006 1:10 pm    Post subject: Reply with quote

Probably this (case of getting the wrong protocols.ini entry) will never be a big issue. Any experts who think otherwise, please jump into this thread and explain.

If it were ever a big issue, I think we should add some syntax to protocols.ini to distinguish strong defaults from ordinary defaults. The OEM fields in the various Kaseikyo protocols would all be strong defaults.

If you change any of these OEM fields you aren't really in the same protocol anymore. We allow you to change the OEM fields in Denon-K and Panasonic to cover the moderately likely case that some third manufacturer will be close enough in its Kaseikyo layout to use one of those before or instead of adding specific support to protocols.ini.

But in decoding a use of that PID:varient combination, mismatching the strong default fields is a very good hint that you're picking the wrong protocols.ini entry.

If we had time to improve such obscure details, we would change the rules so that RM picks the first entry in which the strong defaults match and only failing that drops back to the first entry that works at all.

If we went to the trouble of supporting strong defaults, we might also want a beginner warning of some kind to pop up when a beginner types in an override for a strong default.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2306

PostPosted: Mon Aug 28, 2006 9:52 pm    Post subject: Reply with quote

I guess the complexity is much greater than I ever imagined, and believe me, I appreciate the difficulties and admire how spiffy and convenient RM-IR really is becoming Very Happy
But at this point I'm not sure if what I see is due to it being prototype or what might be permanent design features.
So even if I come in with IR file containing fixed bytes for Panasonic Combo (as I detailed on page 3 of this thread), it'll always default to Denon-K where fixed bytes are different in protocols.ini and it'll report that this file uses Denon-K and main device 10?

I'm also missing two other points: the importance of the use of hex, not OBC, in this instance, and the talk about changing defaults. Panasonic default devices, for instance, are 2 and 32. Nothing changed.
Forgive me if I'm totally out of line here.
_________________
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
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3402
Location: Cary, NC

PostPosted: Mon Aug 28, 2006 10:39 pm    Post subject: Reply with quote

It isn't a prototype issue. The same thing would come up if you used RM (classic) to import this particular device upgrade. It may or may not be a permament design feature. That is TBD.

However, it should be pointed out that using RMIR to import a .IR file without immediately loading the "full" RM/KM device upgrade over the top of the imported upgrade is an unlikely usage scenario. The whole point of moving to RMIR is to get the integrated RM function.

Here's the issue. RMIR has only the raw upgrade to work with:

CD 00 FE 3E 42 9E C1 BF FB FA C7 67 C7 F7 C7 77
C7 B7 C7 37 C7 D7 C7 57 C7 97 C7 17 C7 E7 FF FB
FF 7B F7 B3 C7 C0 C7 40 C7 43 C7 AE C7 55 F7 3E
AF 7F FF BC C7 22 FF 42 FF C2 C7 DE C7 AD C7 6D
AF AF AF AF C7 40 C7 C0 C7 FF C7 26

We can parse this out to see that the PID is 00CD and the fixed data is BF FB FA.

RM knows (from protocols.ini) that both Denon-K and Panasonic Combo have PID 00CD. It also has rules for each for converting the fixed data into Protocol Parameter values, and rules for converting Protocol Parameter value into fixed data.

RM tries to eliminate the ones that don't reproduce the fixed data by converting the fixed data to protocol parameter values and back again.
Unfortunately, both Denon-K and Panasonic Combo pass that test. So RM gives up and just picks the first one defined in protocols.ini.

In this particular case, RM's choice could be improved by giving preference to the protocol with the highest numer of imported protocol parameters values matching their default values, but there are scenarios where even this could result in the wrong choice.
_________________
-- 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
View user's profile Send private message Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2306

PostPosted: Tue Aug 29, 2006 12:44 pm    Post subject: Reply with quote

Got it. Many thanks Greg & John.
It's in the meaning of "Raw upgrade", of course. Sorry to waste your time, I must have been asleep driving through all 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
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2306

PostPosted: Thu Aug 31, 2006 10:26 am    Post subject: Reply with quote

RM1.66 - I played some more with the IR section now that I know more what to expect and how to work it. I noticed few things but I think only #3 might be an issue, the rest are marginal or known at this point:

1. Free keymove bytes miscount somewhat similar to what Capn Trips reported about non-system keymoves migrating over to devices.
Always starting from the same IR file or .RMIR file,
> when a 5 byte keymove is deleted, free bytes of keymove area can go negative (-12 free bytes)
> adding a macro can increase the free keymove space
> deleting a Fav macro of 20 bytes results in a free space drop of some 30 bytes

2. I'm sure this section isn't done yet, but in RawData were "..." entries among the red bytes.

3. At some point during the meter watch, above, Special Functions and Macro button names got converted to button numbers, decimal (ouch!). I could not revert back to button names.

Questions:
1. Sometime after normal exit from either RM or RMIR (not sure which was last), javaw.exe remained in the Task Manager list. Is that RMIR, RM or my XP problem?
2. IR always insists on the Scan/Fav sheet that a Fav macro device has to be selected (to this day I have no idea why). Device index goes to $30 and I see a correct value for RCVR (06). But I don't see a slot in RMIR to enter/show that device. Is it really needed?
3. If you build a Fav macro as a keymove, really bound to a device, can we count on it being BEFORE the macro section, i.e. compliant with the sequence IR now uses? Reason I ask is related to the question Capn Trips asked before, since I haven't used it on a device.
_________________
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
jetskier



Joined: 09 Dec 2003
Posts: 278
Location: Minden, Nevada

PostPosted: Thu Aug 31, 2006 10:39 am    Post subject: Reply with quote

ElizabethD wrote:
1. Sometime after normal exit from either RM or RMIR (not sure which was last), javaw.exe remained in the Task Manager list. Is that RMIR, RM or my XP problem?


I too have noticed that javaw.exe remains in memory after closing RM. I discovered it when I tried to update RM from an old version to the latest. Windows immediately said it couldn't update the file because it was still in use. After terminating the javaw.exe, it overwrote the file. This has happened for the past couple of updates.
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3402
Location: Cary, NC

PostPosted: Thu Aug 31, 2006 10:47 am    Post subject: Reply with quote

1, Bytes used/free is still a work in progress. RMIR also doesn't yet stop you from adding too much stuff.

2, OK

3, I hope you can figure out how you got the button names to show up as numbers, 'cause I am clueless on that one. If you see it again, stop and save the rmaster.err file as it might provide a clue.


Answers
1. I don't know.
2&3. RMIR doesn't yet support Fav/Scan. I made it so it doesn't choke on a Fav/Scan during import, since it's part of the advanced code area. It'll show up as a keymove or macro (depending on the remote), but don't expect it to be handled correctly. It is my intention to keep things in the same order as IR.
_________________
-- 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
View user's profile Send private message Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2306

PostPosted: Thu Aug 31, 2006 8:06 pm    Post subject: Reply with quote

Thanks for the answers. I'll be watching javaw.exe. I've only seen it once, but i never look really. This time PC was too busy and noisy and I needed to see what was doing me in.

gfb107 wrote:
I hope you can figure out how you got the button names to show up as numbers

Still on RMIR v1.65. All evidence in this zip file, replicated key name -> number change http://www.hifi-remote.com/forums/dload.php?action=file&file_id=3540

Having done all this, I just reread page1 here. Turns out I've been working partly on unimplemented features. Thing is , RMIR is so cool, it's hard to resist pushing all available buttons and messing with it Very Happy Twisted Evil

Greg, am I making it up that sometime in the past the .err file had info in it about what file you've been working on. It would be useful to see when you collect evidence, as things can get confusing. Also RM version would be cool to see.
_________________
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: 2306

PostPosted: Sun Sep 10, 2006 2:48 pm    Post subject: Reply with quote

RMIR v1.67. Still not 100% clear what should work, but just in case,
1. Recheck of the switch of button name to button number situation from above under v 1.65 or 66. It replicates over both IR and RMIR versions. To rule out/in the FAV macro presence in the 8910, I usd it on 6131 and 7800. Same thing. Adding keymoves does it. I also tried on the original, official, 8910_ext1 IR file (txt renamed to IR), as that would also be in a typical workflow for starting up. Same thing.
7800 error log: rmaster(7800overRMIR).err
For 8910, see the tail end of the .doc file.
and error log: rmaster8910_ext1-AddKeymove.err
One disclaimer - in this version it took longer to reproduce than in 1.65 but I haven't followed up.

2. New item: Attempt to save 8910_ext1 as RMIR does something goofy - it does not refresh the active window, and the SaveAs dialog is all grey. The file saves.
See the first, main part of .doc file for screen shots.
Also error logs: rmaster(Word detour).err, rmaster8910_ext1savingAsRMIR.err, rmaster(SavedAsRMIR).err, result of save in 8910_ex1.rmir

3. New item: External functions. I open IR file that contains external functions on the keymoves sheet. I then loaded in an upgrade (KM or RM, don't recall) where those functions were defined as part of an upgrade. I presume that the existing external keymoves would have moved to the upgrade, as that's where they were coded. They did not, so I see them in both places, right? wrong?.
Error log: rmaster(6131+extFchk).err

4. Wish list item: I'd like to see in the log the name(s) or opened/loaded/imported files and datestamp in case the filedate gets lost after the original event.

I hope I haven't mixed up logs with events - all in zip file
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=3562
It's more logs than you'll ever need, I'm sure. Holler if too muddy.
_________________
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
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3402
Location: Cary, NC

PostPosted: Mon Sep 11, 2006 3:32 pm    Post subject: Reply with quote

Liz, I've got a handle on all your issues.

What you see for External Functions is to be expected, since I haven't written the code that would scan through the existing keymoves and remove matches when installing a device upgrade.

You have to remember that the "Import IR file then load the real upgrade files" mode of operation really isn't the intended normal usage of RMIR. We use it a lot right now because there's a lot of function missing in RMIR, and because those of us testing RMIR have IR configurations and we don't want to have to put a lot of effort into recreating those as RMIR files.

BTW, next time please include some .IR or .RMIR files you used to recreate the problems in your .zip file, or provide links to them in your post.
_________________
-- 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
View user's profile Send private message Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2306

PostPosted: Mon Sep 11, 2006 4:05 pm    Post subject: Reply with quote

gfb107 wrote:
Liz, I've got a handle on all your issues.
Thanks. Great news. I know you would.
gfb107 wrote:
You have to remember that the "Import IR file then load the real upgrade files" mode of operation really isn't the intended normal usage of RMIR.
Not my place to argue, but I have a feeling that mode will be convenient in the future to have.
gfb107 wrote:
BTW, next time please include some .IR or .RMIR files
I gotta run. But I could've sworn there were some in both of those ForRMIRevidence zips. Sorry about it. Do you still need'm - if so, I'll upload from home.
_________________
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
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3402
Location: Cary, NC

PostPosted: Tue Sep 12, 2006 8:36 am    Post subject: Reply with quote

ElizabethD wrote:
gfb107 wrote:
You have to remember that the "Import IR file then load the real upgrade files" mode of operation really isn't the intended normal usage of RMIR.
Not my place to argue, but I have a feeling that mode will be convenient in the future to have.

I didn't say I was going to remove that feature. It is an important and useful one. It is also necessary because it is exactly the same as decoding a download from a remote, except that in that case there are no comments.

I'm just saying that after the initial switch to RMIR (if/when it's ready), it won't be the normal or typical user scenario, and that it may require some manual tweaking.
_________________
-- 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
View user's profile Send private message Visit poster's website
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, 4, 5 ... 57, 58, 59  Next
Page 4 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