RE: rtl28xxu IR remote

RE: rtl28xxu IR remote

[Rodrigo Tartajo]

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

Re: rtl28xxu IR remote

[Antti Palosaari]

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/

Re: rtl28xxu IR remote

[Antti Palosaari]

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:
1000000000 / 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/

Re: rtl28xxu IR remote

[Rodrigo Tartajo]

[-- Attachment #1: Type: text/plain, Size: 3553 bytes --]

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:
> 1000000000 / 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) * (1000000000/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/

[-- Attachment #2: cuentafreq.txt --]
[-- Type: text/plain, Size: 1028 bytes --]

   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

[Antti Palosaari]

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:
>> 1000000000 / 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) * (1000000000/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/

Re: rtl28xxu IR remote

[marco caminati]

> 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?

Re: rtl28xxu IR remote

[Antti Palosaari]

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/

Re: rtl28xxu IR remote

[marco caminati]

> 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)

rtl28xxu ir remote

[marco caminati]

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.