[linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[e9hack]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hi,

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
makes the UNC value of the femon plugin useless. The attached patch will fix this issue. 
It is simple for the stv0297. For the tda10021, the uncorrected block count must be read 
cyclical, because the resolution of the counter is very low. This can be done within 
tda10021_read_status. The read-status-function is called cyclical from the frontend-thread.

Some other frontends have the same problem (tda10023, ves1820, ves1x93, ...).

-Hartmut




[-- Attachment #2: tda10021-unc-fix.diff --]
[-- Type: text/x-diff, Size: 2209 bytes --]

signed-off-by: Hartmut Birr <e9hack@gmail.com>
- The uncorrected block counter shouldn't be reset on read. The tda10021 contains 
  an uncorrected block counter, which has only a resoltion of 7 bits and 
  which isn't able wrap to zero. The driver must manage the block counter by itself. 
diff -r 4c4fd6b8755c linux/drivers/media/dvb/frontends/tda10021.c
--- a/linux/drivers/media/dvb/frontends/tda10021.c	Fri May 02 07:51:27 2008 -0300
+++ b/linux/drivers/media/dvb/frontends/tda10021.c	Sat May 03 18:55:09 2008 +0200
@@ -41,6 +41,8 @@ struct tda10021_state {
 
 	u8 pwm;
 	u8 reg0;
+	u8 last_lock : 1;
+	u32 ucblocks;
 };
 
 
@@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
 
 	tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
 
+	/* reset uncorrected block counter */
+	state->last_lock = 0;
+	state->ucblocks = 0;
+
 	return 0;
 }
 
@@ -273,6 +279,7 @@ static int tda10021_read_status(struct d
 {
 	struct tda10021_state* state = fe->demodulator_priv;
 	int sync;
+	u32 ucblocks;
 
 	*status = 0;
 	//0x11[0] == EQALGO -> Equalizer algorithms state
@@ -291,6 +298,22 @@ static int tda10021_read_status(struct d
 	if (sync & 8)
 		*status |= FE_HAS_LOCK;
 
+	/* read uncorrected block counter */
+	ucblocks = tda10021_readreg(state, 0x13) & 0x7f;
+
+	/* reset uncorrected block counter */
+	_tda10021_writereg(state, 0x10, tda10021_inittab[0x10] & 0xdf);
+	_tda10021_writereg(state, 0x10, tda10021_inittab[0x10]);
+
+	if (sync & 8) {
+		if (state->last_lock)
+			/* update ucblocks */
+			state->ucblocks += ucblocks;
+		state->last_lock = 1;
+	} else {
+		state->last_lock = 0;
+	}
+
 	return 0;
 }
 
@@ -335,14 +358,10 @@ static int tda10021_read_ucblocks(struct
 static int tda10021_read_ucblocks(struct dvb_frontend* fe, u32* ucblocks)
 {
 	struct tda10021_state* state = fe->demodulator_priv;
-
-	*ucblocks = tda10021_readreg (state, 0x13) & 0x7f;
-	if (*ucblocks == 0x7f)
-		*ucblocks = 0xffffffff;
-
-	/* reset uncorrected block counter */
-	_tda10021_writereg (state, 0x10, tda10021_inittab[0x10] & 0xdf);
-	_tda10021_writereg (state, 0x10, tda10021_inittab[0x10]);
+	fe_status_t status;
+
+	tda10021_read_status(fe, &status);
+	*ucblocks = state->ucblocks;
 
 	return 0;
 }

[-- Attachment #3: stv0297-unc-fix.diff --]
[-- Type: text/x-diff, Size: 653 bytes --]

signed-off-by: Hartmut Birr <e9hack@gmail.com>
- Don't reset the uncorrected block counter on a read request.
diff -r 4c4fd6b8755c linux/drivers/media/dvb/frontends/stv0297.c
--- a/linux/drivers/media/dvb/frontends/stv0297.c	Fri May 02 07:51:27 2008 -0300
+++ b/linux/drivers/media/dvb/frontends/stv0297.c	Sat May 03 15:43:48 2008 +0200
@@ -398,7 +398,6 @@ static int stv0297_read_ucblocks(struct 
 	*ucblocks = (stv0297_readreg(state, 0xD5) << 8)
 		| stv0297_readreg(state, 0xD4);
 
-	stv0297_writereg_mask(state, 0xDF, 0x03, 0x02); /* clear the counters */
 	stv0297_writereg_mask(state, 0xDF, 0x03, 0x01); /* re-enable the counters */
 
 	return 0;

[-- Attachment #4: Type: text/plain, Size: 150 bytes --]

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

e9hack wrote:
> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
> makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e.
nobody wants to know what happened last year...

Afaics it is ok to reset the counter after reading it.
All drivers should behave this way.

If the femon plugin requires something else it might store the values
and process them as desired.

Afaics the femon command line tool has no problems with that.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

Oliver Endriss wrote:
> e9hack wrote:
> > the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
> > makes the UNC value of the femon plugin useless.
> 
> Why? It does not make sense to accumulate the errors forever, i.e.
> nobody wants to know what happened last year...
> 
> Afaics it is ok to reset the counter after reading it.
> All drivers should behave this way.
> 
> If the femon plugin requires something else it might store the values
> and process them as desired.
> 
> Afaics the femon command line tool has no problems with that.

Argh, I just checked the API 1.0.0. spec:
| FE READ UNCORRECTED BLOCKS
| This ioctl call returns the number of uncorrected blocks detected by the device
| driver during its lifetime. For meaningful measurements, the increment
| in block count during a speci c time interval should be calculated. For this
| command, read-only access to the device is suf cient.
| Note that the counter will wrap to zero after its maximum count has been
| reached

So it seens you are right and the drivers should accumulate the errors
forever. Any opinions?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Michael Krufky]

Oliver Endriss wrote:
> Oliver Endriss wrote:
>> e9hack wrote:
>>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
>>> makes the UNC value of the femon plugin useless.
>> Why? It does not make sense to accumulate the errors forever, i.e.
>> nobody wants to know what happened last year...
>>
>> Afaics it is ok to reset the counter after reading it.
>> All drivers should behave this way.
>>
>> If the femon plugin requires something else it might store the values
>> and process them as desired.
>>
>> Afaics the femon command line tool has no problems with that.
> 
> Argh, I just checked the API 1.0.0. spec:
> | FE READ UNCORRECTED BLOCKS
> | This ioctl call returns the number of uncorrected blocks detected by the device
> | driver during its lifetime. For meaningful measurements, the increment
> | in block count during a speci c time interval should be calculated. For this
> | command, read-only access to the device is suf cient.
> | Note that the counter will wrap to zero after its maximum count has been
> | reached
> 
> So it seens you are right and the drivers should accumulate the errors
> forever. Any opinions?
> 

There are some devices that automatically reset the unc counter registers
as they are read, and other devices that wrap to zero after its maximum
count has been reached, unless the driver explicitly clears it. *(see below)

There are other devices that dont give unc info directly, but instead
report an average unc per time interval.

I think it's possible that at the time the 1.0.0 spec was written, most
devices were known to exhibit the behavior as described in the blurb
quoted from the API 1.0.0 spec, above.

I don't think that all of the drivers comply to this, exactly as described,
and it might be difficult to correct this across the board :-(  In many
cases, we might not know for sure how absolute the value is, read from these
registers on a given device.

I am not sure what we should do, but here is an argument that supports the
API 1.0.0 spec:

*There are some demods whose firmware uses these counters to determine lock
state.  If we explicitly clear the counter registers during a channel scan,
we can potentially confuse the firmware into detecting false locks, and not
detecting real locks.

-Mike


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

Michael Krufky wrote:
> Oliver Endriss wrote:
> > Oliver Endriss wrote:
> >> e9hack wrote:
> >>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
> >>> makes the UNC value of the femon plugin useless.
> >> Why? It does not make sense to accumulate the errors forever, i.e.
> >> nobody wants to know what happened last year...
> >>
> >> Afaics it is ok to reset the counter after reading it.
> >> All drivers should behave this way.
> >>
> >> If the femon plugin requires something else it might store the values
> >> and process them as desired.
> >>
> >> Afaics the femon command line tool has no problems with that.
> > 
> > Argh, I just checked the API 1.0.0. spec:
> > | FE READ UNCORRECTED BLOCKS
> > | This ioctl call returns the number of uncorrected blocks detected by the device
> > | driver during its lifetime. For meaningful measurements, the increment
> > | in block count during a speci c time interval should be calculated. For this
> > | command, read-only access to the device is suf cient.
> > | Note that the counter will wrap to zero after its maximum count has been
> > | reached
> > 
> > So it seens you are right and the drivers should accumulate the errors
> > forever. Any opinions?
> > 
> 
> There are some devices that automatically reset the unc counter registers
> as they are read, and other devices that wrap to zero after its maximum
> count has been reached, unless the driver explicitly clears it. *(see below)
> 
> There are other devices that dont give unc info directly, but instead
> report an average unc per time interval.

Anyway, the driver should do its best to follow the API spec.
If the hardware returns an error rate the driver might convert it to an
(estimated) absolute value.

> I think it's possible that at the time the 1.0.0 spec was written, most
> devices were known to exhibit the behavior as described in the blurb
> quoted from the API 1.0.0 spec, above.
> 
> I don't think that all of the drivers comply to this, exactly as described,
> and it might be difficult to correct this across the board :-(  In many
> cases, we might not know for sure how absolute the value is, read from these
> registers on a given device.
>
> I am not sure what we should do, but here is an argument that supports the
> API 1.0.0 spec:
> 
> *There are some demods whose firmware uses these counters to determine lock
> state.  If we explicitly clear the counter registers during a channel scan,
> we can potentially confuse the firmware into detecting false locks, and not
> detecting real locks.

Imho we should try to follow the API spec as close as possible.
If we cannot implement an ioctl due to lack of information, there is
little we can do...

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[e9hack]

Oliver Endriss schrieb:
> Argh, I just checked the API 1.0.0. spec:
> | FE READ UNCORRECTED BLOCKS
> | This ioctl call returns the number of uncorrected blocks detected by the device
> | driver during its lifetime. For meaningful measurements, the increment
> | in block count during a speci c time interval should be calculated. For this
> | command, read-only access to the device is suf cient.
> | Note that the counter will wrap to zero after its maximum count has been
> | reached
> 

First you read a very old spec, now you read an old spec. This description is no longer a 
part of the spec. In the current spec 
(http://linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf), many necessary 
descriptions are missing.

-Hartmut

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

e9hack wrote:
> Oliver Endriss schrieb:
> > Argh, I just checked the API 1.0.0. spec:
> > | FE READ UNCORRECTED BLOCKS
> > | This ioctl call returns the number of uncorrected blocks detected by the device
> > | driver during its lifetime. For meaningful measurements, the increment
> > | in block count during a speci c time interval should be calculated. For this
> > | command, read-only access to the device is suf cient.
> > | Note that the counter will wrap to zero after its maximum count has been
> > | reached
> > 
> 
> First you read a very old spec, now you read an old spec. This description is no longer a 
> part of the spec. In the current spec 
> (http://linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf), many necessary 
> descriptions are missing.

No, the API V4 proposal does not apply to current drivers.
The current API is V3.

Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Andy Walls]

On Sat, 2008-05-10 at 17:27 +0200, Oliver Endriss wrote:
> Oliver Endriss wrote:
> > e9hack wrote:
> > > the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
> > > makes the UNC value of the femon plugin useless.
> > 
> > Why? It does not make sense to accumulate the errors forever, i.e.
> > nobody wants to know what happened last year...
> > 
> > Afaics it is ok to reset the counter after reading it.
> > All drivers should behave this way.
> > 
> > If the femon plugin requires something else it might store the values
> > and process them as desired.
> > 
> > Afaics the femon command line tool has no problems with that.
> 
> Argh, I just checked the API 1.0.0. spec:
> | FE READ UNCORRECTED BLOCKS
> | This ioctl call returns the number of uncorrected blocks detected by the device
> | driver during its lifetime. For meaningful measurements, the increment
> | in block count during a speci c time interval should be calculated. For this
> | command, read-only access to the device is suf cient.
> | Note that the counter will wrap to zero after its maximum count has been
> | reached
> 
> So it seens you are right and the drivers should accumulate the errors
> forever. Any opinions?

For communications systems, whether its is two-way or one-way broadcast,
most people are concerned with the error *rate* (errors per unit time)
rather than absolute error counts.  Communications engineers have a good
understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and
adjust their expectations accordingly.  Absolute counts have less
meaning to engineers, and I'm not sure what a layman would make of them.

I'd suggest whatever error counts you store have a start time and
starting value (i.e. 0) associated with them, so when you look at the
accumulated value at present you can determine the average error rate.

When should the error counter and start time be reset?  On channel
(frequency) change is a convenient and make sense to me.  When the
counter overflows is obviously another time.  When the time reaches a
certain number of seconds?  Maybe implement a moving average (sliding
window) to better report the current instantaneous error rate.


Regards,
Andy



> CU
> Oliver
> 


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Manu Abraham]

Andy Walls wrote:
> On Sat, 2008-05-10 at 17:27 +0200, Oliver Endriss wrote:
>> Oliver Endriss wrote:
>>> e9hack wrote:
>>>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
>>>> makes the UNC value of the femon plugin useless.
>>> Why? It does not make sense to accumulate the errors forever, i.e.
>>> nobody wants to know what happened last year...
>>>
>>> Afaics it is ok to reset the counter after reading it.
>>> All drivers should behave this way.
>>>
>>> If the femon plugin requires something else it might store the values
>>> and process them as desired.
>>>
>>> Afaics the femon command line tool has no problems with that.
>> Argh, I just checked the API 1.0.0. spec:
>> | FE READ UNCORRECTED BLOCKS
>> | This ioctl call returns the number of uncorrected blocks detected by the device
>> | driver during its lifetime. For meaningful measurements, the increment
>> | in block count during a speci c time interval should be calculated. For this
>> | command, read-only access to the device is suf cient.
>> | Note that the counter will wrap to zero after its maximum count has been
>> | reached
>>
>> So it seens you are right and the drivers should accumulate the errors
>> forever. Any opinions?
> 
> For communications systems, whether its is two-way or one-way broadcast,
> most people are concerned with the error *rate* (errors per unit time)
> rather than absolute error counts.  Communications engineers have a good
> understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and
> adjust their expectations accordingly.  Absolute counts have less
> meaning to engineers, and I'm not sure what a layman would make of them.

There is different terminology involved:

BER: implies a rate which is averaged over a period of time. This
implies the errors in the stream, not after FEC.

UNC: Uncorrected symbols over a lifetime, well this is not practically
possible and will wrap around. This is not related to time, but it is
just a measure of the symbols that wasn't been able by the FEC engine to
correct. Generally a meaningless term, in many cases except a few.

Absolute errors are used very scantily, but have been used to see how
good/bad the whole system is. BER cannot define this, as it is defined
before the FEC. Sometimes what's defined in the BER, the FEC engine
might be able to correct and hence.

Regards,
Manu

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Andy Walls]

On Sun, 2008-05-11 at 02:16 +0400, Manu Abraham wrote:
> Andy Walls wrote:
> > On Sat, 2008-05-10 at 17:27 +0200, Oliver Endriss wrote:
> >> Oliver Endriss wrote:
> >>> e9hack wrote:
> >>>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
> >>>> makes the UNC value of the femon plugin useless.
> >>> Why? It does not make sense to accumulate the errors forever, i.e.
> >>> nobody wants to know what happened last year...
> >>>
> >>> Afaics it is ok to reset the counter after reading it.
> >>> All drivers should behave this way.
> >>>
> >>> If the femon plugin requires something else it might store the values
> >>> and process them as desired.
> >>>
> >>> Afaics the femon command line tool has no problems with that.
> >> Argh, I just checked the API 1.0.0. spec:
> >> | FE READ UNCORRECTED BLOCKS
> >> | This ioctl call returns the number of uncorrected blocks detected by the device
> >> | driver during its lifetime. For meaningful measurements, the increment
> >> | in block count during a speci c time interval should be calculated. For this
> >> | command, read-only access to the device is suf cient.
> >> | Note that the counter will wrap to zero after its maximum count has been
> >> | reached
> >>
> >> So it seens you are right and the drivers should accumulate the errors
> >> forever. Any opinions?
> > 
> > For communications systems, whether its is two-way or one-way broadcast,
> > most people are concerned with the error *rate* (errors per unit time)
> > rather than absolute error counts.  Communications engineers have a good
> > understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and
> > adjust their expectations accordingly.  Absolute counts have less
> > meaning to engineers, and I'm not sure what a layman would make of them.
> 
> There is different terminology involved:
> 
> BER: implies a rate which is averaged over a period of time. This
> implies the errors in the stream, not after FEC.

Yes.  I used the term too loosely in my example.  Thank you for the
clarification/correction.


> UNC: Uncorrected symbols over a lifetime, well this is not practically
> possible and will wrap around. This is not related to time, but it is
> just a measure of the symbols that wasn't been able by the FEC engine to
> correct.

Right.  But maybe a Symbol Error (or Erasure) Rate provides more useful
information than just a count, no?  

An error rate computed over a "short" interval can be used to detect a
period of communications interruption within software to alert the user
or to take corrective action.

Absolute counts aren't useful for assessing the current "health" of the
system.


> Generally a meaningless term, in many cases except a few.

I agree.

> Absolute errors are used very scantily, but have been used to see how
> good/bad the whole system is.

Except for in safety critical systems (fire suppression system,
automobile brakes, etc.), how can a "good/bad" determination based on an
error count be separated from a time interval over which that error
count occurred?


>  BER cannot define this, as it is defined
> before the FEC. Sometimes what's defined in the BER, the FEC engine
> might be able to correct and hence.

Right BER doesn't define performance of a system, just a constraint
under which the system is expected to work.

So we can call what I suggested Uncorrected Symbol Rate, or Symbol Error
Rate, or Message Error Rate if the FEC covers more than 1 symbol -
whatever makes the most sense.

My opinion is that reporting of rate is more useful than absolute
counts.

Regards,
Andy

> 
> Regards,
> Manu
> 


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Manu Abraham]

Andy Walls wrote:
> On Sun, 2008-05-11 at 02:16 +0400, Manu Abraham wrote:
>> Andy Walls wrote:
>>> On Sat, 2008-05-10 at 17:27 +0200, Oliver Endriss wrote:
>>>> Oliver Endriss wrote:
>>>>> e9hack wrote:
>>>>>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
>>>>>> makes the UNC value of the femon plugin useless.
>>>>> Why? It does not make sense to accumulate the errors forever, i.e.
>>>>> nobody wants to know what happened last year...
>>>>>
>>>>> Afaics it is ok to reset the counter after reading it.
>>>>> All drivers should behave this way.
>>>>>
>>>>> If the femon plugin requires something else it might store the values
>>>>> and process them as desired.
>>>>>
>>>>> Afaics the femon command line tool has no problems with that.
>>>> Argh, I just checked the API 1.0.0. spec:
>>>> | FE READ UNCORRECTED BLOCKS
>>>> | This ioctl call returns the number of uncorrected blocks detected by the device
>>>> | driver during its lifetime. For meaningful measurements, the increment
>>>> | in block count during a speci c time interval should be calculated. For this
>>>> | command, read-only access to the device is suf cient.
>>>> | Note that the counter will wrap to zero after its maximum count has been
>>>> | reached
>>>>
>>>> So it seens you are right and the drivers should accumulate the errors
>>>> forever. Any opinions?
>>> For communications systems, whether its is two-way or one-way broadcast,
>>> most people are concerned with the error *rate* (errors per unit time)
>>> rather than absolute error counts.  Communications engineers have a good
>>> understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and
>>> adjust their expectations accordingly.  Absolute counts have less
>>> meaning to engineers, and I'm not sure what a layman would make of them.
>> There is different terminology involved:
>>
>> BER: implies a rate which is averaged over a period of time. This
>> implies the errors in the stream, not after FEC.
> 
> Yes.  I used the term too loosely in my example.  Thank you for the
> clarification/correction.
> 
> 
>> UNC: Uncorrected symbols over a lifetime, well this is not practically
>> possible and will wrap around. This is not related to time, but it is
>> just a measure of the symbols that wasn't been able by the FEC engine to
>> correct.
> 
> Right.  But maybe a Symbol Error (or Erasure) Rate provides more useful
> information than just a count, no?


Let me make it more clear. All the parameters defined are quite
standard, and used consistently for all demodulators.
eg: Es/No ==> SNR or CNR

For the channel as it is, there is no UNC used there. No channel is
considered noise free at any rate for a given bandwidth. To avoid this
situation, encoding/decoding is used.

For the channel as it is, the errors are mentioned in relation to time,
ie BER

After it passes through this channel, then BER is useless, because the
constraints of the channel do not apply any more. The encoding/decoding
concept follows the methodology that a certain number of errors can be
corrected when some information is sent alongwith in the same channel
alongwith the same data in a cyclic fashion.

The decoder in this case is able to correct a certain number of symbols
and in certain cases there will uncorrectable symbols. There is not much
of a use knowing at what exact instance these were uncorrectable, as
these are just dealing with block errors.

> 
> An error rate computed over a "short" interval can be used to detect a
> period of communications interruption within software to alert the user
> or to take corrective action.
> 
> Absolute counts aren't useful for assessing the current "health" of the
> system.


When you want to state how many blocks the FEC engine corrected (there
are different FEC engines that we use currently RS32, TurboCodes, LDPC),
you have only the uncorrectable symbols to state and unfortunately these
are not really time bound.

> 
>> Generally a meaningless term, in many cases except a few.
> 
> I agree.
> 
>> Absolute errors are used very scantily, but have been used to see how
>> good/bad the whole system is.
> 
> Except for in safety critical systems (fire suppression system,
> automobile brakes, etc.), how can a "good/bad" determination based on an
> error count be separated from a time interval over which that error
> count occurred?


It defines whether the FEC engine worked as expected. eg: Just looking
at a UNC counter counting up with a high BER shows a bad channel.
looking at a UNC counter going up with a low BER shows a bad error
correction scheme. looking at a very low BER and a high number of
uncorrectables imply a bad FEC engine/scheme.

Error correction works by looking at the last n symbols received, not
symbol errors per unit time.


>>  BER cannot define this, as it is defined
>> before the FEC. Sometimes what's defined in the BER, the FEC engine
>> might be able to correct and hence.
> 
> Right BER doesn't define performance of a system, just a constraint
> under which the system is expected to work.

BER (BER) and Es/No (SNR) together defines the quality of a channel.


> So we can call what I suggested Uncorrected Symbol Rate, or Symbol Error
> Rate, or Message Error Rate if the FEC covers more than 1 symbol -
> whatever makes the most sense.

Error correction is never a part of the channel. In all cases as the
receiver, we are interested in the channel only, but for a safeguard
sometimes we look at what the Error correction engine did, whether the
scheme as a whole worked well. For the channel, the broadcaster knows
that he doesn't have to look at UNC in the long run, but while setting
up his system as a whole UNC is very much useful, as to find whether his
scheme worked as expected.

For the noisy channel, there is no error correction. The channel doesn't
know what error correction you use. Always Rate is measured against time
Similar to an Energy meter in your home doesn't know what you use the
energy for, but it knows how much you consumed and at what power factor.

> My opinion is that reporting of rate is more useful than absolute
> counts.

It is rate that which is used (BER) for the channel, Absolute count from
the FEC engine is used to find whether the FEC scheme alongwith the
engine worked as expected. Error correction schemes are used
selectively, depending upon different conditions. Sometimes it is tested
empirically, by the broadcaster. In this case UNC is very much helpful.
UNC per unit time doesn't make sense in that regard. UNC can be
considered more like a log sheet, that some events occured.


Regards,
Manu


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Andy Walls]

On Sun, 2008-05-11 at 10:14 +0400, Manu Abraham wrote:
> Andy Walls wrote:
> > On Sun, 2008-05-11 at 02:16 +0400, Manu Abraham wrote:
> >> Andy Walls wrote:
> >>> On Sat, 2008-05-10 at 17:27 +0200, Oliver Endriss wrote:
> >>>> Oliver Endriss wrote:
> >>>>> e9hack wrote:
> >>>>>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
> >>>>>> makes the UNC value of the femon plugin useless.
> >>>>> Why? It does not make sense to accumulate the errors forever, i.e.
> >>>>> nobody wants to know what happened last year...
> >>>>>
> >>>>> Afaics it is ok to reset the counter after reading it.
> >>>>> All drivers should behave this way.
> >>>>>
> >>>>> If the femon plugin requires something else it might store the values
> >>>>> and process them as desired.
> >>>>>
> >>>>> Afaics the femon command line tool has no problems with that.
> >>>> Argh, I just checked the API 1.0.0. spec:
> >>>> | FE READ UNCORRECTED BLOCKS
> >>>> | This ioctl call returns the number of uncorrected blocks detected by the device
> >>>> | driver during its lifetime. For meaningful measurements, the increment
> >>>> | in block count during a speci c time interval should be calculated. For this
> >>>> | command, read-only access to the device is suf cient.
> >>>> | Note that the counter will wrap to zero after its maximum count has been
> >>>> | reached
> >>>>
> >>>> So it seens you are right and the drivers should accumulate the errors
> >>>> forever. Any opinions?

> >> UNC: Uncorrected symbols over a lifetime, well this is not practically
> >> possible and will wrap around. This is not related to time, but it is
> >> just a measure of the symbols that wasn't been able by the FEC engine to
> >> correct.
> > 
> > Right.  But maybe a Symbol Error (or Erasure) Rate provides more useful
> > information than just a count, no?
> 
> 
> Let me make it more clear. All the parameters defined are quite
> standard, and used consistently for all demodulators.
> eg: Es/No ==> SNR or CNR
> 
> For the channel as it is, there is no UNC used there. No channel is
> considered noise free at any rate for a given bandwidth. To avoid this
> situation, encoding/decoding is used.
> 
> For the channel as it is, the errors are mentioned in relation to time,
> ie BER
> 
> After it passes through this channel, then BER is useless, because the
> constraints of the channel do not apply any more. The encoding/decoding
> concept follows the methodology that a certain number of errors can be
> corrected when some information is sent alongwith in the same channel
> alongwith the same data in a cyclic fashion.
> 
> The decoder in this case is able to correct a certain number of symbols
> and in certain cases there will uncorrectable symbols. There is not much
> of a use knowing at what exact instance these were uncorrectable, as
> these are just dealing with block errors.
> 
> > 
> > An error rate computed over a "short" interval can be used to detect a
> > period of communications interruption within software to alert the user
> > or to take corrective action.
> > 
> > Absolute counts aren't useful for assessing the current "health" of the
> > system.
> 
> 
> When you want to state how many blocks the FEC engine corrected (there
> are different FEC engines that we use currently RS32, TurboCodes, LDPC),
> you have only the uncorrectable symbols to state and unfortunately these
> are not really time bound.

Assuming the channel conditions are consistent with the assumptions
(e.g. AWGN) made in the design of the system.

Unfortunately for me, since I am far (65 miles?) from the broadcasting
stations, I receive many digital stations at a marginal SNR (Es/No *
Rs/W) for the FEC to work effectively.  Weather conditions (wind, rain,
cold fronts) between my antenna and the station cause transient channel
fades.  The Es/No can intermittently fall below the threshold for the
BER for which the FEC was designed, thus I do get time dependent
uncorrectable symbol indications.  The rate of change of uncorrectable
symbols being declared over a window of time, can tell me when I'm in a
channel fade (rate > 0) or not (rate == 0).

> > 
> >> Generally a meaningless term, in many cases except a few.
> > 
> > I agree.
> > 
> >> Absolute errors are used very scantily, but have been used to see how
> >> good/bad the whole system is.
> > 
> > Except for in safety critical systems (fire suppression system,
> > automobile brakes, etc.), how can a "good/bad" determination based on an
> > error count be separated from a time interval over which that error
> > count occurred?
> 
> 
> It defines whether the FEC engine worked as expected. eg: Just looking
> at a UNC counter counting up with a high BER shows a bad channel.
> looking at a UNC counter going up with a low BER shows a bad error
> correction scheme. looking at a very low BER and a high number of
> uncorrectables imply a bad FEC engine/scheme.
> 
> Error correction works by looking at the last n symbols received, not
> symbol errors per unit time.
> 
> 
> >>  BER cannot define this, as it is defined
> >> before the FEC. Sometimes what's defined in the BER, the FEC engine
> >> might be able to correct and hence.
> > 
> > Right BER doesn't define performance of a system, just a constraint
> > under which the system is expected to work.
> 
> BER (BER) and Es/No (SNR) together defines the quality of a channel.
>
> 
> > So we can call what I suggested Uncorrected Symbol Rate, or Symbol Error
> > Rate, or Message Error Rate if the FEC covers more than 1 symbol -
> > whatever makes the most sense.
> 
> Error correction is never a part of the channel. In all cases as the
> receiver, we are interested in the channel only, but for a safeguard
> sometimes we look at what the Error correction engine did, whether the
> scheme as a whole worked well. For the channel, the broadcaster knows
> that he doesn't have to look at UNC in the long run, but while setting
> up his system as a whole UNC is very much useful, as to find whether his
> scheme worked as expected.
> 
> For the noisy channel, there is no error correction. The channel doesn't
> know what error correction you use. Always Rate is measured against time
> Similar to an Energy meter in your home doesn't know what you use the
> energy for, but it knows how much you consumed and at what power factor.
> 
> > My opinion is that reporting of rate is more useful than absolute
> > counts.
> 
> It is rate that which is used (BER) for the channel,
>  Absolute count from
> the FEC engine is used to find whether the FEC scheme alongwith the
> engine worked as expected.

And if the channel experiences fades in addition to the typically
assumed AWGN characteristic, then the FEC can work well almost all of
the time, but still experience periods of time, during fades, that it
does not work.


>  Error correction schemes are used
> selectively, depending upon different conditions. Sometimes it is tested
> empirically, by the broadcaster. In this case UNC is very much helpful.
> UNC per unit time doesn't make sense in that regard.

OK, for selecting an FEC scheme when testing over a real or simulated
channel.  You still must take a certain amount of time before you
declare a good FEC scheme: the time or message count to declare the UNC
have stopped or are not going to occur (hence you're still dealing with
a rate measurement even if the message count you need to make the
declaration is 1).


>  UNC can be
> considered more like a log sheet, that some events occured.

And getting back to Oliver's original call for opinions: what good is
that log sheet, especially after a long time?

Assuming a good FEC system was selected for the system, the rate of
change of UNC at some short time after tuning to a channel tells you
whether you've got good reception (rate == 0) or not (rate > 0).

Similar periodic UNC rate measurements can tell you whether or not
you're in a fade and have lost reception or regained reception.  But
those measurements don't require you to keep the entire log sheet, just
a short window into the immediate past.

I can't think of a reason to keep the UNC log indefinitely.

In other words:
> >>>> | FE READ UNCORRECTED BLOCKS
> >>>> | This ioctl call returns the number of uncorrected blocks detected by the device
> >>>> | driver during its lifetime. For meaningful measurements, the increment
> >>>> | in block count during a speci c time interval should be calculated.

I agree with that: specifically for the case of declaring good reception
after changing channels or watching for intermittent fades.

>  For this
> >>>> | command, read-only access to the device is suf cient.

I don't agree with that.  Unless the device or driver can maintain an
extremely large accumulations of UNC blocks, an application trying to
make a rate measurement will need to set the counter to a known value if
the driver doesn't provide a rate measurement.



> 
> Regards,
> Manu

Regards,
Andy


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Manu Abraham]

Andy Walls wrote:

> And if the channel experiences fades in addition to the typically
> assumed AWGN characteristic, then the FEC can work well almost all of
> the time, but still experience periods of time, during fades, that it
> does not work.


You are mixing up channel characteristics with the FEC. FEC should never
be considered as a means to fix a noisy channel beyond limits.

After all, basic RF concepts just reach to core concept that, no
amplifier is as good as a proper antenna (implying proper input source)
The concept of the amplifier can be applied to other Rf building blocks
as well, to put it short.

>>  Error correction schemes are used
>> selectively, depending upon different conditions. Sometimes it is tested
>> empirically, by the broadcaster. In this case UNC is very much helpful.
>> UNC per unit time doesn't make sense in that regard.
> 
> OK, for selecting an FEC scheme when testing over a real or simulated
> channel.  You still must take a certain amount of time before you
> declare a good FEC scheme: the time or message count to declare the UNC
> have stopped or are not going to occur (hence you're still dealing with
> a rate measurement even if the message count you need to make the
> declaration is 1).

For your rate measurement, you should use BER alone, not screw up UNC.

All the mentioned parameters against time are calculated by the
demodulator directly and not by a software driver. (In many instances
the driver does some scaling to provide standardized limits, other than
that) A driver doing such conversions to the time domain doesn't yield
anything proper, it just creates something quite and bogus from what is
used as a standard by the industry. Also reads over i2c (a slow
interface, not all devices feature High Speed interfaces) also doesn't
help to provide that sort of a conversion in the driver, the way you
mention.

I am talking about standard DVB demods:
Every demodulator provides a standard interface, whether you know it or not.

BER, Bit Error Rate (symbols per unit time)
Strength, usually a RMS value (Absolute)
SNR, Signal To Noise Ratio (Relative)
UNC, Uncorrectable symbols (Absolute)

These parameters have meanings for the users, not just Linux users but
general users on the whole. Most DVB stuff is quite standardized, most
of which you can find in ETSI specifications and or old DVB.org whitepapers.

All the resultant parameters that which an API provides, should be that
which is a standard definition, rather than defining something which is
bogus. You take anything standardized, you won't find any other
difference from the above, almost all demodulators follow the
specifications involved therein.


HTH,
Manu


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Andy Walls]

On Sun, 2008-05-11 at 23:33 +0400, Manu Abraham wrote:

> I am talking about standard DVB demods:
> Every demodulator provides a standard interface, whether you know it or not.
> 
> BER, Bit Error Rate (symbols per unit time)
> Strength, usually a RMS value (Absolute)
> SNR, Signal To Noise Ratio (Relative)
> UNC, Uncorrectable symbols (Absolute)
> 
> These parameters have meanings for the users, not just Linux users but
> general users on the whole. Most DVB stuff is quite standardized, most
> of which you can find in ETSI specifications and or old DVB.org whitepapers.
> 
> All the resultant parameters that which an API provides, should be that
> which is a standard definition, rather than defining something which is
> bogus. You take anything standardized, you won't find any other
> difference from the above, almost all demodulators follow the
> specifications involved therein.

Manu,

I will agree with you then, drivers shouldn't compute a UNC block rate.


Oliver,

However, the original spec that was quoted, implied that *applications*
would/could do just that: compute a rate from UNC block counts:


> Argh, I just checked the API 1.0.0. spec:
> | FE READ UNCORRECTED BLOCKS
> | This ioctl call returns the number of uncorrected blocks detected by the device
> | driver during its lifetime. For meaningful measurements, the increment
> | in block count during a speci c time interval should be calculated. For this
> | command, read-only access to the device is suf cient.
> | Note that the counter will wrap to zero after its maximum count has been
> | reached

Putting aside whether such UNC block rates are useful or not, the
specification as quoted facilitates the following use case:

Multiple applications, can compute UNC block rates over different,
possibly overlapping intervals of different lengths, with the
applications required to handle rollover gracefully.

The specification as is, appears to be the easiest way to support this
use case, and it works provided the hardware automatically performs
rollover of the UNC block counter.

If this is a use case that needs to be supported, then to handle the
case of hardware that doesn't automatically roll the UNC counter over to
zero, the last sentence of the specification might be changed to
something like this:

"Note that the counter will wrap to zero after its maximum count has
been reached.  For devices where the hardware does not automatically
roll over to zero, when the ioctl would return the maximum supported
value, the driver will reset the hardware counter to zero."


This isn't perfect as some UNC counts will be lost after the counter
saturates, but aside from this exceptional circumstance, the use case
would be correctly supported.


Regards,
Andy


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

Andy Walls wrote:
> On Sun, 2008-05-11 at 23:33 +0400, Manu Abraham wrote:
> 
> > I am talking about standard DVB demods:
> > Every demodulator provides a standard interface, whether you know it or not.
> > 
> > BER, Bit Error Rate (symbols per unit time)
> > Strength, usually a RMS value (Absolute)
> > SNR, Signal To Noise Ratio (Relative)
> > UNC, Uncorrectable symbols (Absolute)
> > 
> > These parameters have meanings for the users, not just Linux users but
> > general users on the whole. Most DVB stuff is quite standardized, most
> > of which you can find in ETSI specifications and or old DVB.org whitepapers.
> > 
> > All the resultant parameters that which an API provides, should be that
> > which is a standard definition, rather than defining something which is
> > bogus. You take anything standardized, you won't find any other
> > difference from the above, almost all demodulators follow the
> > specifications involved therein.
> 
> Manu,
> 
> I will agree with you then, drivers shouldn't compute a UNC block rate.
> 
> 
> Oliver,
> 
> However, the original spec that was quoted, implied that *applications*
> would/could do just that: compute a rate from UNC block counts:

Applications may do whatever they wish with the UNC counter:
- provide the raw error count
- present the number of UNC blocks over a sliding window (last minute,
  last hour, whatever)
- calculate an UNC rate [1]

[1] Imho not very useful. UNC should remain constant or increment very
    slowly. Otherwise the ts stream will be unusable.

> > Argh, I just checked the API 1.0.0. spec:
> > | FE READ UNCORRECTED BLOCKS
> > | This ioctl call returns the number of uncorrected blocks detected by the device
> > | driver during its lifetime. For meaningful measurements, the increment
> > | in block count during a speci c time interval should be calculated. For this
> > | command, read-only access to the device is suf cient.
> > | Note that the counter will wrap to zero after its maximum count has been
> > | reached
> 
> Putting aside whether such UNC block rates are useful or not, the
> specification as quoted facilitates the following use case:
> 
> Multiple applications, can compute UNC block rates over different,
> possibly overlapping intervals of different lengths, with the
> applications required to handle rollover gracefully.

This a a very important point: The frontend may be opened by multiple
readers, so a driver _must_ _not_ reset the UNC counter after reading.
I guess that's why UNC was defined this way.

Btw, this is a common concept: SNMP (Simple Network Management Protocol)
counters behave the same way.

> The specification as is, appears to be the easiest way to support this
> use case, and it works provided the hardware automatically performs
> rollover of the UNC block counter.
> 
> If this is a use case that needs to be supported, then to handle the
> case of hardware that doesn't automatically roll the UNC counter over to
> zero, the last sentence of the specification might be changed to
> something like this:
> 
> "Note that the counter will wrap to zero after its maximum count has
> been reached.  For devices where the hardware does not automatically
> roll over to zero, when the ioctl would return the maximum supported
> value, the driver will reset the hardware counter to zero."
> 
> 
> This isn't perfect as some UNC counts will be lost after the counter
> saturates, but aside from this exceptional circumstance, the use case
> would be correctly supported.

The driver should do its best to implement the API spec. It might:
- return the value of a counter provided by the hardware if it matches
  the API spec
- implement a counter in software (see proposed patch for an example)
- return -ENOSYS if it cannot support the UNC counter [2]

Btw, the spec refers to an error code ENOSIGNAL, which does not exist.
:-(

[2] Unfortunately some drivers return a bogus value if they cannot
    provide UNC. This is a bug and should be fixed!
    Returning 0 is wrong. I'll fix the stv0299.

It is unlikely that the 32 bit UNC error count wraps. If it does, the
'UNC rate' is very high, and it does not matter whether a few errors
are lost...

Anyway the application should handle the wrapping of the UNC counter
properly.


@all:
1. If nobody objects I will commit the patches.
2. Please check and fix the other frontend drivers to follow the spec.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[P. van Gaans]

On 05/12/2008 03:16 PM, Oliver Endriss wrote:
> Andy Walls wrote:
>> On Sun, 2008-05-11 at 23:33 +0400, Manu Abraham wrote:
>>
>>> I am talking about standard DVB demods:
>>> Every demodulator provides a standard interface, whether you know it or not.
>>>
>>> BER, Bit Error Rate (symbols per unit time)
>>> Strength, usually a RMS value (Absolute)
>>> SNR, Signal To Noise Ratio (Relative)
>>> UNC, Uncorrectable symbols (Absolute)
>>>
>>> These parameters have meanings for the users, not just Linux users but
>>> general users on the whole. Most DVB stuff is quite standardized, most
>>> of which you can find in ETSI specifications and or old DVB.org whitepapers.
>>>
>>> All the resultant parameters that which an API provides, should be that
>>> which is a standard definition, rather than defining something which is
>>> bogus. You take anything standardized, you won't find any other
>>> difference from the above, almost all demodulators follow the
>>> specifications involved therein.
>> Manu,
>>
>> I will agree with you then, drivers shouldn't compute a UNC block rate.
>>
>>
>> Oliver,
>>
>> However, the original spec that was quoted, implied that *applications*
>> would/could do just that: compute a rate from UNC block counts:
> 
> Applications may do whatever they wish with the UNC counter:
> - provide the raw error count
> - present the number of UNC blocks over a sliding window (last minute,
>   last hour, whatever)
> - calculate an UNC rate [1]
> 
> [1] Imho not very useful. UNC should remain constant or increment very
>     slowly. Otherwise the ts stream will be unusable.
> 
>>> Argh, I just checked the API 1.0.0. spec:
>>> | FE READ UNCORRECTED BLOCKS
>>> | This ioctl call returns the number of uncorrected blocks detected by the device
>>> | driver during its lifetime. For meaningful measurements, the increment
>>> | in block count during a speci c time interval should be calculated. For this
>>> | command, read-only access to the device is suf cient.
>>> | Note that the counter will wrap to zero after its maximum count has been
>>> | reached
>> Putting aside whether such UNC block rates are useful or not, the
>> specification as quoted facilitates the following use case:
>>
>> Multiple applications, can compute UNC block rates over different,
>> possibly overlapping intervals of different lengths, with the
>> applications required to handle rollover gracefully.
> 
> This a a very important point: The frontend may be opened by multiple
> readers, so a driver _must_ _not_ reset the UNC counter after reading.
> I guess that's why UNC was defined this way.
> 
> Btw, this is a common concept: SNMP (Simple Network Management Protocol)
> counters behave the same way.
> 
>> The specification as is, appears to be the easiest way to support this
>> use case, and it works provided the hardware automatically performs
>> rollover of the UNC block counter.
>>
>> If this is a use case that needs to be supported, then to handle the
>> case of hardware that doesn't automatically roll the UNC counter over to
>> zero, the last sentence of the specification might be changed to
>> something like this:
>>
>> "Note that the counter will wrap to zero after its maximum count has
>> been reached.  For devices where the hardware does not automatically
>> roll over to zero, when the ioctl would return the maximum supported
>> value, the driver will reset the hardware counter to zero."
>>
>>
>> This isn't perfect as some UNC counts will be lost after the counter
>> saturates, but aside from this exceptional circumstance, the use case
>> would be correctly supported.
> 
> The driver should do its best to implement the API spec. It might:
> - return the value of a counter provided by the hardware if it matches
>   the API spec
> - implement a counter in software (see proposed patch for an example)
> - return -ENOSYS if it cannot support the UNC counter [2]
> 
> Btw, the spec refers to an error code ENOSIGNAL, which does not exist.
> :-(
> 
> [2] Unfortunately some drivers return a bogus value if they cannot
>     provide UNC. This is a bug and should be fixed!
>     Returning 0 is wrong. I'll fix the stv0299.
> 
> It is unlikely that the 32 bit UNC error count wraps. If it does, the
> 'UNC rate' is very high, and it does not matter whether a few errors
> are lost...
> 
> Anyway the application should handle the wrapping of the UNC counter
> properly.
> 
> 
> @all:
> 1. If nobody objects I will commit the patches.
> 2. Please check and fix the other frontend drivers to follow the spec.
> 
> CU
> Oliver
> 

Will the behaviour of femon change, and if so, in what way? I use it now 
to see at what points in time I've had hickups by writing femon's output 
to a file and grep -nv "unc 0". This way I can see for example I've had 
errors at 16:35 and 17:48. If this will still work after the patch, I'm 
fine with it. If it won't work, will there be an alternative?

P.

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

P. van Gaans wrote:
> On 05/12/2008 03:16 PM, Oliver Endriss wrote:
> > @all:
> > 1. If nobody objects I will commit the patches.
> > 2. Please check and fix the other frontend drivers to follow the spec.
> 
> Will the behaviour of femon change, and if so, in what way?

For a correct driver unc would not return to 0 (unless the counter
wrapped).

> I use it now  
> to see at what points in time I've had hickups by writing femon's output 
> to a file and grep -nv "unc 0". This way I can see for example I've had 
> errors at 16:35 and 17:48. If this will still work after the patch, I'm 
> fine with it. If it won't work, will there be an alternative?

- Monitor the log for changes of the unc value.
- femon could be modified to display the delta value, or we might add an
  option (-U) to choose between absolute and delta unc display.

I am open to suggestions.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[P. van Gaans]

On 05/12/2008 06:02 PM, Oliver Endriss wrote:
> P. van Gaans wrote:
>> On 05/12/2008 03:16 PM, Oliver Endriss wrote:
>>> @all:
>>> 1. If nobody objects I will commit the patches.
>>> 2. Please check and fix the other frontend drivers to follow the spec.
>> Will the behaviour of femon change, and if so, in what way?
> 
> For a correct driver unc would not return to 0 (unless the counter
> wrapped).
> 
>> I use it now  
>> to see at what points in time I've had hickups by writing femon's output 
>> to a file and grep -nv "unc 0". This way I can see for example I've had 
>> errors at 16:35 and 17:48. If this will still work after the patch, I'm 
>> fine with it. If it won't work, will there be an alternative?
> 
> - Monitor the log for changes of the unc value.
> - femon could be modified to display the delta value, or we might add an
>   option (-U) to choose between absolute and delta unc display.
> 
> I am open to suggestions.
> 
> CU
> Oliver
> 

I don't know much about programming but I guess femon could be changed. 
I doubt I'll be able to do it but otherwise maybe someone else will. 
Looking for changes in the unc value will be more work when 
investigating a 12-hour femon log, so adding an option sounds like a 
good idea.

P.

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Andy Walls]

On Mon, 2008-05-12 at 18:02 +0200, Oliver Endriss wrote:
> P. van Gaans wrote:
> > On 05/12/2008 03:16 PM, Oliver Endriss wrote:
> > > @all:
> > > 1. If nobody objects I will commit the patches.
> > > 2. Please check and fix the other frontend drivers to follow the spec.
> > 
> > Will the behaviour of femon change, and if so, in what way?
> 
> For a correct driver unc would not return to 0 (unless the counter
> wrapped).

And that is the critical part to support multiple opens on the device
and still return meaningful values.

If a 0 could happen under any other condition, the meaning of a 0 being
read would be ambiguous.  An application couldn't tell the difference
between:

a) an error occurred and the counter rolled over or
b) no error occurred and another caller simply cleared the count.

-Andy


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[P. van Gaans]

On 05/11/2008 08:14 AM, Manu Abraham wrote:
>>> Absolute errors are used very scantily, but have been used to see how
>>> good/bad the whole system is.
>> Except for in safety critical systems (fire suppression system,
>> automobile brakes, etc.), how can a "good/bad" determination based on an
>> error count be separated from a time interval over which that error
>> count occurred?
> 
> 
> It defines whether the FEC engine worked as expected. eg: Just looking
> at a UNC counter counting up with a high BER shows a bad channel.
> looking at a UNC counter going up with a low BER shows a bad error
> correction scheme. looking at a very low BER and a high number of
> uncorrectables imply a bad FEC engine/scheme.

Not necessarily. Here some femon output from my Technotrend T-1500:

status SCVYL | signal  54% | snr  99% | ber 188 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 230 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 240 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 228 | unc 21 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 248 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 280 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK

Nothing special for the BER levels, just a fairly good signal (need to 
get into tens of thousands before it drops). But there, all of a sudden, 
unc 21 (meaning the picture gets garbled for a moment). I still don't 
know who or what is bullying me with those, but it seems to be caused by 
sparks. I sometimes get it when I flick a light on or off. At night I 
usually don't get these much (or not at all!), in the weekends usually 
have less as well. At day, and especially in the evening though, 
disaster (several each hour or even minute). It's no fault in the shemes 
or FEC engine, I see the standalones hickup as well. So a very short 
error will cause unc, but no higher BER.

P.

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[e9hack]

P. van Gaans schrieb:
> Not necessarily. Here some femon output from my Technotrend T-1500:
> 
> status SCVYL | signal  54% | snr  99% | ber 188 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 230 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 240 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 228 | unc 21 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 248 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 280 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK
...
> I see the standalones hickup as well. So a very short 
> error will cause unc, but no higher BER.

You may not see a higher BER, because the corrupted signal doesn't hit the BER measuring 
period. Femon asks every 1 second for new values. The UNC counting interval is this 1 
second, but the BER measuring interval is shorter (50..200ms). For a stv0297, it is 150ms 
for QAM256 modulation and 200ms for QAM64. The real measuring interval for the BER is a 
fixed number of bits.

-Hartmut

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Luca Olivetti]

En/na P. van Gaans ha escrit:

> Not necessarily. Here some femon output from my Technotrend T-1500:
> 
> status SCVYL | signal  54% | snr  99% | ber 188 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 230 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 240 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 228 | unc 21 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 248 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 280 | unc 0 | FE_HAS_LOCK
> status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK

Considering that, according to the dvb api spec, unc never should go 
back to 0, I think that the driver is giving bogus values (aren't they 
all, anyway?).

Bye
-- 
Luca


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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[e9hack]

Oliver Endriss schrieb:
> e9hack wrote:
>> the uncorrected block count is reset on a read request for the tda10021 and stv0297. This 
>> makes the UNC value of the femon plugin useless.
> 
> Why? It does not make sense to accumulate the errors forever, i.e.
> nobody wants to know what happened last year...

The femon plugin from vdr updates its values every half second. If the driver got only a 
few block errors, maybe you will not see the value.

For DVB-C, it's more interesting to see the accumulated unc value. If you see some 
artefacts, maybe they are a result of the DVB-C transmission or they are a result of the 
DVB-S transmission and the cable provider wasn't able to correct all errors or wasn't able 
to remux the stream correctly. In this case, it is useful to see the accumulated count.

-Hartmut

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

Hi,

I just wanted to commit this changeset when I spotted this:

e9hack wrote:
> @@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
>  
>         tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
>  
> +       /* reset uncorrected block counter */
> +       state->last_lock = 0;
> +       state->ucblocks = 0;

Note that UCB must count the number of uncorrected blocls during the
lifetime of the driver. So it must not be reset during tuning.
Agreed?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Manu Abraham]

