Mailing List Archive

On Wed, Nov 25, 2009 at 12:52 PM, Dale Pontius <DEPontius@edgehp.net> wrote:
> I've been using the NTSC side of my HVR-1600s for some time now, and
> occasionally play with the ATSC/QAM side, hoping to get it into regular
> usage sooner or later.  The other day I first did some ATSC scans using
> an antenna, and managed to get about what I'd expect for channels, even
> watched a sampling of them.  Then I hooked to an unused port on my
> splitter/amp and did a QAM scan, wondering what Comcast has left
> unencrypted.  I got a pile of messages :
> WARNING: filter timeout pid 0x1ffb
> and dvbscan generated 200+ unlabeled entries.
>
> What does the filter timeout message mean?
> Is there anything I can do about it.
>
> I plan to do more looking at this stuff, but was hoping for a little
> more understanding than just mimicking steps I've googled.
>
> Last time I tried this stuff, I came up with only 1 fully identified
> QAM256 channel - QVC.  (Oh Boy!!!)
>
> Any suggestions, pointers, etc would be welcome.

Hi Dale,

The ATSC PSIP standard provides things like channel identification
information and program guide data on MPEG PID 0x1FFB. The channel
scanner is looking for that data so that it can provide a reasonable
name for the channel in channels.conf (for example "CBS-HD").

When you see that filter timeout message, it typically means that the
tuner achieved a signal lock on the target frequency, but the sender
was not providing any PSIP info. This is really common for QAM, since
many of the cable companies are not forwarding the channel information
even for the "must carry channels" (in violation of the FCC
specification, I might add). It can also mean the channel is
encrypted (requiring a cablecard), and in that case the cable company
is not required to provide PSIP info.

Unlabeled entries are cases where a channel was detected but either
the channel was encrypted or did not have any PSIP info (but
admittedly all the channel scanners do a lousy job of telling you
which it was).

Cheers,

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 12:52 PM, Dale Pontius <DEPontius@edgehp.net> wrote:
>> I've been using the NTSC side of my HVR-1600s for some time now, and
>> occasionally play with the ATSC/QAM side, hoping to get it into regular
>> usage sooner or later. The other day I first did some ATSC scans using
>> an antenna, and managed to get about what I'd expect for channels, even
>> watched a sampling of them. Then I hooked to an unused port on my
>> splitter/amp and did a QAM scan, wondering what Comcast has left
>> unencrypted. I got a pile of messages :
>> WARNING: filter timeout pid 0x1ffb
>> and dvbscan generated 200+ unlabeled entries.
>>
>> What does the filter timeout message mean?
>> Is there anything I can do about it.
>>
>> I plan to do more looking at this stuff, but was hoping for a little
>> more understanding than just mimicking steps I've googled.
>>
>> Last time I tried this stuff, I came up with only 1 fully identified
>> QAM256 channel - QVC. (Oh Boy!!!)
>>
>> Any suggestions, pointers, etc would be welcome.
>
> Hi Dale,
>
> The ATSC PSIP standard provides things like channel identification
> information and program guide data on MPEG PID 0x1FFB. The channel
> scanner is looking for that data so that it can provide a reasonable
> name for the channel in channels.conf (for example "CBS-HD").
>
> When you see that filter timeout message, it typically means that the
> tuner achieved a signal lock on the target frequency, but the sender
> was not providing any PSIP info. This is really common for QAM, since
> many of the cable companies are not forwarding the channel information
> even for the "must carry channels" (in violation of the FCC
> specification, I might add). It can also mean the channel is
> encrypted (requiring a cablecard), and in that case the cable company
> is not required to provide PSIP info.
>
> Unlabeled entries are cases where a channel was detected but either
> the channel was encrypted or did not have any PSIP info (but
> admittedly all the channel scanners do a lousy job of telling you
> which it was).
>
Well it is Comcast, after all... More of which will become evident
shortly. I can't receive any channels adequately over QAM. Either the
channel is encrypted, apparently with adequate signal strength, or it's
clear with poor signal strength. Here are some results from azap:

user@localhost ~/computers/hdtv $ azap CH567-1
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 567000000 Hz
video pid 0x07c0, audio pid 0x07c1
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 013a | snr 013c | ber 00001c2f | unc 00001c2f |
status 00 | signal 0142 | snr 0142 | ber 000032b9 | unc 000032b9 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0145 | snr 0145 | ber 00000b0d | unc 00000b0d |
status 00 | signal 0145 | snr 0145 | ber 000032ce | unc 000032ce |
status 1f | signal 0145 | snr 0145 | ber 00001be0 | unc 00001be0 | FE_HAS_LOCK
status 1f | signal 013e | snr 013e | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0145 | snr 0146 | ber 00000bce | unc 00000bce |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 0140 | snr 0140 | ber 00001aa0 | unc 00001aa0 |
status 00 | signal 0140 | snr 0140 | ber 000032ca | unc 000032ca |
status 1f | signal 0142 | snr 0142 | ber 00001c04 | unc 00001c04 | FE_HAS_LOCK
status 18 | signal 013c | snr 013c | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0145 | snr 0145 | ber 00000c0b | unc 00000c0b |
^C

