Xceive XC3028/XC2028
This article discusses a family of silicon ICs, produced by Xceive, that combine RF tuner and analog IF demodulator functions within one chip. In addition, this page addresses the drivers that support these chips, as well as their firmware requirements.
IC Family Members
XC3028
The XC3028 has robust support for both analog and digital signals; it supports the analog TV broadcast standards (NTSC, PAL, & SECAM), CVBS, SIF and most digital TV standards (ATSC, DVB-C, DVB-T, DMB-T, & ISDB-T).
The XC3028 IC is found in a large number of devices. There is also a low power variant of the chip available, the 3028L; which requires a different firmware then the "plain vannila" version (instruction on obtaining it are found below).
XC3018
The XC3018 is a lesser version of the XC3028; it supports only the analog TV broadcast standards (NTSC, PAL, & SECAM) and just the DVB-T digital TV standard, whereas the XC3028 has more robust support for both analog and digital signals.
List of devices using this chip:
- AVerMedia CardBus Hybrid TV+FM E506R
- AVerMedia AVerTV USB Hybrid+FM Volar A828 Avermedia Web Site Inside Photos
XC2028
An analog only variant.
Drivers
Development -- There are two drivers versions. The oldest out-of-tree driver, from mrec. Newer kernels (2.6.25+) will have tuner-xc2028 for xc2028/3028 based boards.
Feature Support
- in-kernel xc3028 driver - analog/DVB-T/ATSC work fine; radio support is untested
- mrec's - analog and digital are both supported
Firmware Information
The information in this section is directed only towards support for the in-kernel driver. For 3rd party driver requirements and/or information, please consult those sources directly.
How to Obtain the Firmware
Follow the instructions outlined on lines 6-14 of the extract_xc3028.pl perl script. Specifically:
# In order to use, you need to: # 1) Download the windows driver with something like: # wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip # 2) Extract the file hcw85bda.sys from the zip into the current dir: # unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys # 3) Download the extract script # wget http://linuxtv.org/hg/v4l-dvb/raw-file/3919b17dc88e/linux/Documentation/video4linux/extract_xc3028.pl # 3) run the script: # perl extract_xc3028.pl # 4) copy the generated file: # sudo cp xc3028-v27.fw /lib/firmware
/usr/src/linux/Documentation/video4linux/
directory ... you can also download a copy directly from the link provided aboveThe above instructions allow the extraction of Xceive's v.2.7 firmwares from a specific Windows driver file (i.e. the script won't accept nor be able to extract the firmware from other files ... see below for further details). This approach is known to work with a large number of boards from different manufacturers.
The in-kernel driver approach for xc2028/xc3028 has a complex logic for loading a firmware. The big advantage of this approach is that:
- just one firmware file is needed in order to provide support for all video/dvb/radio standards.
- almost no changes are required at the device's bridge drivers.
In order to do that, the firmware format of the in-kernel driver is completely different from the format used by other approaches.
About the Windows driver file from which the Xceive firmware is extracted
The Windows ".sys" file contains the Xceive firmware *+ xc3028 code + device-specific code + vendor-specific code. So, the ".sys" file from your Windows driver CD/download is likely to be different between two different cards, even if they have the exact same Xceive firmware version.
* In fact, the file used by LinuxTV's "extract_xc3028.pl" script also contains the firmware relevant for the XC5000 too (which one might have surmised from examining the name of the download link). The extraction of the XC5000 firmware, however, is handled by another script; see Xceive XC5000 for further details.
About the Xceive firmware
Internally, the Xceive firmware actually contains several small firmwares, for each different xc3028 supported standard. The in kernel driver loads all firmwares once, and will automatically load the proper part, based on the required standard.
The Xceive firmware has an internal version number; the newest of which, to the best of knowledge, is version 2.7, for xc2028/xc3028 and version 3.6 for the low power variants (xc3028l). In theory, this particular firmware can be the same one that is used for all xc3028 based devices. However, in practice, there are some devices that might require an older firmware version (eg. this is the case with the tm6000 based 10moons device, which requires firmware version 1.e). If you happen to know that the Windows ".sys" driver file for your device is supplied with a version 2.7 firmware, then in all likelihood you can use the perl script above (which extracts the firmware from the specific hcw85bda.sys file), and this should work properly for your device...of course, not many end users are going to know that information. So, without further theoretical explanations, the bottom line is that you should just try the above method first, and, if that proves to be unsuccessful, then proceed to try to figure out the reason why.
Some Notes
- The in-kernel driver supports older firmware, but some extracting tool is needed for older firmwares; see here.
- If you use the debug option with the tuner-xc2028 driver, then after the firmware has been successfully loaded, you will find that the firmware's internal version code is reported within your system log / dmesg output.
- The firmware is not dependent on system architecture (i.e whether it is a 32 or 64 bit machine has no bearing).
About the tuner_callback requirement
In order for the proper firmware to load, the bridge chip must be coded with a xc3028-specific setup and a tuner_callback, with the proper GPIO codes to reset the xc2028/3038.
The reset code is specific to each hardware design. Since several hardwares are based at the same reference design, generally, the initialization code may be the same for two different boards, though this may not hold true and and different initialization needs may be required for some boards,
See the particular bridge chip articles/code for further information.