DecodeIR: Where do we go from here?

[mathdon]

Thanks, Liz, for the .ir file with the JVC learning in it. I find it very interesting. The IRP notation for JVC is

{38k,525}<1,-1|1,-3>(16,-8,(D:8,F:8,1,-45)+)

Your well-learned signals all have a full frame, starting with the 16, -8 leadin, marked as sent Once, followed by a frame without the lead-in marked as Repeat, but this is followed by another frame sent only once, marked Extra, that lacks the lead-in but also lacks the final OneOn pulse before the -45.

The Once, Repeat and Extra frames are all different from one another, so they are all reported by DecodeIR and appear as the three entries in the listing. The Once frame is seen as a full JVC signal and is listed as JVC. The Repeat frame is seen as a JVC signal without the lead-in, which is reported as JVC{2}. The Extra frame is not seen as a valid JVC signal and so is reported as a generic Gap.

Why does this not show up before RC5? Because the combination of RC5 with DecodeIR v2.37 is the first combination that passes the Extra frame to DecodeIR for processing. The philosophy appears to have been that the Extra frame, when present, is not needed for protocol identification, so was not passed to DecodeIR, though it has always shown up in the raw data timings.

So it is not some random part-signal at the end, it is real and possibly says something about the JVC protocol that has not previously been noticed. Your signals suggest that the full JVC protocol actually has IRP notation

{38k,525}<1,-1|1,-3>(16,-8,(D:8,F:8,1,-45)*,D:8,F:8,-45)

It would be interesting if a protocol expert could comment on this possibility.
________________
Graham

[arrow]

To mathdon . I am not understand ...
1.The all keys give Floating Point Error , but I delete two keys( mute and red ) error is not .
2.With the nec protocol error no .
3.When I am press OK on the error box , it the window closed .
4.I am using Windows2000 by the my oldest noutbook with com port .
Picture include https://www.hifi-remote.com/forums/dload ... le_id=7263

[mathdon]

1.The all keys give Floating Point Error , but I delete two keys( mute and red ) error is not .

That is very helpful. But in the file you posted, the keys you deleted were Fav and Red. Does the error go away if you just delete Red?

Could you please try re-learning the Red signal? There is bad data in it and I think that may be the cause of the problem. You should not get an error, even with bad data, but it would help me to know if the error goes away when the signal is learned correctly.

4.I am using Windows2000 by the my oldest noutbook with com port .

I will see if I can try your file on a computer that uses Windows 2000. I am using Vista and do not get any errors with DecodeIR v2.38 Beta.
____________
Graham

[mathdon]

Hi again, Arrow. I have obtained a computer that uses Windows 2000. When I try your file on that computer, I get exactly the same Floating Point Exception message that you get. So the problem depends on the Windows version being used.

Now that I can create your error, I no longer need to ask you to try things. I will continue trying to solve the problem and will report progress in this thread.
_____________
Graham

[arrow]

To mathdon .No error.
1.I delete the red key , to error is not .
2.With the new learned red key error is no .
File https://www.hifi-remote.com/forums/dload ... le_id=7270

[mathdon]

Thanks again, Arrow. This time I think I've solved it, as I no longer get an error on my Windows 2000 machine. Please try DecodeIR v2.38 Beta2 and post a message here to say if it works.
_______________
Graham

[arrow]

Thanks, mathdon. Thank you for patience . DecodeIR v2.38 Beta2 is the good work and no problem .

[mathdon]

[Edit: Merged from another thread. This answers the post by ElizabethD that is now the first post in this thread.]

Hi, Liz. I've just come across this while searching for info on protocols where the repeat is not the same as the original. The motivation for the search was another post of yours, about you now getting 3 decodes (JVC, JVC{2} and Gap) for JVC signals. It's not an issue with the IRScope software, it is one with DecodeIR. I will look into it.

BTW With DecodeIR v2.37 you should see that your Panasonic example no longer gives many identical entries, but instead a single entry with something like "6 frames" in the Misc column. I've been expecting some comment, either for or against, on this change but so far I've had deafening silence. If I can do anything about your non-data repeats, it will be in the same form as that, ie you would get a single NEC entry with, say, "6 frames" in the Misc column. Or perhaps something different with non-data repeats, say "6 dittos"? Since that's what they are, electronic ditto marks!
_______________
Graham

[mathdon]

Hi again, Liz. I've been looking at this JVC behaviour in more detail, and it is even more curious that I thought. I've worked back from your learned signal and found that it appears to be from setup code DVD/0623, keys 1,2,3. I've put this into both my URC-7781 (JP1.2) and URC-7940 (JP1.3) and looked at the signals with IRScope. Both show only the JVC frame followed by several JVC{2} frames, no sign of a signal missing that final OneOn pulse. Looking at the graphical data shows again that all the signals are identical, apart from the initial lead-in of the the first frame.

