Hauppage HVR-2250 Tuning problems

Hauppage HVR-2250 Tuning problems

[dan]

I can't seem to get my HVR-2250 (rev. 88061) card to tune any
channels.  I have Comcast digital cable, and my VIZIO VL370M
television is able to tune all of the QAM channels, so I know that the
signal is present and is usable (in theory).  I have tried scanning
for channels in Mythbuntu 9.10 RC (2.6.31 kernel), with MythTV, scan,
dvbscan and scte65scan, without finding any channels.  I have tried
installing the saa7164 drivers from the kernellabs repository and also
the linuxtv repository, with the same results.

The channel scanner in MythTV has two bars at the top of the screen to
indicate signal strength and signal-to-noise ratio, and they both stay
at 0% during the channel scan.  The scanner will say "locked" for a
particular channel, but then it will show a message saying that it
timed and without finding any channels.  I have already set the
timeout to the maximum allowed by the software.

scte65 scan get the closest to giving some kind of output.  I run it
with this command:

$ ./scte65scan -f1 -n1 ./us-Cable-Standard-center-frequencies-QAM256 >
channels.conf

At some point it  gives the following output:

tuning 741000000hz..locked...PID 0x1ffc found
Collecting data (may take up to 2 minutes)

but then it basically just hangs indefinitely until I kill it, and
channels.conf is always empty afterward.

I do have a couple of errors show up in dmesg, but I'm not sure if
they're relevant.  Just in case it's helpful, here is the output from
dmesg.

