Hi, And the 6MHz patch you mentioned is a wrong patch. http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 + if (priv->cur_fw.type & DTV6) + offset = 1750000; + if (priv->cur_fw.type & DTV7) + offset = 2250000; + else /* DTV8 or DTV78 */ + offset = 2750000; and latest patch should be: + if (priv->cur_fw.type & DTV6) + offset = 1750000; + else if (priv->cur_fw.type & DTV7) + offset = 2250000; + else /* DTV8 or DTV78 */ + offset = 2750000; Terry 2010/1/7 Terry Wu <terrywu2009@xxxxxxxxx>: > Hi, > > The 6MHz patch is for Taiwan only. > It should not change anything for 7MHz and 8MHz. > > Terry > > 2010/1/7 Robert Lowery <rglowery@xxxxxxxxxxxxxx>: >>> On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: >>>> > On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: >>>> >> On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: >>>> >> > > Mauro, >>>> >> > > >>>> >> > > I've split the revert2.diff that I sent you previously to fix the >>>> >> tuning >>>> >> > > regression on my DViCO Dual Digital 4 (rev 1) into three separate >>>> >> patches >>>> >> > > that will hopefully allow you to review more easily. >>>> >> > > >>>> >> > > The first two patches revert their respective changesets and >>>> nothing >>>> >> else, >>>> >> > > fixing the issue for me. >>>> >> > > 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T >>>> >> > > 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ >>>> >> 6MHz >>>> >> > > >>>> >> > > The third patch does what I believe is the obvious equivalent fix >>>> to >>>> >> > > e6a8672631a0 but without the cleanup that breaks tuning on my >>>> card. >>>> >> > > >>>> >> > > Please review and merge >>>> >> > > >>>> >> > > Signed-off-by: Robert Lowery <rglowery@xxxxxxxxxxxxxx> >>>> >> > >>>> >> > Mauro, >>>> >> > >>>> >> > I'm yet to receive a response from you on this clear regression >>>> >> introduced >>>> >> > in the 2.6.31 kernel. You attention would be appreciated >>>> >> > >>>> >> > Thanks >>>> >> > >>>> >> > -Rob >>>> >> Robert, >>>> >> The changes in question (mostly authored by me) are based on >>>> >> documentation on what offsets are to be used with the firmware for >>>> various DVB bandwidths and demodulators. The change was tested by Terry >>>> >> on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) >>>> and >>>> >> some other cards I can't remember, using a DVB-T pattern generator >>>> for >>>> 7 >>>> >> and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. >>>> (Devin, >>>> >> Maybe you can double check on the offsets in tuner-xc2028.c with any >>>> documentation you have available to you?) >>>> >> I haven't been following this thread really at all as the board in >>>> the >>>> subject line was unfamiliar to me, so sorry for any late response or >>>> dumb >>>> questions by me. >>>> >> May I ask: >>>> >> 1. what are the exact problem frequencies? >>>> >> 2. what is the data source from which you are getting the frequency >>>> information? >>>> >> 3. what does tuner-xc2028 debug logging show as the firmware loaded >>>> when >>>> >> tune to one of the the problem frequencies? >>>> > >>>> > >>>> > Robert, >>>> > >>>> > I just found that ACMA has a very nice compilation licensed DTV >>>> > transmitters in Australia and their frequencies. Have a look at the >>>> Excel spreadsheet linked on this page: >>>> > >>>> > http://acma.gov.au/WEB/STANDARD/pc=PC_9150 >>>> > >>>> > The DTV tab has a list of the Area, callsign, and DTV center freq. The >>>> Glossary tab mentions that DTV broadcasters can have an offset of +/- >>>> 125 >>>> kHz from the DTV center freq. >>>> > >>>> > If you could verify that the frequencies you are using for the problem >>>> stations match the list, that would help eliminate commanded tuning >>>> frequency as source of the problem. >>>> >>>> Andy, I don't think this issue is frequency, it is the removal of the >>>> 500kHz offset. >>> >>> OK. I forgot there were two offsets at play here: one for the RF >>> frequency and one for the SCODE/Intermediate Frequency. >>> >>> Right, the S-CODE offsets are somewhat of a mystery to me as I don't >>> exactly know the mathematical basis behind them. The 500 kHz came from >>> the best interpretation Maruo and I could make at the time, but it could >>> very well be the wrong thing. (I was guessing it came from a relation >>> something like this: 8 MHz - 7 MHz / 2 = 500 kHz) >>> >>> If it is the wrong thing, and it looks like it could be, we can back it >>> out. As my colleauge, who used to work at CERN, says "Experiment trumps >>> theory ... *every* time". Terry had positive results, you and Vincent >>> have negative results. So I'd like to see what Devin finds, if he can >>> test with a DVB-T generator. >> >> Andy, >> >> Resend of my proposed patches attached. >> >> My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just >> change the ATSC test to DTV6 but at the same time a cleanup that was done >> inadvertently removed the 500kHz offset subtraction for DTV7 introducing >> the defect. 01_revert_966ce12c444d.diff partially fixed this regression >> for Terry, but not for me or Vincent. >> >> I'm having trouble convincing Mauro of this though :), so I would >> appreciate it if Terry could test my patch set and confirm it is ok for >> him. >> >> So in short, my 01 and 02 patches attached revert the changes that break >> tuning for me and 03 re-implements the DTV6 fix, but without the cleanup >> which breaks me. >> >> Please review and comment >> >> -Rob >> >>> >>> >>> >>>> The channel with the biggest problem (most stuttering) is Channel 8 in >>>> Melbourne, which looks correct at 191.625 MHz on the above site. >>> >>> OK. Vincent must have been the one with all the Sydney stations. >>> >>> DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is >>> interesting; it comes from the same towers as the adjacent analog >>> channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200 >>> kW). >>> >>> I guess if anything is off center when setting up the XC3028, the analog >>> stations may show up as strong noise - a situation that would not be >>> obvious with a single channel DVB-T signal generator. GTV8 is probably >>> a good channel for you to use for testing. >>> >>> >>> (BTW, given that the analog channel of where GTV8 now resides would have >>> been Fr = 189.25 MHz, I would have expected GTV8 to really be operating >>> at Fc = Fr + 2.25 MHz = 191.50 MHz and not 191.625 MHz) >>> >>> >>> >>>> With debug enabled on the the current hg tip (stuttering case) we have >>>> divisor= 00 00 2f 58 (freq=191.625) >>>> >>>> With the patch reverted (working case) >>>> divisor= 00 00 2f 38 (freq=191.625) >>>> >>>> Have you reviewed my patch. It leaves your original DTV6 fix in place, >>>> but reverts the cleanup which broke the offset calculation for me. >>> >>> I don't have a copy in my email archives, I'll have to go check for them >>> on the list archives. >>> >>> Regards, >>> Andy >>> >>>> -Rob >>>> >>>> > >>>> > Regards, >>>> > Andy >>>> > >>>> > >>>> >> BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c: >>>> >> cxusb_dvico_xc3028_tuner_attach(), this declaration >>>> >> static struct xc2028_ctrl ctl = { >>>> >> .fname = XC2028_DEFAULT_FIRMWARE, >>>> >> .max_len = 64, >>>> >> .demod = XC3028_FE_ZARLINK456, >>>> >> }; >>>> >> really should have ".type = XC2028_AUTO" or ".type = XC2028_D2633", >>>> but >>>> since XC2028_AUTO has a value of 0, it probably doesn't matter. >>>> Regards, >>>> >> Andy >>> >>> >>> -- >>> 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 >>> >> > -- 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
