DecodeIR: Where do we go from here?

[mathdon]

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.

Having seen the notes you attached to the pictures, I don't think it's just a case of I prevail, it seems you actually like it. I was beginning to think you really did want to see a long list of identical entries when there was a long repeat! I agree about showing explicitly when there is no repeat, and will deal with it.

An even better test, with your macro that doesn't give the JVC{2} frames, would be to try JVC 1,1,2 rather than 1,2,3. The macro will then send two consecutive identical frames for the two 1's, but you should get two entries of JVC (no Misc, i.e 1 frame) rather than one entry with "2 frames". DecodeIR knows that is not the proper structure for a JVC repeat and that it must therefore be a second signal.

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

I hope so too! I've certainly tried to make it so. I trust you to shout if I've missed something!
_______________
Graham

[mathdon]

DecodeIR.dll v2.38 Beta6

There is now a new DecodeIR version for testing, v2.38 Beta6. I have not posted it separately, but it is included in the package for IR 8.01 RC7. Betas 4 and 5 were only intended for Greg, for testing with RMIR. Beta6 is the first public version since Beta3 that was included in IR 8.01 RC6.

The only change concerns the display of information about frame repeats. These are now entirely suppressed in IR.exe and RMIR (previously they would appear if the remote's learning software had not detected a repeat pattern that was actually present) and always present with applications such as IRScope. In the latter case, no indication was shown if there were no repeat or ditto frames. Now "no repeat" is displayed in this case, for emphasis.

To Greg: No further change is needed to RMIR. All you need do is use Beta6 of the DLL instead of Beta5 to get the corresponding change to that made between RC6 and RC7 of IR.exe 8.01.
_______________
Graham

[gfb107]

I've tried the new beat6 of DecodeIR, with the code changes you provided. It worked with the Liz's JVC learn IR file in that it only produced a single JVC decode for each learned signal. No GAP decodes anywhere.

Thank you. Are we getting close to a release (of DecodeIR at least)?

[mathdon]

Thanks, Greg. I'm glad my code changes (2nd version!) worked and had the desired effect. Now I have your confirmation that Beta6 is OK too with RMIR, I think it will be the release version. Certainly I have no more enhancements planned and I think I have met Liz's wishes, too. So unless someone reports a bug in the next few days, I will recompile it without the "Beta6" and issue it as a final version. I'll post the source code at the same time.
_____________
Graham

[ElizabethD]

Your worst nightmare is back

Still on Beta3. I'm reporting something I didn't expect.
When I record a macro 1,1,2 using protocol 0034 (jvc), DecodeIR reports 3 lines of 3 frames each (jvc{2} repeats) - and we agreed that's what should be.

But here is a different situation:
When I press 1,1,2 OR record a macro 1,1,2 using protocol 001C for SharpTV, IRscope reports Denon 2 frames, followed by Denon with blank. Basically two lines come out of DecodeIR while I expected three.

So since, maybe, the Denon/Sharp signal is such due to its second half image, that the first half of the second 1 in the macro is not seen as a new signal in spite of the silence in between??
Pics and IRscope files for 1,1,2 macro and 1,1,2 from the keyboard
https://www.hifi-remote.com/forums/dload ... le_id=7319

Sure hard to distinguish these two, as CapnTrips pointed out numerous times. This from DecodeIR.htm:
Denon
IRP notation: {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+
EFC translation: LSB
Sharp
IRP notation: {38k,264}<1,-3|1,-7>(D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)+
EFC translation: LSB

My drift here is not Denon vs Sharp, That's CapnTrips' territory . Just how many lines I get reported at this time.

[mathdon]

Your worst nightmare is back

You're not my worst nightmare, you're my best friend on this. Really and truly. I want it thoroughly tested and any nasties reported so that I can deal with them.

Now to your issue. DecodeIR doesn't look at the silence in between - it sees it no differently than as a lead-out. So a protocol in which repeats send identical frames is seen as the same, whether the repeat is generated by holding the key down or pressing it a second time. In v2.36 each frame would have caused a separate line, in v2.38 they are counted and reported as "x frames". I'm actually surprised that a real JVC{2} signal distinguishes two separate keypresses. I've just tried it and it added the frames. JVC is different, because the first frame is distinctive.

So what you are seeing is what I expect. But I will look at whether I can do something about it, based on the length of the lead-out. I will also see if I can refine the Denon/Sharp distinction.

Please try Beta 6 and let me know if you are happy with the "no repeat" entries it should give.
_________________
Graham

[ElizabethD]

No repeat is there. Nice. Thank you!
That's considerably less ambiguous.
I still wonder what Rob will think of these changes in display.
He can get everything he needs, I think, in three ways in IR of course, but sure would be nice to get some feedback here. I know I'm slanting it some way not even knowing what's needed or not.

[mathdon]

DecodeIR.dll v2.38 Beta7

There is now a new DecodeIR version for testing, v2.38 Beta7. I have not posted it separately, but it is included in the package for IR 8.01 RC8.

The changes are to meet Liz's issues. I had not been aware of the subtleties in the Denon/Sharp protocol until I saw her IRScope pictures. I have now made the following changes:

1. Repeat keypresses of the same button in the Denon/Sharp protocol should now always show up as separate entries in IRScope. (That uses specific features of the protocol.)

2. Repeat keypresses of the same button for any protocol will show up as separate entries if the gap between the signals is more than 200ms. This figure seems a reasonable compromise between longish leadouts (the maximum duration the learning software of UEI remotes can store is about 130ms, and some lead-out times get close to that) and fast repeat keypresses. It is possible to beat 200ms if you are quick off the mark, and if so, and if the protocol has identical repeat frames, then they will get combined into a single entry with "x frames". I cannot see how that can be avoided.

A couple of other notes. Liz also wrote

I still wonder what Rob will think of these changes in display.
He can get everything he needs, I think, in three ways in IR of course, but sure would be nice to get some feedback here. I know I'm slanting it some way not even knowing what's needed or not.

The displays of "x frames", "x dittos" and "no repeat" are suppressed in IR.exe and RMIR so there is little change in those apps other than an increased resistance to spurious extra decodes being displayed. So I hope Rob is not concerned.

On the Denon/Sharp distinction, Liz, it sure is difficult to distinguish them. Your TV may be Sharp but the protocol showing up on your IRScope signals was definitely Denon according to the IRP entries you quoted!

Liz, I hereby appoint you Official DecodeIR Tester. Seriously, when you are happy with it then I will make it a general release. But please do look for bugs, oddities, infelicities and the like, as I would like v2.38 to be a good and stable version that will last for some time.
_____________
Graham

[Tommy Tyler]

Graham,

I've been following this thread casually because I'm not actively engaged in any IR activity. While working with Liz on another subject today, I pointed out that certain Dish remote commands in one of her special protocols were being repeated five times minimum for a single key press, and also five times for each iteration in a repeating macro we were considering. When I suggested this was excessively redundant Liz made one simple change to the special protocol code to reduce it from five to three, and I confirmed it using the Widget.

Then it occurred to me that it was sometimes useful to use the Widget to find out how many times a signal was repeated, and I began to wonder if the changes you've been working on spelled an end to that. You know, one man's superfluous data is another man's treasure. So I downloaded DecodeIR.dll version 2.38 to see what the IRScope data would look like, and encountered a much more serious problem. I was unable after many repeated attempts to get IRScope to respond to a capture when 2.38 was used instead of my old (version unknown, but probably a couple of years old) copy of the dll.

Have you tried using 2.38 with the Widget? I realize that compared to IR, the Widget is just a "hanger on" as far as DecodeIR compatibility is concerned, and so can't stand in the way of progress. On the other hand, it would be nice if the Widget could benefit from the latest advances in DecodeIR if that were possible, but I don't know who is best suited to achieving that, you as the current maintainer of DecodeIR, or Kevin Timmerman, the author of IRScope.exe. I'm trying to decide if the best that can be done for users of the Widget is to advise them to use an obsolete version of DecodeIR and make do the best they can.

Tommy

[mathdon]

Tommy, I've no idea what your problem can be. The changes and new features in DecodeIR v2.38 are entirely for the benefit of IR Widget with IRScope. It's what all my testing (and Liz's, I believe) is done with, and it is what is driving that development. Then just a final check that I haven't messed anything up for IR.exe and RMIR.

Is there possibly a later version of IRScope than you are using? Every Beta version of DecodeIR I have produced has been tested with IRScope. If you've checked that there isn't a later IRScope, please tell me what Windows version you are using. There has been one issue that seemed to show up only on Windows 2000, so it is not impossible that there is a problem specific to a particular Windows version.

Failing that, I will post a version of DecodeIR 2.36 (the 2007 version) compiled with my compiler, to see if it is compiler-related. For some weird reason the Win2K-only bug showed up when compiled with my compiler (MS Visual C++ 2008) but not with John's original compilation that used an earlier version of MS Visual C++, despite the bug being present in the source code all along.

Do you get any sort of error message or does it just fail to capture?
______________
Graham

[vickyg2003]

it has been my experience that if a signal doesn't decode, the irscope will be blank, no matter which version of decodeIR.dll is used.

[mathdon]

Vicky, Liz and anyone else using DecodeIR.dll v2.38 Betas with IR Widget and IRScope, could you please say what version of Windows you are using, just so I know what it has been tested with. I use Vista. I have an old Win2K machine that I haven't used the Widget with, but I will do so to check that, too.
____________
Graham

[Tommy Tyler]

I've been afraid my problem might be self-induced, but I've tried just about everything except a fresh download of 2.38 to rule out a corrupted file. And the symptoms look more like broken software than hardware problems.

For my final tests I put just three files in a folder to minimize variables, IRScope.exe and an old and new (2.38) version of DecodeIR.dll. I alternately disabled one or the other dll (by renaming it) and tried using the Widget. Each time with the old dll it worked nornally. Each time with the new dll here's what happens:

IRScope opens normally, and I can select the COM port. If I click on Capture! and let it time out with no data I get the usual error message "No data received from IR Widget". If I click on Capture! and transmit a signal, at the end of Capture Duration an empty IRScope window pops up and hangs forever with an hourglass. After a bit the Main IRScope window also turns completely blank and adds the words "Not responding" in the title bar. When you get tired of waiting and close either window you get the standard Windows message "End program - IRScope This program is not responding . . ."

[vickyg2003]

I use win2k. Let me clarify what I said above. In my quest to learn how protocol builder works, I write A LOT of protocols that don't decode. When they don't decode, I work with the raw timings from my ICT file. The protocol doesn't display in the IRScope window, and I wouldn't expect that it would.

Tommy wrote:
I realize that compared to IR, the Widget is just a "hanger on" as far as DecodeIR compatibility is concerned, and so can't stand in the way of progress. On the other hand, it would be nice if the Widget could benefit from the latest advances in DecodeIR if that were possible, but I don't know who is best suited to achieving that, you as the current maintainer of DecodeIR, or Kevin Timmerman, the author of IRScope.exe.

Tommy and Kevin, you should know that Graham, Elizabeth and I are all Widget users. The Widget is more than just a "hanger on" to us, and we'll make sure that decodeIR continues to work with the Widget..

[vickyg2003]

I've tried just about everything except a fresh download of 2.38 to rule out a corrupted file. And the symptoms look more like broken software than hardware problems.

With as FLAKEY as the server has been in recent days, a fresh download is exactly where I'd start. I've had 3 corrupted downloads this week, while the server was so sloooooowwwwww.

However, if that is not the case, my second guess would be a data specific error. If that's the case, we'll need data, and fortunately you have one version that works so we can get that information from your working version.