JP1 Remotes

DecodeIR.dll v2.38 Beta8

I have posted DecodeIR.dll v2.38 Beta8. This corrects the bug in Beta7 that caused it to lock up with Dish protocols (and probably other non-robust protocols, too).

I have tried hard to break this version and failed miserably. I also cannot provoke it into giving any spurious decodes with the Dish protocols that were causing the problem. Please give it a good working over and tell me how you find it.
_______________
Graham

It works for me.

Tommy

Beta8 works nicely here as well.

Graham, Just FYI, I have a macro which uses one or two Panasonic protocols, GI cable and JVC protocols. That macro was also crashing IRscope under Beta7.

Thanks, Liz. I take it the macro no longer crashes with Beta8.

I was serious about waiting for your OK before promoting Beta8 to an official release, as you are giving it a more thorough test than me, or anyone else as far as I can tell. So when you are happy, say so and I will make it official.
________________
Graham

Correct, no crashes even with all below stuff. I cannot be the judge FGS!!

mathdon wrote: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.

That's an evil thing to suggest
But YOU asked for it. Few things for your collection:
https://www.hifi-remote.com/forums/dload ... le_id=7352
I used different methods for different things, depending what I have or not have.
Far as I'm concerned, no action on your part needed. All that follows is mostly FYI.

(1) I ran through many of my IR learning files (by 8910), loaded them into 8910, and sent signals out to Widget/IRscope.
All Panasonic, Panasonic2, JVC, Denon, Samsung HT, Proscan VCR, Sony box with 5 variation (12,17,13,20), Aiwa - all signals match the spot checks against various upgrades I did.
Graham,You have a device that sends only JVC{2}. I have a learning file (Tv in a local store) from a Polaroid TV. JVC{2} as well. Apparently Mitsubishi upgrade works this TV. I don't have it, I don't care.

(2) I ran through several OEM remotes I have and sent signals directly to Widget
Panasonic, JVD, Philips, RC6 protocol, Denon several devices, Aiwa several devices, and you know about JVC before. Nothing to report here. All seem ok, spot-checking expected values.

(3) Then I read DecodeIR to see which protocols might be more difficult than others (I really do not understand most of it, so it's a blind fishing expedition over John's amazing work).
There are many. So I selected just tiny few, attempting to match what my 8910 has in the user guide for setup codes(they speak no protocols, sorry). I setup the remote, confirmed on the LCD that I got the right thing, and sent few signals from each of these to the Widget:
- X10 protocol setup 0167 for home automation is not decoding at all Irscope is blank(included in zip)
- GE/0240 for home automation uses NEC1 - looks ok, unless NEC1 is wrong
- RadioShack SAT/0869 uses GI4DTV protocol - decodes, but has non GI lines (included in zip 2x)
- Pace CBL/0237 uses pid0237 - RC5 - likely ok, a very difficult list for me to understand (included in zip)
- Jerrold CBL/0003 uses Jerrold protocol, also Recs80 is reported (included in zip)
- Proton TV/0178 uses Nec1 protocol, likely ok.

OT: When you have nothing to do - Also in this zip is an old IR file of mine from learning a fancy $65000 or $6500 office Panasonic projector codes, to be controlled by a $20 remote mind you...
It's included just as a curiosity item. This projector uses a very looooong Panasonic2 protocol (all decodes correct of course), and some other phase-type, keyboard(?) codes for a computer or mouse interface, or something similar, possibly serial RS232 signals. No need to decode or sweat over it. IR file shows some results. Widget shows nothing which is the ONLY reason I include this file for your collection.

If YOU or ANYONE else wants me to IRscope some specific things (proton, matsui, archer,sampo,thomson,viewstar...), I'm willing to do it. But the easiest thing for me is to use setup codes (protocols unknown!) in the 8910 manual because the LCD displays the setup code I use so no errors on my part possible.