[   14.266956] saa7164 driver loaded
[   14.267518] saa7164 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   14.267621] CORE saa7164[0]: subsystem: 0070:8891, board: Hauppauge
WinTV-HVR2250 [card=7,autodetected]
[   14.267627] saa7164[0]/0: found at 0000:01:00.0, rev: 129, irq: 16,
latency: 0, mmio: 0xe4000000
[   14.267633] saa7164 0000:01:00.0: setting latency timer to 64
[   14.267637] IRQ 16/saa7164[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[   14.460016] saa7164_downloadfirmware() no first image
[   14.460029] saa7164_downloadfirmware() Waiting for firmware upload
(v4l-saa7164-1.0.3.fw)
[   14.460035] saa7164 0000:01:00.0: firmware: requesting v4l-saa7164-1.0.3.fw
[   16.075415] saa7164_downloadfirmware() firmware read 3978608 bytes.
[   16.075417] saa7164_downloadfirmware() firmware loaded.
[   16.075425] saa7164_downloadfirmware() SecBootLoader.FileSize = 3978608
[   16.075431] saa7164_downloadfirmware() FirmwareSize = 0x1fd6
[   16.075433] saa7164_downloadfirmware() BSLSize = 0x0
[   16.075434] saa7164_downloadfirmware() Reserved = 0x0
[   16.075435] saa7164_downloadfirmware() Version = 0x51cc1
[   23.351830] saa7164_downloadimage() Image downloaded, booting...
[   23.460015] saa7164_downloadimage() Image booted successfully.
[   25.840015] saa7164_downloadimage() Image downloaded, booting...
[   27.260019] saa7164_downloadimage() Image booted successfully.
[   27.302513] saa7164[0]: Hauppauge eeprom: model=88061
[   28.539398] saa7164_api_i2c_read() error, ret(2) = 0x13
[   28.542913] saa7164_api_i2c_read() error, ret(2) = 0x13
[   28.543201] DVB: registering new adapter (saa7164)
[   32.148177] DVB: registering new adapter (saa7164)

I have done some searching online, and that's what led me to scan,
dvbscan and scte65scan, but none of the suggestions I've found so far
seem to help.  Does anyone have any suggestions as to where I can go
from here?  Could there be something wrong with the card itself?  Are
there any diagnostics I could run?

Thanks in advance for any help that anyone can offer.

--dan

Re: Hauppage HVR-2250 Tuning problems

[Another Sillyname]

2009/10/26 dan <danwalkeriv@gmail.com>:
> I can't seem to get my HVR-2250 (rev. 88061) card to tune any
> channels.  I have Comcast digital cable, and my VIZIO VL370M
> television is able to tune all of the QAM channels, so I know that the
> signal is present and is usable (in theory).  I have tried scanning
> for channels in Mythbuntu 9.10 RC (2.6.31 kernel), with MythTV, scan,
> dvbscan and scte65scan, without finding any channels.  I have tried
> installing the saa7164 drivers from the kernellabs repository and also
> the linuxtv repository, with the same results.
>
> The channel scanner in MythTV has two bars at the top of the screen to
> indicate signal strength and signal-to-noise ratio, and they both stay
> at 0% during the channel scan.  The scanner will say "locked" for a
> particular channel, but then it will show a message saying that it
> timed and without finding any channels.  I have already set the
> timeout to the maximum allowed by the software.
>
> scte65 scan get the closest to giving some kind of output.  I run it
> with this command:
>
> $ ./scte65scan -f1 -n1 ./us-Cable-Standard-center-frequencies-QAM256 >
> channels.conf
>
> At some point it  gives the following output:
>
> tuning 741000000hz..locked...PID 0x1ffc found
> Collecting data (may take up to 2 minutes)
>
> but then it basically just hangs indefinitely until I kill it, and
> channels.conf is always empty afterward.
>
> I do have a couple of errors show up in dmesg, but I'm not sure if
> they're relevant.  Just in case it's helpful, here is the output from
> dmesg.
>
> [   14.266956] saa7164 driver loaded
> [   14.267518] saa7164 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [   14.267621] CORE saa7164[0]: subsystem: 0070:8891, board: Hauppauge
> WinTV-HVR2250 [card=7,autodetected]
> [   14.267627] saa7164[0]/0: found at 0000:01:00.0, rev: 129, irq: 16,
> latency: 0, mmio: 0xe4000000
> [   14.267633] saa7164 0000:01:00.0: setting latency timer to 64
> [   14.267637] IRQ 16/saa7164[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> [   14.460016] saa7164_downloadfirmware() no first image
> [   14.460029] saa7164_downloadfirmware() Waiting for firmware upload
> (v4l-saa7164-1.0.3.fw)
> [   14.460035] saa7164 0000:01:00.0: firmware: requesting v4l-saa7164-1.0.3.fw
> [   16.075415] saa7164_downloadfirmware() firmware read 3978608 bytes.
> [   16.075417] saa7164_downloadfirmware() firmware loaded.
> [   16.075425] saa7164_downloadfirmware() SecBootLoader.FileSize = 3978608
> [   16.075431] saa7164_downloadfirmware() FirmwareSize = 0x1fd6
> [   16.075433] saa7164_downloadfirmware() BSLSize = 0x0
> [   16.075434] saa7164_downloadfirmware() Reserved = 0x0
> [   16.075435] saa7164_downloadfirmware() Version = 0x51cc1
> [   23.351830] saa7164_downloadimage() Image downloaded, booting...
> [   23.460015] saa7164_downloadimage() Image booted successfully.
> [   25.840015] saa7164_downloadimage() Image downloaded, booting...
> [   27.260019] saa7164_downloadimage() Image booted successfully.
> [   27.302513] saa7164[0]: Hauppauge eeprom: model=88061
> [   28.539398] saa7164_api_i2c_read() error, ret(2) = 0x13
> [   28.542913] saa7164_api_i2c_read() error, ret(2) = 0x13
> [   28.543201] DVB: registering new adapter (saa7164)
> [   32.148177] DVB: registering new adapter (saa7164)
>
> I have done some searching online, and that's what led me to scan,
> dvbscan and scte65scan, but none of the suggestions I've found so far
> seem to help.  Does anyone have any suggestions as to where I can go
> from here?  Could there be something wrong with the card itself?  Are
> there any diagnostics I could run?
>
> Thanks in advance for any help that anyone can offer.
>
> --dan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Dan

I've got the 2200 version of this device and I do not get any error
messages during the load.

Steven Toth wrote the driver and has a status page here...

http://www.steventoth.net/blog/products/hvr-2250/

you may want to contact him directly, keeping in mind he does this out
of love and doesn't get paid for support :) (Although Hauppauge should
pay him something for the amount of work he does on their products
IMHO).

Good Luck

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

>> I have done some searching online, and that's what led me to scan,
>> dvbscan and scte65scan, but none of the suggestions I've found so far
>> seem to help.  Does anyone have any suggestions as to where I can go
>> from here?  Could there be something wrong with the card itself?  Are
>> there any diagnostics I could run?
>>
>> Thanks in advance for any help that anyone can offer.

Dan,

I'm not aware of any digital cable issues currently.

1) Do you have any other tvtuners that can validate your signal is
working correctly? Specifically, for a number of identifiable
frequencies?

