If you’ve ever had to poke at a DVB driver under Linux, you’ll notice that the configuration for the demodulator and tuner refer to an “IF”. For example, with the xc5000 driver, there is a mandatory parameter called “if_khz” which has to be provided when the driver is initialized.
What is an IF, and what role does it play in making tuners work under Linux?
“IF” stands for “intermediate frequency”. To understand the role of the IF, we need to first take a step back and understand what a tuner actually does. A tuner takes a slice of the available spectrum coming in on the antenna, and outputs just that slice. That slice of spectrum has a defined width (called the bandwidth) which is the amount of spectrum that carries the TV channel being tuned to. Further, that channel being output is on its own target frequency, commonly referred to as the intermediate frequency center. Hence, regardless of the target frequency that the user is requesting to tune to, the output of the tuner is always in the same place (which is where the demodulator knows to look for it).
The goal behind the intermediate frequency is to allow the digital demodulator to focus *just* on the channel it needs to demodulate, instead of being exposed to the entire spectrum coming from the antenna.
They say a picture is worth a thousands words, so let’s look at one now.
[lightbox title=”A Quick Primer on Intermediate Frequencies” href=”../../blog/wp-content/uploads/2012/07/dtv2.png”]
[/lightbox]
(Click to see full resolution version)
I’ll use this opportunity to give some free advertising to Bitscope (http://www.bitscope.com). The following screen capture was taken from a Bitscope 120 which I bought for less than $600.00. There was a time when doing such analysis would require you to spend tens of thousands of dollars for an Agilent spectrum analyzer – now it’s built into a PC based oscilloscope solution cheap enough that even a hobbyist can afford it. They also have GUIs for OSX and Linux, which is nice since I don’t use a Windows box very often.
Let’s break down the important parts of this image. For the purposes of discussion, everything we will be talking about is in regards to the top half of the photo (which is the spectrum analyzer output).
This capture was taken from a ClearQAM tune to 447 MHz from an xc5000 tuner on an HVR-950q. I attached the probe to the IF output that connects the xc5000 tuner to the au8522 digital demodulator. Notice the “FP = 6 MHz”. That’s the distance between the green and orange lines. It’s the bandwidth of the signal being output from the tuner. 6 MHz is the standard size of channels for ATSC and ClearQAM (as it was for the older NTSC analog standard as well).
You’ll also note the “FM = 3MHz”. FM is the “frequency mark” of the green line. Basically it means that the waveform begins at that offset. Do a bit of math and you realize that a 3 MHz offset + 6 MHz bandwidth, divided by 2 means that the IF center is at exactly a 6 MHz offset.
So why should I care about this?
It’s important if you’re trying to add support for a new tuner product, either in cases where there are existing drivers and you’re just trying to figure out the right configuration, or in cases where you have to write a new driver from scratch. By seeing the actual IF waveform, you can see if it’s properly formatted. When trying to determine why you don’t get a signal lock, being able to look at the properties of the waveform can tell you what is wrong with the signal being delivered to the demodulator.
For example, let’s say we saw the above waveform, but it was 7 MHz wide instead of 6 MHz. That would suggest that the tuner is improperly configured and outputting a signal intended for digital television in Europe (which can typically have a bandwidth of 6, 7, or 8 MHz).
Likewise, let’s say we saw the above waveform but it was shifted a couple of MHz to the right. That would mean that the IF center is improperly configured in either the tuner or the demodulator. Note that I didn’t say it was necessarily the tuner that is misconfigured in this case. It could be that the tuner is outputting the correct IF center but the demodulator is expecting it at a different frequency. The important thing is that they are mismatched and thus the demodulator is looking in the wrong place for the signal.
If you look at the above photo, notice how there is a bit of dead space between the green line and the actual start of the waveform? Likewise there is dead space between the end of the waveform and the orange line? This is because while 6 MHz is allocated for the channel, there is white space between the actual signals to prevent interference between them. Why is this relevant? Look at the next photo:
[lightbox title=”A Quick Primer on Intermediate Frequencies” href=”../../blog/wp-content/uploads/2012/07/dtv_offtune.png”]
[/lightbox]
(Click to see full resolution version)
Notice the huge gap in the waveform about 1/6 of the way from the left? It’s actually the same white space you saw in the previous photo, but back to back instead of at the edges of the waveform. That’s because the tuner is actually off-tune. In this case I “faked it” by explicitly telling the tuner to tune to 446 MHz instead of 447 MHz, but you would see the same effect if I had given the driver the correct frequency as input but the tuner was interpreting it improperly and thus tuning to the wrong frequency (for example, as a result of a bug in the tuner driver). In effect the above photo is showing the top 1/6 of the previous channel and the bottom 5/6 of the current channel.
If I were trying to figure out why I wasn’t getting a signal lock based on the above picture, I could see that I am indeed getting a 6 MHz signal, that the signal is correctly centered at a 6 MHz offset, but that the slice of spectrum being delivered is not properly centered on the target frequency. Remember that the tuner is taking a slice of spectrum, and in this case it was taking a slice of the right width but at the wrong location.
Long story short, you don’t need to spend a fortune on equipment and a degree in EE to do this sort of analysis. Even with inexpensive hardware and a basic understanding how RF can allow someone to resolve driver problems.
Comments/feedback welcome below, as always…