DVB via USB

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

• ATSC USB Devices
• DVB-C USB Devices
• DVB-S USB Devices
• DVB-S2 USB Devices
• DVB-T USB Devices
• DVB-T2 USB Devices

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