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

Hartmut Hackmann hartmut.hackmann at t-online.de
Thu Mar 8 00:33:37 CET 2007

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?


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

Best regards
Best regards

More information about the linux-dvb mailing list