Kernel Labs

For this blog post, I figured I would introduce you to the basics of tuner design. The goal is to give a high level overview of how these products are built, so you can better understand what is required to work on LinuxTV drivers. We’ll also introduce the key concepts and terminology so that when you see discussion on the linux-media mailing list, you’ll understand what the developers are talking about when they refer to things such as a “demod driver”.

In order to reverse engineer a device so you can add Linux support, you need to understand how the device works. This post is targeted at people who might want to add Linux support for some currently unsupported product but are unfamiliar with tuners.

Let’s start with a block diagram showing a tuner product, and then I’ll explain what each of the components is and introduce you to the terminology. We’re going to use the Hauppauge HVR-950 tuner as our example, since it is a relatively simple design but still has all of the basic components you find in a hybrid tuner product. I’ve also made an effort to provide references throughout the definitions, so the hyperlinks you see point to what I have vetted as “good additional information”. Please don’t complain about my brevity of the explanations for each item, since I am focusing on how it effects LinuxTV tuners (so feel free to read the Wikipedia article for more generalized explanations).

[lightbox title=”How Tuners Work…” href=”../../blog/wp-content/uploads/2009/11/hvr950.png”][/lightbox]
(Click to Enlarge)

I’ll take this opportunity to apologize for the overall quality of the diagrams – I’m admittedly trying to impart all of the relevant information while minimizing the time spent writing these articles. If this were a PowerPoint for a conference talk, I would have spent much more time making the diagrams prettier.

So let’s look at each of the components, following the path of the signal. We’re going to start by following how a digital TV signal such as ATSC or ClearQAM would travel (red), and then we’ll come back and see how traditional analog works (green).

The Tuner

The tuner is the where the signal comes into the device. In this case we’re not talking about an overall tuner product, but rather the actual chip in the product that receives the signal from the coax input. It can be a single chip like the Xceive 3028 shown above, or it can be what is commonly referred to as a “can tuner”. This is the metal box that you see on the circuit board inmmediately next to where you connect the antenna. In the case of the HVR-950, we actually have a tuner that supports both analog and digital standards, which is why it is connected to both the digital demodulator and the analog video decoder. This is also why a simple product like this cannot be used for capturing both analog and digital transmissions at the same time.

The tuner’s responsibility is to “tune” to the desired frequency, and provide an analog signal to the demodulator or video decoder. Now note in that I said “analog” even though this tuner supports both analog and digital standards? Well, that’s right. At this point even for digital transmissions the signal that comes out of the tuner is still an analog waveform (commonly known as an “Intermediate Frequency” or “IF”). That brings us to the demodulator:

The Digital Demodulator

The digital demodulator is responsible for taking an analog waveform representing a DTV transmission, and “demodulate” it to its digital form. The output of the demodulator is typically MPEG2 packets, which are then sent over either a serial or parallel bus to the bridge chip. In the case of the HVR-950, a LGDT3303 is used (made by LG Electronics)

The Bridge

The bridge is the central part of any tuner product. It is the part that connects to the host computer (over a bus such as PCI, PCIe or USB), and is responsible for communicating with all the other chips in the tuner product. In the case of the HVR-950, the USB bridge is an Empia EM2883.

Now let’s talk about Analog…

So that you don’t have to scroll back and forth, let’s look at the same diagram again:

[lightbox title=”How Tuners Work…” href=”../../blog/wp-content/uploads/2009/11/hvr950.png”][/lightbox]

The Tuner

Again, the signal comes in on the RF connector into the tuner, and the tuner has tuned to the desired target frequency. However, because the tuner has been put into analog mode, it will treat the signal differently. In the case of the xc3028, it will actually demodulate the signal internally (no need for an “analog demodulator”) and then it will output a CVBS video signal. For those of you who are not familiar with “CVBS”, it just means “composite video”. We’re talking about the same type of signal that as the yellow RCA cable you hook to from your VCR to your television.

The Video Decoder

Well, given that you now have a CVBS signal coming out of the tuner, how does this translate to a digital picture on your TV? This is where the video decoder comes in. The video decoder (in the case of the HVR-950, it’s a Texas Instruments TVP5150) takes a composite or s-video input, and creates a digital representation of the picture. This format is typically referred to as ITU-R BT-656, or often abbreviated as ITU656 or BT656. The individual lines of picture information are sent one at a time to the bridge. The video decoder is typically where you see controls like hue, brightness, contrast, and saturation taking effect, since these are mainly transforms that effect the way the analog signal is interpreted. The video decoder is typically also responsible for input selection, letting the user choose whether to look at the video coming in through the tuner, or the video coming in through the composite or s-video connector.

The Audio Decoder

The audio decoder does the same work for audio as the video decoder does for video. It takes an analog signal representing the audio, and converts it to a digital format. This analog can be from the RCA audio input cables provided via the HVR-950’s breakout dongle, or it can be provided by the tuner (the tuner separates out the analog audio and video and provides them as separate signals). And like the video decoder, the audio decoder typically chooses what input to look at (either from the tuner or the RCA audio input).

