fyi
PS: also for your info, http://www.dba.org.au/ has frequencies for all
Australian DVB-T transmitters, including all regions in Tasmania.
Doesn't have all the frequencies in sydney, ch 44 is missing
On 14/06/2004, at 10:08 PM, 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
<mt352.c>