But then I learned the signals from the URC-7940 to the URC-7781 and looked at the result in IR. Lo and behold, it showed up your Gap decode, and the raw timings showed the final frame with the missing OneOn pulse. I then shone the learned signals at IRScope and now I got the Gap decode, with the graphics clearly showing the absence of the OneOn pulse in the final frame.

So the Gap decode appears to be a result of a problem with the UEI learning process, rather than anything real in the JVC signal. Had it proved to be real, I would have tried to add a JVC{3} decode for that final frame, but as it is bogus it should clearly be left as an unidentified signal, which is what a generic Gap decode really is.
_______________
Graham

[ElizabethD]

Graham,
I understand 100% your first message. Really cool.
I almost understand the second one. Interesting. Curiouser and curiouser.
It could be UEI sort of gives up after it gets enough information, then they get messy.

I will dig up a genuine JVC remote if I can find it. It's for my DVD and I will do the widget routine and post a file.

I was not looking for any missing blips. I used to do that with IRSA. This was, I suppose one instance to check that.

I wonder if we could merge this repeating issue into its own thread, considering I'm now heading to answer the other post!

[ElizabethD]

Thanks for answering.
What I'd like to see is some distinction as to what the repeat holds. That's useful when we tweak the protocols or need to check what you put in one remote or another. For that reason, while I have no problem with your suggestion of "6 frames" in Misc, I still would like to see the non-data reps names differently, perhaps 6 LI/LO, something like that.

I know that NEC protocols have a ton of variants. And if I recall, some put out LI/LO, the hacked ones might put out data frames ... I might be making this up. But just in case, could they be named slightly differently?

Also macros play a role. For instance 7800 when puts out a JVC macro it never sends those non-data repeats, just the base message. Yet other remotes do. Once again, distinct naming would help.

Boy, this is interesting stuff, isn't it?

[ElizabethD]

This is how JVC signals look from the genuine JVC remote
https://www.hifi-remote.com/forums/dload ... le_id=7277

[ElizabethD]

I've worked back from your learned signal and found that it appears to be from setup code DVD/0623, keys 1,2,3. I've put this into both my URC-7781 (JP1.2) and URC-7940 (JP1.3)

DVD/0623 - good guess. I actually base these upgrades on DVD/0558. Far as I know it uses the same 0034 protocol

Besides the possible UEI thing, learning from one UEI remote to another UEI remote also might also affect things, but I don't know details how those things work. Something might be missing in double translations.

[mathdon]

It seems to me, from the JVC signals in another thread, that you are not yet using DecodeIR v2.37 with IRScope, as the repeating JVC{2} signals would have shown up with "x frames" rather than repeats. However, don't bother as I will post v2.38 Beta3 shortly. (The first two Beta's were essentially private ones for Arrow to test with his problem).

I agree entirely about distinctiveness. I've already put "dittos" into NEC1, so as examples, NEC1 says "5 dittos", NEC2 says "5 frames". The first of these means one NEC signal with 5 non-data repeats, the second means 5 identical NEC signals.
____________
Graham

[mathdon]

Here is an illustration of how DecodeIR, in its current state (not yet posted) works with IRWidget/IRScope:



In the Misc column, "x dittos" denotes repeat indications that do not carry the signal data, "x repeats" denotes repeats that are either identical or which differ in some way according to the protocol spec, but still carry the full data. NEC1 repeats use non-data dittos, NEC2 repeats are identical to the first frame. JVC repeats omit the lead-in so the repeat frames are not identical. JVC{2} signals all omit the lead-in, even the first frame.

Because of the way the NEC1/NEC2 difference is recognised by DecodeIR, v2.36 (and v2.37) would report NEC2 signals as the non-specific NEC when used with IRScope, even though they identify it as NEC2 when showing learned signals with IR.exe. I have refined the recognition method so that it works also with IRScope.

In DecodeIR v2.36 the JVC signal would have shown as 10 listings, one of JVC and 9 of JVC{2}. In DecodeIR v2.37, it would have shown as "JVC" (one frame) followed by "JVC{2} 9 frames" as the frames are not all identical. IMHO that is an improvement, but recognising the frame variation and showing the single entry with "10 frames" is a greater one.

The form of the "ditto" frame is checked for each protocol against the protocol spec. The Kathrein protocol actually includes the function data but not the device data in the "ditto frame", and that too is checked for consistency with the first frame, so this "ditto" indication is not some catch-all that may miss real data. (Kathrein is in DecodeIR.html, but it is there as pid-0066 and is not in the index. It can be found at the bottom of the document, after the indexed entries.)

If anyone has used DecodeIR v2.37 with IRWidget/IRScope, they have remained awfully silent about the changes. I hope posting this image will produce some comments, either positive or negative. I need them, as there is no point in me making these changes if they are not liked.
______________
Graham