Hi, Pierre Pierre Willenbrock schrieb: > Hartmut Hackmann schrieb: >> Hi, >> >> Aapo Tahkola schrieb: >>> On Sat, 3 Mar 2007 03:10:41 +0200 >>> Aapo Tahkola <aet@xxxxxxxxxxxxxx> wrote: >>> >>>> On Fri, 02 Mar 2007 23:06:15 +0100 >>>> Pierre Willenbrock <pierre@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> >>> >> 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. Best regards Hartmut Best regards Hartmut _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
