JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

DecodeIR version 2.40

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3303
Location: Cambridge, UK

PostPosted: Sat Feb 06, 2010 10:33 am    Post subject: DecodeIR version 2.40 Reply with quote

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


Last edited by mathdon on Wed Jul 07, 2010 6:25 am; edited 1 time in total
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1026

PostPosted: Sun Mar 14, 2010 3:19 pm    Post subject: Reply with quote

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:

Code:
*** DecodeIR.cpp.orig   Sun Mar 14 18:29:52 2010
--- DecodeIR.cpp        Sun Mar 14 21:18:18 2010
***************
*** 3493,3500 ****
        if ( nFrameL == 8 )
        {
                strcpy(pProtocol, "Nokia12");
!               *pDevice = getLsb(0,4);
!               *pOBC = getLsb(4,8);
        }
        else
        {
--- 3493,3500 ----
        if ( nFrameL == 8 )
        {
                strcpy(pProtocol, "Nokia12");
!               *pDevice = getMsb(0,4);
!               *pOBC = getMsb(4,8);
        }
        else
        {
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3303
Location: Cambridge, UK

PostPosted: Wed May 05, 2010 8:28 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
info_dan



Joined: 25 May 2010
Posts: 3

PostPosted: Tue May 25, 2010 7:23 pm    Post subject: Bug in DecodeIR 2.40 or in my understanding? Reply with quote

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.
Back to top
View user's profile Send private message
info_dan



Joined: 25 May 2010
Posts: 3

PostPosted: Tue May 25, 2010 7:30 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19460
Location: Chicago, IL

PostPosted: Tue May 25, 2010 10:06 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
info_dan



Joined: 25 May 2010
Posts: 3

PostPosted: Wed May 26, 2010 7:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Wed May 26, 2010 8:11 am    Post subject: Reply with quote

info_dan wrote:
Unless you know of another existing tool that would show me the remotes codes as they're "supposed" to be read?


The device number and OBC for this protocol (and almost all others) are the codes as they're supposed to be read.

The Hex cmd and EFC are tied to internal details of the UEI universal remotes in a way that varies by protocol. It sounds like you are using the tools for a purpose for which hex cmd and efc are best ignored.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19460
Location: Chicago, IL

PostPosted: Wed May 26, 2010 9:05 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central