On Tue, 2010-03-16 at 13:45 -0400, Kyle Lil wrote: > > > > Date: Thu, 4 Mar 2010 19:16:37 -0500 > > From: [email protected] > > To: [email protected] > > Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete > frame > > > > On Thu, Mar 4, 2010 at 7:11 PM, Kyle Lil <[email protected]> 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 > > [email protected] > > 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 [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
