irdb.tk uses the same engine as IrScrutinizer, so in a way I am guilty for both :-).
My intuition says that the first message refers to two parameter NEC1 form, i.e. with subdevice default, i.e. 255-device. In IrScrutinizer you can just leave S blank; in irdb.tk you have to enter it explicitly. Bottom line: NEC1 128 127 5.
The vendor tries to help, but it sees that he cannot describe the used signals in a universally understandable language. What mdavej and I tied to do was to *guess* what was meant, and you claim that both guesses were wrong. There are discussions on the internet that are equally unclear, like [Link: head-fi.org]
Do you have any possibilities to analyze or "learn" the codes? IrScrutinizer supports several different learning devices. Or you can possibly use a learning JP1 remote or a Pronto?
The "sensor" I like most is of course my own "baby" [Link: harctoolbox.org]. But there are may other things that work well with IrScrutinizer, see the manual.
As I mentioned in the previous post, you can also use a JP1 learning remote or a Pronto to capture the signals and then transfer them to a computer using a suitable cable. But there is a leaning curve...
I'm not exactly sure of what you are asking, but every signal was captured/scrutinized with IrSrutinizer?
The remote that came with the amplifier is a very modest one: [Link: tinyurl.com] For instance when pressing "Vol-" you sometimes get the function of "Ana3". Also when capturing with IrSrutinizer I get different results every time I press the same button.
Ok, then I guess my post was quite confusing... Sorry for that.
You probably captured the signals in "raw" mode. This is only in rare occurrences a sensible thing to do. All physical measurements, not only the capturing of IR signals, are associated with measurement errors. This is unavoidable, and a fact of life.
Instead, you should (normally) capture in "parametric" mode. Then IrScrutinizer identifies the signals as belonging to a certain protocol (here NEC1), and replaces them with the computed, mathematically exact representation. Using these instead of the measured ones leads to a more reliable and robust system. We have thus eliminated the measurement errors. If you need for example the Pronto Hex, it can be generated during export. And there will be no "0015".
I get it - on a philosophical level, and now also in using your application. Though I still haven't got the slightest clue as to how a mathematical exact representation of an infrared signal becomes exactly that. But spare your time. This isn't my field. I'm just a humble user relying on your expertise.
Here are my results after capturing in parametric mode: [Link: drive.google.com]
Even though I, as I stated above, do not understand it, it seems more consistent and pleasant to the eye :)
Let me just add that using clean codes is not just theoretically cool, in practice it really makes the system more reliable. When the receiver (in the to-be-controlled device) receives the signal, there are again measurement errors. If using unclean codes, you are actually adding two measurement errors...
Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.