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