That was a clear channel, here's an encrypted one:

user@localhost ~/computers/hdtv $ azap CH561-1
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 561000000 Hz
video pid 0x0000, audio pid 0x0f42
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 013c | snr 013e | ber 00001c0c | unc 00001c0c | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
^C

These are only 2 channels, but everything else is like this - encrypted
channels get a solid lock, clear ones done.

So to boil this down to a question: How do I interpret the results of
azap? If I try searching, all I get is people talking about using it
to look for "FE_HAS_LOCK". I find nothing about how to interpret the
various fields, for instance "status", "signal", "snr", "ber", "unc".
It's kind of obvious what "signal" and "snr" mean, but not how to
interpret the hex numbers presented. It equally seems like an obvious
guess that for signal and snr the bigger the better, but in some cases
I have seen clear channels have decent numbers, as high as 014a, but
not sticking there, and still not getting a decent lock.

I need to script all of this up, so I can do a more thorough jobe, but
so far every encrypted channel I've looked at is good, every clear
channel bad. Given a pattern like this, I'd say that Comcast is doing
this on purpose, to nudge people into getting set-top boxes.

Are there other tools for understanding what I've got here? I've done
a bit more with dvbscan, but once again don't really understand how to
interpret the results. There's a bit more documentation readily
available, but still not a lot on how to interpret the output, beyond
the obvious stuff. I've also seen reference to dvbstream, but don't
seem to have ready access to it under Gentoo, or at least haven't
found what package to install to get it. I've installed and fiddled
a little with w_scan, but have so far been happier with dvbscan.

Thanks,
Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Sat, Nov 28, 2009 at 10:22 AM, Dale Pontius <DEPontius@edgehp.net> wrote:
> Well it is Comcast, after all...  More of which will become evident
> shortly.  I can't receive any channels adequately over QAM.  Either the
> channel is encrypted, apparently with adequate signal strength, or it's
> clear with poor signal strength.  Here are some results from azap:
>
> user@localhost ~/computers/hdtv $ azap CH567-1
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 567000000 Hz
> video pid 0x07c0, audio pid 0x07c1
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 07 | signal 013a | snr 013c | ber 00001c2f | unc 00001c2f |
> status 00 | signal 0142 | snr 0142 | ber 000032b9 | unc 000032b9 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0145 | snr 0145 | ber 00000b0d | unc 00000b0d |
> status 00 | signal 0145 | snr 0145 | ber 000032ce | unc 000032ce |
> status 1f | signal 0145 | snr 0145 | ber 00001be0 | unc 00001be0 | FE_HAS_LOCK
> status 1f | signal 013e | snr 013e | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0145 | snr 0146 | ber 00000bce | unc 00000bce |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 07 | signal 0140 | snr 0140 | ber 00001aa0 | unc 00001aa0 |
> status 00 | signal 0140 | snr 0140 | ber 000032ca | unc 000032ca |
> status 1f | signal 0142 | snr 0142 | ber 00001c04 | unc 00001c04 | FE_HAS_LOCK
> status 18 | signal 013c | snr 013c | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0145 | snr 0145 | ber 00000c0b | unc 00000c0b |
> ^C
>
> That was a clear channel, here's an encrypted one:
>
> user@localhost ~/computers/hdtv $ azap CH561-1
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 561000000 Hz
> video pid 0x0000, audio pid 0x0f42
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 013c | snr 013e | ber 00001c0c | unc 00001c0c | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0148 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> ^C

If you haven't already, you should install the latest v4l-dvb code. I
did some fixes which significantly improve the signal quality for
ClearQAM tuning.

> These are only 2 channels, but everything else is like this - encrypted
> channels get a solid lock, clear ones done.

It is very common for a cable provider to multiplex *all* the ClearQAM
channels onto two or three frequencies. So you shouldn't expect to
see ten or twelve unencrypted frequencies just because there are ten
or twelve "must-carry" ClearQAM channels.

> So to boil this down to a question: How do I interpret the results of
> azap?  If I try searching, all I get is people talking about using it
> to look for "FE_HAS_LOCK".  I find nothing about how to interpret the
> various fields, for instance "status", "signal", "snr", "ber", "unc".
> It's kind of obvious what "signal" and "snr" mean, but not how to
> interpret the hex numbers presented.  It equally seems like an obvious
> guess that for signal and snr the bigger the better, but in some cases
> I have seen clear channels have decent numbers, as high as 014a, but
> not sticking there, and still not getting a decent lock.

