cx18, s5h1409: chronic bit errors, only under Linux

cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

I have a Hauppauge WinTV-HVR-1600 that I am using to capture ATSC and 
clear QAM programming from cable television (Comcast of Chattanooga).  
This card uses the cx18 and s5h1409 kernel modules.

There are frequent bursts of bit errors occurring every few seconds in 
the incoming transport stream, when I have the card tuned under Linux.  
This causes artifacts in the received video as well as skipping in the 
received audio, to the point that it is practically unwatchable.  
However, under Windows on the same system/capture card, I can tune to 
the same programs with nearly perfect reception (no bit errors).  Also 
these programs appear on my TV with great quality as well.  The problem 
is happening on all of several different frequencies/programs that I 
have tried, although it is more pronounced on some programs 
(particularly ATSC) than others.

I have tried the latest v4l-dvb development sources under both kernel 
2.6.24 and kernel 2.6.29, and additionally I have tried to use the 
unmodified v4l-dvb from kernel 2.6.29.  Additionally, I have tried both 
the recommended cx23418 firmware from linuxtv.org, as well as the newer 
firmware provided by latest the Hauppauge drivers for Windows (which I 
am using successfully under Windows).  Unfortunately they all produce 
the same results.

I primarily use MythTV to capture the programs to a file, and the 
resulting file exhibits these problems.  However, I can also see the bit 
errors when I simply use the 'azap' application to tune the card 
directly (and also read the dvr0 device into a file).  The BER and UNC 
values reported by 'azap' are non-zero approximately one out of every 
five samples; then they are usually around 0x200, though this varies.  
The BER and UNC values are almost always identical, i.e., no error 
correction is taking place, only error detection.  Additionally I am not 
seeing any TS continuity or TEI flag errors, as detectable in the system 
log with the latest changeset.

I have tried to rule out other possible causes such as a weak input 
signal (by hooking the capture card directly to the household cable 
television input, bypassing all coaxial splitters) and system-specific 
issues (by trying this on three different systems).  However, to me it 
seems that the problem must be originating from an issue in the kernel 
modules for this card.

I understand that having some errors in the transport stream is 
unavoidable, and I have tried postprocessing with an application such as 
Project-X.  However, it does not magically take care of this -- the 
length of the video is reduced by about 20% and the resulting video 
jumps around constantly.

Please let me know how I should proceed in solving this.  I would be 
happy to provide samples of captured video, results from new tests, etc.

Thanks,

David Ward

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

> Please let me know how I should proceed in solving this.  I would be 
> happy to provide samples of captured video, results from new tests, etc.

When you tune using azap, and you can see UNC and BER values, what is the SNR 
value and does it move over the course of 30 seconds?

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Devin Heitmueller]

On Mon, Jun 8, 2009 at 10:14 AM, Steven Toth <stoth@kernellabs.com> wrote:
>> Please let me know how I should proceed in solving this.  I would be happy
>> to provide samples of captured video, results from new tests, etc.
>
> When you tune using azap, and you can see UNC and BER values, what is the
> SNR value and does it move over the course of 30 seconds?
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com

Also, I believe UNC and BER display garbage when signal lock is lost,
so do you see the "status" field change when the BER/UNC fields show
data?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

On 06/08/2009 10:17 AM, Devin Heitmueller wrote:
> On Mon, Jun 8, 2009 at 10:14 AM, Steven Toth<stoth@kernellabs.com>  wrote:
>    
>>> Please let me know how I should proceed in solving this.  I would be happy
>>> to provide samples of captured video, results from new tests, etc.
>>>        
>> When you tune using azap, and you can see UNC and BER values, what is the
>> SNR value and does it move over the course of 30 seconds?
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.com
>>      
> Also, I believe UNC and BER display garbage when signal lock is lost,
> so do you see the "status" field change when the BER/UNC fields show
> data?
>
> Devin
>
>    
Steven, Devin,

