JP1 Remotes

The Robman · Posted: Sun Feb 26, 2023 1:23 pm Post subject: RMIR learned signals question

In this thread, Carwarr posted a file of Pioneer learns, where several of them show 2 learns (as is common with Pioneer). My question is, is there a way to display the multiple learns other than going into each learn individually to see the codes? To get the for these learns, I ended up switching to IR 8.04 as there is a Code Summary button there that displays the info that I was looking for.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Mon Feb 27, 2023 1:25 pm Post subject:

The Robman · Posted: Mon Feb 27, 2023 2:13 pm Post subject:

Hi Graham, yeah I know how to do it one learn at a time, as I mentioned, what I was asking is, is there a way to display them all at once like you can do in IR? I wanted to cut & paste them all over to Excel to do some further investigation. I was able to do it using IR 8.04 but I would have preferred to do it using RMIR.

If RMIR doesn't currently have this ability, could I ask that it be added to a wish list for future enhancements?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Tue Feb 28, 2023 9:47 am Post subject:

I have now investigated this further. I cannot find a Code Summary button in IR 8.04 so am unable to see exactly what it is you want, but I presume it is the timings of both learns together. Whichever decoder you use in RMIR, I found that the timings displayed in the Advanced Details box are indeed the timings of the entire signal, so I think RMIR already shows what you want.

However, I think the decoding is wrong for both decoders. IR.exe displays Multiple, which when expanded lists two Pioneer signals. Multiple is intended to show alternative decodes of the same signal when the decode is ambiguous, which is not the case here. The two learns displayed are both part of a single unambiguous signal. IrpTransmogrifier treats it as a single signal but displays a Pioneer decode of only the first part.

The correct decode is a single Pioneer Mix signal that shows the device and OBC values for both parts. The documentation of IR.exe does explain that such two-part Pioneer signals will be decoded as two separate signals, so in that sense it is acceptable even if not accurate. IrpTransmogrifier can decode signals as Pioneer Mix but does not do so in this case, which is an error.

I have tried to trace this error in order to fix it. It appears to lie in RMIR rather than IrpTransmogrifier, so it is my problem rather than Barf's. I believe, though, that it may be an issue with the UEI learning process. It supports three-part signals where the first part is sent once when the key is first pressed, the second part is sent repeatedly while the key is held and the final part, present in only a few protocols, is sent when the key is released. If a key is held only briefly then the repeating part also gets sent only once and cannot be separated from the first part. The learning process makes the assumption in this case that it has seen data that is in principle repeating but only one repeat has been received.

This is what appears to have happened with these signals. The learn expands to a signal in which the two Pioneer signals are sent one after the other, repeatedly. This is not recognized as a Pioneer Mix signal as in that, the first part is sent only once with only the second part repeating.

I need to see if I can find a work-around for this.
_________________
Graham

The Robman · Posted: Tue Feb 28, 2023 12:27 pm Post subject:

The Code Summary button is visible at the bottom on the screen here:
https://i.imgur.com/5syVQtv.png

And when you click it, you get the following:
https://i.imgur.com/P2PH6lQ.png

It's not the decoder's job to decide which "executor" is the best to use, it's just supposed to tell you what "protocol" is being used. You need to view all the signals together as a whole in order to decide which is the best executor for the job.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Tue Feb 28, 2023 1:58 pm Post subject:

Further news, particularly if Barf is watching this. The problem is not with sent-once versus repeating parts of the signal. It is the lead-out at the end of the first part that is the problem. The final lead-out is irrelevant provided only that it is long enough, but the one after the first part is a mid-signal burst and so the tolerance allowed in bursts within the signal is significant. In the signals posted by the user, this is about 25ms. For the signal to decode as Pioneer-Mix it needs to be about 40ms. I have edited the learned signal to change this value without changing anything else and it then decodes correctly as Pioneer-Mix.

This makes me wonder how sure we are that the lead-out for Pioneer in the IRP is correct. Have we taken this from official documentation or just borrowed the NEC1 value? Would there be any harm in changing it from ^108m to -25m? The change from total time (^) to lead-out duration (-) just makes it easier to obtain from a decode. I got the 40m that I said it needs to be currently to decode as Pioneer-Mix I got by generating a Pioneer-Mix signal in ItScrutinizer from the current IRP.
_________________
Graham

mathdon · Posted: Tue Feb 28, 2023 2:08 pm Post subject:

Barf · Posted: Tue Feb 28, 2023 2:32 pm Post subject:

The Robman · Posted: Tue Feb 28, 2023 2:38 pm Post subject:

I wasn't aware that Barf has re-used the executor name for a protocol name, so you can see where the confusion came from. I assumed Pioneer Mix was *just* an executor name. There are many 2-part Pioneer signals that are *not* Pioneer mix.

Anyway, this thread is about the Code Summary display, not the Pioneer decoder.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Wed Mar 01, 2023 5:51 am Post subject:

mathdon · Posted: Wed Mar 01, 2023 7:09 am Post subject:

@Barf

I had a vague recollection that this was similar to a previous issue but could not quite place it. However, for present purposes my issue is solved. I looked to see what lead-out is used by UEI for Pioneer 2CMD and see that instead of ^108m it is ^90m for both the mid-signal and end lead-outs. I have created an rmProtocols.xml version that makes this change. I have also re-named the protocol as Pioneer-2Part and given Pioneer-Mix as an alt_name. This is to prevent the confusion that Rob experienced and which I agree with. With these changes, the signals concerned decode as Pioneer-2Part without needing any further edit. I hope these changes are acceptable to you.

@Rob
Please download this rmProtocols.xml file to replace that in the installation folder of RMIR, v2.14.15 or later. You should find that the 2-part signals concerned now decode as Pioneer-2Part with IrpTransmogrifier used as decoder. If you select any of them and press the "Open documentation" button it will explain the two sets of Device and OBC values. If you now create the Learned Signals summary as I described above, I think it should give you what you want.
_________________
Graham

The Robman · Posted: Wed Mar 01, 2023 11:41 am Post subject:

That looks good Graham, thank you.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

Barf · Posted: Wed Mar 01, 2023 4:08 pm Post subject:

@Graham: Of course, I have no objections against your protocol renaming. IIRC, I picked the P-Mix name from 3FG's teaser files/program (in particular his test suite).

Version 1.2.12 is out. I will address more flexible inter-protocol long delays shortly, but feel free to come up with suggestions.

3FG · Expert Joined: 19 May 2009 Posts: 3367