Mailing List Archive

> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Mon, 15 Feb 2010 19:14:00 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Mon, 2010-02-15 at 16:22 -0500, Kyle Lil wrote:
>
> > Previously I'd had the tuner connected at the end of additional
> > splitters and devices, but I shortened the chain in troubleshooting.
> > I'll try attenuating the signal again to see if that helps. I hadn't
> > consider the possibility that the cable signal might exceed the
> > devices input limits.
>
> Actually, I've just verified that my antenna and preamp is overdriving
> my HVR-1600 for two digital TV stations. I could verify independently
> with my Sony TV, which provides SNR, signal, and Error readouts of the
> same channels. For me, WJLA and WUSA over the air are *really* strong
> according to the TV, but my MythTV recordings show errors. Here's the
> output of femon while MythTV is showing WUSA:
>
> status 1f | signal 011d | snr 011d | ber 000001c9 | unc 000001c9 | FE_HAS_LOCK
> status 1f | signal 011d | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 0000006a | unc 0000006a | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 000007f3 | unc 000007f3 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0113 | snr 0118 | ber 00000836 | unc 00000836 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>
> SNR is great, but I get errors every once in a while.
>
> The pattern looks really similar to what you reported from azap.
>
> My problem is subject to weather variations for me, so it doesn't happen
> all the time. However, clear, cold winter nights seem to lead to the
> most problems recording these station with my HVR-1600. (I could turn
> down my amp, but since WETA, a really good station, is a really weak
> signal for me, I probably won't.)
>
>
> I think you'll just need to attenuate your cable signal before it hits
> the HVR-1600.
>
> Regards,
> Andy
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

I built a -10dB attenuator as you described in your link (thanks for that) and still saw the glitches. In fact, I see them whether I connect the cable line straight from the wall into the HVR-1600 or through two splitters and the attenuator (and every other combination). In trying to get a better sense of what's happening to the signal, I went into the service menu of my cable box, a Motorola DCH-3200, which lists various signal statistics. One of the parameters it lists is "AGC", which I'm guessing is some sort of automatic gain control that puts the signal into the optimal range for the tuner. If the cable box is connected after the second splitter, AGC is 18%. If it's connected to the first splitter, it's a few percent lower. If I add the attenuator, the AGC goes up another 5%. It makes sense to me that the attenuator would cause the AGC value to go up, but I'm sure why it only went up 5% with a -10dB attenuator.
Does the HVR-1600 have similar AGC built in? If the cable box cuts the signal to less than 1/5th of its amplitude (even after two splitters), maybe this is an indication that I need to build an even stronger attenuator? Do you have any insight into what value attenuator I should be shooting for?
Kyle

_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/

> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Mon, 15 Feb 2010 19:14:00 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Mon, 2010-02-15 at 16:22 -0500, Kyle Lil wrote:
>
> > Previously I'd had the tuner connected at the end of additional
> > splitters and devices, but I shortened the chain in troubleshooting.
> > I'll try attenuating the signal again to see if that helps. I hadn't
> > consider the possibility that the cable signal might exceed the
> > devices input limits.
>
> Actually, I've just verified that my antenna and preamp is overdriving
> my HVR-1600 for two digital TV stations. I could verify independently
> with my Sony TV, which provides SNR, signal, and Error readouts of the
> same channels. For me, WJLA and WUSA over the air are *really* strong
> according to the TV, but my MythTV recordings show errors. Here's the
> output of femon while MythTV is showing WUSA:
>
> status 1f | signal 011d | snr 011d | ber 000001c9 | unc 000001c9 | FE_HAS_LOCK
> status 1f | signal 011d | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 0000006a | unc 0000006a | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 000007f3 | unc 000007f3 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0113 | snr 0118 | ber 00000836 | unc 00000836 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>
> SNR is great, but I get errors every once in a while.
>
> The pattern looks really similar to what you reported from azap.
>
> My problem is subject to weather variations for me, so it doesn't happen
> all the time. However, clear, cold winter nights seem to lead to the
> most problems recording these station with my HVR-1600. (I could turn
> down my amp, but since WETA, a really good station, is a really weak
> signal for me, I probably won't.)
>
>
> I think you'll just need to attenuate your cable signal before it hits
> the HVR-1600.
>
> Regards,
> Andy
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


p.s. The AGC values I mentioned were for the Out Of Band data stream. For some reason, my cable box does not list the In-band AGC value. It only gives the SNR, which is ~35dB, comparable to what the HVR-1600 reports. By comparison, the OOB SNR was ~21dB.





_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/

On Wed, 2010-02-17 at 08:46 -0500, Kyle Lil wrote:
>
>
> > From: awalls@radix.net
> > To: ivtv-users@ivtvdriver.org
> > Date: Mon, 15 Feb 2010 19:14:00 -0500
> > Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete
> frame
> >
> > On Mon, 2010-02-15 at 16:22 -0500, Kyle Lil wrote:
> >
> > > Previously I'd had the tuner connected at the end of additional
> > > splitters and devices, but I shortened the chain in
> troubleshooting.
> > > I'll try attenuating the signal again to see if that helps. I
> hadn't
> > > consider the possibility that the cable signal might exceed the
> > > devices input limits.

> > I think you'll just need to attenuate your cable signal before it
> hits
> > the HVR-1600.
> >

>
>
> I built a -10dB attenuator as you described in your link (thanks for
> that) and still saw the glitches. In fact, I see them whether I
> connect the cable line straight from the wall into the HVR-1600 or
> through two splitters and the attenuator (and every other
> combination). In trying to get a better sense of what's happening to
> the signal,

My hypothesis is the HVR-1600 digital tuner and demodulator AGC circuits
cannot attenuate the signal enough to avoid occasional clipping of the
analog signal. The clips show up as uncorrectable blocks.



> I went into the service menu of my cable box, a Motorola DCH-3200,
> which lists various signal statistics. One of the parameters it lists
> is "AGC", which I'm guessing is some sort of automatic gain control
> that puts the signal into the optimal range for the tuner.

Yes.


> If the cable box is connected after the second splitter, AGC is 18%.
> If it's connected to the first splitter, it's a few percent lower.

18% is on the low side for an AGC to be operating. That indicates that
you have a strong signal.


> If I add the attenuator, the AGC goes up another 5%. It makes sense
> to me that the attenuator would cause the AGC value to go up, but I'm
> sure why it only went up 5% with a -10dB attenuator.

Well, without knowing 5% of "what" (AGC full scale voltage?), it doesn't
really matter as long as your attenuator appears to be attenuating the
signal.

>
> Does the HVR-1600 have similar AGC built in?

Yes, there should be two: an AGC in the MXL5005s and an AGC in the
CX24227. The MXL5005s will be used for AGC until the AGC Take Over
Point (TOP) setting in the CX24227 is reached, and then the CX24227 will
take over with it's AGC.

The idea is to amplify very weak signals as best you can while getting
the best possible Noise Figure with the MXL5005s; or if the signal is
strong enough, use the CX24227 AGC to get maximum signal while avoiding
clipping.


In my hypothesis, the "glitches" are caused by occasional clipping of
the analog signal in either the MXL5005s or the CX24227.


> If the cable box cuts the signal to less than 1/5th of its amplitude
> (even after two splitters),

No, that's likely 5% of AGC full scale. You don't have enough details
to know what AGC percentage level corresponds to what gain and if it is
expressed as a percantage for linear units or logarithmic (dB) units.

FYI: -14 dB is 1/5 of signal amplitude, -7 dB is 1/5 of signal power.
A 1-to-2 splitter will drop your signal power by more than 3 dB.


> maybe this is an indication that I need to build an even stronger
> attenuator? Do you have any insight into what value attenuator I
> should be shooting for?

Attenuate by 20, 30, or 40 dB I guess. You'll find one or more of:

a. The glitches stop. (Good attenuation value to use.)
b. The signal is so weak you can't lock the stations anymore. (Too much
attenuation)
c. My hypothesis is wrong. :P


As an experiment, I can look at trying to adjust the CX24227's AGC TOP
to kick in earlier, at a much lower threshold, in an attempt to prevent
the MXL5005s from trying to do any amplification at all. However, a
series of tests with external (cheap home-made) attenuators would be
more deterministic in terms of experimental results. The experimental
trials are bounded by an attenuator value so large that the signal
cannot be tuned anymore.

Regards,
Andy



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

> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Wed, 17 Feb 2010 19:35:57 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Wed, 2010-02-17 at 08:46 -0500, Kyle Lil wrote:
> >
> >
> > > From: awalls@radix.net
> > > To: ivtv-users@ivtvdriver.org
> > > Date: Mon, 15 Feb 2010 19:14:00 -0500
> > > Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete
> > frame
> > >
> > > On Mon, 2010-02-15 at 16:22 -0500, Kyle Lil wrote:
> > >
> > > > Previously I'd had the tuner connected at the end of additional
> > > > splitters and devices, but I shortened the chain in
> > troubleshooting.
> > > > I'll try attenuating the signal again to see if that helps. I
> > hadn't
> > > > consider the possibility that the cable signal might exceed the
> > > > devices input limits.
>
> > > I think you'll just need to attenuate your cable signal before it
> > hits
> > > the HVR-1600.
> > >
>
> >
> >
> > I built a -10dB attenuator as you described in your link (thanks for
> > that) and still saw the glitches. In fact, I see them whether I
> > connect the cable line straight from the wall into the HVR-1600 or
> > through two splitters and the attenuator (and every other
> > combination). In trying to get a better sense of what's happening to
> > the signal,
>
> My hypothesis is the HVR-1600 digital tuner and demodulator AGC circuits
> cannot attenuate the signal enough to avoid occasional clipping of the
> analog signal. The clips show up as uncorrectable blocks.
>
>
>
> > I went into the service menu of my cable box, a Motorola DCH-3200,
> > which lists various signal statistics. One of the parameters it lists
> > is "AGC", which I'm guessing is some sort of automatic gain control
> > that puts the signal into the optimal range for the tuner.
>
> Yes.
>
>
> > If the cable box is connected after the second splitter, AGC is 18%.
> > If it's connected to the first splitter, it's a few percent lower.
>
> 18% is on the low side for an AGC to be operating. That indicates that
> you have a strong signal.
>
>
> > If I add the attenuator, the AGC goes up another 5%. It makes sense
> > to me that the attenuator would cause the AGC value to go up, but I'm
> > sure why it only went up 5% with a -10dB attenuator.
>
> Well, without knowing 5% of "what" (AGC full scale voltage?), it doesn't
> really matter as long as your attenuator appears to be attenuating the
> signal.
>
> >
> > Does the HVR-1600 have similar AGC built in?
>
> Yes, there should be two: an AGC in the MXL5005s and an AGC in the
> CX24227. The MXL5005s will be used for AGC until the AGC Take Over
> Point (TOP) setting in the CX24227 is reached, and then the CX24227 will
> take over with it's AGC.
>
> The idea is to amplify very weak signals as best you can while getting
> the best possible Noise Figure with the MXL5005s; or if the signal is
> strong enough, use the CX24227 AGC to get maximum signal while avoiding
> clipping.
>
>
> In my hypothesis, the "glitches" are caused by occasional clipping of
> the analog signal in either the MXL5005s or the CX24227.
>
>
> > If the cable box cuts the signal to less than 1/5th of its amplitude
> > (even after two splitters),
>
> No, that's likely 5% of AGC full scale. You don't have enough details
> to know what AGC percentage level corresponds to what gain and if it is
> expressed as a percantage for linear units or logarithmic (dB) units.
>
> FYI: -14 dB is 1/5 of signal amplitude, -7 dB is 1/5 of signal power.
> A 1-to-2 splitter will drop your signal power by more than 3 dB.
>
>
> > maybe this is an indication that I need to build an even stronger
> > attenuator? Do you have any insight into what value attenuator I
> > should be shooting for?
>
> Attenuate by 20, 30, or 40 dB I guess. You'll find one or more of:
>
> a. The glitches stop. (Good attenuation value to use.)
> b. The signal is so weak you can't lock the stations anymore. (Too much
> attenuation)
> c. My hypothesis is wrong. :P
>
>
> As an experiment, I can look at trying to adjust the CX24227's AGC TOP
> to kick in earlier, at a much lower threshold, in an attempt to prevent
> the MXL5005s from trying to do any amplification at all. However, a
> series of tests with external (cheap home-made) attenuators would be
> more deterministic in terms of experimental results. The experimental
> trials are bounded by an attenuator value so large that the signal
> cannot be tuned anymore.
>
> Regards,
> Andy
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