2) Is your cable plant standard cable, IRC, or HRC?

3) I suggest you put together a rudamentary $HOME/.azap/channels.conf
and experiment with azap, that works really well for me.

Here's a sample from my development channels.conf:
c112:723000000:QAM_256:288:289:713
c86:597000000:QAM_256:288:289:713

Try this with azap -r c86 or c112, what happens?

- Steve

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

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

> Steven Toth wrote the driver and has a status page here...
>
> http://www.steventoth.net/blog/products/hvr-2250/
>
> you may want to contact him directly, keeping in mind he does this out
> of love and doesn't get paid for support :) (Although Hauppauge should
> pay him something for the amount of work he does on their products
> IMHO).
>
> Good Luck

Kind words, thank you. :)

- Steve

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

Re: Hauppage HVR-2250 Tuning problems

[dan]

Steve,

Thanks for responding.  I created the channels.conf file and ran the
azap command you suggested.  In both cases I get something that looks
like this:

$ azap -r c112
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 723000000 Hz
video pid 0x0120, audio pid 0x0121
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0172 | snr 0172 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |

Does that mean the signal is going in and out?  Any suggestions?

Thanks again.  I really appreciate the work you've done on the driver
for this card, and that you're willing to take the time to help out.

Thanks to Mr. Sillyname, also, for adding another data point.

--dan

On Tue, Oct 27, 2009 at 8:17 AM, Steven Toth <stoth@kernellabs.com> wrote:
>>> I have done some searching online, and that's what led me to scan,
>>> dvbscan and scte65scan, but none of the suggestions I've found so far
>>> seem to help.  Does anyone have any suggestions as to where I can go
>>> from here?  Could there be something wrong with the card itself?  Are
>>> there any diagnostics I could run?
>>>
>>> Thanks in advance for any help that anyone can offer.
>
> Dan,
>
> I'm not aware of any digital cable issues currently.
>
> 1) Do you have any other tvtuners that can validate your signal is
> working correctly? Specifically, for a number of identifiable
> frequencies?
>
> 2) Is your cable plant standard cable, IRC, or HRC?
>
> 3) I suggest you put together a rudamentary $HOME/.azap/channels.conf
> and experiment with azap, that works really well for me.
>
> Here's a sample from my development channels.conf:
> c112:723000000:QAM_256:288:289:713
> c86:597000000:QAM_256:288:289:713
>
> Try this with azap -r c86 or c112, what happens?
>
> - Steve
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

On Tue, Oct 27, 2009 at 10:55 AM, dan <danwalkeriv@gmail.com> wrote:
> Steve,
>
> Thanks for responding.  I created the channels.conf file and ran the
> azap command you suggested.  In both cases I get something that looks
> like this:
>
> $ azap -r c112
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 723000000 Hz
> video pid 0x0120, audio pid 0x0121
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 0172 | snr 0172 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

Are you amping up or splitting the signal in any way? If so, for test
purposes remove anything that can degrade or improve RF. It looks like
the tuner gets into lock briefly but falls out, implying abnormal RF
conditions. When it locks you have perfect SNR, kind of implying that
the signal may be too strong.

Additionally, for all your testing, repeat the tests on tuner#2 by
azap -a1 -r c112.

Additionally, try channel 83 or edit the conf file and add some lower
channels in the 40-80 range where the RF characteristics would be
wildly different. I'd like to see how the card performs in these
circumstances for you.

Regards,

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

Re: Hauppage HVR-2250 Tuning problems

[dan]

I do have 2 2-way splitters between the card in the wall.  I tried
hooking the card straight to the cable outlet on the wall and ran some
more tests.  It's a little difficult, because there's only one cable
outlet in my whole apartment, and it means doing some re-arranging and
being offline while I'm running the tests.

