[linux-dvb] [RFC] [PATCH] Make S/N values to appear at cx24123 frontend

Yeasah Pell yeasah at schwide.com
Wed Apr 19 00:12:05 CEST 2006


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.




More information about the linux-dvb mailing list