OK, so I built an attenuator with a potentiometer in position Z2 for the circuit diagram you sent me. I'm sure there are probably a whole slew of problems this could introduce (especially since I did not put a pot in position Z1 also), but I wanted to be able to easily look at the various attenuation levels (and I don't have a soldering iron at home, just at work). What I found was that the glitches are still apparent even when I turn the potentiometer to a level that make my cable box OOB AGC go to >30% (which it now rates as "fair" instead of "good"). The cable box and HVR-1600 are at the output of the same splitter, which is after (downstream of) the adjustable attenuator I built. The way I constructed the circuit, I could not provide enough attenuation to cause the tuner to lose station lock, but with the maximum attenuation (~-14dB from attenuator + -6dB from the two splitters between the HVR-1600 and the wall) I could achieve, the glitch rate was the same (or maybe slightly higher).

I will try to build an attenuator today that is able to reduce the signal all the way down to an un-lockable level. Is it possible that the HVR-1600 is so sensitive that a signal level my cable box rates as only fair is still too large for it?

Many thanks,
Kyle


_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/

On Thu, 2010-02-18 at 10:33 -0500, Kyle Lil wrote:
>
>

> OK, so I built an attenuator with a potentiometer in position Z2 for
> the circuit diagram you sent me. I'm sure there are probably a whole
> slew of problems this could introduce (especially since I did not put
> a pot in position Z1 also), but I wanted to be able to easily look at
> the various attenuation levels (and I don't have a soldering iron at
> home, just at work). What I found was that the glitches are still
> apparent even when I turn the potentiometer to a level that make my
> cable box OOB AGC go to >30% (which it now rates as "fair" instead of
> "good"). The cable box and HVR-1600 are at the output of the same
> splitter, which is after (downstream of) the adjustable attenuator I
> built. The way I constructed the circuit, I could not provide enough
> attenuation to cause the tuner to lose station lock, but with the
> maximum attenuation (~-14dB from attenuator + -6dB from the two
> splitters between the HVR-1600 and the wall) I could achieve, the
> glitch rate was the same (or maybe slightly higher).

