Trent Piepho wrote:
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.
Yes, according to the demod datasheet. There's two main modes the error
counter can run in -- reed solomon, or PN sequence BER (as well as
several sub-modes for reed-solomon counting). It's currently setup as
the default, which is to count reed solomon block errors. I agree that
sounds like something that should be returned as uncorrected blocks
count rather than a bit error rate.
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.
Again, I can't disagree with any of this. It's a trivial change --
changing the initialization of register 0x56 to 0x20 (instead of 0x41,
the default) would configure the counter for PN BER mode, with a window
size of 2^22. There are other options for things such as PN sequence
inversion or window size, but that seems like a reasonable
configuration. Certainly easy to try, anyway.
I thought it was pretty strange/lame that the driver returned the same
value for both UCB and BER, but who would have suspected that it was
actually the UCB value that was correct, despite the fact that the code
calls the variable BER everywhere? :-) It would be theoretically
possible to switch the mode of the counter on demand to measure both UCB
and BER, but there would need to be extra code to reset the counter and
wait for the count to complete, and I'm not sure how long that would
take, so caller latency might be an issue.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