The SNR and strength values vary in terms of how they are interpreted,
which is why everybody says that you can only rely on the FE_HAS_LOCK
field across different products. For your product, both the SNR and
strength field return the SNR in 0.1dB increments. A value of 0x014a
translates to an SNR of 33.0 dB.

> I need to script all of this up, so I can do a more thorough jobe, but
> so far every encrypted channel I've looked at is good, every clear
> channel bad.  Given a pattern like this, I'd say that Comcast is doing
> this on purpose, to nudge people into getting set-top boxes.

Doubtful. While I don't trust Comcast any further than I can throw
them, I suspect in this case you will find that your situation is
greatly improved once you update your driver.

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Devin Heitmueller wrote:
> <snip>
>
> If you haven't already, you should install the latest v4l-dvb code. I
> did some fixes which significantly improve the signal quality for
> ClearQAM tuning.
>
I'm running your drivers that you announced back on Oct 29, and I
downloaded on Nov 1. I never got a decent chance to A-B them against
the standard drivers, so I never reported anything. It was only a few
weeks ago that I got back into messing with the digital side, again.

>> These are only 2 channels, but everything else is like this - encrypted
>> channels get a solid lock, clear ones done.
>
> It is very common for a cable provider to multiplex *all* the ClearQAM
> channels onto two or three frequencies. So you shouldn't expect to
> see ten or twelve unencrypted frequencies just because there are ten
> or twelve "must-carry" ClearQAM channels.
>
When I said "only 2 channels", I meant listings and information for 1
clear, 1 encrypted. For the clear stuff, Comcast has generally stuffed
2 HD and 2 SD channels on several frequencies, 7 SH channels on another,
etc. The SD and clearQAM counts don't match up because some of our HD
channels have an extra SD channel (or 2, for one PBS) attached.

>> So to boil this down to a question: How do I interpret the results of
>> azap? If I try searching, all I get is people talking about using it
>> to look for "FE_HAS_LOCK". I find nothing about how to interpret the
>> various fields, for instance "status", "signal", "snr", "ber", "unc".
>> It's kind of obvious what "signal" and "snr" mean, but not how to
>> interpret the hex numbers presented. It equally seems like an obvious
>> guess that for signal and snr the bigger the better, but in some cases
>> I have seen clear channels have decent numbers, as high as 014a, but
>> not sticking there, and still not getting a decent lock.
>
> The SNR and strength values vary in terms of how they are interpreted,
> which is why everybody says that you can only rely on the FE_HAS_LOCK
> field across different products. For your product, both the SNR and
> strength field return the SNR in 0.1dB increments. A value of 0x014a
> translates to an SNR of 33.0 dB.
>
Which leaves me wondering, what is "good" and "bad" for SNR? It looks
to me as if it takes a consistent 146+ to lock and stay there, but is
that really "good", or just "adequate?"

>> I need to script all of this up, so I can do a more thorough jobe, but
>> so far every encrypted channel I've looked at is good, every clear
>> channel bad. Given a pattern like this, I'd say that Comcast is doing
>> this on purpose, to nudge people into getting set-top boxes.
>
> Doubtful. While I don't trust Comcast any further than I can throw
> them, I suspect in this case you will find that your situation is
> greatly improved once you update your driver.
>
Have there been more changes since Oct 29/Nov 1? I'm a little behind on
my kernel, and wouldn't mind refreshing. Is your stuff into the v4l
mainline, or still just in your space?

Thanks,
Dale

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Sat, Nov 28, 2009 at 1:08 PM, Dale Pontius <DEPontius@edgehp.net> wrote:
> I'm running your drivers that you announced back on Oct 29, and I
> downloaded on Nov 1.  I never got a decent chance to A-B them against
> the standard drivers, so I never reported anything.  It was only a few
> weeks ago that I got back into messing with the digital side, again.

There actually was an additional fix made after the original
announcement, committed on November 1st at 23:30. Depending on
specifically when you installed, this will dictate whether you got the
fix. Everything was merged into the mainline v4l-dvb tree though, so
you should stop using my tree and switch to the main
http://linuxtv.org/hg/v4l-dvb tree.

> Which leaves me wondering, what is "good" and "bad" for SNR?  It looks
> to me as if it takes a consistent 146+ to lock and stay there, but is
> that really "good", or just "adequate?"

Yeah, around 32 is marginal. And if you don't have the second fix,
then that could definitely explain why you are gaining/losing lock.

> Have there been more changes since Oct 29/Nov 1?  I'm a little behind on
> my kernel, and wouldn't mind refreshing.  Is your stuff into the v4l
> mainline, or still just in your space?

