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@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. > > 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. Hartmut _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
