Devin Heitmueller wrote:
> On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham wrote:
>> Sure, of course. Here is an updated list based on the information
>> that you accumulated. I have corrected some of them, which were not
>> accurate.
>
> Before I comment any further on your email, could you please
On Wed, Mar 25, 2009 at 6:27 PM, Devin Heitmueller
wrote:
> Before I comment any further on your email, could you please clarify
> what you mean by "Relative, confirms to API". The current DVB API
> specification does not specify any units of measure for the content of
> the field, so I am not su
VDR User wrote:
> On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham wrote:
>> * At the peak, you will get the maximum quality
>> * falling down the slope to the left and right you will get falling
>> signal strengths
>> * Still rolling down, you will get increasing ERROR's, with still
>> UNCORRECTABL
On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham wrote:
> Sure, of course. Here is an updated list based on the information
> that you accumulated. I have corrected some of them, which were not
> accurate.
Before I comment any further on your email, could you please clarify
what you mean by "Relativ
Devin Heitmueller wrote:
> On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham wrote:
>> Mika Laitio wrote:
>> That said, the solution takes the approach of "revolutionary" as
>> opposed to "evolutionary", which always worries me. While providing a
>> much more powerful interface, it also m
On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham wrote:
> Mika Laitio wrote:
> That said, the solution takes the approach of "revolutionary" as
> opposed to "evolutionary", which always worries me. While providing a
> much more powerful interface, it also means all of the applications
>>
On Tue, 2009-03-24 at 18:08 -0400, Steven Toth wrote:
> >> Let me ask this rhetorical question: if we did nothing more than just
> >> normalize the SNR to provide a consistent value in dB, and did nothing
> >> more than normalize the existing strength field to be 0-100%, leaving
> >> it up to the d
On Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham wrote:
>>> From the end user point of view it is not very usefull if he has 2
>> different cards and application can not show any usefull signal goodness
>> info in a way that would be easy to compare. So I think the attempt to
>> standardize to db is
Mika Laitio wrote:
> But there should anyway be mandatory to have this one "standard goodness
> value" in a way that does not require apps to make any complicate
> comparisons... (I bet half of those apps would be broken for years)
That said, the conversion functions can be added into libdvb, ho
Mika Laitio wrote:
That said, the solution takes the approach of "revolutionary" as
opposed to "evolutionary", which always worries me. While providing a
much more powerful interface, it also means all of the applications
will have to properly support all of the various possibl
That said, the solution takes the approach of "revolutionary" as
opposed to "evolutionary", which always worries me. While providing a
much more powerful interface, it also means all of the applications
will have to properly support all of the various possible
representations of the data, increas
Devin Heitmueller wrote:
> On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
> wrote:
>> Wow, well this literally kept me up all night pondering the various options.
>>
>> Manu's idea has alot of merit - providing a completely new API that
>> provides the "raw data without translation" as well as
Let me ask this rhetorical question: if we did nothing more than just
normalize the SNR to provide a consistent value in dB, and did nothing
more than normalize the existing strength field to be 0-100%, leaving
it up to the driver author to decide the actual heuristic, what
percentage of user's ne
On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
wrote:
> Wow, well this literally kept me up all night pondering the various options.
>
> Manu's idea has alot of merit - providing a completely new API that
> provides the "raw data without translation" as well as a way to query
> for what that f
On Sat, Mar 21, 2009 at 10:45 PM, Andy Walls wrote:
> There are lots of interesting ideas here. From the implementation Manu
> has presented to explain his ideas, let me separate out the problem
> statement, concept, content, and form from each other and comment on
> those separately.
>
>
>
> 1.
Andy Walls wrote:
> On Fri, 2009-03-20 at 10:55 +0400, Manu Abraham wrote:
>> Manu Abraham wrote:
>
>>> I have been going through this thread with much interest to see
>>> where it was going.
>>>
>>> In fact, what i found after reading the emails in this thread:
>>>
>>> People would like to see st
On Fri, 2009-03-20 at 10:55 +0400, Manu Abraham wrote:
> Manu Abraham wrote:
> > I have been going through this thread with much interest to see
> > where it was going.
> >
> > In fact, what i found after reading the emails in this thread:
> >
> > People would like to see standardized Signal sta
On Fri, 20 Mar 2009, Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho wrote:
> >> The argument being put forth is based on the relative efficiency of
> >> the multiply versus divide opcodes on modern CPU architectures?? ?And
> >
> > Maybe I just like writing efficient code
On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham wrote:
> Well, that said positioning could be explained for those who on't
> have an understanding on how to do it.
>
> Let's assume, currently at position "X" there is no signal, no
> frontend LOCK. You can move the antenna to the approximate X-Y
> c
On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho wrote:
>> The argument being put forth is based on the relative efficiency of
>> the multiply versus divide opcodes on modern CPU architectures?? And
>
> Maybe I just like writing efficient code to do interesting things?
Wow, um, ok. You realize tha
On Fri, Mar 20, 2009 at 2:55 AM, Manu Abraham wrote:
> When you position an antenna, you do not get a LOCK in most cases.
> The signal statistics for any demodulator are valid only with a
> frontend LOCK.
This is absolutely true, and a very common problem in the drivers (at
least with the ATSC/QA
Manu Abraham wrote:
> Devin Heitmueller wrote:
>> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
>>> On Thu, 19 Mar 2009, Trent Piepho wrote:
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
>> On Thu, 19 Mar 2009, Trent Piepho wrote:
>>> Since the driver often needs to use a logarithm from dvb-math to find SNR,
>>> you have code like this in the driver (from lgdt3305.c):
>>> /* report SNR in dB *
On Thu, 19 Mar 2009, Devin Heitmueller wrote:
> On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
>
> == rant mode on ==
> Wow, I think we have lost our minds!
>
> The argument being put forth is based on the relative efficiency of
> the multiply versus divide opcodes on modern CPU architecture
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho wrote:
> On Thu, 19 Mar 2009, Trent Piepho wrote:
>> Since the driver often needs to use a logarithm from dvb-math to find SNR,
>> you have code like this in the driver (from lgdt3305.c):
>> /* report SNR in dB * 10 */
>> *snr = (state-
On Thu, 19 Mar 2009, Trent Piepho wrote:
> Since the driver often needs to use a logarithm from dvb-math to find SNR,
> you have code like this in the driver (from lgdt3305.c):
> /* report SNR in dB * 10 */
> *snr = (state->snr / ((1 << 24) / 10));
>
> > The SNR(dB) will be given by
On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote:
> that we should discuss about it for some time, comparing each alternatives we
> have, focused on SNR only. Later, use can use the same approach for the
> other quality measurements on DVB.
>
> In order to start such discussions, I'm summarizing bo
On Fri, 13 Mar 2009 16:55:40 -0700 (PDT)
Trent Piepho wrote:
> On Fri, 13 Mar 2009, Devin Heitmueller wrote:
> > On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote:
> > > I like 8.8 fixed point a lot better. It gives more precision. The range
> > > is more in line with that the range of real
On Sun, Mar 15, 2009 at 9:20 AM, wk wrote:
>> 1. Getting everyone to agree on a standard representation for the
>> field, and how to represent certain error conditions (such as when a
>> demod doesn't support SNR, or when it cannot return a valid value at a
>> given time).
>>
>>
>
> Its just stra
Devin Heitmueller schrieb:
On Fri, Mar 13, 2009 at 6:27 PM, VDR User wrote:
Just wanted to comment that I'm glad there is a lot of interest in
this. I've heard endless talk & confusion on the user end over the
years as to the accuracy of the values, or in some cases (as with
Genpix adapters
On Fri, 2009-03-13 at 18:34 -0700, Trent Piepho wrote:
> On Fri, 13 Mar 2009, Andy Walls wrote:
> > On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote:
> > > On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote:
> > > >
> > > > Yes, please :)
> > >
> > > Yeah, Michael Krufky and I were d
On Fri, 13 Mar 2009, Andy Walls wrote:
> On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote:
> > On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote:
> > >
> > > Yes, please :)
> >
> > Yeah, Michael Krufky and I were discussing it in more detail yesterday
> > on the #linuxtv ML. Essent
On Fri, 2009-03-13 at 10:27 -0400, Devin Heitmueller wrote:
> On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote:
> >
> > Yes, please :)
>
> Yeah, Michael Krufky and I were discussing it in more detail yesterday
> on the #linuxtv ML. Essentially there are a few issues:
>
> 1. Getting every
On Fri, 13 Mar 2009, Devin Heitmueller wrote:
> On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote:
> > I like 8.8 fixed point a lot better. ?It gives more precision. ?The range
> > is more in line with that the range of real SNRs are. ?Computers are
> > binary, so the math can end up faster. ?It
On Fri, Mar 13, 2009 at 6:27 PM, VDR User wrote:
> Just wanted to comment that I'm glad there is a lot of interest in
> this. I've heard endless talk & confusion on the user end over the
> years as to the accuracy of the values, or in some cases (as with
> Genpix adapters for example) where you d
Just wanted to comment that I'm glad there is a lot of interest in
this. I've heard endless talk & confusion on the user end over the
years as to the accuracy of the values, or in some cases (as with
Genpix adapters for example) where you don't seem to get any useful
information. Of course making
On Fri, Mar 13, 2009 at 5:32 PM, Devin Heitmueller
wrote:
> On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote:
>> I like 8.8 fixed point a lot better. It gives more precision. The range
>> is more in line with that the range of real SNRs are. Computers are
>> binary, so the math can end up f
On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho wrote:
> I like 8.8 fixed point a lot better. It gives more precision. The range
> is more in line with that the range of real SNRs are. Computers are
> binary, so the math can end up faster. It's easier to read when printed
> out in hex, since you
On Fri, 13 Mar 2009, Devin Heitmueller wrote:
> On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote:
> >
> > Yes, please :)
>
> Yeah, Michael Krufky and I were discussing it in more detail yesterday
> on the #linuxtv ML. Essentially there are a few issues:
>
> 1. Getting everyone to agree on
On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang wrote:
>
> Yes, please :)
Yeah, Michael Krufky and I were discussing it in more detail yesterday
on the #linuxtv ML. Essentially there are a few issues:
1. Getting everyone to agree on the definition of "SNR", and what
units to represent it in.
VDR User wrote:
On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wrote:
Hi all,
I've looked through the mailing list and there seems to be no
standard
way to interpret to content of SNR, signal strength and BER returned
from the DVB API. So, I wonder if someone knows how to interpret thes
On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wrote:
> Hi all,
> I've looked through the mailing list and there seems to be no
> standard
> way to interpret to content of SNR, signal strength and BER returned
> from the DVB API. So, I wonder if someone knows how to interpret these
> value
Hi all,
I've looked through the mailing list and there seems to be no standard
way to interpret to content of SNR, signal strength and BER returned
from the DVB API. So, I wonder if someone knows how to interpret these
values at least for HVR 4000 Lite? Thanks.
Regards,
Ang Way Chuang
--
43 matches
Mail list logo
