public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Toth <stoth@kernellabs.com>
To: David Ward <david.ward@gatech.edu>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
	linux-media@vger.kernel.org
Subject: Re: cx18, s5h1409: chronic bit errors, only under Linux
Date: Wed, 10 Jun 2009 10:32:11 -0400	[thread overview]
Message-ID: <4A2FC3EB.6010802@kernellabs.com> (raw)
In-Reply-To: <4A2F6AB3.7080406@gatech.edu>

David Ward wrote:
> On 06/09/2009 03:26 PM, Steven Toth wrote:
>> 30db for the top end of ATSC sounds about right.
>>
>> David, when you ran the windows signal monitor - did it claim QAM64 or 
>> 256 when it was reporting 30db?
> 
> Steven and Devin,
> 
> All the digital signals are 256 QAM.
> 
>> 39 is very good, exceptional.
>>
>> And did they do as I suggested, which is measure db across the high 
>> channels? ... and ideally against your problematic channel?
>>
>> I assume not.
> 
> Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB).  I 
> looked afterwards and saw that the first of those is analog programming, 
> but the second just appears as analog noise on my TV set. (??)  I asked 
> them to check a specific ATSC channel, but it seems that their meter was 
> fixed to those two frequencies, which doesn't really help.  The ATSC 
> rebroadcasts by Comcast are on high frequencies; the program I am 
> testing primarily is on channel 79 (tunes at 555 MHz).
> 
> Under Windows I'm now seeing 34.5-34.8 dB for lower frequency QAM, 
> 32.5-32.7 dB for higher frequency QAM, and about 30.5 dB for ATSC.  
> Under Linux with azap, the corresponding BER/UNC values are 0x0140, 
> 0x0134, and 0x0132.  I'm not exactly sure what numbers I should be going 
> by here...again, wish I had my own meter.

Which of these three values is UNC/BER and which is snr? I don't understand, I 
need you to be more specific.

34 is good, normal. However 30.5 is still edgy under windows, assuming QAM 256. 
Did you get a chance to review the signal monitor to determine whether it was 64 
or 256?

If you have any way to attenuate the signal then you'll find that very quickly 
the windows 30.5 will drop just a little and you'll begin to see real 
uncorrectable errors. I alluded to this yesterday. With 30.5 your just a 
fraction above 'working' reliably.

If you were to insert attenuation through some barrel connectors, or join some 
other cables together to impede the RF, you'd see that 30.5 drop quickly and the 
errors would begin to appear. I suspect this will still occur, as I mentioned 
yesterday.

The windows drivers is working slightly better for you but it's still no where 
near good enough RF for reliable 24x7x365 viewing. You'll find the RF on your 
local cable rings varies during an average day. It certainly does for me on 
various products. What looks great today (when you're on the edge) can look ugly 
at 9pm in the evening or 7am thursday morning.

I wouldn't expect pristine recordings with Microsoft MCE (or other apps) (for 
any random moment in the week) with a 30.5 reading.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

  reply	other threads:[~2009-06-10 14:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08 10:31 cx18, s5h1409: chronic bit errors, only under Linux David Ward
2009-06-08 14:14 ` Steven Toth
2009-06-08 14:17   ` Devin Heitmueller
2009-06-08 16:20     ` David Ward
2009-06-08 16:31       ` Steven Toth
2009-06-08 17:16         ` David Ward
2009-06-08 20:20           ` Steven Toth
2009-06-08 20:36             ` Devin Heitmueller
2009-06-08 21:03               ` David Ward
2009-06-08 21:09                 ` Devin Heitmueller
2009-06-09 14:23                 ` Steven Toth
2009-06-09 14:21               ` Steven Toth
2009-06-09 14:23                 ` Devin Heitmueller
2009-06-09 14:24                   ` Steven Toth
2009-06-09 18:52                     ` David Ward
2009-06-09 18:55                       ` Devin Heitmueller
2009-06-09 19:04                         ` Steven Toth
2009-06-09 19:07                           ` Devin Heitmueller
2009-06-09 19:26                             ` Steven Toth
2009-06-10  8:11                               ` David Ward
2009-06-10 14:32                                 ` Steven Toth [this message]
2009-06-11 21:27                                   ` David Ward
2009-06-09 19:05                         ` Steven Toth
2009-06-09  2:44             ` Andy Walls

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=4A2FC3EB.6010802@kernellabs.com \
    --to=stoth@kernellabs.com \
    --cc=david.ward@gatech.edu \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@vger.kernel.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