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

Andy Walls awalls at radix.net
Sun May 11 23:32:03 CEST 2008


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




More information about the linux-dvb mailing list