RMIR: Advanced Handling of Learned Signals

[The Robman]

Can the leadin be just a ( + ) like that...or does it have to be a ( + - )?

The easy answer is "anything's possible" because as soon as we all agree on a rule, someone will make a remote that breaks it! But, 99% of the time, signals have a leadin PAIR (ie, + and -). In this case, the correct leadin is +2700 -900. I can't make IR.exe display it exactly like that, but getting +2700 -450 -450 is good enough because I know how to work it, but if you can make it display correctly, that would be great.

Is there a way to know which way is right?

That's why I was interested to see your code in action, because normally it's a judgement call which you make when looking at lots of samples, not just one sample at a time like you're having to do.

How do we know which one is correct? My intuition is to go with "the one that results in an even number of logical pairs" since that seems most likely.

Normally, I adjust the ODD/EVEN setting to see which one gives me all legal pairs (ie, all "+n -n" and "-n +n", with no "-n -n" or "+n +n") but the ReplayTV signals is one which breaks that rule, so I have to allow for that one double wide pair. I would say that, if you try both methods and one results in all legal pairs and the other doesn't, then that's the one you should default to. But, if both methods produce illegal pairs (which would be the case with Replay) or both methods only produce legal pairs, then let the user control it manually.

[Vyrolan]

OK, I gave it a try and the bi-phase logic did not recognize that either of the edited signals that I posted earlier were bi-phase.

Yes, I was not properly handling signals with repeats. That has been fixed though. I have updated my jar and it should work now.

It works fine for those two signals...here are the timings (with some red boxes for emphasis around the difficult parts)... Here's the first one with the long leadout in the middle:


Here's the second with the short leadout in the middle:


Those decodes both yielded even number of pairs, and so the leadin was left exactly as-is and the final On time is included in the leadouts. That is "correct" as we can reasonably guess it to be I believe. Thoughts?

[Vyrolan]

The file below contains 3 copies of the signal from the P&P/REW button in the FromRob.ir file. The first is the vanilla signal from the original file with no changes. The second is where I have converted it to a "sent once" string with 2 repeats and the normal leadout time. The third is the same as the second, except that I've reduced the leadout time as described above so that it's small enough to fool the bi-phase logic in IR.exe

https://www.hifi-remote.com/forums/dload ... e_id=11283

I tried this file you provided Rob...all 3 of the signals decode perfectly with my latest version. It properly handles either leadout time, and it properly handles the double pairs. Let me know what you think when you have a chance to take a look.

[The Robman]

I see that, it does look good, now I just need it to persist over to the Timing Summary sheet, because if I'm decoding all the learns for a device, I cut and paste the data from there to Notepad so I can convert it to binary.

[Vyrolan]

I see that, it does look good, now I just need it to persist over to the Timing Summary sheet, because if I'm decoding all the learns for a device, I cut and paste the data from there to Notepad so I can convert it to binary.

Done. I updated the jar for you to try it out. One small note (which I put in the app as well) is that the rounding box on the Timing Summary won't effect bi-phase signals unless you enter a number that makes sense. If it's a ( +440, -440 ) signal and you enter 100, it won't change because the +440 go to 400 but the +880 go to 900 and so the signal no longer parses correctly as bi-phase. However if you enter 150 for the rounding, then they are appropriately rounded to ( +450, -450). The rounding effects all non-bi-phase signals as usual.

[The Robman]

Hi Vyro, it's looking very good. Few minor comments though, even if I clear the rounding value on an individual learn screen and select Raw as the bi-phase option, when I look at the times on the Summary sheet, they still appear to be rounded. I would still like the ability to get all the raw times at once, plus, just in case the bi-phase decode is a mistake, I would like to be able to turn it off. I use the rounding option mainly to get to the binary, when I'm about to enter times into PB I like to look at the un-rounded times to get a better idea of what values to use.

