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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