I'm not sure if there was any change.  Here's the output from azap for
a few channels.  I added one in the 40 range, like you asked, and I
also added another frequency that my TV is able tune, 717000000.

$ azap -r c112
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 723000000 Hz
video pid 0x0120, audio pid 0x0121
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0110 | snr 0113 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0110 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0110 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |

$ azap -r c45
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 417000000 Hz
video pid 0x0120, audio pid 0x0121
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0121 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |

$ azap -r c111
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 717000000 Hz
video pid 0x0120, audio pid 0x0121
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0144 | snr 0148 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0144 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0144 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0144 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0144 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0144 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0148 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 07 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
status 00 | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |

Just in case it's helpful, my TV gives this information about the
channel on that last frequency when connected to the television with
the same cable in the same configuration:
Physical Channel: 111
Frequency: 71700000
SNR: 39
Signal: 100

I tried scanning with scan again, with the card plugged straight into
the wall with this command:

$ scan -f /dev/dvb/adapter0/frontend0 -5
/usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256  >
scan_channels_standard.conf


The 717000000 frequency that tunes fine on my TV gave the following output:
>>> tune to: 717000000:QAM_256
WARNING: filter timeout pid 0x0000
WARNING: filter timeout pid 0x1ffb

The scan program still doesn't find any channels.

I also tried testing the other adapter, like you suggested, but I get
this error:
$ azap -a1 -r c111
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
ERROR: failed opening '/dev/dvb/adapter1/frontend0' (Device or resource busy)

lsof doesn't show anything as using it, so I'm not sure what's going on.

I'm sorry if that's an overload of information.  Thanks again for the help.

--dan

On Tue, Oct 27, 2009 at 10:20 AM, Steven Toth <stoth@kernellabs.com> wrote:
> On Tue, Oct 27, 2009 at 10:55 AM, dan <danwalkeriv@gmail.com> wrote:
>> Steve,
>>
>> Thanks for responding.  I created the channels.conf file and ran the
>> azap command you suggested.  In both cases I get something that looks
>> like this:
>>
>> $ azap -r c112
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>> tuning to 723000000 Hz
>> video pid 0x0120, audio pid 0x0121
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 1f | signal 0172 | snr 0172 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>
> Are you amping up or splitting the signal in any way? If so, for test
> purposes remove anything that can degrade or improve RF. It looks like
> the tuner gets into lock briefly but falls out, implying abnormal RF
> conditions. When it locks you have perfect SNR, kind of implying that
> the signal may be too strong.
>
> Additionally, for all your testing, repeat the tests on tuner#2 by
> azap -a1 -r c112.
>
> Additionally, try channel 83 or edit the conf file and add some lower
> channels in the 40-80 range where the RF characteristics would be
> wildly different. I'd like to see how the card performs in these
> circumstances for you.
>
> Regards,
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
>

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

On Wed, Oct 28, 2009 at 1:44 AM, dan <danwalkeriv@gmail.com> wrote:
> I do have 2 2-way splitters between the card in the wall.  I tried
> hooking the card straight to the cable outlet on the wall and ran some
> more tests.  It's a little difficult, because there's only one cable
> outlet in my whole apartment, and it means doing some re-arranging and
> being offline while I'm running the tests.

Removing splitters proves it's probably not a weak signal issue (also
the SNR or 39 on the TV).  Can you apply some attenuation to reduce
the overall rf strength? I'm thinking it's too hot.

Something must be using your second tuner, mythtv maybe?

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

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth <stoth@kernellabs.com> wrote:
> On Wed, Oct 28, 2009 at 1:44 AM, dan <danwalkeriv@gmail.com> wrote:
>> I do have 2 2-way splitters between the card in the wall.  I tried
>> hooking the card straight to the cable outlet on the wall and ran some
>> more tests.  It's a little difficult, because there's only one cable
>> outlet in my whole apartment, and it means doing some re-arranging and
>> being offline while I'm running the tests.
>
> Removing splitters proves it's probably not a weak signal issue (also
> the SNR or 39 on the TV).  Can you apply some attenuation to reduce
> the overall rf strength? I'm thinking it's too hot.
>
> Something must be using your second tuner, mythtv maybe?