Thanks for your replies.  The signal and SNR are usually in the range 
0x0128 - 0x0140.  They may increment or decrement on a per-second basis 
but otherwise remain steady.  The status field does not change most of 
the time when bit errors occur, but it does lose the lock from time to 
time for a second.  Here is a representative sample:

david@delldimension:~$ azap -r RTN
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 555000000 Hz
video pid 0x0051, audio pid 0x0052
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 012e | snr 012e | ber 00001b04 | unc 00001b04 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000269 | unc 00000269 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012c | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012c | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000266 | unc 00000266 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000002 | unc 00000002 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000150 | unc 00000150 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000273 | unc 00000273 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000001 | unc 00000001 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012c | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 07 | signal 012c | snr 012c | ber 00000000 | unc 00000000 |
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012c | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012c | snr 012e | ber 00000263 | unc 00000263 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status 1f | signal 012e | snr 012e | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

David Ward wrote:
> On 06/08/2009 10:17 AM, Devin Heitmueller wrote:
>> On Mon, Jun 8, 2009 at 10:14 AM, Steven Toth<stoth@kernellabs.com>  
>> wrote:
>>   
>>>> Please let me know how I should proceed in solving this.  I would be 
>>>> happy
>>>> to provide samples of captured video, results from new tests, etc.
>>>>        
>>> When you tune using azap, and you can see UNC and BER values, what is 
>>> the
>>> SNR value and does it move over the course of 30 seconds?
>>>
>>> -- 
>>> Steven Toth - Kernel Labs
>>> http://www.kernellabs.com
>>>      
>> Also, I believe UNC and BER display garbage when signal lock is lost,
>> so do you see the "status" field change when the BER/UNC fields show
>> data?
>>
>> Devin
>>
>>    
> Steven, Devin,
> 
> Thanks for your replies.  The signal and SNR are usually in the range 
> 0x0128 - 0x0140.  They may increment or decrement on a per-second basis 
> but otherwise remain steady.  The status field does not change most of 
> the time when bit errors occur, but it does lose the lock from time to 
> time for a second.  Here is a representative sample:
> 
> david@delldimension:~$ azap -r RTN
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 555000000 Hz
> video pid 0x0051, audio pid 0x0052
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 012e | snr 012e | ber 00001b04 | unc 00001b04 | 
> FE_HAS_LOCK
> status 1f | signal 012c | snr 012e | ber 00000000 | unc 00000000 | 
> FE_HAS_LOCK

Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is 
borderline.

I like my cable system at home to be atleast 32db (0x140) bare minimum, it's 
typically 0x160 (36db) for comfort.

It's possible that the tuner and 1409 driver are a little more optimized under 
windows.

How much attenuation can you add under windows with signal loss? It's probably 
reasonably close to the edge also.

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

On 06/08/2009 12:31 PM, Steven Toth wrote:
> Your SNR is very low, 0x12c is 30db. I assume you're using digital 
> cable this is borderline.
Oh okay ... I wasn't sure how to translate those values before.

> I like my cable system at home to be atleast 32db (0x140) bare 
> minimum, it's typically 0x160 (36db) for comfort.
In your opinion, would I have enough justification for asking Comcast to 
increase the signal strength coming to my house?  I'd like to avoid 
calling someone to come out to my house to say "your TV works fine, 
what's the problem?" and get slapped with a repair fee.  I wasn't sure 
how well I could trust the SNR values reported by the card either...  I 
wish I had a meter or something to test it on my own.  When I move the 
computer directly to the input for the entire house, I get an increase 
of about 0.1dB.

FYI, the signal strength is about 1dB higher for clear QAM signals.  
(The values I sent are for ATSC.)

