Afatech AF9015
A DVB-T demodulator from Afatech. This is the company's second generation COFDM demodulator, and is the successor to the AF900x family of chips.
The AF901x family consists of the following chips:
- (list chips here)
The AF9015 chip is the main USB control/demux in found in some currently available DVB-T USB devices, such as:
- 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)
The AF9015 chip is fairly complex and supports 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.
Drivers
At present there are three different drivers 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 being, and collectively they highlight the relative complexity of the chip and the flexibility in device design that its usage 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. (It was from that leaked driver that Antti was able to largely base/ and derive his RE attempts; see above discussion).
In any regard, users have reported that this vendor driver is indeed working, including for x64_64 (for some further information see the threads here and here.
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:
replace
typedef unsigned long UData_t;
with
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.
External Links
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.
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
- Hot Plug
- and then: Snooping the USB Data Stream
Also get the source for V4L-DVB:
You will find the usb drivers are in ./v4l-dvb/linux/drivers/media/dvb/dvb-usb. Have a bit of a browse through them while you're reading through the first article above, get a feel for how the driver is put together (There is a procedure described in a thread found here).
Sometimes you can get a good head start in your development efforts by attempting to leverage parts of earlier released code -- that which may have been written specificly 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. Modifying existing code to suite your own endeavour can greatly expediate the process of driver development.