RMIR: Making Upgrades from Learned Signals

xnappo · Post by **xnappo** » Fri Dec 07, 2012 7:57 am

The Robman wrote: Anyway, a parm value of 0x01 will indeed yield an NEC2 signal. So, if you actually selected NEC1 and then entered 1 as the parm, you would actually get NEC2.

Okay... But that still doesn't explain where the problem lies in the learn->upgrade process.

If I make a new NEC2 upgrade from scratch, Param is blank, and if I saw learns with NEC2 as the protocol I would LEAVE it blank like Rob suggests since the Protocol notes say:

Although NEC1 and NEC2 are by far the most popular versions of NEC, there are some other variations, which you may find listed with names like NEC-30, NEC-04, etc. If you need to use one of these protocols, select "NEC1" or "NEC2" and enter the number after the dash as the parm. For example, if you need "NEC-30", the parm value is "30".

Does this mean Protocol.ini is in fact wrong?

With it is left blank, the fixed data is 0x21(which works). If you enter Param=1 it changes to 0x01(which doesn't work).

It looks like RM is taking the Param field whole-sale as the first byte of fixed data when in fact it should be ORed with something?

xnappo

Post by **The Robman** » Fri Dec 07, 2012 11:52 am

01 = NEC2 with a single device code (ie, device2 is the comp of device1)
21 = NEC2 with two different device codes

Another good example of why it should be left blank so RM can do the right thing with it. You should only set the parm value if you are looking at the whole set of learns and have determined that you are dealing with one of the special cases not covered by the standard NEC1, NEC2, NECx1, NECx2 versions.

For example, if all the learns are NEC1 except for the volume, channel, ffwd and rew buttons, you might use 08 or 28 as the parm (ie, B3 is set).

If you see the signal repeated twice but then see an NEC1 repeating trail, set B1.

Post by **The Robman** » Fri Dec 07, 2012 1:13 pm

Just FYI, I have split the discussion about advanced handling of learned signals to the following thread, leaving this one to discuss the ability to generate upgrades from learned signals.

https://www.hifi-remote.com/forums/viewtopic.php?t=14418

I also split the discussion about getting the learned tab to appear in RMIR here:
https://www.hifi-remote.com/forums/viewtopic.php?t=14420

Vyrolan · Post by **Vyrolan** » Fri Dec 07, 2012 1:59 pm

It seems that I should just never set a parameter value to a default...just leave them blank and let RMIR handle any defaulting. I can make that change.

Post by **The Robman** » Fri Dec 07, 2012 2:02 pm

Vyrolan wrote:It seems that I should just never set a parameter value to a default...just leave them blank and let RMIR handle any defaulting. I can make that change.

You should probably make that judgement on a case by case basis, but certainly in the case of the NEC parm, you should always leave it blank. That one is primarily there to allow an expert to create a custom NEC signal if needed but 99% of the time, it's not needed as RM will generate the correct value.

Vyrolan · Post by **Vyrolan** » Fri Dec 07, 2012 2:45 pm

The Robman wrote:
Vyrolan wrote:It seems that I should just never set a parameter value to a default...just leave them blank and let RMIR handle any defaulting. I can make that change.
You should probably make that judgement on a case by case basis, but certainly in the case of the NEC parm, you should always leave it blank. That one is primarily there to allow an expert to create a custom NEC signal if needed but 99% of the time, it's not needed as RM will generate the correct value.

Yea, if DecodeIR shows the values, I try to use them...but if it doesn't, I had just been setting to the defaults (that the RMIR code parses out of protocols.ini). It seems better though to just not use the defaults and leave them blank and let RMIR handle it. I do think there's room for error in that feature...perfect conversion from learns to an upgrade is probably not going to happen, but it can do most of the work and leave the user with only a few tweaks on a parameter or whatever to finish it up. /shrug

Post by **The Robman** » Fri Dec 07, 2012 3:33 pm

Another possibility would be to create a separate "NEC Generic" protocol entry in protocols.ini and then delete the Parm entry completely from the regular NEC1,2,x1,x2 entries.

Vyrolan · Post by **Vyrolan** » Fri Dec 07, 2012 3:48 pm

The Robman wrote:Another possibility would be to create a separate "NEC Generic" protocol entry in protocols.ini and then delete the Parm entry completely from the regular NEC1,2,x1,x2 entries.

That would fix NEC... Is the "use the value in protocols.ini as default instead of leaving it blank" going to mess up anywhere else though?

Post by **The Robman** » Fri Dec 07, 2012 4:09 pm

Someone would have to go through protocols.ini and review each protocol one by one.