Oliver Endriss wrote:
> Hi,
> 
> I just wanted to commit this changeset when I spotted this:
> 
> e9hack wrote:
>> @@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
>>  
>>         tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
>>  
>> +       /* reset uncorrected block counter */
>> +       state->last_lock = 0;
>> +       state->ucblocks = 0;
> 
> Note that UCB must count the number of uncorrected blocls during the
> lifetime of the driver. So it must not be reset during tuning.
> Agreed?
> 

ACK

Regards,
Manu

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[e9hack]

Oliver Endriss schrieb:
> Hi,
> 
> I just wanted to commit this changeset when I spotted this:
> 
> e9hack wrote:
>> @@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
>>  
>>         tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
>>  
>> +       /* reset uncorrected block counter */
>> +       state->last_lock = 0;
>> +       state->ucblocks = 0;
> 
> Note that UCB must count the number of uncorrected blocls during the
> lifetime of the driver. So it must not be reset during tuning.

I've add this reset for two reasons:

1) My second card uses a stv0297. The UCB value is always reset during the tuning, because 
the stv0297 is completely reinitialized. This occurs, if the frequency is changed or if 
the frontend lost the lock. I've add the reset to see the same behavior within the 
femon-plugin for both cards.

2) Above 650MHz, the signal strength of my cable is very low. It isn't usable. I get high 
BER and UCB values. The card with the tda10021 is a budget one. It is used for epg 
scanning in the background. It isn't possible to compare the UCB values of both cards, if 
the cards are tuned to the same frequency/channel and if the tda10021 was previous tuned 
to a frequency with a low signal.

