Re: rtl28xxu IR remote
I think the most easiest way could be compile install whole Kernel from my tree. It is 3.10-rc4 + some fixes. Ok, but I first tried the easier alternative you advised below. media_build.git has also option to fetch developer git tree from linuxtv.org. Something like ./build --git git://linuxtv.org/anttip/media_tree.git rtl28xxu . That approach seem to be not documented on wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Thanks for the suggestion. It is documented only in ./build --help, it seems. I tried this latter way, it built succesfully, but the modules won't work: modprobe --force dvb_usb_rtl28xxu gives err kernel: dvb_core: exports duplicate symbol dvb_ca_en50221_camchange_irq (owned by kernel) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu IR remote
Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Thanks, but I can't confirm if this fixes my problem, because the modules I obtain building Antti's branch are not compatible with my existing kernel, so I can't test them (modprobe --force fails, and using a brand new kernel would be too much work on Tinycore at the moment). On the other hand, I tried the sources fromgit://linuxtv.org/media_build.git, first with manual patches and then (when the latter got accepted) without them. But the ir remote does not work. I think Antti's repo and patching linuxtv repo should lead to the same results, right? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu IR remote
On 06/10/2013 06:09 PM, marco caminati wrote: Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Thanks, but I can't confirm if this fixes my problem, because the modules I obtain building Antti's branch are not compatible with my existing kernel, so I can't test them (modprobe --force fails, and using a brand new kernel would be too much work on Tinycore at the moment). On the other hand, I tried the sources fromgit://linuxtv.org/media_build.git, first with manual patches and then (when the latter got accepted) without them. But the ir remote does not work. I think Antti's repo and patching linuxtv repo should lead to the same results, right? I think the most easiest way could be compile install whole Kernel from my tree. It is 3.10-rc4 + some fixes. media_build.git has also option to fetch developer git tree from linuxtv.org. Something like ./build --git git://linuxtv.org/anttip/media_tree.git rtl28xxu . That approach seem to be not documented on wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu IR remote
On 06/08/2013 02:22 AM, Rodrigo Tartajo wrote: Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Rodrigo. [1] http://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U Good. I tested it quite limited set of remote controllers and even found one NEC remote which didn't worked - RC_MAP_MSI_DIGIVOX_II. Maybe timings should be adjusted or there is some other factor. I didn't cared to look it more as I am not very familiar with these raw remote protocols and real life variations. I also had no reference to adjust remote timings. I just used one RC5 remote and calibrated timings according to that. If there is someone having better reference signals, then feel free to change that timing value to more correct. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu IR remote
On 06/08/2013 02:31 PM, Antti Palosaari wrote: On 06/08/2013 02:22 AM, Rodrigo Tartajo wrote: Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Rodrigo. [1] http://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U Good. I tested it quite limited set of remote controllers and even found one NEC remote which didn't worked - RC_MAP_MSI_DIGIVOX_II. Maybe timings should be adjusted or there is some other factor. I didn't cared to look it more as I am not very familiar with these raw remote protocols and real life variations. I also had no reference to adjust remote timings. I just used one RC5 remote and calibrated timings according to that. If there is someone having better reference signals, then feel free to change that timing value to more correct. Rodrigo, as it was you who has defined that factor as a: 10 / 38000 * 2 = 52631 I found 50800 most suitable by error and trial testing against one RC5 remote. I see 38000 is coming from IR frequency, but what is 1GHz clock derived? And why multiply by 2? Reference clock feed to chip is 28.800 MHz and most likely these timings should be derived somehow from it. I tried to make different calculations but didn't find any suitable... Also what I remember, these IR leds will not return receiver carrier at given frequency (38kHz in that case) but instead longer pulses. If there is 0.5 sec 38 kHz modulated IR wave then IR-led will return 0.5 sec continuous pulse. So that frequency should not matter too. I did learning IR remote controller, which has both receiver and IR sender, as a school project: http://palosaari.fi/img_1305.jpg Unfortunately that was returned to the uni and was thrown to the trash can :S I have thought many times that board could be handy tool for hacking support for these remote controllers... regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu IR remote
El 08/06/13 14:02, Antti Palosaari escribió: On 06/08/2013 02:31 PM, Antti Palosaari wrote: On 06/08/2013 02:22 AM, Rodrigo Tartajo wrote: Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Rodrigo. [1] http://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U Good. I tested it quite limited set of remote controllers and even found one NEC remote which didn't worked - RC_MAP_MSI_DIGIVOX_II. Maybe timings should be adjusted or there is some other factor. I didn't cared to look it more as I am not very familiar with these raw remote protocols and real life variations. I also had no reference to adjust remote timings. I just used one RC5 remote and calibrated timings according to that. If there is someone having better reference signals, then feel free to change that timing value to more correct. Rodrigo, as it was you who has defined that factor as a: 10 / 38000 * 2 = 52631 I found 50800 most suitable by error and trial testing against one RC5 remote. I see 38000 is coming from IR frequency, but what is 1GHz clock derived? And why multiply by 2? Reference clock feed to chip is 28.800 MHz and most likely these timings should be derived somehow from it. I tried to make different calculations but didn't find any suitable... Also what I remember, these IR leds will not return receiver carrier at given frequency (38kHz in that case) but instead longer pulses. If there is 0.5 sec 38 kHz modulated IR wave then IR-led will return 0.5 sec continuous pulse. So that frequency should not matter too. I did learning IR remote controller, which has both receiver and IR sender, as a school project: http://palosaari.fi/img_1305.jpg Unfortunately that was returned to the uni and was thrown to the trash can :S I have thought many times that board could be handy tool for hacking support for these remote controllers... regards Antti Hi, The kernel IR protocol decoder works with nanoseconds length for the pulses/silences, while the IR receiver is sending back a runlenght encoded bytes with the number of ticks at 38KHz (I suppose it is 38Khz, as it is the most common carrier). While doing an hexdump of these IR bytes returned by the device, I could discern their encoding: the higher bit is the indicator of pulses (1) or space (0), the next 7 bits encode the higher 7 bits of a 8 bit counter, dropping the lowest bit (you lose precision, but increase the range of possible values from 127 to 255, reducing the chance of needing multiple bytes to encode a single value). The formula in the macro '#define TICSAT38KHZTONS(x) ((x) * (10/38000))', and why it was feed with 'TICSAT38KHZTONS(((u32)(buf[i] 0x7F)) 1)' should be now easier to understand. And you are right, unless there is some hidden register we have no information about the carrier frequency, and can only guess the one used. As a bonus, found attached a statistics of the frequency and count of commands for the remote controls in available on Remote Central[1], as you can see the most common carrier frequency is 38KHz or some light variations of it (36, 40 comes next). This list is at least 5 years old, but I dont think there should be any variations with the possible current values. Rodrigo. [1]: http://www.remotecentral.com/cgi-bin/codes/ 6644 38.38 6481 38.03 3101 36.04 3024 40.24 2295 37.01 2063 38.74 1444 35.73 1237 57.57 1113 36.68 792 39.1 599 37.34 564 37.68 546 40.64 370 32.9 352 460.57 209 35.43 179 58.38 177 41.87 166 109.08 157 39.48 120 345.43 119 32.64 80 121.92 64 42.3 61 43.63 60 30.48 51 41.45 47 41.04 47 33.16 46 34.26 43 56.78 42 39.86 40 88.19 40 30.7 37 56.02 30 33.98 28 32.38 24 98.69 21 106.28 20 75.37 20 63.77 20 34.54 20 31.17 20 20.22 20 115.14 20 1036.29 19 35.13 17 59.22 16 43.18 15 26.92 11 50.55 9 33.43 8 142.94 6 30.04 5 28.39 5 26.74 5 118.43 4 153.52 3 42.73 3 33.7 3 31.4 3 28.59 2 64.77 2 60.96 2 518.14 2 48.2 2 47.1 1 62.8 1 60.07 1 49.35 1 414.51 1 180.22 1 112.03
Re: rtl28xxu IR remote
On 06/08/2013 03:50 PM, Rodrigo Tartajo wrote: El 08/06/13 14:02, Antti Palosaari escribió: On 06/08/2013 02:31 PM, Antti Palosaari wrote: On 06/08/2013 02:22 AM, Rodrigo Tartajo wrote: Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Rodrigo. [1] http://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U Good. I tested it quite limited set of remote controllers and even found one NEC remote which didn't worked - RC_MAP_MSI_DIGIVOX_II. Maybe timings should be adjusted or there is some other factor. I didn't cared to look it more as I am not very familiar with these raw remote protocols and real life variations. I also had no reference to adjust remote timings. I just used one RC5 remote and calibrated timings according to that. If there is someone having better reference signals, then feel free to change that timing value to more correct. Rodrigo, as it was you who has defined that factor as a: 10 / 38000 * 2 = 52631 I found 50800 most suitable by error and trial testing against one RC5 remote. I see 38000 is coming from IR frequency, but what is 1GHz clock derived? And why multiply by 2? Reference clock feed to chip is 28.800 MHz and most likely these timings should be derived somehow from it. I tried to make different calculations but didn't find any suitable... Also what I remember, these IR leds will not return receiver carrier at given frequency (38kHz in that case) but instead longer pulses. If there is 0.5 sec 38 kHz modulated IR wave then IR-led will return 0.5 sec continuous pulse. So that frequency should not matter too. I did learning IR remote controller, which has both receiver and IR sender, as a school project: http://palosaari.fi/img_1305.jpg Unfortunately that was returned to the uni and was thrown to the trash can :S I have thought many times that board could be handy tool for hacking support for these remote controllers... regards Antti Hi, The kernel IR protocol decoder works with nanoseconds length for the pulses/silences, while the IR receiver is sending back a runlenght encoded bytes with the number of ticks at 38KHz (I suppose it is 38Khz, as it is the most common carrier). While doing an hexdump of these IR bytes returned by the device, I could discern their encoding: the higher bit is the indicator of pulses (1) or space (0), the next 7 bits encode the higher 7 bits of a 8 bit counter, dropping the lowest bit (you lose precision, but increase the range of possible values from 127 to 255, reducing the chance of needing multiple bytes to encode a single value). The formula in the macro '#define TICSAT38KHZTONS(x) ((x) * (10/38000))', and why it was feed with 'TICSAT38KHZTONS(((u32)(buf[i] 0x7F)) 1)' should be now easier to understand. And you are right, unless there is some hidden register we have no information about the carrier frequency, and can only guess the one used. Aah, now I see, it is not 1GHz but 1 second in nanoseconds. Yeah, seems like that calculation is very near. There is some inner logic inside chip to calculate nanoseconds from the reference clock. I think 28.800 MHz is the only possible reference clock so it is easy. As a bonus, found attached a statistics of the frequency and count of commands for the remote controls in available on Remote Central[1], as you can see the most common carrier frequency is 38KHz or some light variations of it (36, 40 comes next). This list is at least 5 years old, but I dont think there should be any variations with the possible current values. Rodrigo. [1]: http://www.remotecentral.com/cgi-bin/codes/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: rtl28xxu IR remote
Hi, I just compiled and tested Antti Palosaari branch and can confirm the remote works for my RTL2832U. I have updated the wiki[1] entry with the steps necessary to configure the remote control. Please confirm if these fixes your problem. Rodrigo. [1] http://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rtl28xxu ir remote
Thanks for the recent efforts as from subject. I tested it with no success, however. Indeed, with old r820t-unaware drivers (e.g., v4l version df33bbd60225), I used to get some output from cat /dev/input/eventX upon pressing ir remote buttons (passingrtl2832u_rc_mode=2 to modprobe). Now this does not work any longer. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
