Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Airstar2 and VHF
Nico Sabbi wrote:
> Dieter Zander wrote:
>
> >Nico Sabbi wrote:
> >
> >
> >>Dieter Zander wrote:
> >>
> >>
> >>
> >>>Hi Folks,
> >>>
> >>>the solution seems so easy. After studying the mt352 Design Manual we
> >>>changed only one bit.
> >>>
> >>>According the table 7 on page 52 in this Design Manual you can see 7
> >>>modes for the CLOCK_CTL. Mode 1 is default and it is only for 8 MHz OFDM
> >>>reception. For receiving channels using 6 or 7 MHz you have to change
> >>>this mode to mode 2.
> >>>
> >>>In the file skystar2.c you will find at line 2341:
> >>>
> >>>-> static u8 mt352_clock_config [] = { 0x89, 0x10, 0x2d };
> >>>
> >>>The second hex-number (0x10) stands for the mode 1 of CLOCK_CTL.
> >>>
> >>>Just change it to the following:
> >>>
> >>>-> static u8 mt352_clock_config [] = { 0x89, 0x18, 0x2d };
> >>>
> >>>Here the second hex-number is 0x18, that means mode 2 of CLOCK_CTL.
> >>>
> >>>Et voilá! Compiling the drivers and have fun. We have tried it here in
> >>>the german Rhein-Main-Area, where the ARD is using a VHF-frequency with
> >>>7 MHz. And.... it works fine! :-)))
> >>>
> >>>Please, try it, and if it works in other areas also, change the code of
> >>>the file skystar2.c.
> >>>
> >>>Thank You.
> >>>
> >>>Thomas Martin and Dieter Zander
> >>>
> >>>Index: skystar2.c
> >>>===================================================================
> >>>RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/b2c2/skystar2.c
> >>>revision 1.21
> >>>@@ 2339 @@ static int samsung tdtc9251dh0_demod_init
> >>>
> >>>static int samsung_tdtc9251dh0_demod_init(struct dvb_frontend* fe)
> >>>{
> >>>- static u8 mt352_clock_config [] = { 0x89, 0x10, 0x2d };
> >>>+ static u8 mt352_clock_config [] = { 0x89, 0x18, 0x2d };
> >>> static u8 mt352_reset [] = { 0x50, 0x80 };
> >>> static u8 mt352_adc_ctl_1_cfg [] = { 0x8E, 0x40 };
> >>> static u8 mt352_agc_cfg [] = { 0x67, 0x28, 0xa1 };
> >>> static u8 mt352_capt_range_cfg[] = { 0x75, 0x32 };
> >>>
> >>> mt352_write(fe, mt352_clock_config, sizeof(mt352_clock_config));
> >>> udelay(2000);
> >>> mt352_write(fe, mt352_reset, sizeof(mt352_reset));
> >>> mt352_write(fe, mt352_adc_ctl_1_cfg, sizeof(mt352_adc_ctl_1_cfg));
> >>>
> >>> mt352_write(fe, mt352_agc_cfg, sizeof(mt352_agc_cfg));
> >>> mt352_write(fe, mt352_capt_range_cfg, sizeof(mt352_capt_range_cfg));
> >>>
> >>> return 0;
> >>>}
> >>>
> >>>
> >>>
> >>>
> >>GREAT! it's working, but there's a strange thing: that clock must be
> >>used only
> >>for 7 and 6 Mhz bandwidth, while 0x10 for 8 Mhz, (so your patch should
> >>change the value
> >>
> >>mt352_clock_config[1]
> >>
> >>accordingly), yet tuning to 8 Mhz channels still succeeds :)
> >>
> >>In any case Thanks!
> >>
> >>
> >>
> >>
> >
> >Fine.. :-)
> >
> >But one question: What is wrong? What do you mean? We use this patch and
> >EVERY bandwidth is working... 6, 7 and 8 MHz. Because in the Design
> >Manual on page 51 are some notes:
> >
> >"The register is reset to its default only by the hardware[...]It's
> >important to note that mode 1 is valid only for 8 MHz channel bandwidth.
> >All other modes are valid for all channel bandwidth 6, 7 and 8 MHz."
> >
> >So we understand that mode 2 will work with ALL bandwidths, for 8 MHz
> >too. That's why we think there is no necessity for a additional value
> >like mt352_clock_config[1].
> >
> >Or are we completly wrong?
> >
> >
> >
> I must have missed this section, but the reference code I have seem to
> use the other clock
> (20.48 hz) for 8 Mhz channels. I want to try and see what happens after
> reboot :)
>
Each channel, 6, 7 or 8 MHz, is using the same cristal clock: 20,48 MHz!
Mode 1 and mode 2 are using cristal clock 20,48 MHz as well as generated
ADC-clock at 20,48 MHz. We are wondering why there is a mode 1, which is
only usable with a 8 MHz bandwidth.
T+D
Home |
Main Index |
Thread Index