> 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 <rglow...@exemail.com.au> >> >> > >> >> > 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
01_revert_966ce12c444d.diff
Description: /
02_revert_e6a8672631a0.diff
Description: /
03_refix_e6a8672631a0.diff
Description: /
