[quote author="Shadowsoul"]
After playing around a bit today I have managed to create a program drawing the received signal, in the process of seeing if i can write a rudimentary decoding in C# now.
However, what I have noticed is that the timings I receive are way off from what they should be according to the protocol (NEC/Pioneer uses 564us). I Always get between 511 and 533us and multiples thereof.
Do you know if that could have anything to do with the fact that Pioneer uses 40KHz instead of 38KHz? I only have Pioneer remotes to test with so it's a bit hard to verify myself.
I multiply the values I get in sampling mode with 21.333333 to get the "correct" time, is this still the correct constant?
Also, from what I understood you start the timer on a falling edge, is that correct? The reason I am asking is that the NEC/Pioneer protocol should start with 16 periods ON, followed by 8 periods of OFF, and then comes the real data. However the IR Toy always lists the beginning as about 6 periods (3000us) ON followed by about 8 periods (4000us) OFF for me..
[/quote]
I'm not 100% sure about the 40khz difference, but I don't think it makes that type of difference.
That is still the constant, but my calculations could be off. I will try to verify it on a logic analyzer before the next firmware release.
The timing on the IR toy and the remote control aren't exact, so it can be a few us off. The resolution is only 21.33, so it might end right before another interval and the actual value could be closer to 533-554. Other programs use constants between 50us and 100us, so ours is pretty accurate (if odd..), so I guess the matching is pretty fuzzy.
We could add the feature to adjust the sampling speed to a higher resolution (faster, such as 10uS).
How long do you think it takes an infra-red receiver to turn from a 0 -> 1 ?
In my experience with different receivers, even the simplest ones, infra-red receiver hooked directly to the sound card, sampled at 96,000 times / s the expected times can be up to 100us off. I think it's just the response time of the actual receiver itself. I think they have something like an accuracy of 50-100us. Sampling faster won't fix this. In any case, we dont need that much accuracy to decode most signals.
Regarding the protocol I am talking about I will quote the answer I got from Robman regarding this over at Hifi-remote:
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 (http://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://http://www.swordspider.com/images/BFP_Pioneer.jpg)
http://www.swordspider.com/images/UsbIrToy-Timings.jpg (http://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 :)
Forgot to add:
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?
The falling edge of the receiver output is the start of IR pulse. The IR receiver output is inverted from the IR signal. IR ON = 0, IR OFF=1.
[quote author="Shadowsoul"]I do think that the sampling mode is the correct way to do things at least, ...[/quote]I agree. The new sampling protocol for the USB Infrared Toy is basically a run-length-encoded variation of the original sampling protocol. As a generic protocol to describe multiple encoding schemes, I don't see how it could go wrong. The decoding task itself is still difficult, but it's easier to handle that on the host computer, provided that the sampled data is communicated accurately. Higher sample rates might be useful, and host control of the sample rate is ideal.
After more work than I like to do I now have a fully functional, albeit very ugly, decoding of the Pioneer protocol working in C# :)
The meanies are sending 2 commands for some buttons though which will be "fun" to solve..
Regarding the timings, they seem to be pretty spot on except for the strange drop I see in the header-pulse. The Blu-Ray-remote sends Off-pulses with 490us duration, but the receiver seems to follow the protocol very well (within 20us of the specified 564us) on all the buttons I tested.
Just need to polish it up a bit now and then I can look at the fun of implementing it in C for the firmware (where I might add that my knowledge of C stretches to a basic C++ course some five years ago).
How much space is there in the firmware for this kind of stuff anyways? Is there room for multiple decoding algorithms or is multiple versions of firmware required? Performance might also be an issue if you have to try alot of different algorithms..
Or can it be done inside a Lirc plugin?
As is evident I have no experience coding for LIRC, I tried learning it in sampling mode but it really really doesn't like the Pioneer protocol with multiple signals for some buttons, as it seems to flag it as toggle signals.
If you got problems like that you can always try just capturing data in raw mode. It won't try and decode the values, it'll just match the times with a certain % error tolerence.
IRRecord.exe -f -d IRToy.dll ..config.cfg
it really really doesn't like the Pioneer protocol with multiple signals for some buttons, as it seems to flag it as toggle signals.
They probably are toggle bits? If you hold down the remote, it'll send the same value. But if you release it and press it again 1 bit will change (the toggle bit). It's done so remotes can tell the difference between the user holding down a button, and just pressing it multiple times.
That's what I tried.
The problem is that Pioneer has decided that alot of buttons need two separate IR signals.
So e.g. the RED-button is sent as A181 followed by AF64.
The GREEN-button is sent as A181 followed by AF65.
What this does is that IRRecord thinks that A181 is the signal for both buttons =(
Or, sometimes it based the Toggle bitmask on the separate codes, which is wrong as the Pioneer/NEC2 protocol sends full repeats when holding down the button.
Luckily Pioneer are open with their remote codes due to custom installers so I know the exact combos for all buttons ( http://www.pioneerelectronics.com/PUSA/Home+Entertainment+Custom+Install/IR+Codes (http://http://www.pioneerelectronics.com/PUSA/Home+Entertainment+Custom+Install/IR+Codes) if anyone wants a looksies) which should mean I can combine the double signals.
As a side note, I noticed that the IRRecorder got the correct lead-in (8000ish us followed by 4000ish us) when sampling so that issue is not with the USB IR Toy.
How much space is there in the firmware for this kind of stuff anyways? Is there room for multiple decoding algorithms or is multiple versions of firmware required? Performance might also be an issue if you have to try alot of different algorithms..
Or can it be done inside a Lirc plugin?
There is a ton of room in the IR Toy for more stuff. The current firmware is only 10-20% of the space. I'm going to update IR Man mode with multiple decoders, but stuff like decoding the multiple byte packets is probably easiest on a computer. The PIC has to keep up with the IR signal timing, and it could have problems if we implement a big switch or other sort of intensive signal analysis.
[quote author="Shadowsoul"]
That's what I tried.
The problem is that Pioneer has decided that alot of buttons need two separate IR signals.
So e.g. the RED-button is sent as A181 followed by AF64.
The GREEN-button is sent as A181 followed by AF65.
What this does is that IRRecord thinks that A181 is the signal for both buttons =(
Or, sometimes it based the Toggle bitmask on the separate codes, which is wrong as the Pioneer/NEC2 protocol sends full repeats when holding down the button.
[/quote]
One of the problems with decoding certain protocols is, there are so many ! And often manufacturers customise the protocol slightly. For instance the streamzap one I have, it's meant to be RC5 but they added an extra bit or two so with the irman decoder, it doesn't work anymore ! But anyway I think I know whats happening with the pioneer remote.
(http://http://img580.imageshack.us/img580/5949/pioneer.png)
That's just for a random remote, I am not sure what pioneer remote you have. However it looks to me like it isn't sending a toggle bit at all. It looks like its sending (for some buttons), the group name for the button, ie in the example above it's sending A49F for the radio buttons, then the actual value for the button, I assume as a seperate transmission. I can see why that would cause problems. If you wanted to persue, lirc/winlirc if i were you i'd generate a config for 1 button. Then look look at the pioneer document for your remote, then just paste in the hex values for the buttons directly into the config. That should work fine, you just want to (I assume) ignore the group name, or hex value for the first part of the button, and only use the latter part. I think that should work fine :)
[quote author="ian"]stuff like decoding the multiple byte packets is probably easiest on a computer. The PIC has to keep up with the IR signal timing, and it could have problems if we implement a big switch or other sort of intensive signal analysis.
[/quote]I agree that decoding is easiest on the host computer, but it might be possible to use interrupts so that the PIC could keep up with the IR signal and still slowly decode signals.
[quote author="dukey"]
[..] However it looks to me like it isn't sending a toggle bit at all. It looks like its sending (for some buttons), the group name for the button, ie in the example above it's sending A49F for the radio buttons, then the actual value for the button, I assume as a seperate transmission. [..]
[/quote]
That's exactly what it does :)
Thanks for the tip on configing with only the second hex value, it should work unless there are some overlaps between the different groups (hard to believe there would be).
The problem is to get a nice HEX-value from the IR Toy on the NEC/Pioneer protocol. Or I suppose I can just encode the HEX-values as time-codings, should be fairly straightforward now that I have a working decoder. But that's like cheating :)
The RC5 decoder is setup that way. The irsample mode also uses an interrupt for capturing the signal times, and a service routine loop that moves bytes to USB (and soon USB to IR).
All in all, I'm pretty reticent to decode stuff on the chip because it seems like a battle that can never be won. A few protocols (that can be easily distinguished) can be decoded. But if there are all sorts of custom tweaks for each manufacturer like Dukey says, then I will loose my hair. If the hardware gives accurate timing, I'd rather let the user train the computer to their remote buttons through a point&click interface. Everyone can do their own, rather than centralize that responsibility on the firmware developers :)
[quote author="ian"]The RC5 decoder is setup that way. The irsample mode also uses an interrupt for capturing the signal times, and a service routine loop that moves bytes to USB (and soon USB to IR).[/quote]Sounds about right.
I really only mentioned that it might be possible to decode, but I would not recommend that option, either.
My general goal is to make the hardware do as much as possible, and the firmware represent the raw hardware is closely as possible to the host application. That way, anything that the firmware cannot handle can be handled on a fast computer, so long as the data can be shuttled between the two fast enough. The USB Infrared Toy is doing great here, starting with a decent raw sampling mode and improving upon that with the compressed protocol.