Fix the unc for the frontends tda10021 and stv0297

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

Quoted 6 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

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

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 9 lines · Oliver Endriss

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

First you read a very old spec, now you read an old spec. This description is no longer a part of the spec. In the current spec
(http://linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf), many necessary descriptions are missing.

Quoted 7 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

CU
Oliver

Quoted 23 lines · Oliver Endriss

Quoted 6 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

Quoted 2 lines

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

For communications systems, whether its is two-way or one-way broadcast, most people are concerned with the error *rate* (errors per unit time) rather than absolute error counts. Communications engineers have a good understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and adjust their expectations accordingly. Absolute counts have less meaning to engineers, and I'm not sure what a layman would make of them.

Quoted 27 lines · Andy Walls

Quoted 23 lines · Oliver Endriss

Quoted 6 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

Quoted 2 lines

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

Quoted 6 lines

For communications systems, whether its is two-way or one-way broadcast, most people are concerned with the error *rate* (errors per unit time) rather than absolute error counts. Communications engineers have a good understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and adjust their expectations accordingly. Absolute counts have less meaning to engineers, and I'm not sure what a layman would make of them.

There is different terminology involved:

BER: implies a rate which is averaged over a period of time. This implies the errors in the stream, not after FEC.

UNC: Uncorrected symbols over a lifetime, well this is not practically possible and will wrap around. This is not related to time, but it is just a measure of the symbols that wasn't been able by the FEC engine to correct.

Generally a meaningless term, in many cases except a few.

Absolute errors are used very scantily, but have been used to see how good/bad the whole system is.

BER cannot define this, as it is defined
before the FEC. Sometimes what's defined in the BER, the FEC engine might be able to correct and hence.

Regards,
Manu

Quoted 33 lines · Manu Abraham

Quoted 24 lines · Andy Walls

Quoted 23 lines · Oliver Endriss

Quoted 6 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

Quoted 8 lines

Quoted 2 lines

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

For communications systems, whether its is two-way or one-way broadcast, most people are concerned with the error *rate* (errors per unit time) rather than absolute error counts. Communications engineers have a good understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and adjust their expectations accordingly. Absolute counts have less meaning to engineers, and I'm not sure what a layman would make of them.

Quoted 4 lines

There is different terminology involved:

BER: implies a rate which is averaged over a period of time. This implies the errors in the stream, not after FEC.

Yes. I used the term too loosely in my example. Thank you for the clarification/correction.

Quoted 4 lines

UNC: Uncorrected symbols over a lifetime, well this is not practically possible and will wrap around. This is not related to time, but it is just a measure of the symbols that wasn't been able by the FEC engine to correct.

Right. But maybe a Symbol Error (or Erasure) Rate provides more useful information than just a count, no?

An error rate computed over a "short" interval can be used to detect a period of communications interruption within software to alert the user or to take corrective action.

Absolute counts aren't useful for assessing the current "health" of the system.

Quoted 2 lines

Generally a meaningless term, in many cases except a few.

I agree.

Quoted 2 lines

Absolute errors are used very scantily, but have been used to see how good/bad the whole system is.

Except for in safety critical systems (fire suppression system, automobile brakes, etc.), how can a "good/bad" determination based on an error count be separated from a time interval over which that error count occurred?

Quoted 3 lines

BER cannot define this, as it is defined
before the FEC. Sometimes what's defined in the BER, the FEC engine might be able to correct and hence.

Right BER doesn't define performance of a system, just a constraint under which the system is expected to work.

So we can call what I suggested Uncorrected Symbol Rate, or Symbol Error Rate, or Message Error Rate if the FEC covers more than 1 symbol - whatever makes the most sense.

My opinion is that reporting of rate is more useful than absolute counts.

Quoted 29 lines · Andy Walls

Quoted 27 lines · Manu Abraham

Quoted 26 lines · Andy Walls

Quoted 25 lines · Oliver Endriss

Quoted 6 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

Quoted 7 lines

Quoted 4 lines

UNC: Uncorrected symbols over a lifetime, well this is not practically possible and will wrap around. This is not related to time, but it is just a measure of the symbols that wasn't been able by the FEC engine to correct.

Right. But maybe a Symbol Error (or Erasure) Rate provides more useful information than just a count, no?

Let me make it more clear. All the parameters defined are quite standard, and used consistently for all demodulators.
eg: Es/No ==> SNR or CNR

For the channel as it is, there is no UNC used there. No channel is considered noise free at any rate for a given bandwidth. To avoid this situation, encoding/decoding is used.

For the channel as it is, the errors are mentioned in relation to time, ie BER

After it passes through this channel, then BER is useless, because the constraints of the channel do not apply any more. The encoding/decoding concept follows the methodology that a certain number of errors can be corrected when some information is sent alongwith in the same channel alongwith the same data in a cyclic fashion.

The decoder in this case is able to correct a certain number of symbols and in certain cases there will uncorrectable symbols. There is not much of a use knowing at what exact instance these were uncorrectable, as these are just dealing with block errors.

Quoted 5 lines

An error rate computed over a "short" interval can be used to detect a period of communications interruption within software to alert the user or to take corrective action.

Quoted 2 lines

Absolute counts aren't useful for assessing the current "health" of the system.

When you want to state how many blocks the FEC engine corrected (there are different FEC engines that we use currently RS32, TurboCodes, LDPC), you have only the uncorrectable symbols to state and unfortunately these are not really time bound.

Quoted 5 lines

Quoted 2 lines

Generally a meaningless term, in many cases except a few.

I agree.

Quoted 7 lines

Quoted 2 lines

Absolute errors are used very scantily, but have been used to see how good/bad the whole system is.

Except for in safety critical systems (fire suppression system, automobile brakes, etc.), how can a "good/bad" determination based on an error count be separated from a time interval over which that error count occurred?

It defines whether the FEC engine worked as expected. eg: Just looking at a UNC counter counting up with a high BER shows a bad channel. looking at a UNC counter going up with a low BER shows a bad error correction scheme. looking at a very low BER and a high number of uncorrectables imply a bad FEC engine/scheme.

Error correction works by looking at the last n symbols received, not symbol errors per unit time.

Quoted 6 lines

Quoted 3 lines

BER cannot define this, as it is defined
before the FEC. Sometimes what's defined in the BER, the FEC engine might be able to correct and hence.

Right BER doesn't define performance of a system, just a constraint under which the system is expected to work.

BER (BER) and Es/No (SNR) together defines the quality of a channel.

Quoted 3 lines

So we can call what I suggested Uncorrected Symbol Rate, or Symbol Error Rate, or Message Error Rate if the FEC covers more than 1 symbol - whatever makes the most sense.

Error correction is never a part of the channel. In all cases as the receiver, we are interested in the channel only, but for a safeguard sometimes we look at what the Error correction engine did, whether the scheme as a whole worked well. For the channel, the broadcaster knows that he doesn't have to look at UNC in the long run, but while setting up his system as a whole UNC is very much useful, as to find whether his scheme worked as expected.

For the noisy channel, there is no error correction. The channel doesn't know what error correction you use. Always Rate is measured against time Similar to an Energy meter in your home doesn't know what you use the energy for, but it knows how much you consumed and at what power factor.

Quoted 2 lines

My opinion is that reporting of rate is more useful than absolute counts.

It is rate that which is used (BER) for the channel,
Absolute count from
the FEC engine is used to find whether the FEC scheme alongwith the engine worked as expected.

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.

UNC can be
considered more like a log sheet, that some events occured.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

| 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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

| command, read-only access to the device is suf cient.

Regards,
Manu

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.

Quoted 4 lines

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).

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.

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

