[linux-dvb] Anubis Electronics "Lifeview"(0x10fd:0x1513)

Hartmut Hackmann hartmut.hackmann at t-online.de
Thu Mar 8 23:25:19 CET 2007

Hi, Pierre

Pierre Willenbrock schrieb:
> Hi Hartmut,
> Hartmut Hackmann schrieb:
>> Hi, Pierre
>> Pierre Willenbrock schrieb:
>>> Hartmut Hackmann schrieb:
>>>> Hi,
>>>> Aapo Tahkola schrieb:
>>>>> On Sat, 3 Mar 2007 03:10:41 +0200
>>>>> Aapo Tahkola <aet at rasterburn.org> wrote:
>>>>>> On Fri, 02 Mar 2007 23:06:15 +0100
>>>>>> Pierre Willenbrock <pierre at pirsoft.dnsalias.org> wrote:
>>>>>>> Michael Krufky schrieb:
>>>>>>>> Pierre Willenbrock wrote:
>>>>>>>>> Hi list,
>>>>>>>>> I am owner of a "MSI DIGIVOX mini-II". I got it to work using the
>>>>>>>>> attached patch and firmware. The patch and firmware are the
>>>>>>>>> result of analyzing some usb logs from windows.
>>>>>>>>> The patch breaks all users of tda10046, as i don't understand how
>>>>>>>>> that chip is supposed to work. The same goes for my driver
>>>>>>>>> implementation of the Philips 8275a.
>>>>>>>>> So this mess needs to be fixed before it can go into the
>>>>>>>>> repository.
>>>>>>>>> The patch is against a fresh hg checkout from
>>>>>>>>> http://linuxtv.org/hg/v4l-dvb at 2007-02-22 21:00 UTC.
>>>>>>>>> Regards,
>>>>>>>>>   Pierre
>>>>>>>> Pierre-
>>>>>>>> I am very happy to hear that you got this device working...
>>>>>>>> Interestingly enough, we have already created a new tda827x dvb fe
>>>>>>>> module, which might be better for your device...  This new tda827x
>>>>>>>> module has not yet been merged into the master v4l-dvb repository,
>>>>>>>> but it will be soon.  Could you try to use the code located in:
>>>>>>>> http://linuxtv.org/hg/~hhackmann/v4l-dvb
>>>>>>>> The tda827x module will be able to detect the difference between
>>>>>>>> the tda8275 and the tda8275a ...  You do not have to fill the
>>>>>>>> callback functions in the config struct -- that is really meant as
>>>>>>>> a hack for some required GPIO handling in the saa7134-dvb driver
>>>>>>>> for input switching.
>>>>>>>> If you can generate a new patch against the repository above, it
>>>>>>>> would make it _much_ easier to integrate your patch into the
>>>>>>>> sources.   After you get that done, we can work out the tda1004x
>>>>>>>> differences.
>>>>>>>> You might also want to speak to aett and friedrich, regulars of
>>>>>>>> the #linuxtv irc chat room on irc.freenode.net ... aet is the
>>>>>>>> author of the m920x driver, and friedrich has the same device
>>>>>>>> that you have. They have been working on it, but haven't yet
>>>>>>>> gotten successful results.
>>>>>>>> Good work!  Hopefully we can clean this up after you generate a
>>>>>>>> new patch using the tda827x module from hhackmann's repository.
>>>>>>>> Regards,
>>>>>>>> Mike Krufky
>>>>>>> Hi Mike and Hartmut,
>>>>>>> this time, the patch does not change tda827x.c at all. I fiddled
>>>>>>> with the PHY2 value in tda1004x.c and found it to be related to the
>>>>>>> IF(there seems to be some factor between the IF and PHY2 introduced
>>>>>>> somewhere else). This leaves some differences in tda1004x.c. I don't
>>>>>>> know what to do with these, so i would be glad to get any hints.
>>>>>> Updated patch. I'm fine with these m920x changes.
>>>>> Signed-of-by: Aapo Tahkola <aet at rasterburn.org>
>>>> PHY2 indeed defines the IF frequency relative to the sampling frequency.
>>>> If you need a different value here, the reason most probably is the
>>>> following:
>>>> In some countries, i.e. Britain, France and Australia, the tranmitters
>>>> are +/- 166kHz off the channel center frequency. This isn't documented.
>>>> You can compensate this by simply tuning to the actually used channel
>>>> center frequency.
>>> The windows driver used an IF of 4.75MHz for UHF, so i resorted to
>>> hardcoding it to 4.75MHz in tda827x.c, while using PHY2, WREF and the
>>> other settings from an usb log. After changing PHY2 the hack in
>>> tda827x.c is no longer needed. This leaves me with these settings for
>>> UHF(cannot test VHF -- i don't get any channels in that range):
>>> CONFPLL2=7 //52MHz sampling clock?
>> yes
>>> FREQ_PHY2=0xc4f
>>> TIME_WREF1..5=0x5b, 0x02, 0xd0, 0x2d, 0x03
>> This gives a IF center frequency of 5.0MHz and a bandwidth of 8MHz.
>>>> A note: Some channel decoders can compensate this offset automatically.
>>>> The tda10046 needs assistance from the driver for this. This is not
>>>> built in yet.
>>>> Hartmut
>>> Regards,
>>>   Pierre
>> The only difference is that you use a sampling clock of 52MHz while the
>> original driver uses 48MHz. This btw is the same as the Philips default
>> driver for windows uses.
>> We could have a long discussion now about ideal sampling frequencies but
>> believe me: as long as your board does not have a weird interference
>> problem, 48MHz is the better choice for the sampling clock and adding a
>> additional one would only make life more difficult.
> I thought i checked that it does not easily work with 48MHz, but
> obviously i did not. The reception part works now perfectly without any
> modifications.
Ok, fine.

> This leaves me with a last difference:
> CONF_TRISTATE1 must be -0-- -0-1 (binary, msb first, - is don't care) in
> tda10046_init.
The only difference i see here is bit 6 which enables the serial TS output.
All known applications yet use the parallel output but this can be different
in your case.

RFC: should we make this a configuration option?
I would tend to add an entry "ts_mode" to tda1004x_config
which defaults to parallel (0) to remain backward compatible. At least
the standard modes should turn the other output off to avoid noise.
I can prepare a experimental patch for this to cross-check.

> In case this helps, i am using AGC_IFO_AUTO_NEG and GPTRI, but
> CONF_POLARITY = 0x20 instead of 0x60 works, too, as well as
> CONFADC2=0x34 instead of 0x38.
You should use TDA10046_AGC_TDA827X, its a recommendation from Philips.
It reduces the AGC threshold to avoid distortion.

> Regards,
>   Pierre
> PS: A quick guess: 48MHz is said to interfere with the USB frequency?
> How does the tda10046 generate its clocks, anyway?
Hm, I have no idea about the spectral distribution on the USB interface.
The tda10046 generates its sampling (and processing) clock with a PLL
from a reference - either a crystal or from external source. Most probably
it uses the tuner reference (16MHz) in your case.
This clock MUST be very stable. This is one explaination why 48 MHz is a
good choice: it is a integer multiple of the reference.


More information about the linux-dvb mailing list