DVB via USB: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
mNo edit summary
 
(12 intermediate revisions by 6 users not shown)
Line 1: Line 1:
For information about supported devices, see an article under the appropriate device category (e.g. DVB-T, ATSC,...)
For information about supported USB devices, see the appropriate device category: <BR>
* [[ATSC USB Devices]]
and then classification (USB) section. For USB:<BR>
* [[DVB-T USB Devices]]
* [[DVB-C USB Devices]]
* [[DVB-C USB Devices]]
* [[DVB-S USB Devices]]
* [[DVB-S USB Devices]]
* [[DVB-S2 USB Devices]]
* [[ATSC USB Devices]]
* [[DVB-T USB Devices]]
* [[Work-in-progress and new USB Devices]]
* [[DVB-T2 USB Devices]]
<BR>
Please help to keep these lists up-to-date so that they are useful for everyone!

Here is an (non-exhaustive) overview of DVB/ATSC USB devices. Generally, when it comes to support for USB devices, it is a good idea to try the [http://linuxtv.org/repo/ current Hg sources] because some device drivers can be very new and thus may have not made their way into the mainstream kernel.


__TOC__
__TOC__

==Introduction==
==Introduction==
'''For all devices shown below you need to load (if not compiled into the kernel):'''
'''For all DVB USB devices you will need to load (if not compiled into the kernel):'''
- i2c-core
* i2c-core
- crc32
* crc32
- firmware_class
* firmware_class
- dvb-core.ko
* dvb-core.ko
- dvb-pll.ko
* dvb-pll.ko
and maybe others too. If the loading fails for any particular module you'll get a "unknown symbol" message. Then have a look at dmesg to find out, which symbols (functions) are missing. After you've found out which module was absent, please come back here and add it to the list/device-entry.
and maybe others too. If the loading fails for any particular module you'll get a "unknown symbol" message. Then have a look at dmesg to find out, which symbols (functions) are missing. After you've found out which module was absent, please come back here and add it to the list/device-entry.


Line 33: Line 29:
== Firmware ==
== Firmware ==


Most of the USB devices need firmware to run. Some of the firmware files can be downloaded from [http://www.linuxtv.org/downloads/firmware/ here] or [http://www.thadathil.net/dvb/fw/ here].
Most of the USB devices need firmware to run. Some of the firmware files can be downloaded from [http://www.linuxtv.org/downloads/firmware/ here].


You need to copy the firmware to the correct place on your system. This will normally be /lib/firmware or a folder below it. Here is an example:
You need to copy the firmware to the correct place on your system. This will normally be /lib/firmware or a folder below it. Here is an example:
Line 56: Line 52:
In this case, I have success, because the firmware was loaded.
In this case, I have success, because the firmware was loaded.


Remember that on some system the firmware is loaded by udev, so if for some reason the firmware is not loaded you may check that
== Additional technical information ==
udev is acutally running.
To check you could for example issue the command:
- $ ps -e | grep udev

If the output is empty, then you have to restart the udev daemon. For example in a Debian based system you may try with:
- $ sudo /etc/init.d/udev restart

then try again, removing and inserting the module again with modprobe.

== Additional Technical Information ==


This section starts describing devices which hit the market beginning of spring 2004. It does not cover TTUSB-based devices.
This section starts describing devices which hit the market beginning of spring 2004. It does not cover TTUSB-based devices.


=== DVB-USB devices host-controlled ===
=== Host Controlled DVB USB Devices ===


When first AC-Adapter-free USB devices (with the capability of receiving DVB Signals) hit the market, every vendor was using the generic USB-device-controller from Cypress (FX1 (AN2135/AN2235), FX2) as an interface between the DVB-hardware and the host.
When first AC-Adapter-free USB devices (with the capability of receiving DVB Signals) hit the market, every vendor was using the generic USB-device-controller from Cypress (FX1 (AN2135/AN2235), FX2) as an interface between the DVB-hardware and the host.
Line 66: Line 72:
As those controllers are very generic, one has to create (and download) an (small or not so small) embedded software to those controller to give vendor-specific and the wanted functionality. After downloading the so-called firmware vendors used the reboot-feature of the controller to re-enumerate with new USB Vendor/Product-IDs and a new USB-layout. On the host this looks like a normal disconnect and connect of an USB device.
As those controllers are very generic, one has to create (and download) an (small or not so small) embedded software to those controller to give vendor-specific and the wanted functionality. After downloading the so-called firmware vendors used the reboot-feature of the controller to re-enumerate with new USB Vendor/Product-IDs and a new USB-layout. On the host this looks like a normal disconnect and connect of an USB device.


Because the memory for storing the firmware was limited, vendors decided not to put any DVB-demodulator and RF-tuner specific code into the firmware, but only to implement interface functionality. At that time, the common way to control other components was [[I2C]]. The other necessary feature was data-streaming. With such a firmware, every functionality is done from the host - mainly the driving of the demodulator and the tuner.
Because the memory for storing the firmware was limited, vendors decided not to put any DVB-demodulator and RF-tuner specific code into the firmware, but only to implement interface functionality. At that time, the common way to control other components was [[I²C Protocol|I²C]]. The other necessary feature was data-streaming. With such a firmware, every functionality is done from the host - mainly the driving of the demodulator and the tuner.


Host-controlled devices are the ones based on DiBcom (dibusb, dib0700), Nebula (DigiTV), Hanftek and others. (see below)
Host-controlled devices are the ones based on DiBcom (dibusb, dib0700), Nebula (DigiTV), Hanftek and others. (see below)


=== Firmware Controlled DVB USB Devices===
=== DVB-USB device firmware-controlled ===


Another approach was coming later: When it started, that putting more memory on a board/into an IC with almost no increase of the [[BOM]]. Vendors started to put the demodulator and tuner-driver into the firmware. This was simplifying the host-part dramatically, because if you have a new hardware, you just need to modify the (platform-independent) firmware part and, as long as the firmware-interface is not changing, the host-driver stays the same.
Another approach was coming later: When it started, that putting more memory on a board/into an IC with almost no increase of the [[BOM]]. Vendors started to put the demodulator and tuner-driver into the firmware. This was simplifying the host-part dramatically, because if you have a new hardware, you just need to modify the (platform-independent) firmware part and, as long as the firmware-interface is not changing, the host-driver stays the same.


Firmware-controlled devices: Twinhan VP7045/VP7021, Terratec Cinergy T2, Wideview and others.
Firmware-controlled devices: Twinhan VP7045/VP7021, Terratec Cinergy T2, Wideview and others.

To be continued ...


== lsusb -t ==

=== Wrong ===
With this setup you will have bandwidth problems with no appropriate warning whatsoever on any log file. Except that video will look horrible.
<pre>
/: 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
</pre>

=== OK ===
You can solve the above situation by adding a PCI-Express to USB3.0 card:
<pre>
/: 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
</pre>

'''''Rule''': One device per bus''




[[Category:DVB-T|!USB devices DVB-T]]
[[Category:Hardware| ]]
[[Category:Hardware|!USB devices DVB-T]]

Latest revision as of 10:13, 3 December 2012

For information about supported USB devices, see the appropriate device category:


Introduction

For all DVB USB devices you will need to load (if not compiled into the kernel):

  • i2c-core
  • crc32
  • firmware_class
  • dvb-core.ko
  • dvb-pll.ko

and maybe others too. If the loading fails for any particular module you'll get a "unknown symbol" message. Then have a look at dmesg to find out, which symbols (functions) are missing. After you've found out which module was absent, please come back here and add it to the list/device-entry.

The Type field specifies the USB standard(s) supported by the device.

USB1.1
The device supports USB 1.1 only, and will work at 1.1 speeds when attached to a USB 2.0 port.
USB2.0
The device supports USB 2.0 only, and will not work when attached to a USB 1.1-only port. Such devices are normally capable of delivering the complete Transport Stream to the software demuxer.
USB2.0, USB1.1
The device supports USB 1.1 and USB 2.0, and will work at any speed supported by 1.1 or 2.0. When running in USB 2.0 mode, such devices can deliver the complete Transport Stream (unless specified otherwise).

Firmware

Most of the USB devices need firmware to run. Some of the firmware files can be downloaded from here.

You need to copy the firmware to the correct place on your system. This will normally be /lib/firmware or a folder below it. Here is an example:

- $ cd /lib/firmware
- $ ls
- 2.6.15-23-amd64-xeon
- $ cd 2.6.15-23-amd64-xeon
- $ sudo cp ~/dvb-usb-umt-010-02.fw .

Now, you need to unplug your USB device. Plug it in again, and then take a look at dmesg.

- $ dmesg
- < ...... lines cut for clarity ..... >
- usb 5-2: USB disconnect, address 3
- usb 5-2: new high speed USB device using ehci_hcd and address 8
- dvb-usb: found a 'Hanftek UMT-010 DVB-T USB2.0' in cold state, will try to load a firmware
- dvb-usb: downloading firmware from file 'dvb-usb-umt-010-02.fw' to the 'Cypress FX2'
- dvb-usb: Hanftek UMT-010 DVB-T USB2.0 successfully initialized and connected.
- usb 5-2: USB disconnect, address 8
- dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.

In this case, I have success, because the firmware was loaded.

Remember that on some system the firmware is loaded by udev, so if for some reason the firmware is not loaded you may check that udev is acutally running. To check you could for example issue the command:

- $ ps -e | grep udev

If the output is empty, then you have to restart the udev daemon. For example in a Debian based system you may try with:

- $ sudo /etc/init.d/udev restart

then try again, removing and inserting the module again with modprobe.

Additional Technical Information

This section starts describing devices which hit the market beginning of spring 2004. It does not cover TTUSB-based devices.

Host Controlled DVB USB Devices

When first AC-Adapter-free USB devices (with the capability of receiving DVB Signals) hit the market, every vendor was using the generic USB-device-controller from Cypress (FX1 (AN2135/AN2235), FX2) as an interface between the DVB-hardware and the host.

As those controllers are very generic, one has to create (and download) an (small or not so small) embedded software to those controller to give vendor-specific and the wanted functionality. After downloading the so-called firmware vendors used the reboot-feature of the controller to re-enumerate with new USB Vendor/Product-IDs and a new USB-layout. On the host this looks like a normal disconnect and connect of an USB device.

Because the memory for storing the firmware was limited, vendors decided not to put any DVB-demodulator and RF-tuner specific code into the firmware, but only to implement interface functionality. At that time, the common way to control other components was I²C. The other necessary feature was data-streaming. With such a firmware, every functionality is done from the host - mainly the driving of the demodulator and the tuner.

Host-controlled devices are the ones based on DiBcom (dibusb, dib0700), Nebula (DigiTV), Hanftek and others. (see below)

Firmware Controlled DVB USB Devices

Another approach was coming later: When it started, that putting more memory on a board/into an IC with almost no increase of the BOM. Vendors started to put the demodulator and tuner-driver into the firmware. This was simplifying the host-part dramatically, because if you have a new hardware, you just need to modify the (platform-independent) firmware part and, as long as the firmware-interface is not changing, the host-driver stays the same.

Firmware-controlled devices: Twinhan VP7045/VP7021, Terratec Cinergy T2, Wideview and others.

To be continued ...


lsusb -t

Wrong

With this setup you will have bandwidth problems with no appropriate warning whatsoever on any log file. Except that video will look horrible.

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

OK

You can solve the above situation by adding a PCI-Express to USB3.0 card:

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