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

Questions regaring the decoding of an IR signal

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> Non-JP1
View previous topic :: View next topic  
Author Message
Shadowsoul



Joined: 21 Jul 2010
Posts: 2

PostPosted: Wed Jul 21, 2010 7:10 am    Post subject: Questions regaring the decoding of an IR signal Reply with quote

Hello all, I hope someone can help me a bit with an issue I'm having.

I have recently built an IR receiver for USB (the USB IR Toy from DangerousPrototypes) and want to use it in conjunction with my Pioneer KURO Remote to control my mediapc.

The IR Toy only supports RC5 out of the box so I am trying to modify either the firmware or the driver to decode the Pioneer protocol.

If I look at the raw data supplied from the IR Toy in a logic analyzer I notice the pattern described by the specification (i.e the IR-receiver gets 10 1000 10 1000... etc which if I understood the IRP-specification should in the end be translated to 0101... ).


However when I try to visualize the signal as string of 1's and 0's it looks nothing like the protocol at all..it has stuff like 7 0's and 8 1's in a row in the middle of the transmission.

My questions thus is:
1. Is there a detailed description of the IRP specification somewhere? THe NEC2 IRP is {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ which i undestand it as 38.4khz, 564us pulses, 10 is a 0, 1000 is a 1, 16 1s is the beginning of signal...
I assume the -8 means it's part of the start signal, D: means 8 bit device, F: should be function? But what about the S: and the ~F: (one's complement of function code?)...
2. Is it even possible to to what I try to do? (convert the raw stream to a byte array)
3. If the above is possible, can the timing in the microcontroller that interprets and retransmits the IR-signal be an issue if it's not synced to the 564us that NEC uses?
4. Can i use the DecodeIR dll to decode the signal on my PC?

And as a side not, does anyone know what kind of license the DecodeIR is under? It would be great if i could use the decoding of it in the IR Toy firmware itself but I don't want to violate the license.


Thanks for any suggestions/pointers towards more information!

/Shadowsoul
_________________
Happy amateur
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7055
Location: Florida

PostPosted: Wed Jul 21, 2010 7:38 am    Post subject: Re: Questions regaring the decoding of an IR signal Reply with quote

Shadowsoul wrote:
However when I try to visualize the signal as string of 1's and 0's it looks nothing like the protocol at all..it has stuff like 7 0's and 8 1's in a row in the middle of the transmission.

My questions thus is:
1. Is there a detailed description of the IRP specification somewhere? THe NEC2 IRP is {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ which i undestand it as 38.4khz, 564us pulses, 10 is a 0, 1000 is a 1, 16 1s is the beginning of signal...
I assume the -8 means it's part of the start signal, D: means 8 bit device, F: should be function? But what about the S: and the ~F: (one's complement of function code?)...
/Shadowsoul


I had a really hard time visualizing signals, and understanding IRP too. When I finally was able to understand it I wrote this document
Infrared Protocol Primer

I hope this helps you with the IRP.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


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

PostPosted: Wed Jul 21, 2010 8:02 am    Post subject: Reply with quote

It would help to set some terminology rules for this discussion as you seem to be using 1s and 0s to represent both the ON and OFF times and the logical ONEs and ZEROs found in binary. Let's just use 1s and 0s for the binary stream.

The RC5 protocol is a bi-phase protocol, which means it's burst times are constant and it reverses the pair for a ZERO. So for RC5, a logical ONE is ON-OFF, and a logical ZERO is OFF-ON.

The Pioneer (NEC) protocol is a Pulse Width Method (PWM) protocol, so it's pairs are always in the ON-OFF format, and it uses different burst times for the logical ONE and ZERO pairs. It's pairs are approximately:

1 = +564 -1692
0 = +564 -564

(The positive notation refers to the ON time, the negative to the OFF time).

The carrier frequency for NEC signals is 38kHz, but for Pioneer signals it's 40 kHz.

Looking at the NEC2 IRP:
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+

This tells us that the carrier freq is 38kHz and the time for a single burst is 564uS.

The next part tells us that a logical ONE is +564 -1692 and a logical zero is +564 -564

The "16,-8" says that there is a leadin pair where the ON time is 16 units of 564 (ie, 9024) and the OFF time is 8 units of 564 (ie, 4512).

The "D:8,S:8,F:8,~F:8" part tells us that there's an 8 bit device code, followed by an 8 bit sub-device code, followed by an 8 bit function code, followed by an 8 bit complement of the function code (ie, the 1s and 0s are inverted).

The "1,-78" part tells us that there is a leadout pair where the ON time is 564 and the OFF time is 78 units of 564 (ie, 43992).

The fact that all that is wrapped in parens followed by a + sign tells us that the entire signal repeats when the remote button is held.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Wed Jul 21, 2010 7:50 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


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

PostPosted: Wed Jul 21, 2010 8:13 am    Post subject: Re: Questions regaring the decoding of an IR signal Reply with quote

Shadowsoul wrote:
If I look at the raw data supplied from the IR Toy in a logic analyzer I notice the pattern described by the specification (i.e the IR-receiver gets 10 1000 10 1000... etc


That is surprising. It would mean something (the IR Toy or the logic analyzer) is processing the input either with the knowledge that there are 564uS chunks, or somehow looking at the overall pattern to detect the chunk size.

Quote:
which if I understood the IRP-specification should in the end be translated to 0101...


If the 10 1000 10 1000 you describe is on the right time scale (about 564uS per sample) then you are correct that it would translate to data bits 0101.

Quote:
However when I try to visualize the signal as string of 1's and 0's it looks nothing like the protocol at all..it has stuff like 7 0's and 8 1's in a row in the middle of the transmission.


This is tricky to discuss because we are talking about 1's and 0's both on the signal sample scale and on the decoded data scale, so I don't know which you mean.

Quote:
10 is a 0, 1000 is a 1, 16 1s is the beginning of signal...
I assume the -8 means it's part of the start signal,


10 in signal sample scale is 0 in data scale.
1000 in signal sample scale is 1 in data scale.
111111111111111100000000 in signal sample scale is start of frame in data scale.

Quote:
D: means 8 bit device, F: should be function? But what about the S: and the ~F: (one's complement of function code?).


D is device, F is function, S is SubDevice, ~F is one's complement of function.

Quote:
2. Is it even possible to to what I try to do? (convert the raw stream to a byte array)


If you have a correct raw stream (if the IR Toy is either doing very little processing before you get control or is doing only correct processing) then you can decode the result.

Quote:
If the above is possible, can the timing in the microcontroller that interprets and retransmits the IR-signal be an issue if it's not synced to the 564us that NEC uses?


The 56uuS is an approximate (typical or nominal) value, not exact. When capturing a signal, you cannot simply sample on a fixed clock. You need to resync on the transitions. When transmitting a signal, you can simply work from an internal clock and that clock only needs to be approximately correct.

Quote:
4. Can i use the DecodeIR dll to decode the signal on my PC?


Yes.

Quote:
And as a side not, does anyone know what kind of license the DecodeIR is under? It would be great if i could use the decoding of it in the IR Toy firmware itself but I don't want to violate the license.


The original DecodeIR source I wrote was under a "do anything you want" license, including integrating with a closed source product if you wanted.

I think some of the work by others in DecodeIR is under a more formal open source license, but I'd need to check what is written in or with the latest sources to find out for sure.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Shadowsoul



Joined: 21 Jul 2010
Posts: 2

PostPosted: Wed Jul 21, 2010 3:05 pm    Post subject: Reply with quote

Wow, thanks for a ton of info. Time to wrap my head around it.

I managed to find the relevant source code for the clock in the IR Toy firmware, it seems to sample at 10KHz in raw mode which is the reason for too many bits when converting the ON/OFF-signal from the IR receiver to a byte array. It also explains why I see the correct wave form in the analyzer, what i thought was one long ON-period is actually multiple samplings that were all ON.
Have to fix that before I can make any more headroom, but throwing out all but every 5th bit in the result looks almost as it should.


Thanks for explaining the IRP notation in such detail, makes sense now.
_________________
Happy amateur
Back to top
View user's profile Send private message
johnsfine
Site Admin


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

PostPosted: Thu Jul 22, 2010 9:36 am    Post subject: Reply with quote

Shadowsoul wrote:
it seems to sample at 10KHz in raw mode which is the reason for too many bits when converting the ON/OFF-signal from the IR receiver to a byte array. It also explains why I see the correct wave form in the analyzer, what i thought was one long ON-period is actually multiple samplings that were all ON.
Have to fix that before I can make any more headroom, but throwing out all but every 5th bit in the result looks almost as it should.


I would advise against that approach (throwing out all but every 5th sample).

Decoding from timed samples will not work as well as decoding from durations.

Most of our software (including decodeIr) works with durations rather than samples. When we discuss durations, we always use a positive number for a duration in which the signal is ON and use a negative number for a duration in which the signal is OFF. Inside programs, sometimes we also use positive for ON and Negative for OFF, but sometimes we use positive for everything and distinguish ON from OFF only by position within the list of durations.

So if you have "raw" data sampled at 10Khz, each sample is 100uS. You can easily count the number of duplicate samples to each transition in order to convert to a sequence of durations. For example

1111110000111110000000000
would convert to 600 -400 500 -1000

Then for NEC or Pioneer protocols, you could take each pair of durations and see what bit type it is close enough to.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> Non-JP1 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