> It's possible that the tuner and 1409 driver are a little more 
> optimized under windows.
>
> How much attenuation can you add under windows with signal loss? It's 
> probably reasonably close to the edge also.
>
I tuned to the same channel under Windows, and I used the Signal 
Strength Indicator application from Hauppauge (downloadable under the 
Accessories page in the Support section).  It's reporting a SNR of 29-30 
dB, and the value for 'correctable' errors goes to a single-digit value 
about every 5 seconds -- following the same pattern seen with 'azap'.  
However, the difference is that 'uncorrectable' errors stays at 0.  
Under Linux, it seems that all errors are 'uncorrectable'.

Does the error correction occur in the driver or in the chipset?  Seems 
to me like maybe error correction is either not enabled or not 
implemented correctly by the driver?

I agree that the SNR could be better, and if you think it is worth a 
try, I'll see what Comcast will do.  However, because Windows and my TV 
work almost flawlessly, the Linux driver would ideally handle the 
signals at least as well as them...

Let me know what else is helpful from me, and thanks again for your help.

David

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

David Ward wrote:
> On 06/08/2009 12:31 PM, Steven Toth wrote:
>> Your SNR is very low, 0x12c is 30db. I assume you're using digital 
>> cable this is borderline.
> Oh okay ... I wasn't sure how to translate those values before.
> 
>> I like my cable system at home to be atleast 32db (0x140) bare 
>> minimum, it's typically 0x160 (36db) for comfort.
> In your opinion, would I have enough justification for asking Comcast to 
> increase the signal strength coming to my house?  I'd like to avoid 
> calling someone to come out to my house to say "your TV works fine, 
> what's the problem?" and get slapped with a repair fee.  I wasn't sure 
> how well I could trust the SNR values reported by the card either...  I 
> wish I had a meter or something to test it on my own.  When I move the 
> computer directly to the input for the entire house, I get an increase 
> of about 0.1dB.

No idea, I debug my own cable network issues. That being said, usually cable 
companies like to deliver 0db to the house which is nice and hot, then it gets 
split and energy loss occurs 9as well as noise injection). I usually take home 
some metering equipment from the office to sweep my home network.

> 
> FYI, the signal strength is about 1dB higher for clear QAM signals.  
> (The values I sent are for ATSC.)
> 
>> It's possible that the tuner and 1409 driver are a little more 
>> optimized under windows.
>>
>> How much attenuation can you add under windows with signal loss? It's 
>> probably reasonably close to the edge also.
>>
> I tuned to the same channel under Windows, and I used the Signal 
> Strength Indicator application from Hauppauge (downloadable under the 
> Accessories page in the Support section).  It's reporting a SNR of 29-30 
> dB, and the value for 'correctable' errors goes to a single-digit value 
> about every 5 seconds -- following the same pattern seen with 'azap'.  
> However, the difference is that 'uncorrectable' errors stays at 0.  
> Under Linux, it seems that all errors are 'uncorrectable'.

So you don't have much leg room with windows either, certainly not enough for my 
liking. The difference between zero errors and a small handful can be pretty 
small in RF terms.

> 
> Does the error correction occur in the driver or in the chipset?  Seems 
> to me like maybe error correction is either not enabled or not 
> implemented correctly by the driver?

Error recovery is done in the chipset and is only as good as the RF signal 
reaching the demodulator.

> 
> I agree that the SNR could be better, and if you think it is worth a 
> try, I'll see what Comcast will do.  However, because Windows and my TV 
> work almost flawlessly, the Linux driver would ideally handle the 
> signals at least as well as them...

No idea and no I don't agree, just because your TV works doesn't mean the Linux 
driver has to be reliable. That's wishful thinking on your part and Comcast are 
not obliged to make your TV tuner work.

Again, if you have 29-30db on Windows you don't have a lot of legroom for signal 
  attenuation before you'll see errors. I frequently had windows reception 
errors when running at 31db with some boards.

We're getting into the realm of 'do you need to amplify and/or debug your cable 
network', and out of the realm of driver development.

Is the mxl5005s Linux tuner driver perfect? Is it as good as windows? Not quite, 
but it's good for many people and it's unlikely to improve in the near future.

