Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: AverMedia DVB-T 771 problems



My apologies to Wolfgang. I see the mt352.c has incorrect values but his
linux-dvb-1.1.1.diff applies the correct values. Mea culpa.

Silly question, have you tried viewing the DVB stream in something like
mplayer? Try mplayer dvb://"Ten Digital". The tzap output proves you've
got a strong signal and it can LOCK. No SYNC or VITERBI though, hrm.



On Mon, 2004-06-14 at 22:08 +1000, Nathan Hand wrote:
> The mt352.c at the URL you provided appears to be incorrect. I submitted
> a patch last week but Wolfgang apparently hasn't integrated it yet. The
> shifts in mt352_set_parameters are all completely wrong. I have attached
> a slightly modified version that works for me here in Canberra. I have
> been using an AverMedia DVB-T 771 for a week now with MythTV, absolutely
> perfect reception for all stations. It is a good card.
> 
> For reference, the correct values are documented on page 38 of the MT352
> Design Manual in the TPS_GIVEN table.
> 
>     http://assets.zarlink.com/DM/MT352_Design_Manual_Nov03.pdf
> 
> PS: also for your info, http://www.dba.org.au/ has frequencies for all
> Australian DVB-T transmitters, including all regions in Tasmania.
> 
> 
> On Tue, 2004-06-15 at 05:33 +1000, Jolse Maginnis wrote:
> > Hi,
> > 
> > I've purchased an AverMedia DVB-T 771, and I live in Tasmania,
> > Australia, but I can't seem to get it to tune anything in linux. It
> > works in winxp (I can tune nearly all the channels with my crap
> > aerial), so it's got to be the driver.
> > 
> > I'm using the patches from
> > http://www.frokaschwei.net/avtv771/avermedia.html
> > and they appear to work better than what's in cvs, but all I get when I
> > try using tzap is something like:
> > 
> > ./tzap -c channels.conf-dvbt-australia "Ten Digital"
> > 
> > status 13 | signal 8b8b | snr 7474 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 13 | signal 8383 | snr 7c7c | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 13 | signal 8383 | snr 7c7c | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 13 | signal 8b8b | snr 7474 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 13 | signal 8b8b | snr 7474 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 13 | signal 8b8b | snr 7474 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > 
> > I know that the frequency is correct because i noted the frequencies for 
> > the channels in windows.
> > 
> > I did some exploring in mt352.c and managed to get the mt352 to scan for 
> > channels, but there was no luck. But what was more disturbing was that status 
> > registers appeared to be not being read properly.
> > 
> > In mt352.c the code that checks the status of the signal:
> > 
> > 	case FE_READ_STATUS:
> > 		status = arg;
> > 		*status = 0;
> > 		r = mt352_read_register (i2c, 0x00);
> > 		if (r & (1 << 4))
> > 			*status = FE_HAS_CARRIER;
> > 		if (r & (1 << 1))
> > 			*status |= FE_HAS_VITERBI;
> > 		if (r & (1 << 5))
> > 			*status |= FE_HAS_LOCK;
> > 
> > 		r = mt352_read_register (i2c, 0x01);
> > 		if (r & (1 << 1))
> > 			*status |= FE_HAS_SYNC;
> > 
> > 		r = mt352_read_register (i2c, 0x03);
> > 		if (r & (1 << 6))
> > 			*status |= FE_HAS_SIGNAL;
> > 		
> > 		break;
> > 
> > if i add:
> > 		r = mt352_read_register (i2c, 0x7f);
> > before:
> > 		r = mt352_read_register (i2c, 0x00);
> > the read of register 0x00 returns the same as the read of register 0x7f!
> > And it appears that the "snr" values from above are actually the value of register 0x03!
> > 
> > Very strange indeed..
> > 
> > Can anybody shed any light on this problem? 
> > I'm running 2.6.7-rc3 with a Pentium4 2.8ghz.
> > 
> > Jolse
> > 
> > 
> > 




Home | Main Index | Thread Index