Hmmm. Crud, io suspect there must be something else going on.

My next guess is that the HVR-1600's AGC is responding too quickly (or
too slowly?) to variations in the incoming signal.

I'll have to think about it though.

Since I have a somewhat similar condition on two ATSC stations, I'll
work up a debug patch for the s5h1409 driver that reports some more
stats from the CX24227. I have never used the additional statistics
registers before and I don't have much faith in the documentation I
have, so I'm not sure if they work or will be useful. We'll see. I
won't be able to do anything until Saturday night at the earliest.



>
>
> I will try to build an attenuator today that is able to reduce the
> signal all the way down to an un-lockable level. Is it possible that
> the HVR-1600 is so sensitive that a signal level my cable box rates as
> only fair is still too large for it?

I would doubt it, but it still could be the case.

I think if we can get more stats from the CX24227 chip, we may get more
insight as to what might be wrong.

Regards,
Andy




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

> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Thu, 18 Feb 2010 19:28:58 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Thu, 2010-02-18 at 10:33 -0500, Kyle Lil wrote:
> >
> >
>
> > OK, so I built an attenuator with a potentiometer in position Z2 for
> > the circuit diagram you sent me. I'm sure there are probably a whole
> > slew of problems this could introduce (especially since I did not put
> > a pot in position Z1 also), but I wanted to be able to easily look at
> > the various attenuation levels (and I don't have a soldering iron at
> > home, just at work). What I found was that the glitches are still
> > apparent even when I turn the potentiometer to a level that make my
> > cable box OOB AGC go to >30% (which it now rates as "fair" instead of
> > "good"). The cable box and HVR-1600 are at the output of the same
> > splitter, which is after (downstream of) the adjustable attenuator I
> > built. The way I constructed the circuit, I could not provide enough
> > attenuation to cause the tuner to lose station lock, but with the
> > maximum attenuation (~-14dB from attenuator + -6dB from the two
> > splitters between the HVR-1600 and the wall) I could achieve, the
> > glitch rate was the same (or maybe slightly higher).
>
> Hmmm. Crud, io suspect there must be something else going on.
>
> My next guess is that the HVR-1600's AGC is responding too quickly (or
> too slowly?) to variations in the incoming signal.
>
> I'll have to think about it though.
>
> Since I have a somewhat similar condition on two ATSC stations, I'll
> work up a debug patch for the s5h1409 driver that reports some more
> stats from the CX24227. I have never used the additional statistics
> registers before and I don't have much faith in the documentation I
> have, so I'm not sure if they work or will be useful. We'll see. I
> won't be able to do anything until Saturday night at the earliest.
>
>
>
> >
> >
> > I will try to build an attenuator today that is able to reduce the
> > signal all the way down to an un-lockable level. Is it possible that
> > the HVR-1600 is so sensitive that a signal level my cable box rates as
> > only fair is still too large for it?
>
> I would doubt it, but it still could be the case.
>
> I think if we can get more stats from the CX24227 chip, we may get more
> insight as to what might be wrong.
>
> Regards,
> Andy
>
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

