DecodeIR: Where do we go from here?

[mathdon]

Liz, the idea is that if the protocol structure is known and it has variations between the repeat frames (first with lead-in, repeats without, or a toggle changing) then DecodeIR recognises this and tells you that you have multiple frames of that protocol. There's not a lot of point in continuing to show frame differences when they are known about, as all that will do is cause confusion to users who don't understand, say, why their JVC decode is followed by JVC{2} decodes.

Yes, the difference between IR.exe and the Widget is that DecodeIR knows, when it gets a structured signal (Once, Repeat and Extra parts) that it is dealing with a single learned signal. From IRScope it gets a long unpunctuated series of frames that could be from many protocols. So from IR.exe it suppresses the Gap as not consistent with what it has already seen. From IRScope it considers that it may be a genuine new protocol, and so shows it.

If Rob or anyone else doesn't like this handling, which I consider to be "intelligent decoding", then I can make it switchable. But I hope no-one asks for that.
_____________
Graham

[ElizabethD]

I assume that by "known" you mean is in the list with all those IRP notations, and I have no problem with what shows in IR, especially that details are still available which they are.

My earlier question, with reference to your design, had to do with Widget, where I didn't get what your screen shot shows. No jvc{2} there, just jvc and gap. That screen shot was your message 9/21 at 11:29am.

[mathdon]

I assume that by "known" you mean is in the list with all those IRP notations, and I have no problem with what shows in IR, especially that details are still available which they are.

That's indeed what I mean.

My earlier question, with reference to your design, had to do with Widget, where I didn't get what your screen shot shows. No jvc{2} there, just jvc and gap. That screen shot was your message 9/21 at 11:29am.

You misread the screenshot. The JVC and JVC{2} entries are from different keys - look at the OBCs - one entry from each key. For the second I deliberately missed the first frame. It is there to show that I hadn't done this simply by removing JVC{2} from the possible decodes. It was taken from a true JVC signal (which doesn't have the corrupted Gap at the end), not from a learned version of that signal (which does have that end corruption). If you get the Gap with a true JVC signal, please tell me because I don't think that should happen.
_____________
Graham

[ElizabethD]

Widget only.
I did misunderstand, I see keys are different in the screen shot

So I just took the OEM JVC remote, and threw 1,2,3 at the widget and got one JVC line/number. They say 4 frames, 3 frames, two frames. Another run: 3 frames, nothing, 5 frames. I made very short 2, and I held onto 3 for a bit. No trace of JVC{2} which this true, unlearned, signal contains.

Is this all important? Does it not match your design? I dunno

I think I'm after reconciling your statement: "In the Misc column, "x dittos" denotes repeat indications that do not carry the signal data,"

[mathdon]

No trace of JVC{2} which this true, unlearned, signal contains.

What do you mean by "contains"? If you mean that there is only one lead-in preceding multple identical data frames, so that the first frame should be JVC and the rest JVC{2}, that's exactly what I was trying to prevent. DecodeIR now knows that is the structure of a JVC signal, and reports it as JVC with "x frames". If you have a JVC signal with no lead-in at all, only then will you get JVC{2}. If there actually are multiple JVC frames each with a lead-in (you were quick on the button, pressed it several times, each just long enough to send one frame) THEN you should get ONE JVC entry for each signal (no "x frames", as this doesn't show when x = 1). In other words, DecodeIR knows that you have pressed the button several times and will give you an answer for each one. I've tried it - this does work.

It appears, though it's not obvious from John's notes in DecodeIR.html, that there are JVC remotes that genuinely send a JVC{2} (no lead-in at all) signal. I have a JVC VCR remote that does exactly that, and it shows as JVC{2} in IRScope. BTW My learning remote also learns THAT signal correctly, without corrupting the final frame - very strange.

Is this all important? Does it not match your design?

Yes, it's important to me. I want to be sure that it is behaving as planned, and that protocol experts like you understand that plan and, in the end, are happy with it. (And even like it, if I dare hope!) So far, what you have reported does match my design, if I understand you correctly.

Do keep asking/commenting if you still have questions/doubts about what it (or I) am doing.

Edit: The underlying philosophy is that IRScope should show ONE entry for each button press, whether the press is long or short, and should give enough information for you to know what it has seen (eg multiple data-carrying frames, or one such frame with non-data repeats) and to be able to reconcile that with the graphics.
______________
Graham

[mathdon]