Quoted 6 lines

Quoted 2 lines

Absolute errors are used very scantily, but have been used to see how good/bad the whole system is.

Except for in safety critical systems (fire suppression system, automobile brakes, etc.), how can a "good/bad" determination based on an error count be separated from a time interval over which that error count occurred?

It defines whether the FEC engine worked as expected. eg: Just looking at a UNC counter counting up with a high BER shows a bad channel. looking at a UNC counter going up with a low BER shows a bad error correction scheme. looking at a very low BER and a high number of uncorrectables imply a bad FEC engine/scheme.

Not necessarily. Here some femon output from my Technotrend T-1500:

status SCVYL | signal  54% | snr  99% | ber 188 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 230 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 240 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 228 | unc 21 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 248 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 280 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK

I see the standalones hickup as well. So a very short error will cause unc, but no higher BER.

Quoted 12 lines · Manu Abraham

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.

Quoted 5 lines

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:

Quoted 8 lines

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.

Quoted 24 lines · Oliver Endriss

Quoted 6 lines · Oliver Endriss

Quoted 2 lines · e9hack wrote:

the uncorrected block count is reset on a read request for the tda10021 and stv0297. This makes the UNC value of the femon plugin useless.

Why? It does not make sense to accumulate the errors forever, i.e. nobody wants to know what happened last year...