Yeah, like I said above, switch to the mainline and see if it works
better (since we know that has *all* the fixes).

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Devin Heitmueller wrote:
> On Sat, Nov 28, 2009 at 1:08 PM, Dale Pontius <DEPontius@edgehp.net> wrote:
>> I'm running your drivers that you announced back on Oct 29, and I
>> downloaded on Nov 1. I never got a decent chance to A-B them against
>> the standard drivers, so I never reported anything. It was only a few
>> weeks ago that I got back into messing with the digital side, again.
>
> There actually was an additional fix made after the original
> announcement, committed on November 1st at 23:30. Depending on
> specifically when you installed, this will dictate whether you got the
> fix. Everything was merged into the mainline v4l-dvb tree though, so
> you should stop using my tree and switch to the main
> http://linuxtv.org/hg/v4l-dvb tree.
>
I downloaded at 7:23 in the morning, so clearly I was missing something.
My kernel was a little down-level, so I just built the latest'n'greatest
Gentoo kernel, grabbed a new snapshot from mercurial, and built.

I now have locks on my ClearQAM channels. I posted 2 examples of using
azap, one clear, one encrypted before. Here they are now...
Clear -
user@localhost ~/computers/hdtv $ azap CH567-1
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 567000000 Hz
video pid 0x07c0, audio pid 0x07c1
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0142 | snr 0142 | ber 00001be4 | unc 00001be4 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0142 | snr 0142 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0142 | snr 0142 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0142 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0142 | snr 0142 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
^C
Encrypted -
user@localhost ~/computers/hdtv $ azap CH561-1
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 561000000 Hz
video pid 0x0000, audio pid 0x0f42
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0146 | snr 0146 | ber 00001a1d | unc 00001a1d | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
^C
The numbers aren't that different, but the big thing is that the clear channel
doesn't have all of the dropouts it did before. There seems to be some sort of
shelf, and with the old drivers I was spending enough time below that shelf to
make it unworkable. There is still one frequency with 2 channels that are too
week, but I'm not sure what they are, from what I've been able to see of the
content. All of the other stuff that I've checked appears to be good.

Now to figure out how to integrate this stuff with Myth, including the fact
that several channels can be gotten in HD, digital SD, or NTSC. Then it'll be
even more fun if/when I hook a cable box to the svideo input. But that's a
different list.

Thanks,
Dale


>> Which leaves me wondering, what is "good" and "bad" for SNR? It looks
>> to me as if it takes a consistent 146+ to lock and stay there, but is
>> that really "good", or just "adequate?"
>
> Yeah, around 32 is marginal. And if you don't have the second fix,
> then that could definitely explain why you are gaining/losing lock.
>
>> Have there been more changes since Oct 29/Nov 1? I'm a little behind on
>> my kernel, and wouldn't mind refreshing. Is your stuff into the v4l
>> mainline, or still just in your space?
>
> Yeah, like I said above, switch to the mainline and see if it works
> better (since we know that has *all* the fixes).
>
> Devin
>


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Sun, Nov 29, 2009 at 5:41 PM, Dale Pontius <DEPontius@edgehp.net> wrote:
> I downloaded at 7:23 in the morning, so clearly I was missing something.
> My kernel was a little down-level, so I just built the latest'n'greatest
> Gentoo kernel, grabbed a new snapshot from mercurial, and built.
>
> I now have locks on my ClearQAM channels.  I posted 2 examples of using
> azap, one clear, one encrypted before.  Here they are now...
> Clear -
> user@localhost ~/computers/hdtv $ azap CH567-1
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 567000000 Hz
> video pid 0x07c0, audio pid 0x07c1
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 0142 | snr 0142 | ber 00001be4 | unc 00001be4 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0142 | snr 0142 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0142 | snr 0142 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0142 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0142 | snr 0142 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> ^C
> Encrypted -
> user@localhost ~/computers/hdtv $ azap CH561-1
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 561000000 Hz
> video pid 0x0000, audio pid 0x0f42
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 0146 | snr 0146 | ber 00001a1d | unc 00001a1d | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> ^C
> The numbers aren't that different, but the big thing is that the clear channel
> doesn't have all of the dropouts it did before.  There seems to be some sort of
> shelf, and with the old drivers I was spending enough time below that shelf to
> make it unworkable.  There is still one frequency with 2 channels that are too
> week, but I'm not sure what they are, from what I've been able to see of the
> content.  All of the other stuff that I've checked appears to be good.

Great. That's pretty much what I thought was going on. My first set
of patches boosted the signal quality by about 3 dB across the board,
but introduced the edge case that you ran into. The last patch in the
series fixed that issue.

> Now to figure out how to integrate this stuff with Myth, including the fact
> that several channels can be gotten in HD, digital SD, or NTSC.  Then it'll be
> even more fun if/when I hook a cable box to the svideo input.  But that's a
> different list.

Yeah, those are challenges that many users encounter, regardless of
which card they are using. Good luck!

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users