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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
