JP1 Remotes

[mathdon]

I have posted Version 2.40 of DecodeIR.dll in a package that includes the equivalent 32-bit and 64-bit Linux libraries. My thanks to Bill Marr (WagonMaster) for providing the Linux compilations.

The main change from version 2.39 is that handling of the XMP protocol from learned signals has been substantially improved. Correction routines have been added to resolve common problems of corruption that the learning of XMP signals often causes. The Russound protocol has been renamed DirecTV to align with RemoteMaster and its decode now reports the Parm parameter used by RemoteMaster to select options within this protocol. Decodes of the Grundig16 protocol now recognise two frequency variants. The name Grundig16 has been retained for the 38kHz version (PID=0112), the 30kHz version has been named Grundig16-30 (PID=00AB).

The source code of DecodeIR v2.40 is available here.
________________

Graham

[Barf]

There is a bug in the decoding of Nokia12, causing erroneous device- and obc-numbers to be returned. This fix (against 2.40 sources) appears to work:

[mathdon]

I forgot this fix when putting together the package for IR 8.03 Beta 5, which includes DecodeIR 2.41 Beta 4. It will go into 2.41 Beta 5.
______________
Graham

[info_dan]

Hello, complete newbie to JP1 forums and the tools here with what may be a stupid question.

I wanted to be able to see the codes sent by my Harmony remote to double-check what Logitech really has in its database.

Hooked up an IR receiver to my parallel port (separate +5V power supply, used status pin 13, data pin 9 did not seem to work).

I am using DecodeIR 2.40 with CaptureIR Prototype 12 Build 1. Overall, it seems to work great, thanks for making this available!

However, there seems to be a problem in the Hex Cmd decoding of the Nec protocol. Here is the raw signal I get when pressing cursor left on my display remote:

8613 -4117 661 -403 660 -1477 642 -420 641 -1458 685 -398 666 -1451 668 -394 668 -1450 668 -1451 667 -394 667 -1453 667 -396 665 -1452 668 -396 667 -1451 668 -394 668 -1450 667 -395 668 -1451 667 -395 668 -395 667 -1452 667 -394 668 -394 668 -394 667 -1451 668 -393 668 -1451 668 -1453 666 -394 668 -1452 666 -1451 668 -25796 8686 -4065

When decoding the raw bits, here is my interpretation:

0 1 0 1 0 1 0 1 => 10101010 => 0xAA = 170
1 0 1 0 1 0 1 0 => Inverted data ok
1 0 1 0 0 1 0 0 => 00100101 => 0x25
0 1 0 1 1 0 1 1 => Inverted data ok.

So the device code should be 0xAA, and the command 0x25. This matches the Pioneer IR code list which states that cursor left is AA25.

CaptureIR shows Protocol NEC2 and device as 170, but the Hex Cmd given is 5B (OBC is 37, EFC is 216, in case it means anything)

Am I misunderstanding the "Hex cmd" field?

Thanks in advance,

Dan.

[info_dan]

Ok, after looking at the code of DecodeIR, I think I figured it out. For NEC command, the decimal code number (37 in my example above) is in the OBC column, and the Hex Cmd contains the hex value of the inverted data, but in LSB=>MSB order.

Sorry for any inconvenience my post may have caused.

[The Robman]

Close but not exact. The hex data used by UEI remotes is not necessarily a representation of the IR signal, it's actually input data to an "executor" written in assembler.

When you translated your learned data into binary, you correctlydesignated the short off time pairs to be ZEROES and the long off time pairs to be ONES. But, UEI typically gets this backwards, which is indeed the case with the NEC executor, so you have to invert the data when you feed it into the executor.

Also, when you read back the binary, you read it the way it was intended to be read but UEI requires the data to be exactly how it's sent, which is why the binary is "backwards".

To use JP1 terminology, the NEC executor is LSB-COMP, the LSB part meaning that you have to read the binary backwards, and the COMP part meaning that you have to invert it.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[info_dan]

Thanks for the info. The issue is more that I'm using the tool for a different purpose than what it was designed for, and not being familiar with its context. Thanks for clarifying it a little.

For now, I can get the info I need, so I'm all set. Unless you know of another existing tool that would show me the remotes codes as they're "supposed" to be read?

Thanks!

Dan.

[johnsfine]

[The Robman]

Also, just FYI, the term as they're "supposed" to be read means different things for different protocols. The binary for some signals, like NEC, needs to be read backwards whereas the binary for others, like RC-5, does not. The command code is usually all in one place (ie, in a single byte of data) but in some protocols, like RC-5, it isn't (the MSB of the command is in a different byte of data).

So, regardless of what tool you use, if it converts the data into decimal numbers like device codes and command codes, you need to understand the protocol format in order to know what those numbers will look like in a binary format. Of course, that's assuming it's a binary protocol because we have quite a few that are base-4 (several), base-8 (XMP14) and even base-16 (XMP).

John has most known protocols documented on his web page here:
http://www.hifi-remote.com/johnsfine/

The syntax used to document the protocols is called IRP, which is fully documented here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7926

There is another document on IRP here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6996
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!