So you're telling me there is a bug in DecodeIr.
Please give me an .ir file containing a few of the learned signals that decode as NEC2 but are really NECx2, so I can diagnose and correct that bug.
To send that file: Use email if you like (see my profile here or at RC). Or post in one of the diagnosis folders and post or email the URL.
JVC TH-A5 DVD/Audio system
Moderator: Moderators
I discovered that I had intentionally avoided using the obvious direct test to distinguish between NEC and NECx.
NEC is much more common than NECx and bad learns of NEC fairly often have the distinguishing characteristic of NECx. If the decoder used the obvious distinction then an unreasonably large fraction of the NECx decodes in my large collection of learned signals are actually bad learns of NEC. That would cause lots of confusion.
Instead I used a dumb kludge that doesn't get it right very reliably, but doesn't cause as much confusion.
I just changed it to a more complicated kludge, that still doesn't get NEC vs. NECx right very reliably, but has some advantages and still doesn't mislable a massive number of NEC's as NECx's.
At some later time I'll try to improve it further.
NEC is much more common than NECx and bad learns of NEC fairly often have the distinguishing characteristic of NECx. If the decoder used the obvious distinction then an unreasonably large fraction of the NECx decodes in my large collection of learned signals are actually bad learns of NEC. That would cause lots of confusion.
Instead I used a dumb kludge that doesn't get it right very reliably, but doesn't cause as much confusion.
I just changed it to a more complicated kludge, that still doesn't get NEC vs. NECx right very reliably, but has some advantages and still doesn't mislable a massive number of NEC's as NECx's.
At some later time I'll try to improve it further.
Ok. So on the whole - if someone learns 10 NEC signals that are predisposed to badness (is that the OEM remote, Learning remote or tecnique at fault?) will they get all NECx2 or a mixture of both.
If they get both then Mark might make a note to suggest trying NEC or NECx2. Where I'm going is that unless it's decoded 100% unreliably then near enough may be good enough.
If they get both then Mark might make a note to suggest trying NEC or NECx2. Where I'm going is that unless it's decoded 100% unreliably then near enough may be good enough.
Moving the original remote at the moment you press its button during the learning process is the best way to mislearn an NEC to look a lot like an NECx, and a lot of people do that.
I didn't release the simple code that would have called all those mislearns NECx. Almost all of those are still correctly guessed as NEC.
NECx1's would be easy to distinguish IF the user held the key long enough to capture the repeat pattern. Otherwise they're at moderate risk to just say "NEC", which is supposed to mean too short a learn to tell NEC1 from NEC2.
Various other learning flaws convert a very few NEC's to misreport NECx and a somewhat larger fraction of NECx's as NEC's. The latest version misdecodes a very different set of NECx's, but not a significantly smaller set.
A set like the signals in this thread will no longer all misdecode. So a user who understands things will see a mix of NEC and NECx decodes and be able to use some judgement. That doesn't help a beginner much.
I still think I need to make the decoding of problem signals smarter. Till then, I might improve DecodeIr's documentation for the problem cases, but no one seems to read it.
I certainly don't think IR.EXE should pop up messages to explain flaws in DecodeIr. The two are not kept in good enough sync, even if Mark thought it was worth his time.
I didn't release the simple code that would have called all those mislearns NECx. Almost all of those are still correctly guessed as NEC.
NECx1's would be easy to distinguish IF the user held the key long enough to capture the repeat pattern. Otherwise they're at moderate risk to just say "NEC", which is supposed to mean too short a learn to tell NEC1 from NEC2.
Various other learning flaws convert a very few NEC's to misreport NECx and a somewhat larger fraction of NECx's as NEC's. The latest version misdecodes a very different set of NECx's, but not a significantly smaller set.
A set like the signals in this thread will no longer all misdecode. So a user who understands things will see a mix of NEC and NECx decodes and be able to use some judgement. That doesn't help a beginner much.
I still think I need to make the decoding of problem signals smarter. Till then, I might improve DecodeIr's documentation for the problem cases, but no one seems to read it.
I certainly don't think IR.EXE should pop up messages to explain flaws in DecodeIr. The two are not kept in good enough sync, even if Mark thought it was worth his time.
well, I'm a beginner and I worked it out. 
for anyone who comes after me:
Here is my complete JVC TH-A5R device upgrade
for anyone who comes after me:
Here is my complete JVC TH-A5R device upgrade