ElizabethD wrote:I cannot be the judge FGS!!That's an evil thing to suggest ...
But YOU asked for it. Few things for your collection:

Many thanks, Liz. I haven't had time to digest it all, but it is lovely to have such thorough testing. As for being the judge, someone has to do it and it is usually better for the roles of judge and accused (me - when things go wrong ) to be separated. I think you've given your verdict - a qualified "not guilty" - so after your great service to the cause, I will release you from the post of Official Tester.

ElizabethD wrote:Graham,You have a device that sends only JVC{2}. I have a learning file (Tv in a local store) from a Polaroid TV. JVC{2} as well. Apparently Mitsubishi upgrade works this TV. I don't have it, I don't care.

Not quite. I have an OEM remote from a defunct JVC VCR that sends only JVC{2} signals, so JVC used such a protocol at some time. But as the VCR is defunct, I can't test anything with it. I'll have a look at the Mitsubish upgrade, though, and compare the protocols.

This is just a quick initial thank you. I'll look at your stuff in more detail later and report again.
________________
Graham

ElizabethD wrote:IR file shows some results. Widget shows nothing

I've just noticed this comment of yours, and it has reminded me that I've seen a few others recently about the fact that the Widget can show nothing when IR.exe shows some generic info.

The difference is that IR.exe has a default decoder built in that always returns something, even when it can't decode a signal properly. When DecodeIR can't decode, it returns an empty string for the protocol name. IRScope just takes this and displays nothing. IR.exe first passes the signal to DecodeIR, but when it gets that null return, it passes it to its own internal decoder, which won't succeed (as it is less competent than DecodeIR) but it will return some generic info.

I can't make DecodeIR return anything like "No success", since the apps that use it call it repeatedly until they get the null return. On each successive call, DecodeIR picks up from where it left off, so it might find another decode for the same signal (which is when IR.exe will report more than one decode) but if it doesn't it will move on to the next signal (giving the list that IRScope produces). Both rely on the null return to know when to stop trying.

Hope this explains the difference, if it was puzzling anyone.
______________
Graham

mathdon wrote:Hope this explains the difference, if it was puzzling anyone.

Yes it does. I now remember John mentioned several times over the years about the internal decoder, but I completely forgot about it.

When I was trying to dig out what setup codes to try for a protocol, I forgot a fabulous tool we have on this site - DecodeIR.xls... For future projects

Edit:
It's NOT DecodeIR.xls, it's DEVICES.XLS
dload.php?action=file&file_id=2039

ElizabethD wrote:When I was trying to dig out what setup codes to try for a protocol, I forgot a fabulous tool we have on this site - DecodeIR.xls...

Thanks, Liz, but I can't find DecodeIR.xls. Might you mean Devices.xls, which also serves that purpose and which I too forgot about? But have you tried Vicky's fabulous new Lookup Tool - so fabulous it has been given its own spot in the menu that heads every page. That's what I used to check the PIDs used by the setup codes in your tests, and it is superb. But as Vicky emphasises, it is a work in progress, so I think that not all remotes yet have accurate device code lists. Either that, or I was using it wrongly, as the list for the URC-7781 is not correct.

The results of your tests have spurred me to further effort. I'm continuing my "search and destroy" mission for spurious decodes. If that makes John worried, it shouldn't do as I'm not doing it by tightening up timing margins but either by adding new checks that themselves have wide margins or through the "look ahead" facility that I have introduced that can see a possible spurious decode in the context of the "real" one.

When I've completed that, I will post a new Beta for you to check that it really has eliminated the spurious decodes in your tests. At that point I think we'll call it enough, and make a final release. I know Greg wants that, as he needs it for the next RMIR version.
_______________
Graham

Oh darn, I was hoping there was something called DecodeIR.xls. I really really wanted to find a new tool.