Quoted 7 lines

Afaics it is ok to reset the counter after reading it. All drivers should behave this way.

If the femon plugin requires something else it might store the values and process them as desired.

Afaics the femon command line tool has no problems with that.

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

Quoted 3 lines

So it seens you are right and the drivers should accumulate the errors forever. Any opinions?

There are some devices that automatically reset the unc counter registers as they are read, and other devices that wrap to zero after its maximum count has been reached, unless the driver explicitly clears it. *(see below)

There are other devices that dont give unc info directly, but instead report an average unc per time interval.

I think it's possible that at the time the 1.0.0 spec was written, most devices were known to exhibit the behavior as described in the blurb quoted from the API 1.0.0 spec, above.

I don't think that all of the drivers comply to this, exactly as described, and it might be difficult to correct this across the board :-( In many cases, we might not know for sure how absolute the value is, read from these registers on a given device.

I am not sure what we should do, but here is an argument that supports the API 1.0.0 spec:

*There are some demods whose firmware uses these counters to determine lock state. If we explicitly clear the counter registers during a channel scan, we can potentially confuse the firmware into detecting false locks, and not detecting real locks.

Quoted 21 lines · Andy Walls

Quoted 12 lines · Manu Abraham

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.

Quoted 5 lines

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,

Quoted 7 lines

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:

Applications may do whatever they wish with the UNC counter:
- provide the raw error count
- present the number of UNC blocks over a sliding window (last minute, last hour, whatever)
- calculate an UNC rate [1]

[1] Imho not very useful. UNC should remain constant or increment very slowly. Otherwise the ts stream will be unusable.

Quoted 8 lines

Quoted 8 lines

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

Quoted 6 lines

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.

This a a very important point: The frontend may be opened by multiple readers, so a driver _must_ _not_ reset the UNC counter after reading. I guess that's why UNC was defined this way.

Btw, this is a common concept: SNMP (Simple Network Management Protocol) counters behave the same way.

Quoted 15 lines

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."

Quoted 3 lines

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.

The driver should do its best to implement the API spec. It might:
- return the value of a counter provided by the hardware if it matches the API spec
- implement a counter in software (see proposed patch for an example)
- return -ENOSYS if it cannot support the UNC counter [2]