Try installing a decent cable amp. Try looking at the MythTV wiki and support 
sites for improving your cable network.

> 
> Let me know what else is helpful from me, and thanks again for your help.
> 
> David

No problem, your welcome. I hope this advice helps.

Regards,

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Devin Heitmueller]

On Mon, Jun 8, 2009 at 4:20 PM, Steven Toth <stoth@kernellabs.com> wrote:
> David Ward wrote:
>>
>> On 06/08/2009 12:31 PM, Steven Toth wrote:
>>>
>>> Your SNR is very low, 0x12c is 30db. I assume you're using digital cable
>>> this is borderline.
>>
>> Oh okay ... I wasn't sure how to translate those values before.
>>
>>> I like my cable system at home to be atleast 32db (0x140) bare minimum,
>>> it's typically 0x160 (36db) for comfort.
>>
>> In your opinion, would I have enough justification for asking Comcast to
>> increase the signal strength coming to my house?  I'd like to avoid calling
>> someone to come out to my house to say "your TV works fine, what's the
>> problem?" and get slapped with a repair fee.  I wasn't sure how well I could
>> trust the SNR values reported by the card either...  I wish I had a meter or
>> something to test it on my own.  When I move the computer directly to the
>> input for the entire house, I get an increase of about 0.1dB.
>
> No idea, I debug my own cable network issues. That being said, usually cable
> companies like to deliver 0db to the house which is nice and hot, then it
> gets split and energy loss occurs 9as well as noise injection). I usually
> take home some metering equipment from the office to sweep my home network.
>
>>
>> FYI, the signal strength is about 1dB higher for clear QAM signals.  (The
>> values I sent are for ATSC.)
>>
>>> It's possible that the tuner and 1409 driver are a little more optimized
>>> under windows.
>>>
>>> How much attenuation can you add under windows with signal loss? It's
>>> probably reasonably close to the edge also.
>>>
>> I tuned to the same channel under Windows, and I used the Signal Strength
>> Indicator application from Hauppauge (downloadable under the Accessories
>> page in the Support section).  It's reporting a SNR of 29-30 dB, and the
>> value for 'correctable' errors goes to a single-digit value about every 5
>> seconds -- following the same pattern seen with 'azap'.  However, the
>> difference is that 'uncorrectable' errors stays at 0.  Under Linux, it seems
>> that all errors are 'uncorrectable'.
>
> So you don't have much leg room with windows either, certainly not enough
> for my liking. The difference between zero errors and a small handful can be
> pretty small in RF terms.
>
>>
>> Does the error correction occur in the driver or in the chipset?  Seems to
>> me like maybe error correction is either not enabled or not implemented
>> correctly by the driver?
>
> Error recovery is done in the chipset and is only as good as the RF signal
> reaching the demodulator.
>
>>
>> I agree that the SNR could be better, and if you think it is worth a try,
>> I'll see what Comcast will do.  However, because Windows and my TV work
>> almost flawlessly, the Linux driver would ideally handle the signals at
>> least as well as them...
>
> No idea and no I don't agree, just because your TV works doesn't mean the
> Linux driver has to be reliable. That's wishful thinking on your part and
> Comcast are not obliged to make your TV tuner work.
>
> Again, if you have 29-30db on Windows you don't have a lot of legroom for
> signal  attenuation before you'll see errors. I frequently had windows
> reception errors when running at 31db with some boards.
>
> We're getting into the realm of 'do you need to amplify and/or debug your
> cable network', and out of the realm of driver development.
>
> Is the mxl5005s Linux tuner driver perfect? Is it as good as windows? Not
> quite, but it's good for many people and it's unlikely to improve in the
> near future.
>
> Try installing a decent cable amp. Try looking at the MythTV wiki and
> support sites for improving your cable network.
>
>>
>> Let me know what else is helpful from me, and thanks again for your help.
>>
>> David
>
> No problem, your welcome. I hope this advice helps.
>
> Regards,
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
>

Steven,

One thing that is interesting is that he is getting BER/UNC errors
even on ATSC, when he has a 30.2 dB signal.  While I agree that the
cable company could be sending a weak signal, 30 dB should be plenty
for ATSC.

Also, it's possible that the playback application/codec in question
poorly handles recovery from MPEG errors such as discontinuity, which
results in the experience appearing to be worse under Linux.

I'm going to see if I can find some cycles to do some testing here
with s5h1409/s5h1411 and see if I can reproduce what David is seeing.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

On 06/08/2009 04:36 PM, Devin Heitmueller wrote:
> On Mon, Jun 8, 2009 at 4:20 PM, Steven Toth<stoth@kernellabs.com>  wrote:
>    
>> We're getting into the realm of 'do you need to amplify and/or debug your
>> cable network', and out of the realm of driver development.
>>      
Comcast is coming tomorrow to check out the signal quality.  They said 
that they expect to deliver SNR in the range of 33dB - 45dB to the 
premises.  I will let you know how that affects Linux captures.
> Steven,
>
> One thing that is interesting is that he is getting BER/UNC errors
> even on ATSC, when he has a 30.2 dB signal.  While I agree that the
> cable company could be sending a weak signal, 30 dB should be plenty
> for ATSC.
>
> Also, it's possible that the playback application/codec in question
> poorly handles recovery from MPEG errors such as discontinuity, which
> results in the experience appearing to be worse under Linux.
>    
I am actually comparing the TS files captured under both Linux and 
Windows side-by-side in the same environment, copying the files to other 
computers in my home.  I can demux the video with Project-X which prints 
out the errors in the bitstream as it reads them.  I can also observe 
the overall quality by playing it back with VLC, WinDVD, etc.  When I 
use TMPGEnc Authoring Works 4 to read the file, the errors in the 
bitstream even seem to crash the application -- though obviously TMPGEnc 
is to blame for that.
> I'm going to see if I can find some cycles to do some testing here
> with s5h1409/s5h1411 and see if I can reproduce what David is seeing.
>
>    
Devin, I would really really appreciate this.  I hesitated to e-mail 
this list for several weeks, because I wanted to investigate thoroughly 
first and avoid wasting anyone's time as much as possible.  I hope you 
are able to reproduce this.

David

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Devin Heitmueller]

On Mon, Jun 8, 2009 at 5:03 PM, David Ward <david.ward@gatech.edu> wrote:
> Devin, I would really really appreciate this.  I hesitated to e-mail this
> list for several weeks, because I wanted to investigate thoroughly first and
> avoid wasting anyone's time as much as possible.  I hope you are able to
> reproduce this.

Well, I've got a few different combinations of s5h1409 tuners and
demods (including the HVR-1600), so if I can reproduce the issue, I
can probably narrow it down as to whether it's a tuner or a demod
issue.  I've spent a good bit of time analyzing the s5h1409 driver in
the past, although I don't have the datasheet for the chip.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Andy Walls]

On Mon, 2009-06-08 at 16:20 -0400, Steven Toth wrote:


> Try installing a decent cable amp. Try looking at the MythTV wiki and support 
> sites for improving your cable network.

If using an amp, be sure you pick one with appropriate gain and noise
figure.   Overdriving the mxl5005s with too much signal can degrade SNR
as well.

Here's my standard list of things to check:

http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality

Good luck.

Andy

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

> Steven,
> 
> One thing that is interesting is that he is getting BER/UNC errors
> even on ATSC, when he has a 30.2 dB signal.  While I agree that the
> cable company could be sending a weak signal, 30 dB should be plenty
> for ATSC.
> 
> Also, it's possible that the playback application/codec in question
> poorly handles recovery from MPEG errors such as discontinuity, which
> results in the experience appearing to be worse under Linux.
> 
> I'm going to see if I can find some cycles to do some testing here
> with s5h1409/s5h1411 and see if I can reproduce what David is seeing.

Thanks.