And one VERY MINOR detail, normally the "Once:" and "Repeat:" tags are followed by 1 tab and then the data, but the new "More:" tag is followed by a tab and a space then the data, could you remove that extra space please?

[Vyrolan]

...even if I clear the rounding value on an individual learn screen and select Raw as the bi-phase option, when I look at the times on the Summary sheet, they still appear to be rounded.

Yea, I just kinda hacked that in there. I am working now though on refactoring all of this stuff to be much better integrated and I will be expanding how much control you have over what you see.

And one VERY MINOR detail, normally the "Once:" and "Repeat:" tags are followed by 1 tab and then the data, but the new "More:" tag is followed by a tab and a space then the data, could you remove that extra space please?

Will fix. =)


One other question... Does anyone actually care to see the "bursts" area of the signal? That part seems unremarkable to me an just takes up space. I'd like to remove it. Thoughts?

[vickyg2003]

One other question... Does anyone actually care to see the "bursts" area of the signal? That part seems unremarkable to me an just takes up space. I'd like to remove it. Thoughts?

That box not in IR. I'm not sure why that box is in RMIR. Was it by request or at the author's whim. But I think it might be useful for a quick glance assessment of the type of signal you are dealing with.

Have you seen anything other than binary learn? XMP for example is in pulse width hex command. Noikia is a pulse width quad, and just a month or so ago we had a quad-phase encoded learns.

[Vyrolan]

I have updated my RemoteMaster.jar file again with the results of my refactoring. The code is much cleaner and simpler now, and I have abstracted all of the bi-phase stuff into a generic framework for timing analysis. So for now we just have two analyzers: the bi-phase one and a raw data one (that just dumps raw timings). I've adapted all of the UI to support this generic timing analysis setup. You can select an analyzer and an analysis to see the resulting timings:


The multiple analyses in the drop down represent different possible results for looking at the timings. In this particular example, analyzing the timings resulted in a left +440 at the end...so it generated both possible outcomes: first the +440 is part of leadout ( +440, -X ) and second that the +440 is part of final pair ( +440, -440 ) with leadout reduced to ( -(X-440) ). So you can see all possible variants.

Your selected analyzer, analysis, and rounding are preserved while you have the file open, and they are also preserved for viewing on the Timing Summary. So if you select a specific anayzer/analysis/rounding and then view the Timing Summary, you will see it there. The Timing Summary's rounding box will not override those settings set on a single signal.

I'd love some feedback on this version and what you think about the new setup.

One other question... Does anyone actually care to see the "bursts" area of the signal? That part seems unremarkable to me an just takes up space. I'd like to remove it. Thoughts?

That box not in IR. I'm not sure why that box is in RMIR. Was it by request or at the author's whim. But I think it might be useful for a quick glance assessment of the type of signal you are dealing with.

I removed it for now...but just by making it invisible so we could bring it back if desired.

Have you seen anything other than binary learn? XMP for example is in pulse width hex command. Noikia is a pulse width quad, and just a month or so ago we had a quad-phase encoded learns.

With the new analysis framework, it will now be much easier to add others. I have not seen the other kinds you mention vicky, but I'd love to see examples so I could look into writing analyzers for those as well.

[mathdon]

What Vicky is referring to is where four different IR "bursts" are used to encode bit pairs, rather than two bursts encoding a single bit. XMP goes further and uses 16 bursts to encode entire 4-bit nibbles. In that case the ON time is common to all 16 bursts but the OFF time has the form a+b*n where a, b are constants and n is the nibble value. I see this as more of a decoding issue than an issue for the raw data display of Learned Signals.

[Vyrolan]

What Vicky is referring to is where four different IR "bursts" are used to encode bit pairs, rather than two bursts encoding a single bit. XMP goes further and uses 16 bursts to encode entire 4-bit nibbles. In that case the ON time is common to all 16 bursts but the OFF time has the form a+b*n where a, b are constants and n is the nibble value. I see this as more of a decoding issue than an issue for the raw data display of Learned Signals.