mathdon wrote:But have you tried Vicky's fabulous new Lookup Tool ... That's what I used to check the PIDs used by the setup codes in your tests, and it is superb. But as Vicky emphasises, it is a work in progress, so I think that not all remotes yet have accurate device code lists. Either that, or I was using it wrongly, as the list for the URC-7781 is not correct.

Thank goodness I put in that qualification "Either that, or I was using it wrongly", as I was using, or rather interpreting, it wrongly. I am happy to put the record straight and say that as far as I can tell, it is correct for the URC-7781.
_____________
Graham

DecodeIR.dll v2.38 Beta9 posted

I have posted DecodeIR v2.38 Beta9. Here is the story behind the changes.

ElizabethD wrote:Then I read DecodeIR to see which protocols might be more difficult than others (I really do not understand most of it, so it's a blind fishing expedition over John's amazing work).
There are many. So I selected just tiny few, attempting to match what my 8910 has in the user guide for setup codes(they speak no protocols, sorry). I setup the remote, confirmed on the LCD that I got the right thing, and sent few signals from each of these to the Widget:
- X10 protocol setup 0167 for home automation is not decoding at all Irscope is blank(included in zip)
- GE/0240 for home automation uses NEC1 - looks ok, unless NEC1 is wrong
- RadioShack SAT/0869 uses GI4DTV protocol - decodes, but has non GI lines (included in zip 2x)
- Pace CBL/0237 uses pid0237 - RC5 - likely ok, a very difficult list for me to understand (included in zip)
- Jerrold CBL/0003 uses Jerrold protocol, also Recs80 is reported (included in zip)
- Proton TV/0178 uses Nec1 protocol, likely ok.

Ooh, Liz, you have kept me busy these past few days! Thanks ever so much for this detailed testing as I really do want to get out any bugs, and also get rid of as many spurious decodes as possible. Here are my findings and doings:

1. GE/0240 and Proton TV/0178 do use NEC1 protocol, so no problem there.

2. Pace CBL/0237 does use RC5 and all is well here, too. T is a toggle and I think the U entry was put there by John just for diagnostic purposes. There are 3 hex values as this is a mini combo.

3. RadioShack SAT/0869. The spurious pid-0013 decode comes from the last two bursts of the G.I.4DTV signal. Yes, pid-0013 really does have a valid signal that has only two bursts! I've added a new framing test to pid-0013 that eliminates this spurious decode but does not upset real pid-0013 signals (tested!).

The Solidtek8 decode is more interesting. If you look at DecodeIR.html you will see that there is no such thing as a Solidtek8 protocol, only Solidtek16 and Solidtek20! John's code, however, will give decodes for SolidtekN for all values of N from 8 upwards in steps of 4, though they have no Device or OBC values. I presume this was in case new variants came to light. As the Solidtek signal has very weak framing, it was recognising a sequence of bursts entirely within the G.I.4DTV signal as a complete signal for Solidtek8.

I have adapted my look-ahead facility to spot any Solidtek decodes (except N=16 or 20) that come from bursts entirely within a valid signal for another protocol, and to reject them as spurious.

4. Jerrold CBL/0003. The RECS80 decoder was treating two frames of Jerrold as a single RECS80 frame, seeing the lead-out between the two Jerrold frames as a valid RECS80 burst as there was no test on the maximum burst length for RECS80. I have added such a test and this eliminates the spurious decode.

5. I've left the best till last. X10!!! My starting point was to accept that the UEI executor for X10, PID 003F, generates a signal acceptable to equipment that uses this protocol, though the timing details may not be identical with that of an OEM remote. John's code requires the first burst of an X10 signal to be the longest burst, though only by a little (nominally about 10%). The UEI executor, however, generates all bursts of equal length and variations in the IR engine mean that the first burst is, more often than not, not the longest. Hence no decode.

But this is by no means the end of the story. There are actually two types of X10 frame, both in John's code and in the UEI executor, but John's code treats the other one as having a lead-in burst that is missing in the UEI executor. This frame is sent only once, and it carries a serial counter N, value 0 to 15 cyclically repeating, that is incremented between keypresses. N is not carried in the normal (ie repeat) bursts. The missing burst means that this too is not recognised by the decoder.