Greg, if you have tried the code I posted a few days ago to bring RMIR into line with IR.exe in its use of the latest version of DecodeIR, you will have found that it didn't work. This is due to a combination of reasons:

1. The version of DecodeIRCaller.java on which I based my revision of that file was the version included in the posted distribution of DecodeIR.dll v2.36. This is no longer the version you use, so the revised file was inconsistent with your current RM code.

2. There was a minor error of mine in DecodeIR.dll v2.38 Beta4 that would only show up when used with the revised caller.

3. The UnpackLearned class, written by John and to which you gave me a link, included the lines

repeat = ( partTypes[partNdx] ) ? parts[partNdx] : 0;
oneTime = total - repeat;

I did not read the entire code of that class carefully enough. I saw that "total" was a count of durations and so presumed that "repeat", and therefore "parts[ ]", were also duration counts as otherwise this did not make sense. But that is not so. "parts[ ]" and therefore also "repeat" is a count of bursts (ie half the number of durations). The effect of this error of John's on current versions of RMIR is effectively the same as taking repeat=0, which my study of the output of RMIR had led me to believe was the case. The difference is that DecodeIR also sees a corrupt half frame that it is unlikely to find any decode for, spurious or otherwise, so the difference is not visible.

I have posted DecodeIR v2.38 Beta5 together with revised DecodeIRCaller.java, .class and .h files that should now be correct. The correct replacement for lines 194-196 of the UnpackLearned class is

Code: Select all

    repeat = 0;
    extra = 0;

    for  (int n=0; n<partNdx; ++n )
    {
        if ( partTypes[n] && repeat == 0 )
        {
            repeat = 2 * parts[n];
        }
        else if ( repeat > 0 )
        {
            extra += 2 * parts[n];
        }
    }

    oneTime = total - repeat - extra;

which differs from the previous version only in the factors of 2 needed to convert frame counts into duration counts.
________________
Graham

[ElizabethD]

No trace of JVC{2} which this true, unlearned, signal contains.

What do you mean by "contains"? If you mean that there is only one lead-in preceding multple identical data frames, so that the first frame should be JVC and the rest JVC{2}, that's exactly what I was trying to prevent.
...
Edit: The underlying philosophy is that IRScope should show ONE entry for each button press, whether the press is long or short, and should give enough information for you to know what it has seen (eg multiple data-carrying frames, or one such frame with non-data repeats) and to be able to reconcile that with the graphics.

"Contains" - the JVC has first part with lead-in, and second part without, so I mean that the second part, JVC{2} is part of the signal. I don't think of it as two signals. Wrong? Could be just semantics

Hopefully, last iteration, I really do hate to be major pest here -
Maybe I'm losing my mind. So I will rethink it loud. Please don't laugh.

Perhaps it all came out of a variable not yet much discussed, though I did mention it - that is differences in what the remotes put out.
The example I use is JVC. In 8910 and 6131 and Comcast remote and 7800, when you press a button normal length, all is fine. Devices respond, and that file JVC123 confirms.
BUT ...
When the same buttons are sent via a macro, 7800 remote does not send even one frame of the JVC{2} signal, just the one and only JVC.
All other remotes send 3 repeats.

That's not important when Widget or IR is used for learning function codes.

It is important when I debug a macro using Widget.
If the Widget won't show JVC plus JVC{2} - N-times for the 'good' signal, as opposed to just JVC for the bad (7800) signal, the reported data will not look any different from the other remotes.
Squaring with a graph isn't always the simplest thing in a long macro, at least for me.

Maybe what I'm after is to prevent multiple lines but report what they were, at least in Widget. So that when you sit on a button, you won't get 50 lines of JVC{2}, but JVC{2} still is reported. Then when the 7800 macro comes in, it'll jump at me that something is missing.

Or are you saying that the good signal will say JVC 3-frames, and the bad signal will say JVC and then I'll know the repeats (specifically the JVC{2} part of message) didn't happen?

[vickyg2003]

Hi Elizabeth, I hate to butt in, but I have been following this thread and I think, you'd see "1 Ditto" in the Misc where the repeat frame was sent, and nothing when on the remote that doesn't send the second part.

[mathdon]

Or are you saying that the good signal will say JVC 3-frames, and the bad signal will say JVC and then I'll know the repeats (specifically the JVC{2} part of message) didn't happen?