That sounds great, Andy. Thanks so much for spending the time to get to the bottom of this.

I built the more powerful attenuator and essentially what I see is that the error rate increases dramatically as the gain approaches zero.

Please let me know if you are able to get the CX24227 to report more statistics and have some tests you'd like me to run on my end.

Kyle




_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/

> Windows might be able to better render smoothly through the errors.
> BTW, what does the Windows utility form Hauppauge show for signal
> strength? (I haven't used it, I just heard that Hauppauge provides one
> with its osftware.)

Hi Andy,

I just realized I never answered this question you asked a while back...

The Windows utility gives a signal strength in the neighborhood of 32.5, which correlates well with what azap reports. It also has indicators for both corrected errors and uncorrectable errors. I can't find a log file that it stores this data to, but sitting and staring at the indicators I see occasional corrected errors, but I see no uncorrectable errors. The error correction referred to here is done in hardware, correct?

Best regards,
Kyle

_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/

On Thu, Mar 4, 2010 at 5:06 PM, Kyle Lil <kpl388@msn.com> wrote:
> The Windows utility gives a signal strength in the neighborhood of 32.5,
> which correlates well with what azap reports. It also has indicators for
> both corrected errors and uncorrectable errors. I can't find a log file that
> it stores this data to, but sitting and staring at the indicators I see
> occasional corrected errors, but I see no uncorrectable errors. The error
> correction referred to here is done in hardware, correct?