Btw, the spec refers to an error code ENOSIGNAL, which does not exist. :-(

[2] Unfortunately some drivers return a bogus value if they cannot provide UNC. This is a bug and should be fixed! Returning 0 is wrong. I'll fix the stv0299.

It is unlikely that the 32 bit UNC error count wraps. If it does, the 'UNC rate' is very high, and it does not matter whether a few errors are lost...

Anyway the application should handle the wrapping of the UNC counter properly.

@all:
1. If nobody objects I will commit the patches.
2. Please check and fix the other frontend drivers to follow the spec.

CU
Oliver

Not necessarily. Here some femon output from my Technotrend T-1500:

status SCVYL | signal  54% | snr  99% | ber 188 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 230 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 240 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 228 | unc 21 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 248 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 280 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  54% | snr  99% | ber 234 | unc 0 | FE_HAS_LOCK

Quoted 3 lines · Oliver Endriss

@all:
1. If nobody objects I will commit the patches.
2. Please check and fix the other frontend drivers to follow the spec.

Will the behaviour of femon change, and if so, in what way?

I use it now
to see at what points in time I've had hickups by writing femon's output to a file and grep -nv "unc 0". This way I can see for example I've had errors at 16:35 and 17:48. If this will still work after the patch, I'm fine with it. If it won't work, will there be an alternative?

Quoted 5 lines · P. van Gaans

Quoted 3 lines · Oliver Endriss

@all:
1. If nobody objects I will commit the patches.
2. Please check and fix the other frontend drivers to follow the spec.

Will the behaviour of femon change, and if so, in what way?

For a correct driver unc would not return to 0 (unless the counter wrapped).

Quoted 5 lines

I use it now
to see at what points in time I've had hickups by writing femon's output to a file and grep -nv "unc 0". This way I can see for example I've had errors at 16:35 and 17:48. If this will still work after the patch, I'm fine with it. If it won't work, will there be an alternative?

- Monitor the log for changes of the unc value.
- femon could be modified to display the delta value, or we might add an option (-U) to choose between absolute and delta unc display.

I am open to suggestions.

CU
Oliver

Quoted 6 lines · P. van Gaans

Quoted 3 lines · Oliver Endriss

@all:
1. If nobody objects I will commit the patches.
2. Please check and fix the other frontend drivers to follow the spec.

Will the behaviour of femon change, and if so, in what way?

For a correct driver unc would not return to 0 (unless the counter wrapped).

Hi,

I just wanted to commit this changeset when I spotted this:

Quoted 4 lines · e9hack wrote:

linux/drivers/media/dvb/frontends/tda10021.c +0 -0

@@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
 
        tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
 

linux/drivers/media/dvb/frontends/tda10021.c static int tda10021_set_parameters (stru · line 273

Quoted 3 lines

linux/drivers/media/dvb/frontends/tda10021.c +3 -0

+       /* reset uncorrected block counter */
+       state->last_lock = 0;
+       state->ucblocks = 0;

Note that UCB must count the number of uncorrected blocls during the lifetime of the driver. So it must not be reset during tuning. Agreed?

Hi,

I just wanted to commit this changeset when I spotted this:

Quoted 2 lines · e9hack wrote:

(quoted diff) +0 -0

@@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
 

linux/drivers/media/dvb/frontends/tda10021.c static int tda10021_set_parameters (stru · line 273

Quoted 5 lines

linux/drivers/media/dvb/frontends/tda10021.c +3 -0

        tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
 
+       /* reset uncorrected block counter */
+       state->last_lock = 0;
+       state->ucblocks = 0;

Note that UCB must count the number of uncorrected blocls during the lifetime of the driver. So it must not be reset during tuning.

Quoted 7 lines · Oliver Endriss

Hi,

I just wanted to commit this changeset when I spotted this:

Quoted 2 lines · e9hack wrote:

(quoted diff) +0 -0

@@ -266,6 +268,10 @@ static int tda10021_set_parameters (stru
 

Quoted 8 lines

linux/drivers/media/dvb/frontends/tda10021.c static int tda10021_set_parameters (stru · line 273

Quoted 5 lines

linux/drivers/media/dvb/frontends/tda10021.c +3 -0

        tda10021_setup_reg0 (state, reg0x00[qam], p->inversion);
 
+       /* reset uncorrected block counter */
+       state->last_lock = 0;
+       state->ucblocks = 0;

Note that UCB must count the number of uncorrected blocls during the lifetime of the driver. So it must not be reset during tuning.

I've add this reset for two reasons:

1) My second card uses a stv0297. The UCB value is always reset during the tuning, because the stv0297 is completely reinitialized. This occurs, if the frequency is changed or if the frontend lost the lock. I've add the reset to see the same behavior within the femon-plugin for both cards.

2) Above 650MHz, the signal strength of my cable is very low. It isn't usable. I get high BER and UCB values. The card with the tda10021 is a budget one. It is used for epg scanning in the background. It isn't possible to compare the UCB values of both cards, if the cards are tuned to the same frequency/channel and if the tda10021 was previous tuned to a frequency with a low signal.