Thanks for the info. There's definitely an overlap between this and the decode. One aims to display the bursts in a meaningful way and the other aims to determine some specific info. Most of this has been for signals that don't decode though. Nobody needs timing displayed for a signal that decodes perfectly. For those that don't though, if I can do some quick analysis of the timings to display them in a more useful way to help build a custom protocol, it feels like (to me) a worthy goal.

[vickyg2003]

Nobody needs timing displayed for a signal that decodes perfectly.

This is not true.

Reason 1. The curious user, who is having a really difficult time getting a grip on IRP and timings, can learn a lot by seeing the timings and then looking at the IRP. This was one of my main study tools, before I got an IRScope.

Reason 2. Often a signal will decode perfectly and then not work. Then you need to take a close look at the timing data and the frequency to see what the issue is.

The first thing I did when I download IR is to turn on the display to show the timings all the time. Of course turning on that option in IR also gets you the code summary and the timing summary. I have often wondered why we hide the code summary! But I'm straying off topic.

[The Robman]

Now I think the rounding time persists too much. Here's what I did, I opened the FromRob.ir file and went to the P&P/REW button, I noticed that rounding had already defaulted to 20, so next I went to the Summary sheet and entered 550 as the global rounding time. I noticed that it did override the P&P/REW code too, so I guess that it overrides the default times, so I went back to the REW code and entered 440, then returned to the Summary and saw that 440 persisted for that one button, with the rest using 550. OK, so far so good. Next I deleted the 550 time from the summary sheet and went back to one of the learned buttons and found that it still had 550 entered as it's rounding time, leading me to the conclusion that once a time is entered via the summary sheet, you need to delete it from each button individually, is that true? Could you fix it so that if the time is deleted from the Summary, it's deleted everywhere? Maybe there could also be a button that would delete all rounding times, including those entered on individual buttons?

[vickyg2003]

Have you seen anything other than binary learn? XMP for example is in pulse width hex command. Noikia is a pulse width quad, and just a month or so ago we had a quad-phase encoded learns.

With the new analysis framework, it will now be much easier to add others. I have not seen the other kinds you mention vicky, but I'd love to see examples so I could look into writing analyzers for those as well.

Here are some examples of other kinds of protocols
Humax quad phase protocols in IR format
https://www.hifi-remote.com/forums/dload ... le_id=8676

XMP hex based pulse width commands in ict and ir learn format
https://www.hifi-remote.com/forums/dload ... le_id=8177
Note that a UEI remote can't properly learn a hex based command because there are two many timing pairs. This is one of those examples where it might decode, but may be wrong because decode took a guess with some error correcting mathemics that graham developed.


Nokia32 Quad based pulse width protocol
https://www.hifi-remote.com/forums/dload ... le_id=1252

[Vyrolan]

Reason 1. The curious user, who is having a really difficult time getting a grip on IRP and timings, can learn a lot by seeing the timings and then looking at the IRP. This was one of my main study tools, before I got an IRScope.

Reason 2. Often a signal will decode perfectly and then not work. Then you need to take a close look at the timing data and the frequency to see what the issue is.

I personally agree of course as one of those curious users. I do not propose ever hiding information. My statement was meant more to show that decoding and the new "timing analysis" achieve different goals. As you've pointed out, it also serves a purpose beyond what I mentioned.

Next I deleted the 550 time from the summary sheet and went back to one of the learned buttons and found that it still had 550 entered as it's rounding time, leading me to the conclusion that once a time is entered via the summary sheet, you need to delete it from each button individually, is that true? Could you fix it so that if the time is deleted from the Summary, it's deleted everywhere? Maybe there could also be a button that would delete all rounding times, including those entered on individual buttons?

Whoops! That's a bug for sure. Based on your story, it should work exactly like you were expecting it to...I will fix.