In the case of the HVR-950, the audio decoder used is the Empia EMP202. The HVR-950 is a bit unusual because the audio decoder is actually built into the bridge. In other products, it is not uncommon for it to be a separate chip such as the Cirrus CS5340, which outputs the audio to the bridge in a digital format known as I2S.

Now of course the HVR-950 is a rather simple example, but I hope it provides you a general idea how these devices work. More complicated products include components such as MPEG encoders to convert the analog signal to MPEG. In other products it is also worth mentioning that the different logical components may be combined onto the same chip. For example, on the successor to the HVR-950 known as the HVR-950Q, both the digital demodulator and the analog video decoder are on the same chip (the Auvitek au8522). All of the concepts above still apply in terms of the signal flow, but you just have a different organization of where those components reside in terms of the actual silicon.

Other Terminology

While we’re here, let’s talk about some other terms you will commonly see references to:

I2C – We talked about all the various components and how the video signal travels through them to end up back on the PC, but how are all these chips configured? How do you tell the tuner what frequency to tune to? How do you tell the video decoder what video input to use, or where to set the saturation level? This is where the I2C protocol comes in. The I2C protocol typically is composed of an I2C master (built into the bridge) communicating with one or more I2C slaves (typically built into all the other chips). When you want to configure a chip, you create the I2C message and tell the I2C master to send it to the chip in question (each I2C slave has its own unique address). There’s all sorts of nuance related to I2C that isn’t appropriate for an introductory post (multi-master support, clock stretching, etc), so if you are interested then the Wikipedia article on I2C is pretty good.

I2C gate – An i2c gate is a mechanism where communications can be cut off to a particular chip. The most common scenario you see this is where an i2c gate embedded in a digital demodulator controls access to the tuner chip. This is done because the tuner can be very sensitive and having to inspect all the traffic (even traffic not intended for the tuner) can have an effect on tuning quality. To mitigate this, the demodulator cuts off all communciations with the tuner except for when the user wants to change frequencies. In this case, the demodulator opens the gate, allowing the i2c message with the tuning request to be sent to the tuner, and then the gate is closed again. An improperly configured i2c gate will cause the driver to not be able to communicate with the tuner. This results in (depending on the driver) the tuner driver initialization failing or in more subtle and harder to debug cases, communications to the tuner being silently discarded with no error messages.

GPIO – this stands for “General Purpose Input/Output” and usually represents a pin on a chip that can be configured to be “high” or “low” when in output mode, or you can read the current state as high or low when configured for input mode. A GPIO pin is typically connected to some other chip, and performs some function by changing its state. Using the HVR-950 as an example, one of the GPIO pins is connected to the “RESET” pin on the xc3028 tuner. Setting the state of the GPIO pin to low momentarily and then high again has the effect of resetting the chip to a known state. Other common uses of GPIO pins include connecting it to the power supply on a board to cut off power to certain peripherial components, or controlling whether a low noise amplifier (LNA) connected to the tuner is enabled.

It’s also worth noting that holding a chip in reset is often done as a power management measure, which is why you can see driver problems communicating with certain chips if the GPIOs are improperly configured. This sort of power management measure becomes particularly important on USB devices, where there is often not enough power available on the USB bus to have both the analog components and the digital components powered up at the same time.

GPO – this stands for “General Purpose Output”. It’s the same thing as a GPIO but output only. In practical terms, for tuner products it is pretty rare for GPIO pins to be configured as inputs.

IF – The intermediate frequency is the frequency on which the tuner chip is providing the signal to the digital demodulator. The demod needs to know where to find the signal in order to get a signal lock and perform demodulation, and this being improperly configured in the demodulator is a common problem developers have getting a board to work the first time under Linux.

SIF – Sound Intermediate Frequency – this is the raw audio signal that comes out of some tuners before demodulation. The tuner has separated the video out from the sound, and passes the SIF to the audio decoder, which will digitize and provide it in a digital format (such as PCM audio sent over I2S).

Firmware – firmware is executable code that runs inside of the tuner product. It can be stored in a ROM on the device, or much more commonly it is uploaded when the driver is initialized. The firmware is treated by the driver as a “blob” of binary data, and typically has to be provided in an external file in a directory such as /lib/firmware. The use of firmware creates difficulty for open source since special permission is typically required by the chipset vendor to allow redistribution of the firmware. Without such permission, developers typically have to write a script which the user can run to extract the firmware from the Windows driver.

Conclusion

I hope this provides some insight into the basics of how tuners are setup. Now that the groundwork has been laid, upcoming articles will talk in more detail about the individual components (as well as techniques for reverse engineering them).

As always, comments/feedback is welcome (or even an acknowledgment that this was worth the time it took for you to read and me to write).