Oh, and please try the card under windows ideally on the same PC using
the same antenna feed, to rule out any card specific issues.

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

Re: Hauppage HVR-2250 Tuning problems

[dan]

Steven,

I tried adding some 2 way splitters for attenuation.  Each one was
-3dB, and I got up to about 5 total, with no change.

I didn't get a chance to try under windows (for various reasons mostly
related to time and lack of a Windows install CD), but I did get some
evidence that it might be the card.  I have a friend at work with the
same card which he has been using without problems for a while now (in
Fedora 10).  He took my card home and swapped it for his working card
and it didn't work.  He said that he got a message saying that the
card couldn't lock and that he could either try waiting longer or try
another channel.  He did both and he still couldn't get a lock.
Unless there is some other reason that you can't just swap two working
HVR-2250s in a working system and have the system still work, I'm
inclined to believe I got a bad one.

--dan


On Wed, Oct 28, 2009 at 8:12 AM, Steven Toth <stoth@kernellabs.com> wrote:
> On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth <stoth@kernellabs.com> wrote:
>> On Wed, Oct 28, 2009 at 1:44 AM, dan <danwalkeriv@gmail.com> wrote:
>>> I do have 2 2-way splitters between the card in the wall.  I tried
>>> hooking the card straight to the cable outlet on the wall and ran some
>>> more tests.  It's a little difficult, because there's only one cable
>>> outlet in my whole apartment, and it means doing some re-arranging and
>>> being offline while I'm running the tests.
>>
>> Removing splitters proves it's probably not a weak signal issue (also
>> the SNR or 39 on the TV).  Can you apply some attenuation to reduce
>> the overall rf strength? I'm thinking it's too hot.
>>
>> Something must be using your second tuner, mythtv maybe?
>
> Oh, and please try the card under windows ideally on the same PC using
> the same antenna feed, to rule out any card specific issues.
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
>

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

On Fri, Oct 30, 2009 at 1:43 PM, dan <danwalkeriv@gmail.com> wrote:
> Steven,
>
> I tried adding some 2 way splitters for attenuation.  Each one was
> -3dB, and I got up to about 5 total, with no change.
>
> I didn't get a chance to try under windows (for various reasons mostly
> related to time and lack of a Windows install CD), but I did get some
> evidence that it might be the card.  I have a friend at work with the
> same card which he has been using without problems for a while now (in
> Fedora 10).  He took my card home and swapped it for his working card
> and it didn't work.  He said that he got a message saying that the
> card couldn't lock and that he could either try waiting longer or try
> another channel.  He did both and he still couldn't get a lock.
> Unless there is some other reason that you can't just swap two working
> HVR-2250s in a working system and have the system still work, I'm
> inclined to believe I got a bad one.
>
> --dan
>
>
> On Wed, Oct 28, 2009 at 8:12 AM, Steven Toth <stoth@kernellabs.com> wrote:
>> On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth <stoth@kernellabs.com> wrote:
>>> On Wed, Oct 28, 2009 at 1:44 AM, dan <danwalkeriv@gmail.com> wrote:
>>>> I do have 2 2-way splitters between the card in the wall.  I tried
>>>> hooking the card straight to the cable outlet on the wall and ran some
>>>> more tests.  It's a little difficult, because there's only one cable
>>>> outlet in my whole apartment, and it means doing some re-arranging and
>>>> being offline while I'm running the tests.
>>>
>>> Removing splitters proves it's probably not a weak signal issue (also
>>> the SNR or 39 on the TV).  Can you apply some attenuation to reduce
>>> the overall rf strength? I'm thinking it's too hot.
>>>
>>> Something must be using your second tuner, mythtv maybe?
>>
>> Oh, and please try the card under windows ideally on the same PC using
>> the same antenna feed, to rule out any card specific issues.
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.com
>>
>

Urgh. It sounds like a card specific problem. Of course, installing
your friends card in your system to completely confirm the suspicion
would be perfect.

Regards,

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

Re: Hauppage HVR-2250 Tuning problems

[dan]

