Configuring IR Remote that is supplied with tt-4600 tuner

  • Hello,

    So as the Title says and after being able to use my tt-4600 with libreelec -thanks again to CvH and crazycat -, I have been trying to configure the remote control that came with the tuner to work and I have read the wiki carefully and found that there is no working keytable file that is ready to be used so I had to jump to "the hard way" part of that tutorial and when I have reached to the part where I have to relate every scancode to its Linux keycode I have used a keytable wrote by mglae and double checked it using ir-keytable -t after stopping both kodi and eventlircd. this remote also uses only rc-5 type protocol.

    It has only one issue and that is the "Autorepeat", I have tried to disable for example 0xd43 for KEY_1 and leave only 0x543 active as they are both scancodes for key number 1 but it didn't work. I don't know why the same key has 2 different scancodes!!

    I still for example scroll more than one line on TV channel list when I have only pressed the "Down" key one time only. Is there a solution for this?

    here is the keytable I used http://ix.io/1p4g

  • Can you post the ir-keytable -t output of a ~1second button press?

    so long,

    Hias

    This is while pressing Right key for a second

    Code
    libreelec:~ # ir-keytable -t
    Testing events. Please, press CTRL-C to abort.
    558.343470: lirc protocol(rc5): scancode = 0xd50
    558.621547: lirc protocol(rc5): scancode = 0xd50
    558.876888: lirc protocol(rc5): scancode = 0xd50
    559.162419: lirc protocol(rc5): scancode = 0xd50

    Another example, This is while pressing 1 key for a second

    Code
    libreelec:~ # ir-keytable -t
    Testing events. Please, press CTRL-C to abort.
    1119.463409: lirc protocol(rc5): scancode = 0x543
    1119.730132: lirc protocol(rc5): scancode = 0x543
    1119.996816: lirc protocol(rc5): scancode = 0x543
    1120.263477: lirc protocol(rc5): scancode = 0x543

    If I press really quick like what you usually do when browsing through kodi it will generate different scancodes for the same key. And sometimes it will generate 1 scancode and sometimes 2 successive scancodes (the autorepeat I'm talking about), like this for example when pressing 1 key quickly for 2 times (the 1st line for the first press and the 2nd,3rd lines for the second press)

    Code
    libreelec:~ # ir-keytable -t
    Testing events. Please, press CTRL-C to abort.
    1266.450049: lirc protocol(rc5): scancode = 0x543
    1268.050020: lirc protocol(rc5): scancode = 0xd43
    1268.316830: lirc protocol(rc5): scancode = 0xd43
  • Hmmm, the remote doesn't seem to follow the rc5 protocol too well - or there's some bug in the IR receiver driver of your card that then causes rc-5 decoding in the kernel to fail.

    On quickly repeated button presses you should see the toggle bit flipping instead of getting different scancodes for the same button. eg

    Code
    799.923295: lirc protocol(rc5): scancode = 0x1015 toggle=1
    800.183294: lirc protocol(rc5): scancode = 0x1015

    But that's no big deal, you can work around it with 2 scancodes for the same button in your keytable - like you already did.

    The more problematic thing is that the signals seem to arrive at about 250ms interval instead of 110ms which is the standard for the rc-5 protocol. Therefore the kernel will interpret the scancode as distinct button presses and the normal repeat handling won't work.

    You should be able to work around this by increasing the IR receive timeout with eg ir-ctl -t 200000 - you can play a bit with the value, 150000 should probably work as well and give a bit better response or you can go up a bit, eg to 250000. Just test what works best for you.

    so long,

    Hias

  • You should be able to work around this by increasing the IR receive timeout with eg ir-ctl -t 200000 - you can play a bit with the value, 150000 should probably work as well and give a bit better response or you can go up a bit, eg to 250000. Just test what works best for you.

    That command did't work, here is what I've got:

    Code
    libreelec:~ # ir-ctl -t 150000
    /dev/lirc0: device does not support setting timeout

    The more problematic thing is that the signals seem to arrive at about 250ms interval instead of 110ms which is the standard for the rc-5 protocol.

    looks like this if you take a look at dmesg|paste http://ix.io/1pbt here you will see:

    Code
    [    7.374977] Registered IR keymap rc-tt-1500
    [    7.375166] rc rc0: TechnoTrend TT-connect S2-4600 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/rc/rc0
    [    7.375317] input: TechnoTrend TT-connect S2-4600 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/rc/rc0/input1
    [    7.376498] rc rc0: lirc_dev: driver dw2102 registered at minor = 0, scancode receiver, no transmitter
    [    7.376509] dvb-usb: schedule remote query interval to 250 msecs.
    [    7.376522] dw2102: su3000_power_ctrl: 0, initialized 1
    [    7.376526] dvb-usb: TechnoTrend TT-connect S2-4600 successfully initialized and connected.
  • Can you please post a link to your full dmesg dmesg | paste and the output of ir-keytable? If you are using the crazycat drivers can you please also test if you get the same issue with crazycat disabled and the standard kernel drivers?

    so long,

    Hias

  • Can you please post a link to your full dmesg dmesg | paste and the output of ir-keytable

    here is dmesg|paste and ir-keytable while crazycat drivers are activated -which I'm actually using now-

    http://ix.io/1pba

    Code
    libreelec:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event1) with:
            Name: TechnoTrend TT-connect S2-4600
            Driver: dw2102, table: rc-tt-1500
            lirc device: /dev/lirc0
            Supported protocols: rc-5
            Enabled protocols: rc-5
            bus: 3, vendor/product: 0b48:3011, version: 0x0000
            Repeat delay = 500 ms, repeat period = 125 ms

    If I disable crazycat drivers and use the standard kernel the tuner will not work and the remote control is working but with the same problem

    http://ix.io/1pbb

    Code
    libreelec:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event1) with:
            Name: TechnoTrend TT-connect S2-4600
            Driver: dw2102, table: rc-tt-1500
            lirc device: /dev/lirc0
            Supported protocols: rc-5
            Enabled protocols: rc-5
            bus: 3, vendor/product: 0b48:3011, version: 0x0000
            Repeat delay = 500 ms, repeat period = 125 ms
  • Can you check if this build fixes the IR repeat issues?

    libreelec-rpi2.arm-9.0-devel-20181020140428-bd467bb.tar

    Yes it does^^. The autorepeat issue has been fixed, not 100% though I still encounter it like every 20 presses but it is much much better now. The remote is a little bit sluggish but I can live with that, I would love to know what have you done so I can tune it to my preferences. But it is 100% usable.

    It is worth to mention that it does still generate 2 scancodes for every press but somehow it is handled nicely this time.

    On the other hand the driver of the tuner crashes with standard kernel or crazycat drivers :(. I used this Img for RP3 before to get it to work

    Index of /test/ds3103b/

    here is a dmesg|paste with standard kernel activated

    http://ix.io/1pdd

    And this is with crazycat Drivers activated

    http://ix.io/1pde

    and the ir-keytable looks like this in both cases

    Code
    LibreELEC:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event1) with:
            Name: TechnoTrend TT-connect S2-4600
            Driver: dw2102, table: rc-tt-1500
            lirc device: /dev/lirc0
            Supported protocols: rc-5
            Enabled protocols: rc-5
            bus: 3, vendor/product: 0b48:3011, version: 0x0000
            Repeat delay = 500 ms, repeat period = 125 ms

    I almost forgot to mention that also ir-ctl -t 150000 returns the same thing as above in previous post.

    Edited once, last by Softlander (October 20, 2018 at 10:46 PM).

  • Thanks a lot for testing!

    I added this kernel patch to set the timeout to the poll interval - basically the same thing that ir-ctl -t would have done (sorry, forgot that the timeout can't be configured on all devices)

    Diff
    --- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
    +++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
    @@ -285,6 +285,7 @@ static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d)
         dev->dev.parent = &d->udev->dev;
         dev->priv = d;
         dev->scancode_mask = d->props.rc.core.scancode_mask;
    +    dev->timeout = MS_TO_NS(d->props.rc.core.rc_interval);
     
         err = rc_register_device(dev);
         if (err < 0) {

    Here's the LibreELEC tree I built from: GitHub - HiassofT/LibreELEC.tv at le9-dvb-usb-ir-repeat

    This patch was just a quick test to see if it helps on your receiver, in it's current state it will break IR remotes on dvb-usb remotes with long query interval (there are some that query every 400ms or even only once per second).

    I'll have a look at that and should hopefully come up with a proper patch that I can also send upstream. BTW: the sluggishness comes from the 250ms query interval, you'll get a lot better performance from a standard MCE USB receiver or a GPIO receiver on an RPi. Quite a lot of dvb-usb dongles seem to use a 50ms remote query interval, with these the remote should be quite snappy and not suffer from the repeat issues you had, even on stock kernels.

    I can't comment on the tuner crashes, this isn't my area, maybe CvH can help there.

    so long,

    Hias

  • Thanks a lot for your help. Unfortunately I don't have much knowledge in Linux and every thing I learned was from troubleshooting the tt-4600 every once in a while since the moment I bought it and I know it is nothing but a single drop in the sea of Linux. Terms like "poll interval", "upstream", and "libreelec tree" look difficult to understand for me^^ but any way, If I have a working driver on some Img, will I be able to apply your patch to it?

    Another question If you may since this is your area of experience, what do you recommend as a good remote control to be used in KODI environment that is not too expensive or too cheap?

    Thanks a gain for your help

  • Sorry for using too technical terms, the simple version is: the remote is queried only 4 times a second on your DVB dongle and that results in it being sluggish (there's probably not much we can do about that) and the repeat issues (that's a problem with all current kernels and I'll look into finding a solution - could be a bit tricky and may take some time).

    As for remotes: I'd recommend using an official (or fully compatible like the HP branded ones) MCE remote together with the HP branded USB MCE IR receiver from ebay for about 15-20 EUR shipped. Official MCE remotes are the ones best supported in Linux and LibreELEC and the HP USB IR receiver works very well too and can be used with all kinds of other remotes as well - I have these here and regularly test with them.

    Be careful when searching for MCE remotes on ebay or other shopping sites, there are a lot remotes advertised as "MCE" that don't follow the rc-6 MCE protocol. Same thing applies for "MCE USB IR receivers", some of them, like the cheap TopSeed receivers that are often advertised on ebay, have nasty bugs - better stay away from them and go for the known-good HP branded one.

    Another cheap and very versatile option on RPi is to connect a TSOP 34138 IR receiver to the GPIO pins. For about 1-2 EUR/USD you'll have a full-fledged IR receiver that's very well supported in Linux/LibreELEC. This is what I'm using on my main RPi. The only gotcha is that some USB DVB dongles seem to interfere with it (low-level timing issues caused by the RPi's USB driver) - I haven't experienced such issues myself and also don't know if you'd be affected by that or not.

    so long,

    Hias

  • Thanks for both of you for the recommendations, definitely I'm gonna try one of them. On the other hand I will wait for the fix mentioned above to be updated in the upcoming images of Libreelec.

    Regards