Hi, sorry for resurrecting this thread after a year and for my lengthy mail. On Sun, Jun 10, 2012 at 02:25:09PM +0200, Fredrik wrote: > Unfortunatly my cable provider "Comhem" moved almost all channels to > QAM256. > The results are terrible on my two cards. Blocky picture and skipping > audio. On Wed, Jun 13, 2012 at 10:46:00AM +0200, Fontana wrote: > After some further digging i found a post with attached patch. > > http://www.linuxtv.org/pipermail/linux-dvb/attachments/20080731/de8768ed/att > achment.diff > > Dunno why there were no followup on this one? > > http://linuxtv.org/pipermail/linux-dvb/2008-July/027517.html > > Applied cleanly to kernel 3.4.0 with the following change. > > - (p->u.qam.modulation == QAM_256) ? 6718 : 7250); > + (p->modulation == QAM_256) ? 6718 : 7250); As I recently bought a TT premium C2300 suffering from the same problem, I spent Saturday night analyzing in detail what causes it. To make sure there are no offsets introduces by my cable provider, I mapped the complete spectrum with cxadc (and XC3028 switched to DVB-T). Both QAM64 and QAM256 channels are centered exactly at the frequencies mentioned in the NIT. I then tried to measure the output of the tuner with my cheap oscilloscope but failed, probably due to the low signal level. I did succeed however at the output of the TDA9819 (pin 18). There I could see that the center frequency is about 6.6MHz, in contrast to the 7.25MHz configured in the STV0297. From both adjacent channels there are remnants visible, attenuated to about the same level, so the 36.15MHz IF is correct. But why is it not centered around 7.25MHz? That second IF is generated by a VCO that is controlled by pin 16 of the TDA9819. If you look closely, you can see that pin 16 is directly connected to pin 15, which controlls the DVB AGC. This only makes sense if these pins are tied to a fixed voltage. My multimeter says 2.47V, which is close to the typical input voltage mentioned in the data sheet for pin 15. The diagram for the VCO frequency tells us this should make the VCO run at about 86.3MHz, which is halved before it is multiplied with the signal from the tuner. If we lived in a perfect world, we would get a 2nd IF of 86.3/2-36.15=7MHz. If the VCO is off by 1%, we arrive at 6.6MHz. What counts is that there is no calibrated quartz controlling the frequency of the 2nd IF, so it may vary with each device (and probably temperature, supply voltage, etc.). But why does QAM64 work? The STV0297 contains two stages that can compensate for IF offsets. The first one is controlled by stv0297_set_initialdemodfreq the second one by stv0297_set_carrieroffset. Both stages can automatically try different frequencies during locking, but we only allow this for the second stage. The first one we fix at 7.25MHz or rather 7.266MHz due to rounding while calculating the register value. On a tuned QAM64 channel stv0297_get_carrieroffset reports an offset of about 680kHz. By why does QAM256 not work? I also get a lock on QAM256 channels and there stv0297_get_carrieroffset also reports the same offset give or take 5 kHz. The STV0297 data sheet says: "It is possible to optimize chip performance by optimizing the respective uses of CRL and initial derotator (for example if the CRL locks for a given offset value, it is possible to transfer this offset cancellation from CRL to initial derotator before Nyquist filtering, the latter being then better matched to the signal actually received)." So while at QAM64 we get away with doing the correction in the CRL (second stage), QAM256 requires this to be done in the first stage. We once had code in the driver trying to move the offset from the second stage to the first stage, but it didn't work correctly and was removed in 2005 without trying to fix it: http://linuxtv.org/mailinglists/linux-dvb/2005/01-2005/msg00165.html I found an error in stv0297_get_carrieroffset for negative offsets. Maybe that was the cause back then. Maybe we should not reuse the offset for different channels. A module parameter for the IF probably does not work for people wanting to use more than one card. I am not sure what is the best way to solve the problem but I do know that the 7.25MHz don't work for everyone and it does not depend on the modulation as suggested by the patch above. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
