16
USB Infrared Toy / Re: Remote control times, timing issues
Is there a reason the timer starts on a falling edge in the IR signal? I would assume a rising edge would be the correct start as all protocols start with some form of ON-signal?
Messages
This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.
Messages - Shadowsoul
Is there a reason the timer starts on a falling edge in the IR signal? I would assume a rising edge would be the correct start as all protocols start with some form of ON-signal?
17
USB Infrared Toy / Re: Remote control times, timing issues
Quote
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.
There is a document with almost all the protocol timings that exist that i got from the hifi-remote forum ( http://www.hifi-remote.com/johnsfine/DecodeIR.html ) which is what I am basing my protocol understanding on.
I have compared the results I get in sampling mode and the results I get in the BFP Logic Analyzer. The BFP seems to be correct for the Beginning-segment, and reads a total of 33 encoding periods, which is correct with regards to the protocol (8+8+8+8+1 periods).
The program I wrote that uses the sampling mode also correctly reads 33 encoding periods, however it does not correctly read the start...
It also gets the data in different "signals", which may be in regards to the .NET SerialPort Buffer, not sure how it raises "DataReceived".
None of the programs correctly reads the 78 periods of silence as EOS, however that might be due to the IR Toy doing something.
Not sure if any of this comes from the fact that Pioneer uses 40Khz signals.
Images for comparison if it helps someone:
http://www.swordspider.com/images/BFP_Pioneer.jpg
http://www.swordspider.com/images/UsbIrToy-Timings.jpg
What really irks me are the dips I see in my program (evident at the start and end of the red period). If they are the culprit and the sampling mode starts on a falling edge it would explain the issues at the beginning of the stream, then I have a period of about 5000 us that's not visible at the start, followed by 3000us which together are about the protocol start. The same at the middle (my remote sends duplicate command...don't ask why, I have no clue) as there is clearly ~5000+~3000us periods there.
Not sure where I should look next...I noticed that WinLirc supports PWM-based learnings, but it seemed to have immense problems with the Pioneer remotes at least, like 8 buttons received the same timings.
I do think that the sampling mode is the correct way to do things at least, if that works almost every protocol can be decoded to the correct bytes for LIRC/Whatever and the DecodeIR-project over at hifi-remote has support for all the ones listed in the document linked above so it should be fairly straightforward to port protocols as required/necessary/wanted.
Hope it's OK to link like I have
18
USB Infrared Toy / Re: WinLIRC driver update
I think the product I saw actually had some sort of relay, that directly powered on the pc, or crossed the connection which turns it on. But there are other ways to do this I think, wake on Lan, maybe some USB thing. I built myself a media centre pc for my living room, being able to turn it on with my remote is about the only thing I am missing.
[/quote]
I think a simple 2-pin (or 3, can't remember if WOL actually uses all 3 pins or not) connector that is connect to the PIC might be the best option for this.
That way we can just hook up any connector we want for the different power-on features, a relay to use for shorting the power on-pins on MB or WOL/WOUSB/whatever have you..
A relay connected to the power-pins on the MB is by far the most reliable as it works even when the computer is just in stand by mode, and not all motherboards support wake on USB =(
Would need some kind of learning mode though to store the actualy power-code..
19
USB Infrared Toy / Re: Using non RC5 controls in RAW mode
[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 or some other site? You can just embed a URL in a brief reply to this thread.
[/quote]
This 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.
20
USB Infrared Toy / Re: Using non RC5 controls in RAW mode
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
21
USB Infrared Toy / Re: Using non RC5 controls in RAW mode
...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
22
USB Infrared Toy / Using non RC5 controls in RAW mode
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