[linux-dvb] Re: tzap status output - what does it all mean?

[Rob <rob-linuxtv@noblesque.org.uk>]

Holger Waechtler wrote:

> > It looks like there's one byte for signal strength, so "signal 00ff
> > " in the tzap output would be maximum.
>
>  can you please fix the driver so that it reports ((signal << 8) |
>  signal)? This scales the 8bit value into the full 16bit range. Please
>  post a patch if you get this working, then we can take over this
>  change into the main tree.
I can do that, yes.  It's attached, but see below first.

> > And it looks like there's a one byte count for uncorrectable
> > blocks, but it wraps around and the difference (modulo 256) is
> > reported, so I'm still a bit puzzled why I see so many 0x100 in the
> > output. Maybe the 8-bit register increases up to 0x100 times
> > between reads, but then stops to prevent wraparound errors in
> > calculations?
> >
> > So would I be right in guessing that when ber is 0 and unc is
> > 0x100, that probably means the signal is so bad that there are
> > _lots_ of uncorrectable errors, and therefore it wasn't possible to
> > correct any blocks? If the signal gets a bit better, then I'll
> > start to see ber above zero? In other words, if unc is 0x100, then
> > ignore ber.
>
>  I would suggest to report the maximum value (0xffffffff) to userspace
>  in these cases, then the overflow is easy to detect and reported to
>  userspace.
I was guessing about the overflow, and I think guessed wrongly.

First of all I should mention that I'm using the version of cx22702.c 
from video4linux-20050210-124039.tar.gz (so is this the right place to 
discuss it?).

What's happening is that the Uncorrectable Packet Count is being read 
from the card, and mostly it's the same every time (ie. no new unc 
packets since the last time).  The code ends up returning 256 for this 
circumstance:

static int cx22702_read_ucblocks(struct dvb_frontend* fe, u32* ucblocks)
{
       struct cx22702_state *state = fe->demodulator_priv;
       u8 ucb;

       /* RS Uncorrectable Packet Count then reset */
       ucb = readreg(&state->demod, 0xE3);
       if (state->prevUCBlocks < ucb)
               *ucblocks = (ucb - state->prevUCBlocks);
       else
               *ucblocks = 256 + ucb - state->prevUCBlocks;
       state->prevUCBlocks = ucb;
       return 0;
}

Changing that '<' to '<=' seems to fix it.  The version in dvb-kernel 
CVS doesn't have this problem.

--
Rob
*** video4linux/cx22702.c	2005-02-10 22:08:59.000000000 +0000
--- fixed-video4linux/cx22702.c	2005-02-10 22:09:20.000000000 +0000
***************
*** 400,411 ****
  }
  
  static int cx22702_read_signal_strength(struct dvb_frontend* fe, u16* strength)
  {
  	struct cx22702_state *state = fe->demodulator_priv;
  
! 	*strength = readreg(&state->demod, 0x23);
  	return 0;
  }
  
  static int cx22702_read_snr(struct dvb_frontend* fe, u16* snr)
  {
--- 400,413 ----
  }
  
  static int cx22702_read_signal_strength(struct dvb_frontend* fe, u16* strength)
  {
  	struct cx22702_state *state = fe->demodulator_priv;
+ 	u8 signal;
  
! 	signal = readreg(&state->demod, 0x23);
! 	*strength = ((signal<<8) | signal);
  	return 0;
  }
  
  static int cx22702_read_snr(struct dvb_frontend* fe, u16* snr)
  {
***************
*** 423,433 ****
  	struct cx22702_state *state = fe->demodulator_priv;
  	u8 ucb;
  
  	/* RS Uncorrectable Packet Count then reset */
  	ucb = readreg(&state->demod, 0xE3);
! 	if (state->prevUCBlocks < ucb)
  		*ucblocks = (ucb - state->prevUCBlocks);
  	else
  		*ucblocks = 256 + ucb - state->prevUCBlocks;
  	state->prevUCBlocks = ucb;
  	return 0;
--- 425,435 ----
  	struct cx22702_state *state = fe->demodulator_priv;
  	u8 ucb;
  
  	/* RS Uncorrectable Packet Count then reset */
  	ucb = readreg(&state->demod, 0xE3);
! 	if (state->prevUCBlocks <= ucb)
  		*ucblocks = (ucb - state->prevUCBlocks);
  	else
  		*ucblocks = 256 + ucb - state->prevUCBlocks;
  	state->prevUCBlocks = ucb;
  	return 0;