JP1 Remotes

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Yes.

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.

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.

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.