I sort of hinted that I would like to try that and he didn't seem very
excited about the idea.  I think I'll just RMA the card and hope I
have better luck with the replacement.

Thanks again for all your help!

--dan

On Fri, Oct 30, 2009 at 12:09 PM, Steven Toth <stoth@kernellabs.com> wrote:
> On Fri, Oct 30, 2009 at 1:43 PM, dan <danwalkeriv@gmail.com> wrote:
>> Steven,
>>
>> I tried adding some 2 way splitters for attenuation.  Each one was
>> -3dB, and I got up to about 5 total, with no change.
>>
>> I didn't get a chance to try under windows (for various reasons mostly
>> related to time and lack of a Windows install CD), but I did get some
>> evidence that it might be the card.  I have a friend at work with the
>> same card which he has been using without problems for a while now (in
>> Fedora 10).  He took my card home and swapped it for his working card
>> and it didn't work.  He said that he got a message saying that the
>> card couldn't lock and that he could either try waiting longer or try
>> another channel.  He did both and he still couldn't get a lock.
>> Unless there is some other reason that you can't just swap two working
>> HVR-2250s in a working system and have the system still work, I'm
>> inclined to believe I got a bad one.
>>
>> --dan
>>
>>
>> On Wed, Oct 28, 2009 at 8:12 AM, Steven Toth <stoth@kernellabs.com> wrote:
>>> On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth <stoth@kernellabs.com> wrote:
>>>> On Wed, Oct 28, 2009 at 1:44 AM, dan <danwalkeriv@gmail.com> wrote:
>>>>> I do have 2 2-way splitters between the card in the wall.  I tried
>>>>> hooking the card straight to the cable outlet on the wall and ran some
>>>>> more tests.  It's a little difficult, because there's only one cable
>>>>> outlet in my whole apartment, and it means doing some re-arranging and
>>>>> being offline while I'm running the tests.
>>>>
>>>> Removing splitters proves it's probably not a weak signal issue (also
>>>> the SNR or 39 on the TV).  Can you apply some attenuation to reduce
>>>> the overall rf strength? I'm thinking it's too hot.
>>>>
>>>> Something must be using your second tuner, mythtv maybe?
>>>
>>> Oh, and please try the card under windows ideally on the same PC using
>>> the same antenna feed, to rule out any card specific issues.
>>>
>>> --
>>> Steven Toth - Kernel Labs
>>> http://www.kernellabs.com
>>>
>>
>
> Urgh. It sounds like a card specific problem. Of course, installing
> your friends card in your system to completely confirm the suspicion
> would be perfect.
>
> Regards,
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
>

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

On Fri, Oct 30, 2009 at 2:19 PM, dan <danwalkeriv@gmail.com> wrote:
> I sort of hinted that I would like to try that and he didn't seem very
> excited about the idea.  I think I'll just RMA the card and hope I
> have better luck with the replacement.

Fair enough.

> Thanks again for all your help!

You're welcome.

- Steve

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

Re: Hauppage HVR-2250 Tuning problems

[Ross J. Reedstrom]

Steven -
Thanks for all the driver work. Do you want bug reports for the -stable
branch on the list, or both to you and the list? (looked around a bit,
couldn't find a community "how to report a bug")

I've recently installed an HVR-2250 (to replace an HVR-1800 that had
some surface mount component blow a crater out, right near the bus
connector!) in a Mythbuntu box, running mythtv
0.21.0+fixes18207-0ubuntu4~hardy1, kernel 2.6.24-24.61

And have the digital tuning working w/ your stable driver (cloned from
kernellabs on 10/16: I don't know hg well enough to how to report a
specific source set)

It's been working well, until one evening my wife reported that two
shows stopped recording simultaneously. Checking the logs, I see the
occasional pair of i2c errors ( ~ 1 every 12-24 hours):

Oct 23 22:48:04 MediaPC kernel: [679597.153063] saa7164_api_i2c_read() error, ret(2) = 0x13
Oct 23 22:48:04 MediaPC kernel: [679597.153072] tda18271_read_regs: ERROR: i2c_transfer returned: -5

