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.

Note: While the XC3028 is capable of reception of signals using 64-QAM, it is incapable of handling the more complex 256-QAM flavour.

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.

XC2028

An analog only variant.

XC2028L/XC3028L

The XC2028L and XC3028L are low-power version variants of xc2028/xc3028. They require 20% less power than the previous versions, and were launched in Aug, 2006. Modern designs generally use those chipsets in order to reduce power consumption from the USB power supply.

Drivers

Newer kernels (2.6.25+) have tuner-xc2028 that supports those chips.

The driver will also require a firmware, else the device will not operate correctly, and an error like the following example will occur in your system log (see dmesg output) notifying you of this fact:

Note: The extract_xc3028.pl script is located within the /usr/src/linux/Documentation/video4linux/ directory ... you can also download a copy directly from the link provided above

The 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 (e.g. 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.

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 and code for further information.