TechnoTrend TT-connect CT-3650 CI: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
(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 v0.25). According to the developer of the driver, the CI should also work fine when using VDR for playback.
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 ==
== lsusb -t ==
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>
# 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
/: 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>


=== OK ===
=== 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''

== IR keymap ==


Since this keymap starts at 0x1501 `input-kbd` cannot modify this keymap (on Linux 3.2).
== keymap ==


<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.tt-pc.com/2916/TT-connect__CT-3650_CI.html CT-3650 CI product page]
* [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

TT-connect CT-3650 CI.jpg

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

External Links