Yes, those counters are for hardware based correction.

Also, bear in mind that the azap results will not match exactly the
same as the Windows driver, due to some minor differences in the way
the calculation is performed (the quality is the same, the differences
are in the reporting).

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

> Date: Thu, 4 Mar 2010 17:18:33 -0500
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Thu, Mar 4, 2010 at 5:06 PM, Kyle Lil <kpl388@msn.com> wrote:
> > The Windows utility gives a signal strength in the neighborhood of 32.5,
> > which correlates well with what azap reports. It also has indicators for
> > both corrected errors and uncorrectable errors. I can't find a log file that
> > it stores this data to, but sitting and staring at the indicators I see
> > occasional corrected errors, but I see no uncorrectable errors. The error
> > correction referred to here is done in hardware, correct?
>
> Yes, those counters are for hardware based correction.
>
> Also, bear in mind that the azap results will not match exactly the
> same as the Windows driver, due to some minor differences in the way
> the calculation is performed (the quality is the same, the differences
> are in the reporting).
>
> 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

Thanks, Devin. Using the conversion factor you previously gave me for azap output to decibels, it looks like the Windows utility is reporting the same SNR. I'm trying to figure out if the glitches I'm seeing while watching video in Linux (but not in Windows) are caused by differences in the HVR-1600 driver or if the Windows codecs are particularly good at dealing with errors. Based on what the Windows utility is reporting, it seems that there are actually fewer uncorrectable errors at the tuner, which (I think) points to a difference in the drivers...



_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/

On Thu, Mar 4, 2010 at 7:11 PM, Kyle Lil <kpl388@msn.com> wrote:
> Thanks, Devin. Using the conversion factor you previously gave me for azap
> output to decibels, it looks like the Windows utility is reporting the same
> SNR. I'm trying to figure out if the glitches I'm seeing while watching
> video in Linux (but not in Windows) are caused by differences in the
> HVR-1600 driver or if the Windows codecs are particularly good at dealing
> with errors. Based on what the Windows utility is reporting, it seems that
> there are actually fewer uncorrectable errors at the tuner, which (I think)
> points to a difference in the drivers...

The SNR count should be *about* the same +/- 0.2 dB.

Is this ATSC or ClearQAM?

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

> Date: Thu, 4 Mar 2010 19:16:37 -0500
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Thu, Mar 4, 2010 at 7:11 PM, Kyle Lil <kpl388@msn.com> wrote:
> > Thanks, Devin. Using the conversion factor you previously gave me for azap
> > output to decibels, it looks like the Windows utility is reporting the same
> > SNR. I'm trying to figure out if the glitches I'm seeing while watching
> > video in Linux (but not in Windows) are caused by differences in the
> > HVR-1600 driver or if the Windows codecs are particularly good at dealing
> > with errors. Based on what the Windows utility is reporting, it seems that
> > there are actually fewer uncorrectable errors at the tuner, which (I think)
> > points to a difference in the drivers...
>
> The SNR count should be *about* the same +/- 0.2 dB.
>
> Is this ATSC or ClearQAM?
>
> 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

Hmm... the SNR is between 0x145 and 0x146, or 32.5-32.6dB, as measured by azap, and between 32.7 and 32.9 as measured by the Hauppauge Windows utility. The source is ClearQAM.

Kyle



_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/

> Date: Thu, 4 Mar 2010 19:16:37 -0500
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Thu, Mar 4, 2010 at 7:11 PM, Kyle Lil <kpl388@msn.com> wrote:
> > Thanks, Devin. Using the conversion factor you previously gave me for azap
> > output to decibels, it looks like the Windows utility is reporting the same
> > SNR. I'm trying to figure out if the glitches I'm seeing while watching
> > video in Linux (but not in Windows) are caused by differences in the
> > HVR-1600 driver or if the Windows codecs are particularly good at dealing
> > with errors. Based on what the Windows utility is reporting, it seems that
> > there are actually fewer uncorrectable errors at the tuner, which (I think)
> > points to a difference in the drivers...
>
> The SNR count should be *about* the same +/- 0.2 dB.
>
> Is this ATSC or ClearQAM?
>
> 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

