[RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> On Tue, Dec 1, 2009 at 4:18 AM, Vincent McIntyre > wrote: >> Hi Rob >> >> I missed your followup and tested the 'revert.diff' patch, attached >> for reference. >> I have been slow replying because I've been scratching my head over the >> results. >> >> I used 'signaltest.pl' to test[1], which uses tzap under the hood. >> Perhaps this is not the best choice, but I wanted something that I >> thought would >> allow objective comparisons. That's trickier than I thought... >> Unfortunately I only discovered last night how easy 'vlc >> ./channels.conf' makes doing quick visual checks. I didn't have enough >> time to re-patch and test again. >> >> My test procedure was: >> - get a baseline with tzap and signaltest.pl >> - patch, make, install. cold boot. >> - test with tzap and signaltest.pl >> - revert patch, for the moment. >> >> I tested two kernels, and both cards. I tested all the tuners but I'll >> spare you that for now. >> >> * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip) >> >> I got rather different baseline results. All channels had >> significantly higher BER >> than I'd noticed before. After patching, snr on some channels >> seemed a little higher >> and BER was lower. On ch9, I think snr was up and BER improved a >> little. >> >> here are the signaltest summary tables: >> without patch. usb device (dvb0) usbid db78:0fe9 >> Frequency Signal Ber Unc >> = >> 17750 76.0 % 322.6 672.4 Seven >> 191625000 76.0 % 320.2 1783.3 Nine >> 21950 76.8 % 329.8 2948.2 Ten >> 22650 76.9 % 296.6 4885.0 ABC >> 57150 77.0 % 542.0 7529.4 SBS >> 57850 77.1 % 539.5 10669.7 D44 >> >> with patch. usb device (dvb0) usbid db78:0fe9 >> Frequency Signal Ber Unc >> = >> 17750 76.6 % 2.3 0.0 >> 191625000 77.0 % 235.5 83.3 >> 21950 76.9 % 288.0 501.8 >> 22650 76.9 % 295.1 1416.4 >> 57150 77.0 % 523.4 3980.0 >> 57850 77.1 % 549.9 7409.4 >> >> without patch. pcie device (dvb1) pciid db78:18ac >> Frequency Signal Ber Unc >> = >> 17750 71.2 % 3.1 0.0 >> 191625000 21.7 % 645.4 246.4 >> 21950 73.6 % 1.9 1632.0 >> 22650 73.5 % 2.8 1632.0 >> 57150 73.9 % 13.6 2134.6 >> 57850 72.7 % 58.2 6393.4 >> >> with patch. pcie device (dvb1) pciid db78:18ac >> Frequency Signal Ber Unc >> = >> 17750 73.2 % 4.0 0.0 >> 191625000 74.0 % 37.0 0.0 >> 21950 73.9 % 0.0 0.0 >> 22650 73.0 % 4.6 0.0 >> 57150 74.2 % 76.7 193.6 >> 57850 72.8 % 213.8 4480.3 >> >> >> * 2.6.31-14-generic + v4l (19c0469c02c3+ tip) >> Hard to say if I'm seeing an improvement. >> >> before patching - adapter0 usbid db78:0fe9 >> Frequency Signal Ber Unc >> = >> 17750 75.5 % 293.7 1926.4 >> 191625000 75.9 % 363.2 2993.3 >> 21950 76.7 % 304.5 4225.8 >> 22650 76.9 % 223.8 6153.3 >> 57150 77.0 % 491.7 8726.0 >> 57850 77.1 % 558.9 11787.1 >> >> adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..) >> Frequency Signal Ber Unc >> = >> 17750 75.9 % 327.9 13893.6 >> 191625000 76.0 % 392.8 14939.0 >> 21950 76.7 % 252.0 16052.0 >> 22650 76.8 % 254.0 18063.1 >> 57150 76.9 % 533.2 20644.1 >> 57850 76.9 % 464.1 23836.8 >> >> after patching - adapter0 usbid db78:0fe9 >> Frequency Signal Ber Unc >> = >> 17750 76.3 % 2.5 0.0 >> 191625000 76.8 % 227.6 119.0 >> 21950 76.8 % 262.6
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> Mauro, > > Resend of my proposed patch attached that reverts tuning regressions with > my DViCO card, whilst still fixing the original 6Mhz tuning issue. Please > merge or let me know how else I should proceed to get this merged. > > Thanks > > -Rob perhaps the attached notes will help Rob's case here. I did a few more tests, with just one tuner. First I changed a cable that I was suspicious of (it was way too long anyway) but I got no significant improvement. Then I applied the 'revert2.diff' patch that Rob sent and cold-booted. I reran the test and got significantly lower BER and UNC values. There is still something odd going on, in that the UNC seem to get worse with repeated tunings to the same channel, a few minutes apart (less than 10min). This might be a measurement artefact, I don't know. I might try changing the channel order - that should test whether the trend of the UNC values is with frequency or order in the tuning sequence. Cheers VInce 2009-12-07 Try signaltest.pl again. First, with old cable and no code changes hg identify = c57f47cfb0e8+ tip tuner 0 is usbid 0fe9:db78 do three consecutive runs to see if things worsen with repeated tuning. Frequency Signal Ber Unc = 17750 75.9 % 318.9 376.2 191625000 74.5 % 280.1 904.9 21950 77.0 % 245.2 1862.2 22650 77.0 % 186.4 3525.4 57150 77.1 % 502.9 6161.3 57850 77.2 % 541.1 9128.8 Frequency Signal Ber Unc = 17750 75.5 % 314.6 11219.2 191625000 74.0 % 384.3 12057.3 21950 76.8 % 118.7 13236.9 22650 76.8 % 173.5 15256.6 57150 77.0 % 472.3 17930.7 57850 77.1 % 550.0 20888.8 Frequency Signal Ber Unc = 17750 75.4 % 346.0 23052.8 191625000 73.3 % 347.5 24087.7 21950 76.7 % 236.0 25289.0 22650 76.8 % 190.1 27241.0 57150 76.9 % 541.1 29910.0 57850 77.1 % 511.7 32902.1 Now repeat with the 1.5m cable connecting wall socket to splitter. cold boot the machine hg identify = c57f47cfb0e8+ tip dvb0.frontend0: usbid 0fe9:db78 Frequency Signal Ber Unc = 17750 74.0 % 288.2 784.8 191625000 73.3 % 487.2 1890.9 21950 76.7 % 147.2 3189.8 22650 76.8 % 202.2 5094.7 57150 76.9 % 443.1 7640.6 57850 76.9 % 499.9 10675.3 Frequency Signal Ber Unc = 17750 73.0 % 330.7 12795.4 191625000 72.6 % 291.8 13844.3 21950 76.7 % 132.5 15005.5 22650 76.8 % 136.2 16928.0 57150 76.9 % 525.2 19480.7 57850 77.0 % 522.7 22361.7 Frequency Signal Ber Unc = 17750 75.5 % 361.6 24584.2 191625000 73.8 % 480.9 25816.4 21950 76.7 % 143.4 26962.2 22650 76.8 % 187.5 28846.1 57150 77.0 % 468.4 31448.9 57850 77.0 % 547.3 34511.8 Now make the code change. Cold boot. dvb0.frontend0: usbid 0fe9:db78 Frequency Signal Ber Unc = 17750 76.5 % 0.0 0.0 191625000 76.9 % 136.8 102.3 21950 76.9 % 297.6 549.0 22650 76.8 % 304.7 1461.4 57150 76.9 % 505.0 3801.0 57850 77.0 % 573.7 6818.6 Frequency Signal Ber Unc = 17750 76.4 % 0.0 8345.0 191625000 76.8 % 169.7 8476.0 21950 76.7 % 243.8 8967.2 22650 76.9 % 271.6 9904.7 57150 76.9 % 525.9 12097.4 57850 77.1 %
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
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 Thanks -Rob 01_revert_966ce12c444d.diff Description: / 02_revert_e6a8672631a0.diff Description: / 03_refix_e6a8672631a0.diff Description: /
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> 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 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 > > Thanks > > -Rob > -- 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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
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
>
> 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?
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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hey Andy, On Mon, Jan 4, 2010 at 9:27 PM, Andy Walls wrote: > 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?) At this point the extent to which I've looked in to the issue was validating that, for a given frequency, the change resulted in a crappy SNR with lots of BER/UNC errors, and after reverting the change the signal looked really good with zero BER/UNC. I haven't dug into *why* it is an issue, but I examined the traces and looked at the testing methodology and can confirm that there was definitely a regression and Robert narrowed it down to the patch in question. I was kind of hoping that one of the people that helped introduce the regression would take on some of responsibility to help with the debugging. ;-) I think I have one of the boards that will demonstrate the issue (a Terratec board with xc3028/zl10353), and will try to find some time with the generator once I wrap up the xc4000 work for the PCTV 340e. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
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
> >
> > 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.
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
>
--
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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Mon, 2010-01-04 at 22:13 -0500, Devin Heitmueller wrote: > Hey Andy, > > On Mon, Jan 4, 2010 at 9:27 PM, Andy Walls wrote: > > 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?) > > At this point the extent to which I've looked in to the issue was > validating that, for a given frequency, the change resulted in a > crappy SNR with lots of BER/UNC errors, and after reverting the change > the signal looked really good with zero BER/UNC. I haven't dug into > *why* it is an issue, but I examined the traces and looked at the > testing methodology and can confirm that there was definitely a > regression and Robert narrowed it down to the patch in question. > > I was kind of hoping that one of the people that helped introduce the > regression would take on some of responsibility to help with the > debugging. ;-) I take responsiblity for the change. However, if fixing a known problem unmasks another problem, then is that a regression? I puzzled over the docs for a while until I had the "Aha!" moment and understood what they were saying. I'm really confident about the freq offset changes - especially since using the wrong center freq in channels.conf is an easy way to mask incorrect freq offsets in the driver module. I'm less confident about the xc3028 firmware segments as extracted and repackaged for linux. I was not involved in that development and I conveniently (for me) assume it is correct -- although that may be an assumption worth challenging. I also do not know the source of the commanded DTV freq's that are in use in the reported problem case. Using the wrong DTV center freq can cause the same problem symptoms as moving the offset used in the tuner-xc2028 module (two wrongs making a right). I just found a nice authoritative Australian source on DTV freq licensees (see my other foloow-up email), so hopefully Robert can double check that. Of course testing with a DVB-T generator instead of a broadcaster's signal would eliminate any doubt about the center freq in use. > I think I have one of the boards that will demonstrate the issue (a > Terratec board with xc3028/zl10353), and will try to find some time > with the generator once I wrap up the xc4000 work for the PCTV 340e. OK, thanks. I have no hardware with which to test. Regards, Andy > Devin -- 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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> 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
>> >
>> > 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.
The channel with the biggest problem (most stuttering) is Channel 8 in
Melbourne, which looks correct at 191.625 MHz on the above site.
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.
-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
>
> --
> 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
>
--
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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
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 > >> > > >> > 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. > 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'
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> 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 >> >> > >> >> > 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 @
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, The 6MHz patch is for Taiwan only. It should not change anything for 7MHz and 8MHz. Terry 2010/1/7 Robert Lowery : >> 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 >>> >> > >>> >> > 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. >>
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
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 = 175; + if (priv->cur_fw.type & DTV7) + offset = 225; + else/* DTV8 or DTV78 */ + offset = 275; and latest patch should be: + if (priv->cur_fw.type & DTV6) + offset = 175; + else if (priv->cur_fw.type & DTV7) + offset = 225; + else/* DTV8 or DTV78 */ + offset = 275; Terry 2010/1/7 Terry Wu : > Hi, > > The 6MHz patch is for Taiwan only. > It should not change anything for 7MHz and 8MHz. > > Terry > > 2010/1/7 Robert Lowery : >>> 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 >> > >> > 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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, The following codes in the 6MHz patch are not for 6MHz. Please read the mchehab's comments. 1.28/* 1.29 - * We must adjust the offset by 500kHz in two cases in order 1.30 - * to correctly center the IF output: 1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables were explicitly 1.32 - *selected and a 7MHz channel is tuned; 1.33 - * 2) When tuning a VHF channel with DTV78 firmware. 1.34 + * We must adjust the offset by 500kHz when 1.35 + * tuning a 7MHz VHF channel with DTV78 firmware 1.36 + * (used in Australia) 1.37 */ 1.38 - if (((priv->cur_fw.type & DTV7) && 1.39 - (priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) || 1.40 - ((priv->cur_fw.type & DTV78) && freq < 47000)) 1.41 + if ((priv->cur_fw.type & DTV78) && freq < 47000) 1.42offset -= 50; BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning a VHF channel (frequency < 470MHz). And the above mchehab's new codes will not do "offset -= 50;" if DTV7 firmware is using. Terry 2010/1/7 Terry Wu : > 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 = 175; > + if (priv->cur_fw.type & DTV7) > + offset = 225; > + else /* DTV8 or DTV78 */ > + offset = 275; > > and latest patch should be: > + if (priv->cur_fw.type & DTV6) > + offset = 175; > + else if (priv->cur_fw.type & DTV7) > + offset = 225; > + else /* DTV8 or DTV78 */ > + offset = 275; > > > Terry > > 2010/1/7 Terry Wu : >> Hi, >> >> The 6MHz patch is for Taiwan only. >> It should not change anything for 7MHz and 8MHz. >> >> Terry >> >> 2010/1/7 Robert Lowery : 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 > >> > > >> > 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 h
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, You can check the dmesg output to verify which XCEIVE firmware/SCODE is using. For examples, (1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7 firmware is using, SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260 [ 266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90), id . [ 267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456 SCODE HAS_IF_5260 (6280), id . (2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78 firmware is using, SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760 [ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78 (110), id . [ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456 SCODE HAS_IF_4760 (62000100), id . Terry 2010/1/7 Terry Wu : > Hi, > > The following codes in the 6MHz patch are not for 6MHz. > Please read the mchehab's comments. > 1.28 /* > 1.29 - * We must adjust the offset by 500kHz in two cases in > order > 1.30 - * to correctly center the IF output: > 1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables were > explicitly > 1.32 - * selected and a 7MHz channel is tuned; > 1.33 - * 2) When tuning a VHF channel with DTV78 firmware. > 1.34 + * We must adjust the offset by 500kHz when > 1.35 + * tuning a 7MHz VHF channel with DTV78 firmware > 1.36 + * (used in Australia) > 1.37 */ > 1.38 - if (((priv->cur_fw.type & DTV7) && > 1.39 - (priv->cur_fw.scode_table & (ZARLINK456 | > DIBCOM52))) || > 1.40 - ((priv->cur_fw.type & DTV78) && freq < 47000)) > 1.41 + if ((priv->cur_fw.type & DTV78) && freq < 47000) > 1.42 offset -= 50; > > > BTW, the DTV7 firmware or DTV78 firmware is using if you are > tuning a VHF channel (frequency < 470MHz). > And the above mchehab's new codes will not do "offset -= 50;" > if DTV7 firmware is using. > > Terry > > 2010/1/7 Terry Wu : >> 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 = 175; >> + if (priv->cur_fw.type & DTV7) >> + offset = 225; >> + else /* DTV8 or DTV78 */ >> + offset = 275; >> >> and latest patch should be: >> + if (priv->cur_fw.type & DTV6) >> + offset = 175; >> + else if (priv->cur_fw.type & DTV7) >> + offset = 225; >> + else /* DTV8 or DTV78 */ >> + offset = 275; >> >> >> Terry >> >> 2010/1/7 Terry Wu : >>> Hi, >>> >>> The 6MHz patch is for Taiwan only. >>> It should not change anything for 7MHz and 8MHz. >>> >>> Terry >>> >>> 2010/1/7 Robert Lowery : > 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 >> >> > >> >> > 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 o
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi Terry,
Thanks for your comments, my responses are inline below.
> Hi,
>
> You can check the dmesg output to verify which XCEIVE
> firmware/SCODE is using.
> For examples,
> (1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7
> firmware is using,
> SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260
> [ 266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
id .
> [ 267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90),
id .
> [ 267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456
SCODE HAS_IF_5260 (6280), id .
>
> (2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78
> firmware is using,
> SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760
> [ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
id .
> [ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78
(110), id .
> [ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456
SCODE HAS_IF_4760 (62000100), id .
My firmware load logging looks as follows
[ 376.312248] xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id
.
[ 380.832015] xc2028 4-0061: Loading firmware for type=D2633 DTV7 (90),
id .
[ 380.912010] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78
DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id .
>
> Terry
>
> 2010/1/7 Terry Wu :
>> Hi,
>> The following codes in the 6MHz patch are not for 6MHz.
>> Please read the mchehab's comments.
>> 1.28 /*
>> 1.29 - * We must adjust the offset by 500kHz in two
cases in order
>> 1.30 - * to correctly center the IF output:
>> 1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables
were
>> explicitly
>> 1.32 - * selected and a 7MHz channel is tuned;
1.33 - * 2) When tuning a VHF channel with DTV78
firmware.
>> 1.34 + * We must adjust the offset by 500kHz when
1.35 + * tuning a 7MHz VHF channel with DTV78 firmware
1.36 + * (used in Australia)
>> 1.37 */
>> 1.38 - if (((priv->cur_fw.type & DTV7) &&
>> 1.39 - (priv->cur_fw.scode_table & (ZARLINK456 |
DIBCOM52))) ||
>> 1.40 - ((priv->cur_fw.type & DTV78) && freq <
47000))
>> 1.41 + if ((priv->cur_fw.type & DTV78) && freq <
47000)
>> 1.42 offset -= 50;
>> BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning
a VHF channel (frequency < 470MHz).
>> And the above mchehab's new codes will not do "offset -= 50;"
if DTV7 firmware is using.
>> Terry
Mauro's new code does the 50 offset unconditionally for DTV7 by
setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
were explicitly selected. This change is what appears to cause issues for
me.
The working (old) code used to do something like the following for DTV7
+ offset = 275;
...
+ if (((priv->cur_fw.type & DTV7) &&
+(priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) ||
+ ((priv->cur_fw.type & DTV78) && freq < 47000))
offset -= 50;
My firmware type is DTV7, but priv->cur_fw.scode_table == 1<<29 == SCODE,
which does not match the test for (ZARLINK456 | DIBCOM52), so offset is
left as 275 which works perfectly for me.
The current hg tip which does not work well for me now does a
- else if (priv->cur_fw.type & DTV7)
- offset = 225;
including the 500kHz offset adjustment in the initial value. This causes
a lot of stuttering, corruption etc for me.
My patch set proposes to revert back to the original working code, but
still implement the change from testing against ATSC to DTV6 for (Taiwan?)
That is
diff -r 32b2a1875752 linux/drivers/media/common/tuners/tuner-xc2028.c ---
a/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Nov 20 12:47:40
2009 +0100
+++ b/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Nov 27 10:29:22
2009 +1100
@@ -936,7 +936,7 @@
*/
if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
- } else if (priv->cur_fw.type & ATSC) {
+ } else if (priv->cur_fw.type & DTV6) {
offset = 175;
} else {
offset = 275;
Were you able to test my proposed patches to see if they continue to work
for you
-Rob
>> 2010/1/7 Terry Wu :
>>> 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 = 175;
>>> + if (priv->cur_fw.type & DTV7)
>>> + offset = 225;
>>> +
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi,
Please refer to the XCEIVE document.
And set the correct SCODE.
>> 380.912010] xc2028 4-0061: Loading SCODE for >>type=DTV6 QAM DTV7 DTV78
>> (What is this type ???)
>>DTV8 ZARLINK456 SCODE HAS_IF_4760
>>(620003e0), id .
Terry
2010/1/8 Terry Wu :
> Hi,
>
> XCEIVE's documents are attached.
>
> Terry
>
> 2010/1/8 Robert Lowery :
>> Hi Terry,
>>
>> Thanks for your comments, my responses are inline below.
>>
>>> Hi,
>>>
>>> You can check the dmesg output to verify which XCEIVE
>>> firmware/SCODE is using.
>>> For examples,
>>> (1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7
>>> firmware is using,
>>> SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260
>>> [ 266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
>> id .
>>> [ 267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90),
>> id .
>>> [ 267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456
>> SCODE HAS_IF_5260 (6280), id .
>>>
>>> (2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78
>>> firmware is using,
>>> SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760
>>> [ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
>> id .
>>> [ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78
>> (110), id .
>>> [ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456
>> SCODE HAS_IF_4760 (62000100), id .
>>
>> My firmware load logging looks as follows
>> [ 376.312248] xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id
>> .
>> [ 380.832015] xc2028 4-0061: Loading firmware for type=D2633 DTV7 (90),
>> id .
>> [ 380.912010] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78
>> DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id .
>>
>>>
>>> Terry
>>>
>>> 2010/1/7 Terry Wu :
Hi,
The following codes in the 6MHz patch are not for 6MHz.
Please read the mchehab's comments.
1.28 /*
1.29 - * We must adjust the offset by 500kHz in two
>> cases in order
1.30 - * to correctly center the IF output:
1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables
>> were
explicitly
1.32 - * selected and a 7MHz channel is tuned;
>> 1.33 - * 2) When tuning a VHF channel with DTV78
>> firmware.
1.34 + * We must adjust the offset by 500kHz when
>> 1.35 + * tuning a 7MHz VHF channel with DTV78 firmware
>> 1.36 + * (used in Australia)
1.37 */
1.38 - if (((priv->cur_fw.type & DTV7) &&
1.39 - (priv->cur_fw.scode_table & (ZARLINK456 |
>> DIBCOM52))) ||
1.40 - ((priv->cur_fw.type & DTV78) && freq <
>> 47000))
1.41 + if ((priv->cur_fw.type & DTV78) && freq <
>> 47000)
1.42 offset -= 50;
BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning
>> a VHF channel (frequency < 470MHz).
And the above mchehab's new codes will not do "offset -= 50;"
>> if DTV7 firmware is using.
Terry
>> Mauro's new code does the 50 offset unconditionally for DTV7 by
>> setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
>> were explicitly selected. This change is what appears to cause issues for
>> me.
>>
>> The working (old) code used to do something like the following for DTV7
>>
>> + offset = 275;
>> ...
>> + if (((priv->cur_fw.type & DTV7) &&
>> + (priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) ||
>> + ((priv->cur_fw.type & DTV78) && freq < 47000))
>> offset -= 50;
>>
>> My firmware type is DTV7, but priv->cur_fw.scode_table == 1<<29 == SCODE,
>> which does not match the test for (ZARLINK456 | DIBCOM52), so offset is
>> left as 275 which works perfectly for me.
>>
>> The current hg tip which does not work well for me now does a
>> - else if (priv->cur_fw.type & DTV7)
>> - offset = 225;
>>
>> including the 500kHz offset adjustment in the initial value. This causes
>> a lot of stuttering, corruption etc for me.
>>
>> My patch set proposes to revert back to the original working code, but
>> still implement the change from testing against ATSC to DTV6 for (Taiwan?)
>>
>> That is
>> diff -r 32b2a1875752 linux/drivers/media/common/tuners/tuner-xc2028.c ---
>> a/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Nov 20 12:47:40
>> 2009 +0100
>> +++ b/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Nov 27 10:29:22
>> 2009 +1100
>> @@ -936,7 +936,7 @@
>> */
>> if (new_mode == T_ANALOG_TV) {
>> rc = send_seq(priv, {0
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Robert Lowery wrote:
> Mauro's new code does the 50 offset unconditionally for DTV7 by
> setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
> were explicitly selected. This change is what appears to cause issues for
> me.
I've reviewed all information and troubles we have with xc3028 tuning,
including the reports related to newer firmwares for XC3028L. I think
that the right fix is the one provided on this patch.
Could you all please verify if this patch fixes the issues, without causing
any regression?
Cheers,
Mauro.
---
V4L/DVB: tuner-xc2028: fix tuning logic
There's one reported regression in Australia (DTV7) and some
reported troubles with newer firmwares. Rework the logic to improve
tuner on those cases.
Thanks-to: Robert Lowery
Thanks-to: Stefan Ringel
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/tuners/tuner-xc2028.c | 51
1 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..eb782a0 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
- if (new_mode == T_ANALOG_TV)
+ if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
- /*
-* Digital modes require an offset to adjust to the
-* proper frequency.
-* Analog modes require offset = 0
-*/
- if (new_mode == T_DIGITAL_TV) {
- /* Sets the offset according with firmware */
+ /* Analog modes require offset = 0 */
+ } else {
+ /*
+* Digital modes require an offset to adjust to the
+* proper frequency. The offset depends on what
+* firmware version is used.
+*/
+
+ /*
+* Adjust to the center frequency. This is calculated by the
+* formula: offset = 1.25MHz - BW/2
+* For DTV 7/8, the firmware uses BW = 8000, so it needs a
+* further adjustment to get the frequency center on VHF
+*/
if (priv->cur_fw.type & DTV6)
offset = 175;
else if (priv->cur_fw.type & DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;
+ if ((priv->cur_fw.type & DTV78) && freq < 47000)
+ offset -= 50;
/*
-* We must adjust the offset by 500kHz when
-* tuning a 7MHz VHF channel with DTV78 firmware
-* (used in Australia, Italy and Germany)
+* xc3028 additional "magic"
+* Depending on the firmware version, it needs some adjustments
+* to properly centralize the frequency. This seems to be
+* needed to compensate the SCODE table adjustments made by
+* newer firmwares
*/
- if ((priv->cur_fw.type & DTV78) && freq < 47000)
- offset -= 50;
+
+ if (priv->firm_version >= 0x0302) {
+ if (priv->cur_fw.type & DTV7)
+ offset -= 30;
+ else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
*/
+ offset += 20;
+ } else {
+ if (priv->cur_fw.type & DTV7)
+ offset -= 50;
+ }
}
div = (freq - offset + DIV / 2) / DIV;
@@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv->ctrl.demod) {
- demod = priv->ctrl.demod + 200;
+ /*
+* Newer firmwares require a 200 kHz offset only for ATSC
+*/
+ if (type == ATSC || priv->firm_version < 0x0302)
+ demod = priv->ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu for reporting this
--
1.6.6.1
--
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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> Robert Lowery wrote:
>> Mauro's new code does the 50 offset unconditionally for DTV7 by
>> setting offset = 225, not just when the ZARLINK456 or DIBCOM52
>> tables
>> were explicitly selected. This change is what appears to cause issues
>> for
>> me.
>
> I've reviewed all information and troubles we have with xc3028 tuning,
> including the reports related to newer firmwares for XC3028L. I think
> that the right fix is the one provided on this patch.
>
> Could you all please verify if this patch fixes the issues, without
> causing
> any regression?
Thanks Mauro, I'll test this ASAP.
I suspect there will still be issues with the "demod + 500" shift in my
scenario as I had to remove this in the past when changing the offset back
to 275 or else I could not get a tuning lock.
I'll let you know.
-Rob
>
> Cheers,
> Mauro.
>
> ---
>
> V4L/DVB: tuner-xc2028: fix tuning logic
>
> There's one reported regression in Australia (DTV7) and some
> reported troubles with newer firmwares. Rework the logic to improve
> tuner on those cases.
>
> Thanks-to: Robert Lowery
> Thanks-to: Stefan Ringel
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/common/tuners/tuner-xc2028.c | 51
>
> 1 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
> b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..eb782a0 100644
> --- a/drivers/media/common/tuners/tuner-xc2028.c
> +++ b/drivers/media/common/tuners/tuner-xc2028.c
> @@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
> u32 freq /* in HZ */,
>* that xc2028 will be in a safe state.
>* Maybe this might also be needed for DTV.
>*/
> - if (new_mode == T_ANALOG_TV)
> + if (new_mode == T_ANALOG_TV) {
> rc = send_seq(priv, {0x00, 0x00});
>
> - /*
> - * Digital modes require an offset to adjust to the
> - * proper frequency.
> - * Analog modes require offset = 0
> - */
> - if (new_mode == T_DIGITAL_TV) {
> - /* Sets the offset according with firmware */
> + /* Analog modes require offset = 0 */
> + } else {
> + /*
> + * Digital modes require an offset to adjust to the
> + * proper frequency. The offset depends on what
> + * firmware version is used.
> + */
> +
> + /*
> + * Adjust to the center frequency. This is calculated by the
> + * formula: offset = 1.25MHz - BW/2
> + * For DTV 7/8, the firmware uses BW = 8000, so it needs a
> + * further adjustment to get the frequency center on VHF
> + */
> if (priv->cur_fw.type & DTV6)
> offset = 175;
> else if (priv->cur_fw.type & DTV7)
> offset = 225;
> else/* DTV8 or DTV78 */
> offset = 275;
> + if ((priv->cur_fw.type & DTV78) && freq < 47000)
> + offset -= 50;
>
> /*
> - * We must adjust the offset by 500kHz when
> - * tuning a 7MHz VHF channel with DTV78 firmware
> - * (used in Australia, Italy and Germany)
> + * xc3028 additional "magic"
> + * Depending on the firmware version, it needs some adjustments
> + * to properly centralize the frequency. This seems to be
> + * needed to compensate the SCODE table adjustments made by
> + * newer firmwares
>*/
> - if ((priv->cur_fw.type & DTV78) && freq < 47000)
> - offset -= 50;
> +
> + if (priv->firm_version >= 0x0302) {
> + if (priv->cur_fw.type & DTV7)
> + offset -= 30;
> + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
> */
> + offset += 20;
> + } else {
> + if (priv->cur_fw.type & DTV7)
> + offset -= 50;
> + }
> }
>
> div = (freq - offset + DIV / 2) / DIV;
> @@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
> *fe,
>
> /* All S-code tables need a 200kHz shift */
> if (priv->ctrl.demod) {
> - demod = priv->ctrl.demod + 200;
> + /*
> + * Newer firmwares require a 200 kHz offset only for ATSC
> + */
> + if (type == ATSC || priv->firm_version < 0x0302)
> + demod = priv->ctrl.demod + 200;
> /*
>* The DTV7 S-code table needs a 700 kHz shift.
>* Thanks to Terry Wu for reporting this
> --
> 1.6.6.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vg
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Mauro,
I had to make 2 changes to get the patch to work for me
see below
HTH
-Rob
> Robert Lowery wrote:
>> Mauro's new code does the 50 offset unconditionally for DTV7 by
>> setting offset = 225, not just when the ZARLINK456 or DIBCOM52
>> tables
>> were explicitly selected. This change is what appears to cause issues
>> for
>> me.
>
> I've reviewed all information and troubles we have with xc3028 tuning,
> including the reports related to newer firmwares for XC3028L. I think
> that the right fix is the one provided on this patch.
>
> Could you all please verify if this patch fixes the issues, without
> causing
> any regression?
>
> Cheers,
> Mauro.
>
> ---
>
> V4L/DVB: tuner-xc2028: fix tuning logic
>
> There's one reported regression in Australia (DTV7) and some
> reported troubles with newer firmwares. Rework the logic to improve
> tuner on those cases.
>
> Thanks-to: Robert Lowery
> Thanks-to: Stefan Ringel
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/common/tuners/tuner-xc2028.c | 51
>
> 1 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
> b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..eb782a0 100644
> --- a/drivers/media/common/tuners/tuner-xc2028.c
> +++ b/drivers/media/common/tuners/tuner-xc2028.c
> @@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
> u32 freq /* in HZ */,
>* that xc2028 will be in a safe state.
>* Maybe this might also be needed for DTV.
>*/
> - if (new_mode == T_ANALOG_TV)
> + if (new_mode == T_ANALOG_TV) {
> rc = send_seq(priv, {0x00, 0x00});
>
> - /*
> - * Digital modes require an offset to adjust to the
> - * proper frequency.
> - * Analog modes require offset = 0
> - */
> - if (new_mode == T_DIGITAL_TV) {
> - /* Sets the offset according with firmware */
> + /* Analog modes require offset = 0 */
> + } else {
> + /*
> + * Digital modes require an offset to adjust to the
> + * proper frequency. The offset depends on what
> + * firmware version is used.
> + */
> +
> + /*
> + * Adjust to the center frequency. This is calculated by the
> + * formula: offset = 1.25MHz - BW/2
> + * For DTV 7/8, the firmware uses BW = 8000, so it needs a
> + * further adjustment to get the frequency center on VHF
> + */
> if (priv->cur_fw.type & DTV6)
> offset = 175;
> else if (priv->cur_fw.type & DTV7)
> offset = 225;
> else/* DTV8 or DTV78 */
> offset = 275;
> + if ((priv->cur_fw.type & DTV78) && freq < 47000)
> + offset -= 50;
>
> /*
> - * We must adjust the offset by 500kHz when
> - * tuning a 7MHz VHF channel with DTV78 firmware
> - * (used in Australia, Italy and Germany)
> + * xc3028 additional "magic"
> + * Depending on the firmware version, it needs some adjustments
> + * to properly centralize the frequency. This seems to be
> + * needed to compensate the SCODE table adjustments made by
> + * newer firmwares
>*/
> - if ((priv->cur_fw.type & DTV78) && freq < 47000)
> - offset -= 50;
> +
> + if (priv->firm_version >= 0x0302) {
> + if (priv->cur_fw.type & DTV7)
> + offset -= 30;
> + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
> */
> + offset += 20;
> + } else {
> + if (priv->cur_fw.type & DTV7)
> + offset -= 50;
This should be offset += 50;
> + }
> }
>
> div = (freq - offset + DIV / 2) / DIV;
> @@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
> *fe,
>
> /* All S-code tables need a 200kHz shift */
> if (priv->ctrl.demod) {
> - demod = priv->ctrl.demod + 200;
> + /*
> + * Newer firmwares require a 200 kHz offset only for ATSC
> + */
> + if (type == ATSC || priv->firm_version < 0x0302)
> + demod = priv->ctrl.demod + 200;
> /*
>* The DTV7 S-code table needs a 700 kHz shift.
>* Thanks to Terry Wu for reporting this
I had to also delete the
if (type & DTV7)
demod += 500
I suspect this is no longer required due to the offset += 50 above
> --
> 1.6.6.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Robert Lowery wrote:
> Mauro,
>
> I had to make 2 changes to get the patch to work for me
>
> see below
>
> HTH
>
> -Rob
>
>> +if (priv->firm_version >= 0x0302) {
>> +if (priv->cur_fw.type & DTV7)
>> +offset -= 30;
>> +else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
>> */
>> +offset += 20;
>> +} else {
>> +if (priv->cur_fw.type & DTV7)
>> +offset -= 50;
> This should be offset += 50;
>
>> /*
>> * The DTV7 S-code table needs a 700 kHz shift.
>> * Thanks to Terry Wu for reporting this
> I had to also delete the
> if (type & DTV7)
> demod += 500
>
> I suspect this is no longer required due to the offset += 50 above
Both lines should be doing the same thing, but IMO, the better is to keep
the change at the demod.
Could you please preserve the above and remove the offset +=50 ?
Note: are you available for irc? if so, please join #linuxtv at freenode.net.
Cheers,
Mauro
--
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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Robert Lowery wrote:
> Mauro,
>
> I had to make 2 changes to get the patch to work for me
Ok. Please test this (hopefully) final revision.
--
commit bd8bb8798bb96136b6898186d505c9e154334b5d
Author: Mauro Carvalho Chehab
Date: Fri Feb 19 02:45:00 2010 -0200
V4L/DVB: tuner-xc2028: fix tuning logic
There's one reported regression in Australia (DTV7) and some
reported troubles with newer firmwares. Rework the logic to improve
tuner on those cases.
Thanks-to: Robert Lowery
Thanks-to: Stefan Ringel
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..ef61815 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -932,30 +932,52 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
- if (new_mode == T_ANALOG_TV)
+ if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
- /*
-* Digital modes require an offset to adjust to the
-* proper frequency.
-* Analog modes require offset = 0
-*/
- if (new_mode == T_DIGITAL_TV) {
- /* Sets the offset according with firmware */
+ /* Analog modes require offset = 0 */
+ } else {
+ /*
+* Digital modes require an offset to adjust to the
+* proper frequency. The offset depends on what
+* firmware version is used.
+*/
+
+ /*
+* Adjust to the center frequency. This is calculated by the
+* formula: offset = 1.25MHz - BW/2
+* For DTV 7/8, the firmware uses BW = 8000, so it needs a
+* further adjustment to get the frequency center on VHF
+*/
if (priv->cur_fw.type & DTV6)
offset = 175;
else if (priv->cur_fw.type & DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;
+ if ((priv->cur_fw.type & DTV78) && freq < 47000)
+ offset -= 50;
/*
-* We must adjust the offset by 500kHz when
-* tuning a 7MHz VHF channel with DTV78 firmware
-* (used in Australia, Italy and Germany)
+* xc3028 additional "magic"
+* Depending on the firmware version, it needs some adjustments
+* to properly centralize the frequency. This seems to be
+* needed to compensate the SCODE table adjustments made by
+* newer firmwares
*/
- if ((priv->cur_fw.type & DTV78) && freq < 47000)
- offset -= 50;
+
+ if (priv->firm_version < 0x0302) {
+ if (priv->cur_fw.type & DTV7)
+ offset += 50;
+#if 0
+ /* Still need some tests */
+ } else {
+ if (priv->cur_fw.type & DTV7)
+ offset -= 30;
+ else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
*/
+ offset += 20;
+#endif
+ }
}
div = (freq - offset + DIV / 2) / DIV;
@@ -1114,17 +1136,22 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv->ctrl.demod) {
- demod = priv->ctrl.demod + 200;
+ /*
+* Newer firmwares require a 200 kHz offset only for ATSC
+*/
+ if (type == ATSC || priv->firm_version < 0x0302)
+ demod = priv->ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
-* Thanks to Terry Wu for reporting this
*
* DTV7 is only used in Australia. Germany or Italy may also
* use this firmware after initialization, but a tune to a UHF
* channel should then cause DTV78 to be used.
+*
+* Unfortunately, on real-field tests, the s-code offset
+* didn't work as expected, as reported by
+* Robert Lowery
*/
- if (type & DTV7)
- demod += 500;
}
return generic_set_freq(fe, p->frequency,
--
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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> Robert Lowery wrote:
>> Mauro,
>>
>> I had to make 2 changes to get the patch to work for me
>
> Ok. Please test this (hopefully) final revision.
This version works for me
>
> --
>
> commit bd8bb8798bb96136b6898186d505c9e154334b5d
> Author: Mauro Carvalho Chehab
> Date: Fri Feb 19 02:45:00 2010 -0200
>
> V4L/DVB: tuner-xc2028: fix tuning logic
>
> There's one reported regression in Australia (DTV7) and some
> reported troubles with newer firmwares. Rework the logic to improve
> tuner on those cases.
>
> Thanks-to: Robert Lowery
> Thanks-to: Stefan Ringel
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
> b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..ef61815 100644
> --- a/drivers/media/common/tuners/tuner-xc2028.c
> +++ b/drivers/media/common/tuners/tuner-xc2028.c
> @@ -932,30 +932,52 @@ static int generic_set_freq(struct dvb_frontend *fe,
> u32 freq /* in HZ */,
>* that xc2028 will be in a safe state.
>* Maybe this might also be needed for DTV.
>*/
> - if (new_mode == T_ANALOG_TV)
> + if (new_mode == T_ANALOG_TV) {
> rc = send_seq(priv, {0x00, 0x00});
>
> - /*
> - * Digital modes require an offset to adjust to the
> - * proper frequency.
> - * Analog modes require offset = 0
> - */
> - if (new_mode == T_DIGITAL_TV) {
> - /* Sets the offset according with firmware */
> + /* Analog modes require offset = 0 */
> + } else {
> + /*
> + * Digital modes require an offset to adjust to the
> + * proper frequency. The offset depends on what
> + * firmware version is used.
> + */
> +
> + /*
> + * Adjust to the center frequency. This is calculated by the
> + * formula: offset = 1.25MHz - BW/2
> + * For DTV 7/8, the firmware uses BW = 8000, so it needs a
> + * further adjustment to get the frequency center on VHF
> + */
> if (priv->cur_fw.type & DTV6)
> offset = 175;
> else if (priv->cur_fw.type & DTV7)
> offset = 225;
> else/* DTV8 or DTV78 */
> offset = 275;
> + if ((priv->cur_fw.type & DTV78) && freq < 47000)
> + offset -= 50;
>
> /*
> - * We must adjust the offset by 500kHz when
> - * tuning a 7MHz VHF channel with DTV78 firmware
> - * (used in Australia, Italy and Germany)
> + * xc3028 additional "magic"
> + * Depending on the firmware version, it needs some adjustments
> + * to properly centralize the frequency. This seems to be
> + * needed to compensate the SCODE table adjustments made by
> + * newer firmwares
>*/
> - if ((priv->cur_fw.type & DTV78) && freq < 47000)
> - offset -= 50;
> +
> + if (priv->firm_version < 0x0302) {
> + if (priv->cur_fw.type & DTV7)
> + offset += 50;
> +#if 0
> + /* Still need some tests */
> + } else {
> + if (priv->cur_fw.type & DTV7)
> + offset -= 30;
> + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
> */
> + offset += 20;
> +#endif
> + }
> }
>
> div = (freq - offset + DIV / 2) / DIV;
> @@ -1114,17 +1136,22 @@ static int xc2028_set_params(struct dvb_frontend
> *fe,
>
> /* All S-code tables need a 200kHz shift */
> if (priv->ctrl.demod) {
> - demod = priv->ctrl.demod + 200;
> + /*
> + * Newer firmwares require a 200 kHz offset only for ATSC
> + */
> + if (type == ATSC || priv->firm_version < 0x0302)
> + demod = priv->ctrl.demod + 200;
> /*
>* The DTV7 S-code table needs a 700 kHz shift.
> - * Thanks to Terry Wu for reporting this
>*
>* DTV7 is only used in Australia. Germany or Italy may also
>* use this firmware after initialization, but a tune to a UHF
>* channel should then cause DTV78 to be used.
> + *
> + * Unfortunately, on real-field tests, the s-code offset
> + * didn't work as expected, as reported by
> + * Robert Lowery
>*/
> - if (type & DTV7)
> - demod += 500;
> }
>
> return generic_set_freq(fe, p->frequency,
> --
> 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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Fri, 2010-03-12 at 21:34 +1100, Vincent McIntyre wrote: > On 2/20/10, Mauro Carvalho Chehab wrote: > > Robert Lowery wrote: > >> Mauro, > >> > >> I had to make 2 changes to get the patch to work for me > > > > Ok. Please test this (hopefully) final revision. > > > > -- > > > > commit bd8bb8798bb96136b6898186d505c9e154334b5d > > Author: Mauro Carvalho Chehab > > Date: Fri Feb 19 02:45:00 2010 -0200 > > I finally found time to test carefully and if anyone still cares, the > patch works fine for me too. > I pulled it in from the hg tree, by the time it got there it had > morphed a little... > Many thanks for your (and Rob's) patient work on this. > > I've attached a test log that shows what happens with signaltest.pl, > on each tuner. > The first two adapters are the Dual Digital 4 rev1, the next two > belong to a FusionHDTV Dual Digital Express. > > The errors are nice and small now, compared with the values I got > before the patch. > I noticed something a little odd - the UNC error value always > increases, even though > signaltest.pl does a fresh invocation for each station in the sequence. This is proper behavior for the frontend. The UNC count should not be reset when it is read (think of what would happen when more than one app was trying to monitor the frontend status). What matters is the slope of the UNC curve over a measurement interval: == 0 is good, > 0 is bad. > Switching to a different tuner seems to reset the UNC error counters. The zl10353 driver will maintain the UNC block count for each paticular ZL10353 chip in the system. It will only go back to 0 for a particular ZL10353 chip when the the driver's 32 bit "state->ucblocks" variable for that chip rolls over. 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
