JP1 Remotes

The Robman wrote:

eferz wrote:This will allow it to be pasted into IR without requiring the tedium of adding the spaces manually.

In the meantime, I would recommend creating a spreadsheet with formula that inserts the spaces for you.

Ooo, I didn't realize Excel could do that. I'm not very well familiarized with Excel to write up such a formula.

eferz wrote:Here is how I differentiate between the type of learns.

Invalid Learn: A learn that fails to initiate the respective function on the device.
Dirty Learn: A learn which initiate the respective function but shows up with multiple matches in the JP1 tools.
Clean Learn: A learn which initiate the respective function and shows as a single protocol in the JP1 tools.

I would definitely agree with your statement if your definition of "invalid learns" were the same as mine. However, I believe your intimacy with technical aspect of remotes draws a portion of "dirty learns" into the "invalid learn" category. I hope my naivety of the subject doesn't automatically invalidate my disagreement.

A learn is encoded in the learned signal as a series of bytes, the ones you copied into the data window. That is an encoding of a series of durations, the "on" and "off" times of the IR lamp when the signal is sent. The encoding follows a set of rules. If the encoding does not follow those rules, it cannot be decoded back into the series of durations it is supposed to represent. Your faulty signal did not follow those rules. It is therefore in a different category from any of your three, all of which apply to the series of durations, not to their encoding in the learned signal. Perhaps a better description than "invalid" would be "faulty" or "erroneous". Whatever you may wish to call it, it is different from any of your categories, and is worse than any of them in that the series of durations cannot even be properly reconstructed - quite separately from whether it works or not.

Whether IR.exe or RMIR should attempt to interpret the part of the signal it decoded before it reached the faulty part is a separate question.

Or use that VB tool I uploaded, which does exactly that

alanrichey wrote:Or use that VB tool I uploaded, which does exactly that

I'd love to use your tool. Did you ever update it to parse xml files in addition to the log files? I've been primary using the {GUID}.xml files to test these features.

The Robman wrote:In the meantime, I would recommend creating a spreadsheet with formula that inserts the spaces for you.

I tried to hack together a spreadsheet to do it for me. It works, its just really ugly due my ineptitude with Excel. https://www.hifi-remote.com/forums/dload ... le_id=8892

I feel like someone who pipes cat into grep.

mathdon wrote:A learn is encoded in the learned signal as a series of bytes, the ones you copied into the data window. That is an encoding of a series of durations, the "on" and "off" times of the IR lamp when the signal is sent. The encoding follows a set of rules. If the encoding does not follow those rules, it cannot be decoded back into the series of durations it is supposed to represent. Your faulty signal did not follow those rules. It is therefore in a different category from any of your three, all of which apply to the series of durations, not to their encoding in the learned signal. Perhaps a better description than "invalid" would be "faulty" or "erroneous".

Alright, I accept your definitions but can we then change the verbiage in the Learned tab from "none" to "faulty" or "invalid"? "None" is misleading since the learn is there, but its RMIR which is giving up on decoding it. This really does sound like RMIR is throwing out the baby with the bathwater.

mathdon wrote:Whatever you may wish to call it, it is different from any of your categories, and is worse than any of them in that the series of durations cannot even be properly reconstructed - quite separately from whether it works or not.

Whether IR.exe or RMIR should attempt to interpret the part of the signal it decoded before it reached the faulty part is a separate question.

There's no question about IR.exe, since early on this thread you've already proclaimed to cease development for it. Besides, I'm not having a problem with IR.exe. Just the opposite in fact since IR.exe is consistently able to provide the necessary information when RMIR fails. Hence the reason why I'd like to have the option to have the reformatted UEI string placed into the clipboard.

The Robman wrote:I'm always an advocate of more info, rather than less, so my vote would be to decode the signal as best as you can, and report the error, rather than doing nothing as soon as an unexpected value is encountered.

At this point since the matter is still up for debate, I'd like to concur with Rob and toss and my vote too.

While I don't have a problem using IR.exe, this current methodology is going against the Sourceforge description for the project, "This project's goal is to replace and extend the JP1 software. The ultimate goal is to combine the function of IR and the KeymapMaster Excel spreadsheet into a single application." It's just seems a little counter-productive if the intention is replacing IR.exe with RMIR, while also reinforcing the need for IR.exe in these situations.