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 0000000000000000.
> [ 267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90),
id 0000000000000000.
> [ 267.111148] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456
SCODE HAS_IF_5260 (62000080), id 0000000000000000.
>
> (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 0000000000000000.
> [ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78
(110), id 0000000000000000.
> [ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456
SCODE HAS_IF_4760 (62000100), id 0000000000000000.
My firmware load logging looks as follows
[ 376.312248] xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id
0000000000000000.
[ 380.832015] xc2028 4-0061: Loading firmware for type=D2633 DTV7 (90),
id 0000000000000000.
[ 380.912010] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78
DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id 0000000000000000.
>
> Terry
>
> 2010/1/7 Terry Wu <terrywu2...@gmail.com>:
>> 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 <
470000000))
>> 1.41 + if ((priv->cur_fw.type & DTV78) && freq <
470000000)
>> 1.42 offset -= 500000;
>> 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 -= 500000;"
if DTV7 firmware is using.
>> Terry
Mauro's new code does the 500000 offset unconditionally for DTV7 by
setting offset = 2250000, 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 = 2750000;
...
+ if (((priv->cur_fw.type & DTV7) &&
+ (priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) ||
+ ((priv->cur_fw.type & DTV78) && freq < 470000000))
offset -= 500000;
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 2750000 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 = 2250000;
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 = 1750000;
} else {
offset = 2750000;
Were you able to test my proposed patches to see if they continue to work
for you
-Rob
>> 2010/1/7 Terry Wu <terrywu2...@gmail.com>:
>>> 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 <terrywu2...@gmail.com>:
>>>> Hi,
>>>> The 6MHz patch is for Taiwan only.
>>>> It should not change anything for 7MHz and 8MHz.
>>>> Terry
>>>> 2010/1/7 Robert Lowery <rglow...@exemail.com.au>:
>>>>>> 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
> --
> 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
