RMIR: Making Upgrades from Learned Signals

Vyrolan · Post by **Vyrolan** » Fri Sep 07, 2012 3:46 pm

The Robman wrote:Wow, enjoy! But why so short, you should stay in Cancun longer!

4 nights 5 days is pretty good. =p

Post by **The Robman** » Fri Sep 07, 2012 4:27 pm

True, but 6 nights 7 days is better!

Vyrolan · Post by **Vyrolan** » Fri Sep 07, 2012 5:35 pm

The Robman wrote:True, but 6 nights 7 days is better!

LOL. Touché. =)

Vyrolan · Post by **Vyrolan** » Thu Sep 20, 2012 3:17 pm

I'm back and made a few more changes/fixes/etc. As always, I've posted my latest jar here.

Change are:

New "Advanced" sub menu under options:
- Toggle on/off the ability to convert learned signals to device upgrade (disabling removes "Convert to Device Upgrade" button)
- Toggle on/off learned signal timing analysis:
  - Toggles Timing Summary button
  - Toggles analysis controls in the advanced area of the learned signal dialog (off forces signals to always be rendered with the Even version of the Raw Data analyzer)
Added "Edit Upgrade" function to Key Move tab to let you jump right into the device upgrade to which a key move is attached

Vyrolan · Post by **Vyrolan** » Thu Sep 20, 2012 4:09 pm

Small additional update to the jar here. There was a small bug fixed, but also I went ahead and added the ability to delete a key move that is part of a device upgrade. It will prompt you about it...if you say yes, it will detach and then delete it. This saves the extra click of having to do detach yourself before delete.

Vyrolan · Post by **Vyrolan** » Fri Sep 21, 2012 3:41 pm

Another small update (jar still here). I've started to implement a 'suppress messages' similar to what IR had to bypass some of the warnings/popups/dialogs. If you know what you're doing, you don't need those. For now I've only added option for suppressing ones related to detaching/deleting key moves that are part of an upgrade, but I'll be expanding on it going forward. If there are particular prompts that you'd like to be able to suppress, please let me know.

Post by **The Robman** » Sun Sep 30, 2012 7:13 pm

Vyrolan, I don't see your changes in this version anymore.

Vyrolan · Post by **Vyrolan** » Thu Oct 04, 2012 1:19 pm

The Robman wrote:Vyrolan, I don't see your changes in this version anymore.

You don't? I just downloaded it and it seems fine to me.

Oh...I think I realized... Options -> Advanced -> Learned Signal Timing Analysis. It defaults to off. =/

xnappo · Post by **xnappo** » Mon Dec 03, 2012 8:59 pm

Hi Vyrolan,

I have wanted this feature for a long time and finally got to check out your changes this weekend. I used your latest build.

It worked great and definitely saved time except for one minor issue. The learns in question used the NEC2 protocol with device 131 and Sub Device 85. However the upgrade that got built automatically ALSO put a 'Parm' of '1' when it should have been left blank. This took me a while to figure out

I put the .rmir file with the learns here:
https://www.hifi-remote.com/forums/dload ... e_id=11567

The working upgrade is here:
https://www.hifi-remote.com/forums/dload ... e_id=11568

Thanks for the great addition to the toolset!

xnappo

Vyrolan · Post by **Vyrolan** » Thu Dec 06, 2012 1:13 pm

xnappo wrote:The learns in question used the NEC2 protocol with device 131 and Sub Device 85. However the upgrade that got built automatically ALSO put a 'Parm' of '1' when it should have been left blank. This took me a while to figure out

I loop all of the parameters for the protocol and fill them in from the decode and then use the default if they weren't in the decode. So I would expect setting the Parm to 1 is the same as leaving it blank? I guess I could leave it blank instead of using the default values. That makes sense since that way makes fewer assumptions. I'll change it.

xnappo · Post by **xnappo** » Thu Dec 06, 2012 1:27 pm

Vyrolan wrote: I loop all of the parameters for the protocol and fill them in from the decode and then use the default if they weren't in the decode. So I would expect setting the Parm to 1 is the same as leaving it blank? I guess I could leave it blank instead of using the default values. That makes sense since that way makes fewer assumptions. I'll change it.

Yeah '1' is definitely different from 'blank' though I suspect that '0' may be the same. May be something we need the protocol experts to weigh in on as it may vary by protocol...

Thanks,
xnappo

Vyrolan · Post by **Vyrolan** » Thu Dec 06, 2012 1:35 pm

xnappo wrote: Yeah '1' is definitely different from 'blank' though I suspect that '0' may be the same. May be something we need the protocol experts to weigh in on as it may vary by protocol...

Well the 1 is taken from the protocols.ini...

protocols.ini wrote:[NEC2]
PID=00 5A
CmdTranslator=Translator(lsb,comp)
CmdParms=OBC=0
DevParms=Device Number,Sub Device,Parm:$=1
DeviceTranslator=NECParmTranslator(1)
FixedData=01 ff ff

xnappo · Post by **xnappo** » Thu Dec 06, 2012 3:51 pm

Vyrolan wrote:
xnappo wrote: Yeah '1' is definitely different from 'blank' though I suspect that '0' may be the same. May be something we need the protocol experts to weigh in on as it may vary by protocol...
Well the 1 is taken from the protocols.ini...
protocols.ini wrote:[NEC2]
PID=00 5A
CmdTranslator=Translator(lsb,comp)
CmdParms=OBC=0
DevParms=Device Number,Sub Device,Parm:$=1
DeviceTranslator=NECParmTranslator(1)
FixedData=01 ff ff

Ah... I suspect that is incorrect. Rob??

xnappo

3FG · Post by **3FG** » Thu Dec 06, 2012 4:41 pm

Rob's explanation of the param byte in PID 005A

If bit 0 is set, it implies NEC2 or NECx2. So I think the protocol.ini entry for NEC2 is correct.

If the signal is supposed to be NEC1 or NECx1, then bit 0 of the param byte should be zero.

Post by **The Robman** » Thu Dec 06, 2012 5:44 pm

In normal circumstances, you should not specify the parm value when you are setting up one of the 4 common NEC variants (ie, NEC1, NEC2, NECx1, NECx2) because RM will calculate the parm for you.

If you do specify a parm value it will override whichever variant of NEC that you selected. The parm box is available to the user so you can set up one of the odd variants if you need to. (See the previous link for examples).

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.