TechnoTrend TT-connect CT-3650 CI: Difference between revisions
Jump to navigation
Jump to search
Henk Poley (talk | contribs) (→Wrong) |
(Cleanup the page with more descriptive headings) |
||
| (17 intermediate revisions by one other user not shown) | |||
| Line 32: | Line 32: | ||
</pre> |
</pre> |
||
Beware that the initialization of the CAM in most cases will fail as seen above ("Invalid PC card inserted") due to the CAM being in sleep-mode. Once an application requests to use the CAM, it will wake up and get initialized automatically. The CI has been tested to work successfully with a DVB-T Viaccess 4.0 CAM (BoxerTV DK branded) and MythTV (v0.24 and |
Beware that the initialization of the CAM in most cases will fail as seen above ("Invalid PC card inserted") due to the CAM being in sleep-mode. Once an application requests to use the CAM, it will wake up and get initialized automatically. The CI has been tested to work successfully with a DVB-T Viaccess 4.0 CAM (BoxerTV DK branded) and MythTV (v0.24-0.26); and AlphaCrypt Classic with MythTV 0.24-0.26. According to the developer of the driver, the CI should also work fine when using VDR for playback. |
||
Many applications for DVB playback currently doesn't support the structure of the combined tuner, eg. with each DVB-C/T tuner having their own frontend devices (/dev/dvb/adaptor0/frontend0 and /dev/dvb/adaptor0/frontend1) while the other devices are shared between the tuners (/dev/dvb/adaptor0/demux0 exists, but there's no demux1). In such cases it might be needed to make a workaround with symbolic links, as mentioned in [http://www.mail-archive.com/linux-media@vger.kernel.org/msg43015.html this mail on the linux-media list]. |
Many applications for DVB playback currently doesn't support the structure of the combined tuner, eg. with each DVB-C/T tuner having their own frontend devices (/dev/dvb/adaptor0/frontend0 and /dev/dvb/adaptor0/frontend1) while the other devices are shared between the tuners (/dev/dvb/adaptor0/demux0 exists, but there's no demux1). In such cases it might be needed to make a workaround with symbolic links, as mentioned in [http://www.mail-archive.com/linux-media@vger.kernel.org/msg43015.html this mail on the linux-media list]. |
||
== Troubleshooting USB bandwidth issues == |
|||
| ⚫ | |||
The tuner is a USB 2.0 tuner, so connecting the tuner through an USB 1.1 interface will result in performance issues: |
|||
=== Wrong === |
=== Wrong USB configuration === |
||
With this setup you will have bandwidth problems with no warning whatsoever. Except that video will look horrible. |
With this setup you will have bandwidth problems with no appropriate warning whatsoever on any log file. Except that video will look horrible. |
||
<pre> |
<pre> |
||
| ⚫ | |||
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M |
|||
/: Bus |
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/8p, 12M <-- USB1.1, slow, don't us |
||
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/8p, 12M |
|||
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M <-- one bus |
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M <-- one bus |
||
|__ Port 2: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- 1st DVB device, shares bandwidth |
|__ Port 2: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- 1st DVB device, shares bandwidth |
||
|__ Port 4: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- 2nd DVB device, shares bandwidth |
|__ Port 4: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- 2nd DVB device, shares bandwidth |
||
</pre> |
</pre> |
||
=== |
=== Correct USB configuration === |
||
You can solve the above situation by using an USB 2.0 connection or adding for example a PCI-Express to USB3.0 card: |
|||
<pre> |
<pre> |
||
# lsusb -t |
|||
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M |
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M |
||
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M <-- one bus |
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M <-- one bus |
||
|__ Port 2: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- one DVB device |
|__ Port 2: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- one DVB device |
||
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/8p, 12M <-- USB1.1, slow, don't use |
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/8p, 12M <-- USB1.1, slow, don't use |
||
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M <-- one bus |
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M <-- one bus |
||
|__ Port 4: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- one DVB device |
|__ Port 4: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- one DVB device |
||
</pre> |
</pre> |
||
Rule: One device per bus |
'''''Rule''': One device per bus'' |
||
| ⚫ | |||
Since this keymap starts at 0x1501 `input-kbd` cannot modify this keymap (on Linux 3.2). |
|||
| ⚫ | |||
<pre>$ sudo input-kbd 3 |
<pre>$ sudo input-kbd 3 |
||
| Line 75: | Line 79: | ||
map: 39 keys, size: 39/64 |
map: 39 keys, size: 39/64 |
||
0x1501 = 116 # KEY_POWER |
0x1501 = 116 # KEY_POWER |
||
0x1502 = 410 # KEY_SHUFFLE |
0x1502 = 410 # KEY_SHUFFLE <-- above the 256 keys limit of X11 |
||
0x1503 = 2 # KEY_1 |
0x1503 = 2 # KEY_1 |
||
0x1504 = 3 # KEY_2 |
0x1504 = 3 # KEY_2 |
||
| Line 88: | Line 92: | ||
0x150d = 103 # KEY_UP |
0x150d = 103 # KEY_UP |
||
0x150e = 105 # KEY_LEFT |
0x150e = 105 # KEY_LEFT |
||
0x150f = 352 # KEY_OK |
0x150f = 352 # KEY_OK <-- above the 256 keys limit of X11 |
||
0x1510 = 106 # KEY_RIGHT |
0x1510 = 106 # KEY_RIGHT |
||
0x1511 = 108 # KEY_DOWN |
0x1511 = 108 # KEY_DOWN |
||
0x1512 = 358 # KEY_INFO |
0x1512 = 358 # KEY_INFO <-- above the 256 keys limit of X11 |
||
0x1513 = 174 # KEY_EXIT |
0x1513 = 174 # KEY_EXIT |
||
0x1514 = 398 # KEY_RED |
0x1514 = 398 # KEY_RED <-- above the 256 keys limit of X11 |
||
0x1515 = 399 # KEY_GREEN |
0x1515 = 399 # KEY_GREEN <-- above the 256 keys limit of X11 |
||
0x1516 = 400 # KEY_YELLOW |
0x1516 = 400 # KEY_YELLOW <-- above the 256 keys limit of X11 |
||
0x1517 = 401 # KEY_BLUE |
0x1517 = 401 # KEY_BLUE <-- above the 256 keys limit of X11 |
||
0x1518 = 113 # KEY_MIN_INTERESTING |
0x1518 = 113 # KEY_MIN_INTERESTING <-- mute |
||
0x1519 = 388 # KEY_TEXT |
0x1519 = 388 # KEY_TEXT <-- above the 256 keys limit of X11 |
||
0x151a = 373 # KEY_MODE |
0x151a = 373 # KEY_MODE <-- above the 256 keys limit of X11 |
||
0x1521 = 357 # KEY_OPTION |
0x1521 = 357 # KEY_OPTION <-- above the 256 keys limit of X11 |
||
0x1522 = 365 # KEY_EPG |
0x1522 = 365 # KEY_EPG <-- above the 256 keys limit of X11 |
||
0x1523 = 402 # KEY_CHANNELUP |
0x1523 = 402 # KEY_CHANNELUP <-- above the 256 keys limit of X11 |
||
0x1524 = 403 # KEY_CHANNELDOWN |
0x1524 = 403 # KEY_CHANNELDOWN <-- above the 256 keys limit of X11 |
||
0x1525 = 115 # KEY_VOLUMEUP |
0x1525 = 115 # KEY_VOLUMEUP |
||
0x1526 = 114 # KEY_VOLUMEDOWN |
0x1526 = 114 # KEY_VOLUMEDOWN |
||
| Line 115: | Line 119: | ||
==External Links== |
==External Links== |
||
* [http://www. |
* [http://www.technotrend.eu/2914/TT-connect__CT-3650_CI.html CT-3650 CI product page] |
||
[[Category:DVB-C USB Devices]] |
[[Category:DVB-C USB Devices]] |
||
Latest revision as of 20:16, 16 June 2013
A combined DVB-C and DVB-T USB 2.0 device from TechnoTrend with integrated CI.
Driver support
Both the DVB-C and DVB-T part of the tuner are supported in current kernels. As of kernel 3.2, the CI interface is now also supported and can be used to decrypt pay-TV with the use of a CAM.
Log from initialization on kernel 3.2.5:
[ 9528.631071] usb 2-1.1: new high-speed USB device number 5 using ehci_hcd [ 9529.289469] IR NEC protocol handler initialized [ 9529.293534] IR RC5(x) protocol handler initialized [ 9529.296526] IR RC6 protocol handler initialized [ 9529.298099] dvb-usb: found a 'Technotrend TT-connect CT-3650' in warm state. [ 9529.298676] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 9529.298682] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 9529.298960] DVB: registering new adapter (Technotrend TT-connect CT-3650) [ 9529.299433] IR JVC protocol handler initialized [ 9529.302624] IR Sony protocol handler initialized [ 9529.308074] IR MCE Keyboard/mouse protocol handler initialized [ 9529.312022] lirc_dev: IR Remote Control driver registered, major 248 [ 9529.313240] IR LIRC bridge handler initialized [ 9529.315511] ttusb2: CI initialized. [ 9529.315520] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [ 9529.336842] DVB: registering adapter 0 frontend 1 (NXP TDA10048HN DVB-T)... [ 9529.362972] Registered IR keymap rc-tt-1500 [ 9529.363171] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/rc/rc0/input15 [ 9529.363616] rc0: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/rc/rc0 [ 9529.363623] dvb-usb: schedule remote query interval to 150 msecs. [ 9529.364156] dvb-usb: Technotrend TT-connect CT-3650 successfully initialized and connected. [ 9529.364198] usbcore: registered new interface driver dvb_usb_ttusb2 [ 9536.512472] dvb_ca adapter 0: Invalid PC card inserted :(
Beware that the initialization of the CAM in most cases will fail as seen above ("Invalid PC card inserted") due to the CAM being in sleep-mode. Once an application requests to use the CAM, it will wake up and get initialized automatically. The CI has been tested to work successfully with a DVB-T Viaccess 4.0 CAM (BoxerTV DK branded) and MythTV (v0.24-0.26); and AlphaCrypt Classic with MythTV 0.24-0.26. According to the developer of the driver, the CI should also work fine when using VDR for playback.
Many applications for DVB playback currently doesn't support the structure of the combined tuner, eg. with each DVB-C/T tuner having their own frontend devices (/dev/dvb/adaptor0/frontend0 and /dev/dvb/adaptor0/frontend1) while the other devices are shared between the tuners (/dev/dvb/adaptor0/demux0 exists, but there's no demux1). In such cases it might be needed to make a workaround with symbolic links, as mentioned in this mail on the linux-media list.
Troubleshooting USB bandwidth issues
The tuner is a USB 2.0 tuner, so connecting the tuner through an USB 1.1 interface will result in performance issues:
Wrong USB configuration
With this setup you will have bandwidth problems with no appropriate warning whatsoever on any log file. Except that video will look horrible.
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/8p, 12M <-- USB1.1, slow, don't us
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M <-- one bus
|__ Port 2: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- 1st DVB device, shares bandwidth
|__ Port 4: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- 2nd DVB device, shares bandwidth
Correct USB configuration
You can solve the above situation by using an USB 2.0 connection or adding for example a PCI-Express to USB3.0 card:
# lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M <-- one bus
|__ Port 2: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- one DVB device
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/8p, 12M <-- USB1.1, slow, don't use
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M <-- one bus
|__ Port 4: Dev 2, If 0, Class=vend., Driver=dvb_usb_ttusb2, 480M <-- one DVB device
Rule: One device per bus
IR keymap
Since this keymap starts at 0x1501 `input-kbd` cannot modify this keymap (on Linux 3.2).
$ sudo input-kbd 3 /dev/input/event3 bustype : BUS_USB vendor : 0xb48 product : 0x300d version : 257 name : "IR-receiver inside an USB DVB re" phys : "usb-0000:00:0b.1-4/ir0" bits ev : EV_SYN EV_KEY EV_MSC EV_REP map: 39 keys, size: 39/64 0x1501 = 116 # KEY_POWER 0x1502 = 410 # KEY_SHUFFLE <-- above the 256 keys limit of X11 0x1503 = 2 # KEY_1 0x1504 = 3 # KEY_2 0x1505 = 4 # KEY_3 0x1506 = 5 # KEY_4 0x1507 = 6 # KEY_5 0x1508 = 7 # KEY_6 0x1509 = 8 # KEY_7 0x150a = 9 # KEY_8 0x150b = 10 # KEY_9 0x150c = 11 # KEY_0 0x150d = 103 # KEY_UP 0x150e = 105 # KEY_LEFT 0x150f = 352 # KEY_OK <-- above the 256 keys limit of X11 0x1510 = 106 # KEY_RIGHT 0x1511 = 108 # KEY_DOWN 0x1512 = 358 # KEY_INFO <-- above the 256 keys limit of X11 0x1513 = 174 # KEY_EXIT 0x1514 = 398 # KEY_RED <-- above the 256 keys limit of X11 0x1515 = 399 # KEY_GREEN <-- above the 256 keys limit of X11 0x1516 = 400 # KEY_YELLOW <-- above the 256 keys limit of X11 0x1517 = 401 # KEY_BLUE <-- above the 256 keys limit of X11 0x1518 = 113 # KEY_MIN_INTERESTING <-- mute 0x1519 = 388 # KEY_TEXT <-- above the 256 keys limit of X11 0x151a = 373 # KEY_MODE <-- above the 256 keys limit of X11 0x1521 = 357 # KEY_OPTION <-- above the 256 keys limit of X11 0x1522 = 365 # KEY_EPG <-- above the 256 keys limit of X11 0x1523 = 402 # KEY_CHANNELUP <-- above the 256 keys limit of X11 0x1524 = 403 # KEY_CHANNELDOWN <-- above the 256 keys limit of X11 0x1525 = 115 # KEY_VOLUMEUP 0x1526 = 114 # KEY_VOLUMEDOWN 0x1527 = 141 # KEY_SETUP 0x153a = 167 # KEY_RECORD 0x153b = 207 # KEY_PLAY 0x153c = 128 # KEY_STOP 0x153d = 168 # KEY_REWIND 0x153e = 119 # KEY_PAUSE 0x153f = 159 # KEY_FORWARD