-Hartmut

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

Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Oliver Endriss]

e9hack wrote:
> Oliver Endriss schrieb:
> > Hi,
> > 
> > I just wanted to commit this changeset when I spotted this:
> > 
> > e9hack wrote:
> >> @@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
> >>  
> >>         tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
> >>  
> >> +       /* reset uncorrected block counter */
> >> +       state->last_lock = 0;
> >> +       state->ucblocks = 0;
> > 
> > Note that UCB must count the number of uncorrected blocls during the
> > lifetime of the driver. So it must not be reset during tuning.
> 
> I've add this reset for two reasons:
> 
> 1) My second card uses a stv0297. The UCB value is always reset during the tuning, because 
> the stv0297 is completely reinitialized. This occurs, if the frequency is changed or if 
> the frontend lost the lock. I've add the reset to see the same behavior within the 
> femon-plugin for both cards.

Then the stv0297 must also be fixed. This can be achieved by adding a
software counter to the state struct.

> 2) Above 650MHz, the signal strength of my cable is very low. It isn't usable. I get high 
> BER and UCB values. The card with the tda10021 is a budget one. It is used for epg 
> scanning in the background. It isn't possible to compare the UCB values of both cards, if 
> the cards are tuned to the same frequency/channel and if the tda10021 was previous tuned 
> to a frequency with a low signal.

The API is clear: The UNC counter starts when the driver is loaded and
counts up until the driver is unloaded.

Sorry, I will not replace one faulty implementation by another faulty
implementation.

A counter starting at channel switch can be implemented by using the
cStatus class of VDR. cStatus::ChannelSwitch() will notify a plugin
whenever a channel switch happens, so it is very easy to capture the
UNC value at channel switch (UNCsw).

Finally, the plugin may display the value (UNC - UNCsw), and you have
the desired behaviour without breaking the API.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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