I just wanted to give a quick update in case anyone else is experiencing the same problem as me. I was able to reduce my glitch rate from about 2 per minute to approximately one every twenty minutes by changing the .qam_gain parameter in cx18_dvb.c from 0x02 to 0x01. Does anyone know what this does physically? Does this offer any insight as to what could be done to eliminate the remaining errors?

Best,
Kyle







_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_2

On Tue, Mar 16, 2010 at 1:45 PM, Kyle Lil <kpl388@msn.com> wrote:
> I just wanted to give a quick update in case anyone else is experiencing the
> same problem as me. I was able to reduce my glitch rate from about 2 per
> minute to approximately one every twenty minutes by changing the .qam_gain
> parameter in cx18_dvb.c from 0x02 to 0x01. Does anyone know what this does
> physically? Does this offer any insight as to what could be done to
> eliminate the remaining errors?
>
> Best,
> Kyle

Yeah, the mxl5005s has a pretty messy RF profile with regards to
finding the optimal tuning conditions that work properly for both
strong and weak signals. It's not too surprising to find that
adjusting the gain could yield different results.

Can you please provide the SNR data for the both values of the
qam_gain (so I can see if you've got a strong signal or a weak one?).
In other words, do an azap, save the results, then change the qam_gain
and do another azap and save the results.

Thanks,

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

> Date: Tue, 16 Mar 2010 14:12:36 -0400
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Tue, Mar 16, 2010 at 1:45 PM, Kyle Lil <kpl388@msn.com> wrote:
> > I just wanted to give a quick update in case anyone else is experiencing the
> > same problem as me. I was able to reduce my glitch rate from about 2 per
> > minute to approximately one every twenty minutes by changing the .qam_gain
> > parameter in cx18_dvb.c from 0x02 to 0x01. Does anyone know what this does
> > physically? Does this offer any insight as to what could be done to
> > eliminate the remaining errors?
> >
> > Best,
> > Kyle
>
> Yeah, the mxl5005s has a pretty messy RF profile with regards to
> finding the optimal tuning conditions that work properly for both
> strong and weak signals. It's not too surprising to find that
> adjusting the gain could yield different results.
>
> Can you please provide the SNR data for the both values of the
> qam_gain (so I can see if you've got a strong signal or a weak one?).
> In other words, do an azap, save the results, then change the qam_gain
> and do another azap and save the results.
>
> Thanks,
>
> 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

With cables/splitter arranged in a configuration to give the HVR-1600 a stronger signal I see an improvement in SNR from ~0x146 to ~0x14a when I change qam_gain from 0x02 to 0x01. Rearranging connections to provide the HVR-1600 a weaker signal, I see a similar improvement from 0x13c to 0x140 when changing from 0x02 to 0x01. In both cases the SNR appears stable, never changing by more that 0x002.






_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_3

On Tue, Mar 16, 2010 at 2:46 PM, Kyle Lil <kpl388@msn.com> wrote:
> With cables/splitter arranged in a configuration to give the HVR-1600 a
> stronger signal I see an improvement in SNR from ~0x146 to ~0x14a when I
> change qam_gain from 0x02 to 0x01. Rearranging connections to provide the
> HVR-1600 a weaker signal, I see a similar improvement from 0x13c to 0x140
> when changing from 0x02 to 0x01. In both cases the SNR appears stable, never
> changing by more that 0x002.

That's good info, but is the error rate consistent on both a strong
and weak signal?

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

> Date: Tue, 16 Mar 2010 15:49:54 -0400
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Tue, Mar 16, 2010 at 2:46 PM, Kyle Lil <kpl388@msn.com> wrote:
> > With cables/splitter arranged in a configuration to give the HVR-1600 a
> > stronger signal I see an improvement in SNR from ~0x146 to ~0x14a when I
> > change qam_gain from 0x02 to 0x01. Rearranging connections to provide the
> > HVR-1600 a weaker signal, I see a similar improvement from 0x13c to 0x140
> > when changing from 0x02 to 0x01. In both cases the SNR appears stable, never
> > changing by more that 0x002.
>
> That's good info, but is the error rate consistent on both a strong
> and weak signal?
>
> 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

Interesting. It looks like the error rate is ~1 per 25 minutes with qam_gain set to 0x01 and the weak SNR (0x140). With the qam_gain set to 0x02 and the weak SNR (0x13c), the error rate is back to ~2 per minute. So it seems that the error rate is more related to the qam_gain setting than the SNR. I was actually just taking a shot in the dark by changing this parameter. Could you tell me what it actually does? Is this related to AGC gain somehow?





_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/210850552/direct/01/

On Tue, Mar 16, 2010 at 4:22 PM, Kyle Lil <kpl388@msn.com> wrote:
> Interesting. It looks like the error rate is ~1 per 25 minutes with qam_gain
> set to 0x01 and the weak SNR (0x140). With the qam_gain set to 0x02 and the
> weak SNR (0x13c), the error rate is back to ~2 per minute.

Ok, so you described the behavior with the weak SNR. What about with
the strong SNR?

> So it seems that the error rate is more related to the qam_gain setting than the SNR.

Without knowing the behavior with a strong SNR, I cannot confirm or
argue against this conclusion. It's possible that you will see the
opposite behavior with a strong SNR (where you get fewer errors with
the gain set to 0x02).

> I was
> actually just taking a shot in the dark by changing this parameter. Could
> you tell me what it actually does? Is this related to AGC gain somehow?

Not without both of us having a degree in applied signal theory. :-)

It's a tuning value for controlling the gain when in QAM mode. On the
mxl5005s it is typically set based on the selected target frequency.
However, because of the combination of the mxl5005s and the s5h1409 as
well as some nuance of the PCB layout of the HVR-1600, it's always
hard-coded to 0x02. Basically, by hard-coding the setting to 0x02
(instead of making it frequency dependent as per the mxl5005s
datasheet), we duplicate the behavior in the Windows driver (the
engineers at Hauppauge arrived at that conclusion after using
equipment significantly more expensive than what's in my budget).

I keep asking about the error rate and effects of changing the gain
relative to the SNR because I'm wondering whether there is some
optimization I can put in there where I base programming of the the
gain level on the final SNR.

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

On Tue, 2010-03-16 at 13:45 -0400, Kyle Lil wrote:
>
>
> > Date: Thu, 4 Mar 2010 19:16:37 -0500
> > From: dheitmueller@kernellabs.com
> > To: ivtv-users@ivtvdriver.org
> > Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete
> frame
> >
> > On Thu, Mar 4, 2010 at 7:11 PM, Kyle Lil <kpl388@msn.com> wrote:
> > > Thanks, Devin. Using the conversion factor you previously gave me
> for azap
> > > output to decibels, it looks like the Windows utility is reporting
> the same
> > > SNR. I'm trying to figure out if the glitches I'm seeing while
> watching
> > > video in Linux (but not in Windows) are caused by differences in
> the
> > > HVR-1600 driver or if the Windows codecs are particularly good at
> dealing
> > > with errors. Based on what the Windows utility is reporting, it
> seems that
> > > there are actually fewer uncorrectable errors at the tuner, which
> (I think)
> > > points to a difference in the drivers...
> >
> > The SNR count should be *about* the same +/- 0.2 dB.
> >
> > Is this ATSC or ClearQAM?
> >
> > 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
>
> I just wanted to give a quick update in case anyone else is
> experiencing the same problem as me. I was able to reduce my glitch
> rate

I have a quick data point on my ATSC/8-VSB uncorrectable error reports
on strong stations.

I found my wife had disconnected an antenna cable feeding a STB and VCR
in the basement. Once I fixed the termination of this cable, my rate of
glitches on very strong OTA stations decreased greatly: from an unc
error every ~30 seconds to an unc error report every 3 to 5 minutes.

Errors now seem to occur most near SNR variations:

status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 0000004d | unc 0000004d | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
...
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0127 | snr 0127 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 0122 | ber 0000002e | unc 0000002e | FE_HAS_LOCK
status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000035 | unc 00000035 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK

which seems reasonable to me for an AGC adjusting to OTA signal
variations.



I suspect, in my case, strong reflections, due to a strong signal and a
cabling impedance mismatch, was contributing to my problem.

I don't know what control you have over the cabling in your building,
but you might want to investigate if there are unterminated cable runs
or unused wall plates that are downstream from the amplifier or
demarcation point that serves your cable drop.

Regards,
Andy


> from about 2 per minute to approximately one every twenty minutes by
> changing the .qam_gain parameter in cx18_dvb.c from 0x02 to 0x01. Does
> anyone know what this does physically? Does this offer any insight as
> to what could be done to eliminate the remaining errors?
>
> Best,
> Kyle



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

> Date: Tue, 16 Mar 2010 16:54:34 -0400
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Tue, Mar 16, 2010 at 4:22 PM, Kyle Lil <kpl388@msn.com> wrote:
> > Interesting. It looks like the error rate is ~1 per 25 minutes with qam_gain
> > set to 0x01 and the weak SNR (0x140). With the qam_gain set to 0x02 and the
> > weak SNR (0x13c), the error rate is back to ~2 per minute.
>
> Ok, so you described the behavior with the weak SNR. What about with
> the strong SNR?
>
> > So it seems that the error rate is more related to the qam_gain setting than the SNR.
>
> Without knowing the behavior with a strong SNR, I cannot confirm or
> argue against this conclusion. It's possible that you will see the
> opposite behavior with a strong SNR (where you get fewer errors with
> the gain set to 0x02).
>
> > I was
> > actually just taking a shot in the dark by changing this parameter. Could
> > you tell me what it actually does? Is this related to AGC gain somehow?
>
> Not without both of us having a degree in applied signal theory. :-)
>
> It's a tuning value for controlling the gain when in QAM mode. On the
> mxl5005s it is typically set based on the selected target frequency.
> However, because of the combination of the mxl5005s and the s5h1409 as
> well as some nuance of the PCB layout of the HVR-1600, it's always
> hard-coded to 0x02. Basically, by hard-coding the setting to 0x02
> (instead of making it frequency dependent as per the mxl5005s
> datasheet), we duplicate the behavior in the Windows driver (the
> engineers at Hauppauge arrived at that conclusion after using
> equipment significantly more expensive than what's in my budget).
>
> I keep asking about the error rate and effects of changing the gain
> relative to the SNR because I'm wondering whether there is some
> optimization I can put in there where I base programming of the the
> gain level on the final SNR.
>
> 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


OK for me, the stronger signal gives a similar result to the weak signal. If anything, the improvement in SNR appears to be a bit greater. With qam_gain set to 0x02, the SNR is 0x140 and the error rate is about 1 error every 30 seconds. With qam_gain set to 0x01, the SNR is 0x146, and the error rate is approximately 1 every 25 minutes.

It's interesting to learn that the Windows driver hard codes this value to 0x02 since I get no noticeable errors in Windows. It's also interesting that the qam_gain should, in theory be set to a different value for different frequencies. Up to this point, I've been using one channel for all my tests. I'll try different channels to see if there are any for which qam_gain=0x02 works better.






_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/210850552/direct/01/

> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Tue, 16 Mar 2010 19:13:48 -0400
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Tue, 2010-03-16 at 13:45 -0400, Kyle Lil wrote:
> >
> >
> > > Date: Thu, 4 Mar 2010 19:16:37 -0500
> > > From: dheitmueller@kernellabs.com
> > > To: ivtv-users@ivtvdriver.org
> > > Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete
> > frame
> > >
> > > On Thu, Mar 4, 2010 at 7:11 PM, Kyle Lil <kpl388@msn.com> wrote:
> > > > Thanks, Devin. Using the conversion factor you previously gave me
> > for azap
> > > > output to decibels, it looks like the Windows utility is reporting
> > the same
> > > > SNR. I'm trying to figure out if the glitches I'm seeing while
> > watching
> > > > video in Linux (but not in Windows) are caused by differences in
> > the
> > > > HVR-1600 driver or if the Windows codecs are particularly good at
> > dealing
> > > > with errors. Based on what the Windows utility is reporting, it
> > seems that
> > > > there are actually fewer uncorrectable errors at the tuner, which
> > (I think)
> > > > points to a difference in the drivers...
> > >
> > > The SNR count should be *about* the same +/- 0.2 dB.
> > >
> > > Is this ATSC or ClearQAM?
> > >
> > > 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
> >
> > I just wanted to give a quick update in case anyone else is
> > experiencing the same problem as me. I was able to reduce my glitch
> > rate
>
> I have a quick data point on my ATSC/8-VSB uncorrectable error reports
> on strong stations.
>
> I found my wife had disconnected an antenna cable feeding a STB and VCR
> in the basement. Once I fixed the termination of this cable, my rate of
> glitches on very strong OTA stations decreased greatly: from an unc
> error every ~30 seconds to an unc error report every 3 to 5 minutes.
>
> Errors now seem to occur most near SNR variations:
>
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0118 | snr 0118 | ber 0000004d | unc 0000004d | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> ...
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0127 | snr 0127 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 0122 | ber 0000002e | unc 0000002e | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000035 | unc 00000035 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>
> which seems reasonable to me for an AGC adjusting to OTA signal
> variations.
>
>
>
> I suspect, in my case, strong reflections, due to a strong signal and a
> cabling impedance mismatch, was contributing to my problem.
>
> I don't know what control you have over the cabling in your building,
> but you might want to investigate if there are unterminated cable runs
> or unused wall plates that are downstream from the amplifier or
> demarcation point that serves your cable drop.
>
> Regards,
> Andy
>
>
> > from about 2 per minute to approximately one every twenty minutes by
> > changing the .qam_gain parameter in cx18_dvb.c from 0x02 to 0x01. Does
> > anyone know what this does physically? Does this offer any insight as
> > to what could be done to eliminate the remaining errors?
> >
> > Best,
> > Kyle
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


Unfortunately, I think I have very little control over the cabling in my building. But, this sounds like a relevant piece of information - I'll do a little investigating.



_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_1