Yes, that's what I am saying. JVC with "3 frames", say, means 3 frames of a properly formatted JVC signal, what you are calling one JVC and two JVC{2} frames. JVC with nothing in Misc means 1 frame, i.e. no JVC{2} frames to follow. If you actually had two identical frames, both of what you are calling JVC frames, then you would get TWO lines of JVC (with no Misc entry), NOT one entry saying JVC 2 frames, because it is NOT two frames of a properly formatted JVC signal.

I'm beginning to think that I should not suppress "n frames" when n=1, so that the last case would then be two lines, each of JVC 1 frame. Do you think that would help? I originally suppressed it when n=1 to prevent it appearing often in IR.exe and RMIR, but I have a better way of doing that now. In RC7, due shortly, IR.exe will never show the "n frames" or "n dittos" entries - nor will RMIR when Greg puts in my suggested changes.

I really do think what I've done is an improvement and I don't think you are losing any information. I do hope you will agree with this when you get used to it.
_______________
Graham

[mathdon]

Hi Elizabeth, I hate to butt in, but I have been following this thread and I think, you'd see "1 Ditto" in the Misc where the repeat frame was sent, and nothing when on the remote that doesn't send the second part.

Not with JVC. You get "n dittos" with non-data repeats such as NEC1, and "n frames" with repeats that do carry the signal data, such as NEC2 and JVC. That difference stems from Liz's original request to have some indication of non-data repeats.

Vicky, what do you think of my suggestion in my reply to Liz, that for clarity I should not suppress entries saying "1 frame"? Perhaps for protocols that use non-data repeats, instead of "1 frame" it should say "0 dittos"?
____________
Graham

[vickyg2003]

Vicky, what do you think of my suggestion in my reply to Liz, that for clarity I should not suppress entries saying "1 frame"? Perhaps for protocols that use non-data repeats, instead of "1 frame" it should say "0 dittos"?

Well Liz and I are using the tools for completely different purposes, so as long as I get the basic information, Pidname, Devices and OBC's I don't care if there is extra information in the fields at all. I am using my Widget to get my head around protocols.

Liz, is using the Widget to debug macros, and needs more information than I do. I know first hand that Liz's writes powerful macros. She debugged my first extender, and I was totally mind-boggled by her macros. She taught me SOOOOOO much!

Eventually I'll be very interested in knowing how the calls need to be changed to get the most out of calling decodeIR.

[gfb107]

Sorry, I've just now had a chance to read the new information. It'll probably be a couple more days before I have a chance to really look at this and try the code changes.

[ElizabethD]

I really do think what I've done is an improvement and I don't think you are losing any information. I do hope you will agree with this when you get used to it.

Well, Graham, I think you prevail.

I uploaded a file with pictures of a test JVC 1,2,3 MACRO where DecodeIR interpretation in 2.38 Beta3 does make a sufficient distinction for me.
But I would like to see n=0 or "no repeats" to really shout it out to me.
See here if you wish. Included are the data files for no other reason than I have'm.
https://www.hifi-remote.com/forums/dload ... le_id=7308

I hope all this good stuff carries over to other protocols, like all those NEC variants, since we've been beating the poor JVC to death here

[ElizabethD]

Well Liz and I are using the tools for completely different purposes, so as long as I get the basic information, Pidname, Devices and OBC's I don't care if there is extra information in the fields at all. I am using my Widget to get my head around protocols.

Vicky, in this instance, it was a macro issue, but not anything complex about it. Looong ago, when I first used the extender in 7800, DVD didn't hear a word the remote was sending. And that's when this whole issue of the need for the JVC{2} frame all started.

I think the bottom line is that it's not always sufficient to know the protocol and OBC and hex. Most of the time it is. But sometimes it's not, as is this case, and many others where Rob or other experts tweak the small details of a protocol.

[vickyg2003]

Vicky, in this instance, it was a macro issue, but not anything complex about it. Looong ago, when I first used the extender in 7800, DVD didn't hear a word the remote was sending. And that's when this whole issue of the need for the JVC{2} frame all started.

I think the bottom line is that it's not always sufficient to know the protocol and OBC and hex. Most of the time it is. But sometimes it's not, as is this case, and many others where Rob or other experts tweak the small details of a protocol.

Yes, I understand your issue, and what you need from the Widget. If a signal doesn't work in a macro, you need to know why, and that is in the details. When I usel my widget, 99.9% of the time I want to see the raw timings, but it saves me a lot of time, if I can see the protocol name, Dev and OBC. If the general decode is not right, I don't have to dink around the timing tolerance.