A combination DVB-T demodulator and USB bridge chip from Afatech. This is the company's second generation COFDM demodulator, and is the successor to the AF900x family of chips. Given the chip's dual nature, the AF9015 is fairly complex. It is also very flexible, supporting a wide variety of device configurations (single USB, dual USB, Platform mode, PCI/PCIe based devices, and even SPI is supported by it with some tuners (such as for a Consumer Electronics product that runs Windows CE)). Documentation for the AF901x family can be obtained from AFA (under NDA), but it is apparently confusing, as well as incomplete -- as there are a lot of areas that are undocumented.
The AF901x family consists of the following chips:
- (list chips here ...or perhaps start a new article for the AF901x family, and leave this one dedicated to the AF9015)
Examples of DVB-T USB devices in which the AF9015 chip can be found include:
- Dongles with USB ID 15a4:9016 or 15a4:9015
- The WandTV (QT1010)
- The Elements High Definition DVB-T Receiver Model no DK-5203.
- A-Link DTU(m) (15a4:9016, MT2060)
- Fujitech (15a4:9016)
- TubeStick (15a4:9015) (Mac)
- Geniatech T328B (15a4:9016, QT1010)
- BestBuy Easy TV USB Stick (MT2061)
- DENVER DVBT-2U (15a4:9016, MT2060(F))
At present there are three different Linux drivers available for the AF901x. That may strike one as being strange or showing signs of a state of dis-coordination, but in actuality, each driver has its own reason for coming into existence. In addition, taken collectively, the development of three different drivers highlights the relative complexity of the chip, as well as the flexibility in device design that its employment permits.
Opensource Mercurial Repositories
- http://jusst.de/hg/af901x ... This is a second driver attempt for the AF901x by Manu Abrahams. In his personal assessment, he got many things right, but some things are still wrong. In addition, his driver works with just one particular device
- http://linuxtv.org/hg/~anttip/af9015/ (Supported tuners are: MT2060, MT2061 and QT1010.) ... This is a driver written from scratch, first by reverse engineering and afterwards finalized from the reference kit, by Antti Palosaari, that is specific to the AF9015 chip alone, and for device's with a "MASTER based configuration".
Vendor Released Driver
- A vendor-written driver specific to the AF9015 chip alone is available from http://af.zsolttech.com/. Apparently, AFA had this driver written (authour, Rick Huang?) specifically for a single device from one customer, who then in turn ended up violating the NDA.
For devices based on the MT2060 tuner (such as the Geniatech T328B) you may need to patch the file MT2060M.h in the following way:
typedef unsigned long UData_t;
typedef unsigned int UData_t;
Then compile, install, modprobe dvb_usb_af9015 and you are finished.
A Comprehensive OSS Driver
For its part, Afatech does not want any of the above driver attempts to make their way into the kernel, as none of them are very robust in terms of chip support.
Instead, AFA has embarked upon the development of yet another OSS driver, which will be generic in that it will be capable of supporting the entire AF901x family as well as all possible device configurations permitted. In addition to the expectation that it will be this driver that is eventually adopted into the kernel, AFA have also signaled that they intend provide continuous support (i.e. they will stay on as the driver's maintainer).
Currently, this newest driver has reached a second round of testing in AFA labs, but that has only been in conjunction (with some peripheral manufacturers) with a few devices, and, as it stands, the code is still not particularly generic (due to both the complexities of the chip itself as well as those involved in getting the various device configurations to work). So, as of yet, there currently isn't anything for the end user to test. However, as soon things progress past this stage, there will be something released for users to test. There is no specific release timeframe set for this, but hopefully it will be soon, as the chip manufacturer (as well as everybody else involved) is under pressure, due to the large adoption of the chip by different peripheral manufacturers (Avermedia, Terratec, Azurewave, DigitalNow, Pinnacle, as well as some number of unbranded Chinese manufacturers too). In short, a lot more devices based on this chipset are expected to materialize.
This article is meant to serve as an introduction to the task of developing a driver for a usb based dvb device. Currently, in terms of this subject, there are a number of scattered resources available that, when organized together, could form the basis of a howto suitable for the noice developer. Hence, it might be very worthwile documenting the process.
The very first thing you would want to do is to identify the components used in your device. Refer to the section entitled "Gathering Information About Your Unidentified/Unsupported Device" for some clues on how to proceed with that task.
The next logical step would be to try to obtain technical datasheets on the components. Many chip manufacturers make this documentation readiablily available, while in other cases a google search for the chip's part or model number is necessary to track down other sources for such documentation.
Familiarizing yourself with a USB driver
To start with, there are some great Linux USB tutorials on Linux Journal:
- start here: How to Write a Linux USB Device Driver
- then here: Writing a Simple USB Driver
- here: Hot Plug
- and then here: Snooping the USB Data Stream
In addition, get the source code for the LinuxTV V4L-DVB driver set. You will find that USB based DVB drivers are contained within the ./v4l-dvb/linux/drivers/media/dvb/dvb-usb directory. Have a bit of a browse through them while you're reading through the first article listed above, and try to get a feel for how the driver is put together (note: there is also a procedure about this that is described in a thread found here). Sometimes you can get a good head start in your own development efforts by attempting to leverage parts of earlier released code -- that which may have been written specifically for the exact same chip as contained in your own device or via code for a near similar chip, such as say from a previous production generation. Simply, modifying existing code to suite your own endeavour can greatly expediate the process of driver development.
Some useful tools
- usbsnoop - a Windows USB sniffer utilitly, which adheres to the WDM architecture
- also see SniffUSB 2.0 - a usbsnoop derivative
- parser.pl - a script for parsing the huge usbsniff log file
- USB Replay - allows one to replay parsed usbsnoop logfiles on a Linux system
- also see this M920x specific script for some ideas
- Usbmon2usbsnoop - a script that converts the output from usbmon to a format that is compatible with USB Replay