On Mon, 17 Apr 2006, Yeasah Pell wrote: > >So I think THIS is the curve you should be trying to use to convert BER to > >SNR. The question I have it, what are the units of the 22-bit value read from > >the chip? How do you convert this to the fraction of the bits in error? > >Divide by the gross bitrate (bandwidth in MHz times two)? > > > > > The meaning of the 22-bit error counter value is configurable, but it's > always a count of some type of error over a fixed window. Per the > datasheet, the demod is currently configured by the driver to return a > count of reed-solomon block errors with a window size of 65280 blocks > (which is the maximum) So you're saying it a count of the number of 204 byte packets which the Reed-Solomon code couldn't correct? If that's the case then the code that's there is completely wrong. The BER value is wrong too, instead of BER, it's really getting UCB. My guess is that the snr function was written with the demod counter set to return a different value, something like error bits out of the last X. I don't think you can get SNR from uncorrected blocks. You need to know the bit errors before the Vitterbi error correction, much less the Reed-Solomon stage, is done. If the R-S code detects a single error, then there were too many bit errors for the Vitterbi code fix. That means your SNR is already bad. How bad would depend on the FEC ratio used, 1/2 vs 7/8 would be completely different. The code in the driver doesn't take the FEC ratio into account, so it's obviously completely wrong, besides the fact that the scale is completely wrong too. In order to get SNR, I think the driver needs to reconfigure the counter to return a more suitable value. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
