From: Manu Abraham <abraham.manu@gmail.com>
To: Andy Walls <awalls@radix.net>
Cc: linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297
Date: Sun, 11 May 2008 23:33:59 +0400 [thread overview]
Message-ID: <48274A27.9050206@gmail.com> (raw)
In-Reply-To: <1210530916.3198.72.camel@palomino.walls.org>
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@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
next prev parent reply other threads:[~2008-05-11 19:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-10 8:46 [linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297 e9hack
2008-05-10 15:17 ` Oliver Endriss
2008-05-10 15:27 ` Oliver Endriss
2008-05-10 15:48 ` Michael Krufky
2008-05-12 13:29 ` Oliver Endriss
2008-05-10 16:02 ` e9hack
2008-05-10 16:39 ` Oliver Endriss
2008-05-10 21:53 ` Andy Walls
2008-05-10 22:16 ` Manu Abraham
2008-05-10 23:44 ` Andy Walls
2008-05-11 6:14 ` Manu Abraham
2008-05-11 18:35 ` Andy Walls
2008-05-11 19:33 ` Manu Abraham [this message]
2008-05-11 21:32 ` Andy Walls
2008-05-12 13:16 ` Oliver Endriss
2008-05-12 13:47 ` P. van Gaans
2008-05-12 16:02 ` Oliver Endriss
2008-05-12 17:03 ` P. van Gaans
2008-05-12 22:42 ` Andy Walls
2008-05-11 23:45 ` P. van Gaans
2008-05-12 6:47 ` e9hack
2008-05-12 14:26 ` Luca Olivetti
2008-05-10 16:12 ` e9hack
2008-05-30 23:46 ` Oliver Endriss
2008-05-31 0:01 ` Manu Abraham
2008-05-31 7:19 ` e9hack
2008-05-31 12:45 ` Oliver Endriss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48274A27.9050206@gmail.com \
--to=abraham.manu@gmail.com \
--cc=awalls@radix.net \
--cc=linux-dvb@linuxtv.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox