Re: SAA7146 (KNC ONE DVB-C): ber,str values reliable?

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

 



Thomas Börkel wrote:
HI!

thomas schorpp wrote:

Whatever I do (different cables, changing amplification, switching channels), czap always reports a ber of 195000.


status SCVYL | signal 8b8b | snr f3f3 | ber 0000001e | unc ffffffff | FE_HAS_LOCK status SCVYL | signal 8b8b | snr f2f2 | ber 0000001e | unc 00000000 | FE_HAS_LOCK

its static here too on every channel.


In the meantime, using Google, I found one other owner, that also has exactly 195000. This seems pretty unlikely to me, if the ber value is computed right.

At the moment, one card has constantly 195000 and the other 101d0. I guess, when I reboot, it's back to 195000 (like it was once, when one card had a ber of 10.

BTW, czap and femon show different values, if I use femon without a tuning app (like czap) running parallel, is this normal?

$ czap "das vierte" -c channels.conf
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
151 DAS VIERTE:762000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:2047:2048:1793
151 DAS VIERTE: f 762000000, s 6900000, i 2, fec 0, qam 3, v 0x7ff, a 0x800
status 1f | signal 8484 | snr f4f4 | ber 00195000 | unc ffffffff | FE_HAS_LOCK status 1f | signal 8484 | snr f3f3 | ber 00195000 | unc 00000000 | FE_HAS_LOCK

*CTRL-C*

$ femon
using '/dev/dvb/adapter0/frontend0'
FE: Philips TDA10021 DVB-C (CABLE)
status 1f | signal 0000 | snr ffff | ber 00969696 | unc 0000000f | FE_HAS_LOCK status 1f | signal 0000 | snr ffff | ber 00969696 | unc 0000000f | FE_HAS_LOCK


ber from device and driver is ok, use dvbsnoop -s signal.

bug is from misadaption/accesssyncprobs in femon+czap:

tom1:/usr/src/linux# dvbsnoop
dvbsnoop  - a dvb/mpeg2 stream analyzer tool
Version: 1.4.00/api-3  (Sep 25 2005 20:42:27)
        http://dvbsnoop.sourceforge.net/
        (c) 2001-2005  Rainer Scherg  (rasc)

Aug 26 08:59:54 tom1 kernel:  tda10021: Verbose Status:
Aug 26 08:59:54 tom1 kernel: tda10021: VAFC -1
Aug 26 08:59:54 tom1 kernel: tda10021: VAGC 0x7f
Aug 26 08:59:54 tom1 kernel: tda10021: AGCCONF 0x23
Aug 26 08:59:54 tom1 kernel: tda10021: AGCREF 0x5c
Aug 26 08:59:54 tom1 kernel: tda10021: PWMREF 0x48
Aug 26 08:59:54 tom1 kernel: tda10021: MSE 0x0c
Aug 26 08:59:54 tom1 kernel: tda10021: BER-RANGE 0 <---- (inverted output 0...3 from sync register ber bits )
Aug 26 08:59:54 tom1 kernel: tda10021: SATNYQ 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: SATADC 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: HALFADC 0xb2
Aug 26 08:59:54 tom1 kernel: tda10021: SATDEC1 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: SATDEC2 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: SATDEC3 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: CLKOFFSET 0x1c
Aug 26 08:59:54 tom1 kernel: tda10021: SATAAF 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: EQCONF1 0x77
Aug 26 08:59:54 tom1 kernel: tda10021: EQSTEP 0x1a
Aug 26 08:59:54 tom1 kernel: tda10021: PLL 0x00

cycle: 95  d_time: 0.036 s  Sig: 32639  SNR: 62708  BER: 1620  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 96  d_time: 0.036 s  Sig: 32639  SNR: 62708  BER: 1620  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
(256qam channel)

cycle: 265  d_time: 0.035 s  Sig: 35723  SNR: 62451  BER: 20  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 266  d_time: 0.036 s  Sig: 35723  SNR: 62451  BER: 20  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
(64qam)

1. czap (ctrl-z)
2. dvbsnoop
3. femon
4. fg

you may want to reportbug femon and czap, i see no driver issue in tda10021.c

what not seems to be reliable is Sig, cause 256qam channels come with +6db from our network so VAGC must be inverse proportional to signalstrengh, not proportional, philips tuners respond to rising VAGC (tuner loop) with rising gain, too. so a reliable signal reading should be calculated from the tuner AGC loop, which is in detail unknown to me.

you cant just use *strength = (gain << 8) | gain; cause AGC gain is usually -40dB...0dB/0...3.3(5)VAGC on philips tuners.

logarithmic dB calculation with VAGC,AGCREF or like should be done, but not easy in a driver and without circuit knowlegde and in a universal driver and tvapps dont need it.

but you should honor the proportionality with

static int tda10021_read_signal_strength(struct dvb_frontend* fe, u16* strength)
{
	struct tda10021_state* state = fe->demodulator_priv;

	u8 igain = ~tda10021_readreg(state, 0x17);
	*strength = (igain << 8) | igain;

	return 0;
}

at least.





_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux