| View previous topic :: View next topic |
| Author |
Message |
MJ
Joined: 28 Sep 2003
Posts: 25
|
 Posted: Sat Nov 29, 2003 5:22 pm Post subject: RM faulty "fixed data" value ?? |
 |
|
I am just beginning to use RM to upgrade a (OFA 8910/8911). I was unable to get my first upgrade to work although a signal is being transmitted and the new code is displayed on the LCD. I went back to KM to doubleckeck things and the same upgrade seems to work fine. The only difference I have seen is that KM shows the fixed data description as 28 b4 49 and RM shows 1c b4 49. I attempted the import from my KM file as well as starting from scratch. As I enter the setup data; (Onkyo receiver) 0101 NEC1 210 109 28, the fixed data comes up different than KM.
I have attempted all of the RDFs for RM (some of which appear to have been modified minutes apart right around the witching hour in late October) that I can find including the one linked just before this posting but RM consistently spits up this 1c... value.
Trick or treat??
Matthew  |
|
| Back to top |
|
 |
MJ
Joined: 28 Sep 2003
Posts: 25
|
| Posted: Sat Nov 29, 2003 5:29 pm Post subject: P.S. |
|
|
I had to take a step back since I am experimenting with the extender on ths remote. Can I still use KMs unextended remote and still upgrade an extended file on IR? I guess this is how its been done for some time.
Matthew |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Sat Nov 29, 2003 5:40 pm Post subject: |
|
|
RM doesn't seem to have perfect support for the parm value in NEC. Most upgrades don't use the parm value (leave it blank) but from your symptoms, your upgrade must use it.
RM treats parm as a decimal number when it ought to be hex. So you put in 28 (hex). It sees 28 decimal and processes it as 1C hex. For now, I guess the best is to put in 40 (since 40 decimal is 28 hex).
For KM (or RM) there are not (yet) any relevent differences between extended and non extended RDFs for the same model. |
|
| Back to top |
|
|
MJ
Joined: 28 Sep 2003
Posts: 25
|
| Posted: Sun Nov 30, 2003 3:45 pm Post subject: Thanks that did the trick. |
|
|
1 2 3 hexadecimee.
Matthew |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Mon Dec 01, 2003 11:36 am Post subject: |
|
|
| johnsfine wrote: | RM doesn't seem to have perfect support for the parm value in NEC. Most upgrades don't use the parm value (leave it blank) but from your symptoms, your upgrade must use it.
RM treats parm as a decimal number when it ought to be hex. So you put in 28 (hex). It sees 28 decimal and processes it as 1C hex. For now, I guess the best is to put in 40 (since 40 decimal is 28 hex).
|
I'll be releasing RM v0.78 later today that will treat "Parm" as a hex value. Note that you will probably have to correct your saved upgrade.
_________________
-- 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 |
|
|
Nils_Ekberg
Expert
Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY
|
| Posted: Mon Dec 01, 2003 11:58 am Post subject: |
|
|
| gfb107 wrote: | | I'll be releasing RM v0.78 later today that will treat "Parm" as a hex value. Note that you will probably have to correct your saved upgrade. |
Greg, I have no problem with this and will only have a dozen or so changes to make. I am curious why we originally went with decimal for the parm field. I remember the discussion because I ran into the same problem early on converting (before import was available) KM upgrades to RM until you or John pointed out the field was decimal.
I think there was a valid reason but that would be moot if it confuses people anyway.
_________________
Nils
Files Section
Diagnosis File Section |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Mon Dec 01, 2003 12:57 pm Post subject: |
|
|
I'm surprised you have so many to fix, since very few upgrades use NEC parm at all (even fewer if we've fixed protocols.ini for NECx1 and NECx2). Sorry about however many you need to fix.
It was decimal after that discussion because Greg or I dropped the ball on that detail. I don't remember the discussion well enough to know which of us did. Double the "Sorry about" if it was me. There is no "Valid reason" for it to be decimal, just a feature that took a little effort to add and thus wasn't there on first cut. |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Mon Dec 01, 2003 1:11 pm Post subject: |
|
|
| johnsfine wrote: | I'm surprised you have so many to fix, since very few upgrades use NEC parm at all (even fewer if we've fixed protocols.ini for NECx1 and NECx2). Sorry about however many you need to fix.
It was decimal after that discussion because Greg or I dropped the ball on that detail. I don't remember the discussion well enough to know which of us did. Double the "Sorry about" if it was me. There is no "Valid reason" for it to be decimal, just a feature that took a little effort to add and thus wasn't there on first cut. |
Protocols.ini still doesn't have entries for NECx1 and NECx2.
The fix I made simply makes RM respect the $ in protocols.ini that indicates a particular device parm should be displayed/parsed as hex.
The only dev parms that have that are "Parm" for NEC1 and NEC2
_________________
-- 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 |
|
|
Nils_Ekberg
Expert
Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY
|
| Posted: Mon Dec 01, 2003 1:17 pm Post subject: |
|
|
| johnsfine wrote: | I'm surprised you have so many to fix, since very few upgrades use NEC parm at all (even fewer if we've fixed protocols.ini for NECx1 and NECx2). Sorry about however many you need to fix.
It was decimal after that discussion because Greg or I dropped the ball on that detail. I don't remember the discussion well enough to know which of us did. Double the "Sorry about" if it was me. There is no "Valid reason" for it to be decimal, just a feature that took a little effort to add and thus wasn't there on first cut. |
It's no big deal John. I just happen to have a few more than normal since I maintain upgrades for my own, my father in Laws (he tends to buy similar stuff as I do) and my neighbor. I won't need to do anything with them until I decide to modify them or am bored enough to do it "ahead of the curve"
_________________
Nils
Files Section
Diagnosis File Section |
|
| Back to top |
|
|
Nils_Ekberg
Expert
Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY
|
| Posted: Mon Dec 01, 2003 6:08 pm Post subject: |
|
|
| johnsfine wrote: | | I'm surprised you have so many to fix, since very few upgrades use NEC parm at all (even fewer if we've fixed protocols.ini for NECx1 and NECx2). Sorry about however many you need to fix. |
Well John, it turns out that the way Greg coded the fix I did not have to change anything in my upgrades. Now what use to appear in the parm field as dec 49 now appears as hex 31 which ofcourse is what generated the hex 31 in the fixeddata. It looks like Greg was pretty sneaky and still keeps the parm value as dec internally and displays the old dec value converted to hex and also now expects it to be entered as hex in the GUI.
_________________
Nils
Files Section
Diagnosis File Section |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
