Hello all, I just received my USB IR Toy from Seeed and must say they did a nice job.
But now I've run into an issue with the remote control I was hoping to use (the one from my Pioneer Kuro LX6090H) to control my XBMC mediapc.
It seems it is not using RC5 (no big surprise there I suppose) so I was thinking that I could just use the RAW-mode and map that against the LIRC-codes needed for XBMC but after looking at the raw data it seems that i do not get very reliable readings at all.
The number of bytes sent for each button press is also somewhat large (most buttons is 1 64 byte segment, followed by a 19 byte segment, followed by another different 64 byte segment, followed by another 19 byte segment).
I can't really find any information on what protocol is being used aside from probably a modified NEC Message Protocol.
However the very random readings makes me wonder if the frequencies are wrong? I can accept that it's not a perfect science but I would hope I would get the same data at least 9 out of 10 times for the TV to understand the remote?
Also, when I send the "t" for test I randomly get either FAI2 or V102 as a response (about 50/50 split), does anyone else suffer from this?
My main questions thus is:
Does anyone know what protocol Pioneer uses?
Can I check the frequency somehow without having access to an oscilloscope?
Given I find out that the frequencies match, how hard is it to implement my own decoder for the signal?
Does anyone know of a good place to find information on how to figure out what the protocol is? For example it seems almost all the 64 byte segments start with 7F FF FF FF FF, and ends with 00 00 00 00 00 so I suspect they are headers and EOS-markers..
I work as a software engineer and developer so writing the code to handle the data shouldn't be a problem, but I'm hopelessly lost when it comes to hardware so I hope someone can give me some tips.
Otherwise I suppose I will have to look into possible abusing the possibility to set the remote to send another companies RC-codes, some of them might use a simpler format.
/Shadowsoul
Hi Shadowsoul - If you're getting data then the frequency is probably within the range accepted by the receiver. They work over a pretty large range (except with some exotic remotes). There is currently no way to measure frequency with the IR Toy.
The self-test isn't perfect, and the IR Toy generally needs to be pointed at something reflective to pass 100% of the time.
Decoding the signal from rawIO mode probably involve counting the duration of each on and off period (stretches of 1 and 0s in the raw data) and comparing it to sampled signals. I'm actually in the process of adding a new mode to just send the duration counts, which is a more common way to do this. The catch is that you need to know the protocol. Remote protocols are not consistent each time - some vary on alternating key presses (toggle bit), some only transmit the command once and then send a repeat blip. There's more about this in the IR Toy article under the header "Remote control decoder": http://dangerousprototypes.com/2010/01/ ... ansmitter/ (http://dangerousprototypes.com/2010/01/29/prototype-usb-infrared-remote-control-receivertransmitter/)
One thing that might help understand the protocol and what you're getting from the remote is to use the IR Toy with the SUMP logic analyzer client, then you can actually see the signal and timing (see SUMP logic analyzer
in the article).
RawIO mode always ends when it sees no change for 5bytes of samples, that's why it always ends with 0x00 (see IRIO in the article), the beginning part is probably a long on-pulse. You can compare the SUMP captures of the signal with the examples here:
http://www.sbprojects.com/knowledge/ir/ir.htm (http://www.sbprojects.com/knowledge/ir/ir.htm)
I programmed my GE Universal remote as a Phillips RC5. The only alternating key press occurs with the VCR [Record] button (works in TV mode).
[quote author="ian"]
...snip...
[/quote]
I see, then I'll assume my device works 100% until it fails me somehow.
From another forum (dunno if I may link) I've found out that the frequency used by Pioneer is modulated at 40Khz, is it possible to modify the firmware for another frequency (I assume it is needed even if the signals are received by the IR-receiver for decoding purposes)?
The protocol used is apparently the NEC2 IR Protocol, however it was recommended that I should look into the signals to see if they also send Sony 15 or a simpler NEC protocol, I know that i can set the remote to send other manufacturers codes, just not sure how it sends them.
Assuming I manage to find out the protocol and modulation is it possible to fit another decoding algorithm onto the IR Toy? I can probably figure out how to write it and share it with the rest of the world but if it can't fit I'll just do it on the computer instead.
/Shadowsoul
The receive frequency (within spec) doesn't matter to the firmware at all, and no special setup is needed. The receiver module will demodule signals between (?) 20khz-80khz (?) into a stream of 1s and 0s.
You could capture the signals with the IR Toy and look at the waveform on SUMP logic analyzer, that would give us some insight into the protocol.
There's tons of room in the IR Toy to add more protocols. I have a feeling the new timing capture protocol will make a lot of on-chip decoding moot though.
If the remote sends at 40khz, and the receiver is set for 36khz, it'll still work, just the range will be less I believe. A few remotes use 56khz and that wont work with a 36khz receiver. Band and olufsen use 455kHz for their equipment :o You'd need a special receiver to make those work. But 90+ % are probably 36-40 khz :)
A few remotes use 56khz and that wont work with a 36khz receiver.
Thanks, I thought it was a bit wider than that, but after checking the datasheet I see that it's not. Hum, maybe multiple detectors are a good idea on future hardware.
[quote author="ian"]
The receive frequency (within spec) doesn't matter to the firmware at all, and no special setup is needed. The receiver module will demodule signals between (?) 20khz-80khz (?) into a stream of 1s and 0s.
You could capture the signals with the IR Toy and look at the waveform on SUMP logic analyzer, that would give us some insight into the protocol.
There's tons of room in the IR Toy to add more protocols. I have a feeling the new timing capture protocol will make a lot of on-chip decoding moot though.
[/quote]
Excellent modulation info, no need to reinvent the wheel then :)
I've looked at the SUMP output but I find it kind of hard to interpret, however I have found the full protocol specification (NEC2 to be specific, plus almost every other protocol) on another site so I am in the progress of trying to figure out how to convert the signal I receive from the Ir Toy to the hex-codes they should represent (I had no idea there was soemthing called burst pairs so i thought i received 64 byte codes instead of 8 bytes).
If there is interest I can link to the site I am using for the information (or send it in PM, dunno the linking policy) or send it in a PM. It could probably help immensly if more protocol implementations
/Shadowsoul
[quote author="Shadowsoul"]If there is interest I can link to the site I am using for the information[/quote]Are you referencing SB-Projects: IR remote control (http://http://www.sbprojects.com/knowledge/ir/ir.htm) or some other site? You can just embed a URL in a brief reply to this thread.
[quote author="ian"]
A few remotes use 56khz and that wont work with a 36khz receiver.
Thanks, I thought it was a bit wider than that, but after checking the datasheet I see that it's not. Hum, maybe multiple detectors are a good idea on future hardware.
[/quote]
For what it's worth, while digging through the IR widget info, I saw a few mentions from Kevin Timmerman of using an IR LED as a IR detector in order to capture a greater bandwidth range (up to 455 khz) that IR detectors were available for. Unfortunately to work the sending IR LED needs to be as close as possible to the IR LED used for detecting. I've played with an IR LED directly attached to my scope probes as a simple photovoltaic device, which is what I think he's showing at about the 7th post in the minipov3 hack thread. (http://http://forums.adafruit.com/viewtopic.php?p=22247). I didn't play with frequency ranges, I was using some actual remotes.
[quote author="rsdio"]
[quote author="Shadowsoul"]If there is interest I can link to the site I am using for the information[/quote]Are you referencing SB-Projects: IR remote control (http://http://www.sbprojects.com/knowledge/ir/ir.htm) or some other site? You can just embed a URL in a brief reply to this thread.
[/quote]
This (http://http://www.hifi-remote.com/johnsfine/DecodeIR.html) is actually the site, the notation is a bit scary but a search for IRP Notation explaned it. I think in my amateur knowledge that they too use the signal timing instead of the actual bytes that I think Ian was talking about.
[quote author="Shadowsoul"]I think in my amateur knowledge that they too use the signal timing instead of the actual bytes that I think Ian was talking about.[/quote]Be careful, the "actual bytes" don't really exist anywhere. Those bytes are nothing more than a bitstream that has been compressed into bytes for efficient transfer. It's like an audio recording of the incoming IR signal, but with a 1-bit depth and a low sample rate, which is then compressed into 8 consecutive samples per byte. There's no synchronization that would cause the same bytes to appear every time for the same signal, and they're certainly not the same bytes that each remote control would see when decoding its own signals. Basically, the signal timing is there, but you have to know the sample rate to decode it. My own OSX front end for the USB IR Toy converts the bytes into my own shorthand notation for signal timing, and then processes the data from there. My point is that any binary representation of the IR signal is arbitrary, so you'll have to translate between different representations.
It helps to convert the bytes to bits, and then display the bits as a waveform. Then you can see the patterns more easily. Otherwise, the bit patterns can be shifted left or right and turn into byte which look completely different, but are actually almost identical. Anyway, I'm sure it will start to make sense as you work with it more.
Hey rsdio, I'm planning on doing the same for Windows, can you post an overview of your front-end and how it deals with the IR Toy data. :)