Until about 20 min before it locked up, these show up:
Oct 27 20:22:45 MediaPC kernel: [1015942.952099] Event timed out
Oct 27 20:22:45 MediaPC kernel: [1015942.952107] saa7164_api_i2c_read() error, ret(1) = 0x32
Oct 27 20:22:45 MediaPC kernel: [1015942.952110] s5h1411_readreg: readreg error (ret == -5)

and the occasional:

Oct 27 20:23:06 MediaPC kernel: [1015963.906731] Event timed out
Oct 27 20:23:06 MediaPC kernel: [1015963.906741] saa7164_api_i2c_write() error, ret(1) = 0x32
Oct 27 20:23:06 MediaPC kernel: [1015963.906744] s5h1411_writereg: writereg error 0x19 0xf7 0x0000, ret == -5)

in blocks, one set a second for a few seconds, then a few second gap. 
Note at this point, it's still recording both shows.

There are many, many more read than write errors: 232644 read errors
between 20:22:45 and 20:44:10, 168 write errors.

Finally, this changes to:
Oct 27 20:44:10 MediaPC kernel: [1017225.901272] Event timed out
Oct 27 20:44:10 MediaPC kernel: [1017225.901282] saa7164_api_i2c_read() error, ret(1) = 0x32
Oct 27 20:44:10 MediaPC kernel: [1017225.901286] s5h1411_readreg: readreg error (ret == -5)
Oct 27 20:44:10 MediaPC kernel: [1017225.901301] saa7164_cmd_send() No free sequences
Oct 27 20:44:10 MediaPC kernel: [1017225.901303] saa7164_api_i2c_write() error, ret(1) = 0xc
Oct 27 20:44:10 MediaPC kernel: [1017225.901306] s5h1411_writereg: writereg error 0x19 0xf7 0x0000, ret == -5)

And both recordings lock up.

I rebooted to clear the error,and I'm back to the occasional read error
(~1 a day) Not sure if it's been pushed that hard since (recording off
both tuners simultaneously)

Is this useful info? I've got the whole log, and haven't updated the
code yet. I'm willing to do tests, compile other changesets, etc.

Ross
-- 
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist        phone: 713-348-6166
The Connexions Project      http://cnx.org            fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE

Re: Hauppage HVR-2250 Tuning problems

[Steven Toth]

> Is this useful info? I've got the whole log, and haven't updated the
> code yet. I'm willing to do tests, compile other changesets, etc.

Hi Ross,

Thanks for writing.

Do you have an AMD based system?

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

Re: Hauppage HVR-2250 Tuning problems

[Ross J. Reedstrom]

Nope, Intel:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
stepping        : 11

[...]

Ross

On Fri, Oct 30, 2009 at 03:58:28PM -0400, Steven Toth wrote:
> > Is this useful info? I've got the whole log, and haven't updated the
> > code yet. I'm willing to do tests, compile other changesets, etc.
> 
> Hi Ross,
> 
> Thanks for writing.
> 
> Do you have an AMD based system?
> 
> -- 
> Steven Toth - Kernel Labs
> http://www.kernellabs.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Hauppage HVR-2250 Tuning problems

[Ross J. Reedstrom]

Additional info: 
This system is an HP 'Media Center' m9040n, came with the HVR-1800
mentioned, I also have an pcHDTV-2000 (yes, the original) in there. 
Motherboard is an ASUS IPIBL-LA, w/ an nVidia GeForce 8400GS.

Ross
MB specs at:

http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01077641&tmp_track_link=ot_recdoc/c01154933/en_us/c01077641/loc:1&lc=en&dlc=en&cc=us


On Fri, Oct 30, 2009 at 03:09:22PM -0500, Ross J. Reedstrom wrote:
> Nope, Intel:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
> stepping        : 11
> 
> [...]
> 
> Ross
> 
> On Fri, Oct 30, 2009 at 03:58:28PM -0400, Steven Toth wrote:
> > > Is this useful info? I've got the whole log, and haven't updated the
> > > code yet. I'm willing to do tests, compile other changesets, etc.
> > 
> > Hi Ross,
> > 
> > Thanks for writing.
> > 
> > Do you have an AMD based system?
> > 
> > -- 
> > Steven Toth - Kernel Labs
> > http://www.kernellabs.com
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>