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