Still not quite the end! RemoteMaster includes the X10 protocol with the true UEI executor code, but if you put the OBC values from DecodeIR (no hex is shown, so there is no choice on what to use) into RM, not only does it not give the correct signal, the signal it gives isn't even a valid X10 signal at all! Greg needs to add the following lines into the X10 entry in protocols.ini:
DecodeIR v2.38 Beta9 should remove all the spurious decodes found by Liz. The X10 decoder now gives a hex value as well as an OBC and it agrees with that created by RM with the above addition to protocols.ini. A complete X10 signal will now show up with name X10:N, where N is the counter value (eg X10:7 for N=7). I've updated DecodeIR.html accordingly, and this is also in the package.

The changes were more extensive than I had anticipated. I don't think I have introduced any new bugs as a result, but I would be most grateful if Liz in particular, and anyone else interested in doing so, could give it a final checking over. I will deal with any bugs that are found, but I think we'll call a truce in the search and destroy mission on spurious decodes for the time being, as I suspect it could go on for ever! I would still like to be told, however, for future development, of any that arise other than from poor-quality signals. I have dealt with all the ones of which I am currently aware.

________________
Graham

We gotta keep you busy somehow

Graham,
I'm concerned a bit about one thing. When I test what 8910 puts out or 7800 I'm not checking the real thing, that being OEM remote signals, as is the case with the group you quoted. When I do a real OEM remote I have no problem, but also have no such thing as X10 in house.

John's code requires the first burst of an X10 signal to be the longest burst, though only by a little (nominally about 10%). The UEI executor, however, generates all bursts of equal length and variations in the IR engine mean that the first burst is, more often than not, not the longest. Hence no decode.

I would think somebody with a X10 control might provide TRUE information. I do know that UEI collects burst pairs, evens out the signals, and their timing interpretation for output might be different than what John saw from real remotes. I'd hate to see you hassle with a long X10 leadin when it's already a remanufactured thing. Am I wrong? Why or why not.

I'll do few more.

ElizabethD wrote:I would think somebody with a X10 control might provide TRUE information. I do know that UEI collects burst pairs, evens out the signals, and their timing interpretation for output might be different than what John saw from real remotes. I'd hate to see you hassle with a long X10 leadin when it's already a remanufactured thing. Am I wrong? Why or why not.

Yes, I know you are testing against UEI rather than OEM remotes. I think it is important that DecodeIR can recognise both OEM signals and UEI's "remanufactured" ones.

There are two issues about the X10 protocol. One is the main (ie repeating) frame, where John was requiring the first burst to be the longest. I've made sure that what I have done will make it recognise both the UEI timing and the timing in John's code and his IRP notation. The only possible side effect is that it might now appear as a spurious decode in situations where it would not have done before (due to removal of that first burst test) but I think the structure of the data makes that unlikely.

The other issue is the start frame, where either John or UEI is wrong. I've gone with John being wrong, since it looks like a late addition as he hasn't included this start frame in his IRP notation. I think a user of an OEM X10 remote whose main frames were recognised, and so who got a valid decode, would not be aware that there was a distinct start frame that "should" have been decoded separately. They would have seen "one signal, one decode", exactly as one would expect, so no-one would have reported a problem. They will still see "one signal, one decode" with my changes, as my look-ahead combines the two decodes into one.

It would certainly be nice if someone with an OEM X10 remote would provide learned data, and/or test it against Beta9, as I would like to know the truth about that start frame and to be able to write an IRP that reflected the OEM signal accurately. As things are, I've changed the IRP notation in DecodeIR.html to follow the UEI signal, since John's IRP was incomplete.

I hope this allays your concerns. Many thanks once again for the continued testing.
________________
Graham