I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable 
because that would be consistent with the numbers. You could well be right.

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

David Ward wrote:
> On 06/08/2009 04:36 PM, Devin Heitmueller wrote:
>> On Mon, Jun 8, 2009 at 4:20 PM, Steven Toth<stoth@kernellabs.com>  wrote:
>>   
>>> We're getting into the realm of 'do you need to amplify and/or debug 
>>> your
>>> cable network', and out of the realm of driver development.
>>>      
> Comcast is coming tomorrow to check out the signal quality.  They said 
> that they expect to deliver SNR in the range of 33dB - 45dB to the 
> premises.  I will let you know how that affects Linux captures.

33 should be fine for any Linux TV device. Make sure the engineer checks for 
33db across a range of the higher (80 thru 100) rf channels (where rf falloff of 
common).

Let us know how you get on.

Regards,

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Devin Heitmueller]

On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth <stoth@kernellabs.com> wrote:
> I ruled out 30db on ATSC because that sounds incredibly high, I assumed
> cable because that would be consistent with the numbers. You could well be
> right.
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com

I agree it's high, but certainly possible.  I've got a 30 dB signal,
but my situation is a bit unusual.

I spent all of last night working on another issue, but I am hoping to
get back to it this week.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

Devin Heitmueller wrote:
> On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth <stoth@kernellabs.com> wrote:
>> I ruled out 30db on ATSC because that sounds incredibly high, I assumed
>> cable because that would be consistent with the numbers. You could well be
>> right.
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.com
> 
> I agree it's high, but certainly possible.  I've got a 30 dB signal,
> but my situation is a bit unusual.
> 
> I spent all of last night working on another issue, but I am hoping to
> get back to it this week.

David has called out Comcast to review his installation.

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

On 06/09/2009 10:24 AM, Steven Toth wrote:
> David has called out Comcast to review his installation.
After replacing all the connectors and some cables from the pole all the 
way to the outlet, their meter ultimately showed 39-40dB at the outlet.  
My card is showing the same SNR values as before.  Go figure.

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Devin Heitmueller]

On Tue, Jun 9, 2009 at 2:52 PM, David Ward <david.ward@gatech.edu> wrote:
> On 06/09/2009 10:24 AM, Steven Toth wrote:
>>
>> David has called out Comcast to review his installation.
>
> After replacing all the connectors and some cables from the pole all the way
> to the outlet, their meter ultimately showed 39-40dB at the outlet.  My card
> is showing the same SNR values as before.  Go figure.
>

I want to say that the SNR counter for the s5h1409 caps out at 30dB,
but I would have to double check the source code.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

Devin Heitmueller wrote:
> On Tue, Jun 9, 2009 at 2:52 PM, David Ward <david.ward@gatech.edu> wrote:
>> On 06/09/2009 10:24 AM, Steven Toth wrote:
>>> David has called out Comcast to review his installation.
>> After replacing all the connectors and some cables from the pole all the way
>> to the outlet, their meter ultimately showed 39-40dB at the outlet.  My card
>> is showing the same SNR values as before.  Go figure.
>>
> 
> I want to say that the SNR counter for the s5h1409 caps out at 30dB,
> but I would have to double check the source code.
> 
> Devin
> 

40db.

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

Devin Heitmueller wrote:
> On Tue, Jun 9, 2009 at 2:52 PM, David Ward <david.ward@gatech.edu> wrote:
>> On 06/09/2009 10:24 AM, Steven Toth wrote:
>>> David has called out Comcast to review his installation.
>> After replacing all the connectors and some cables from the pole all the way
>> to the outlet, their meter ultimately showed 39-40dB at the outlet.  My card
>> is showing the same SNR values as before.  Go figure.
>>


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.

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Devin Heitmueller]

On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth <stoth@kernellabs.com> wrote:
>
> 40db.
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
>

Just checked the source.  It's 40dB for QAM256, but 30dB for ATSC and
QAM64.  Are we sure he's doing QAM256 and not QAM64?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

