[mythtv-users] Channel Reception Issues

[ryanlists79 at gmail.com]

Rich West wrote:
> Brian Wood wrote:
>   
>> On Feb 22, 2007, at 11:17 AM, ryanlists79 at gmail.com wrote:
>>
>>   
>>     
>>> I've been trying to figure this out for the last few weeks, and am
>>> pretty frustrated.  On certain channels, mainly 3 (ABC), 4 (NBC), 43
>>> (Cartoon Network) & 69 (Spike), I am having what appear to be  
>>> reception
>>> issues.  Basically I have small "bars" rolling across the screen.  On
>>> channel 69, they are color, red and a semi-green, and sometimes  
>>> roll up
>>> and down, and sometimes they don't roll at all.  On channel 3 they are
>>> just darker & lighter bars, almost a change in brightness, and scroll
>>> from the bottom left corner to the upper right corner.  On channel 4,
>>> they are similar to channel 3, but smaller, a bit more subtle, and
>>> scroll directly up.  And channel 43 is an even more subtle version of
>>> channel 4.
>>>
>>> You can see screen shots from channels 3 & 69 on my flickr site:
>>> http://www.flickr.com/photos/83544026@N00/
>>>
>>>     
>>>       
>> What you have are called "beats" in the vernacular. They are caused  
>> by a carrier mixing or "beating" with the visual carrier causing  
>> hetrodyne products that fall within the baseband video frequency range.
>>
>> The fact that they are more or less steady indicates that the  
>> interfering carrier is more or less CW (ie" not modulated), and more  
>> or less "on" a multiple/submultiple of the horizontal scan frequency  
>> or, possibly, the vertical scan rate. The source is almost certainly  
>> from your computer somehow. If the interfering beats are moving  
>> slowly it indicates that the beat product is merely "close" to a  
>> multiple/submultiple of the scan frequency, and as the beat gets  
>> farther and farther away from such multiple (moving faster and  
>> faster) it eventually gets unrecognizable as a "beat" and rather just  
>> results in a general fuzziness or lack of detail in the baseband video.
>>
>> If they are absolutely stationary then they are right on some  
>> multiple or sub-multiple of the horizontal scan frequency. You could  
>> theoretically count the number of bars and thus calculate the precise  
>> frequency of the interfering beat (actually there would be 2 possible  
>> solutions, depending on whether the interfering carrier was above or  
>> below the scan frequency). There's no real point in doing this  
>> because it would not help you in eliminating the problem.
>>
>> The beats *could* be third-order products happening in the RF realm,  
>> and being enhanced by cheap tuner on the PVR card. You could try  
>> attenuating the signal going into the card. The bottom line here is  
>> that expecting broadcast-quality performance from a $100 card is  
>> pretty much the height of optimism.
>>
>> But what you're interested in is what you can do about it. From the  
>> behavior you describe it sounds like it's happening in the recording  
>> itself, you could prove that by playing the mpeg back on another  
>> machine.
>>
>> You could try moving cards and/or cables around inside your case.  
>> Video cards are a notorious source of crap so you could try having  
>> the backend make a recording with no video card in the machine (set  
>> it up then remove the card and re-boot and let it run headless). You  
>> could try some sort of shielding, check that all mobo screws are  
>> tight, make sure everything's grounded well.
>>
>> Even power supplies can generate crap that's within the video  
>> bandwidth ( essentially 0 - 5 Mhz). Cheap switcher supplies  
>> especially are prone to this.
>>
>> But in the end there may be nothing you can do short of a better- 
>> designed PC case and/or motherboard combination. Even well-designed  
>> professional broadcast gear is prone to this sort of thing if the  
>> designer is not extremely careful.
>>
>> But at least you now know *why* you are having problems :-)
>>
>> All this should be obvious to any decent engineer after a 1 second  
>> glance at your pictures, but I guess I have to keep reminding myself  
>> that few here on this list worked in TV broadcasting for 35 years :-)  
>> Obviously what I've said here is a gross oversimplification but I  
>> hope it makes the point clear.
>>     
>
> Yes, the bars are interference from something at or around the same
> frequency.  Finding out what it is can be a bit of a pain with little
> reward since it might not be possible to fix the problem without some
> additional investment or reconfiguration of hardware.
>
> Of course, there is the simple question that should be asked: do you get
> this same problem with the cable plugged directly in to your television
> without the MythTV box in the loop (and powered off or moved away from
> the cable line)?
>
> If the problem goes away, then the problem definitely lies within your
> MythTV box and you can focus on the stuff you have in there, such as the
> quality of the power supply, the proximity of the capture card to other
> devices like the video card, the processor, and case fans, and the
> grounding of the motherboard.
>
> If the problem remains, then it is safe to say it is not your MythTV
> box.  Unfortunately, if this is the case, there is very little you can
> do without contacting the cable company.  You are limited to replacing
> the cable that you are using to connect the TV to the wall jack by using
> a thicker (higher quality) coax cable (you can get lengths of this for
> free from the cable company).
>
> -Rich
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>   
Actually, I only experience the problem when recording on the mythtv 
box, not on the TV.  With the mythtv box running, I can disconnect the 
coax cable from the mythtv box and plug it into the TV and everything 
displays perfectly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070222/84e86818/attachment-0001.htm