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
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