Devin Heitmueller wrote:
> On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth <stoth@kernellabs.com> wrote:
>> 40db.
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.com
>>
> 
> Just checked the source.  It's 40dB for QAM256, but 30dB for ATSC and
> QAM64.  Are we sure he's doing QAM256 and not QAM64?
> 
> Devin
> 

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 Toth - Kernel Labs
http://www.kernellabs.com

Re: cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

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.

I admit that I ruled out the idea of RF issues too soon, which I really 
should know better than.  After reading the thread at 
http://forums.gbpvr.com/showthread.php?t=36049 I'm now realizing why 
reception on the TV and tuner card isn't going to be equal, due to 
limited size and shielding of tuner circuitry on a PCI form factor card 
vs. on a TV set.  Makes sense.

Still, I am continuing to see uncorrectable bit errors at the same rate 
as before under Linux, while Windows sees errors but corrects them.  I 
would think that both drivers should be receiving identical streams of 
data from the chipset, and should be able to process them the same way?  
That's what is confusing me.

Ideally I would like to have access to a lot more equipment to control 
all the variables and make it easier to reproduce what I am seeing...but 
I don't here...

Or do you guys think that this is still primarily an RF problem?  I 
don't know what else I could do about that though.  Since the SNR did 
not improve when I hooked the tuner card directly into the cable input 
from the street, I'm concerned that putting an amplifier would not help 
and could just make things worse.  And clearly Comcast now considers me 
to be within their quality thresholds.

I really appreciate your help and patience with me, especially to the 
extent that this is going outside the realm of DVB drivers.

David

Re: cx18, s5h1409: chronic bit errors, only under Linux

[Steven Toth]

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

Re: cx18, s5h1409: chronic bit errors, only under Linux

[David Ward]

On 06/10/2009 10:32 AM, Steven Toth wrote:
> David Ward wrote:
>> 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).

I need to make a correction here.  I am receiving all programming over 
digital cable.  I mistakenly thought that rebroadcasts of over-the-air 
signals on a cable network followed all the ATSC specifications 
(including the modulation scheme) over the particular carrier 
frequency.  Now I understand that like all other digital cable channels, 
local channels are broadcasted using QAM rather than 8VSB (but then they 
also include PSIP data as required by the FCC).  So the SNR requirements 
for QAM-256 are the ones that should apply to my situation.  That's a 
big misunderstanding on my part...my bad.

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

Sorry for not being clear.  I tested again thoroughly under both Linux 
and Windows before writing this response.

Linux is tuning almost all channels at a SNR approximately 3 dB less 
than under Windows.  That is why I now believe this is a tuner driver 
problem.  I composed a table for myself with average SNRs per channel 
while running both Windows and Linux to determine this, both with the 
tuner card connected directly to the household cable, and connected 
behind the splitter in my house.

Under Windows, channels with low frequencies have an SNR of ~35 dB, and 
channels with high frequency have an SNR of ~33 dB, when connected 
directly to the household input.  The splitter at most gives me a loss 
of 1 dB but often makes no difference.

Again, sorry for not making that clear.  I think the 3 dB difference is 
the real issue at play here, and is the reason I'm writing this message 
to this list, rather than one intended for household wiring issues.

> Did you get a chance to review the signal monitor to determine whether 
> it was 64 or 256?

All channels are 256-QAM -- reported as such by both Linux and Windows.

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

Based on our discussion until now, the difference between 30.5 dB and 
33.5 dB should be very significant, and I hope would warrant an 
investigation into the cause (possibly asking Hauppauge/Conexant to 
compare details of your tuner drivers against theirs?  I understand they 
provide support to the Linux community).  As you said, if Windows was 
only picking up the channels at 30.5 dB, then I shouldn't expect much 
more than I am getting now, as I would be riding on a thin line between 
errors and no errors.

Sorry for not being accurate in some of my earlier messages, and thanks 
for being patient with me.

David