Re: HVR-1600 QAM recordings with slight glitches in them
Oh, and as Andy suggested, please provide a sample of the azap or femon output for the HVR-1600 where you don't grep out the lines, so we can see what the SNR looks like before and after the point in time when the uncorrectable errors occurred. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
Resending with the ML back on the cc:. On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On 12-04-29 08:09 PM, Devin Heitmueller wrote: I don't know why you're not seeing valid data on femon with the 950q. It should be printing out fine, and it's on the same 0.1 dB scale. Try running just azap and see if the SNR is reported there. $ azap -c ~/last-channel-scan.prev 100-3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 65100 Hz video pid 0x, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK ... Doesn't seem to be useful values. That actually is useful data. The SNR of 0x190 means 40.0 dB (which is a max good signal). The fact that it sometimes goes between 0x190 and 0x000 is actually a bug in the driver I discovered a couple of months ago but haven't submitted a patch for. In fact it's strong enough that you might actually be over driving the tuner and may wish to try an attenuator. This suggests the signal is fine (although I would probably run it for longer and make sure you don't see intermittent UNC conditions). And you're using the exact same cabling for the 1600 as you are for the 950q above? Also, which version of the HVR-1600 is this? The one with the mxl5005s or the tda18271? You can check the dmesg output to tell (and if you cannot tell, please pastebin the dmesg output so I can look). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
Devin Heitmueller dheitmuel...@kernellabs.com wrote: Resending with the ML back on the cc:. On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On 12-04-29 08:09 PM, Devin Heitmueller wrote: I don't know why you're not seeing valid data on femon with the 950q. It should be printing out fine, and it's on the same 0.1 dB scale. Try running just azap and see if the SNR is reported there. $ azap -c ~/last-channel-scan.prev 100-3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 65100 Hz video pid 0x, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK ... Doesn't seem to be useful values. That actually is useful data. The SNR of 0x190 means 40.0 dB (which is a max good signal). The fact that it sometimes goes between 0x190 and 0x000 is actually a bug in the driver I discovered a couple of months ago but haven't submitted a patch for. In fact it's strong enough that you might actually be over driving the tuner and may wish to try an attenuator. This suggests the signal is fine (although I would probably run it for longer and make sure you don't see intermittent UNC conditions). And you're using the exact same cabling for the 1600 as you are for the 950q above? Also, which version of the HVR-1600 is this? The one with the mxl5005s or the tda18271? You can check the dmesg output to tell (and if you cannot tell, please pastebin the dmesg output so I can look). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html IIRC, Brian had a MXL5005s/S5H1409 variant. I think Brian might have a bad cable or connector or splitter in the run feeding the hvr1600. Just a guess... Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-05-03 11:37 AM, Andy Walls wrote: Devin Heitmueller dheitmuel...@kernellabs.com wrote: Also, which version of the HVR-1600 is this? The one with the mxl5005s or the tda18271? You can check the dmesg output to tell (and if you cannot tell, please pastebin the dmesg output so I can look). http://brian.interlinx.bc.ca/hvr-1600-dmesg IIRC, Brian had a MXL5005s/S5H1409 variant. The latter part sounds familiar from femon and gnutv. I think Brian might have a bad cable or connector or splitter in the run feeding the hvr1600. The same 4-way splitter fed the HVR-950Q and the HVR-1600 and cables were swapped just about every way they could be to try to get the HVR-1600's SNR up. But as I mentioned before, it's now completely non-functional due to the coax connector on the card having become loose enough to turn (with some effort, so screwing an female F-connector on/off was still quite doable). Perhaps it was marginal before due to that same problem. I guess I will never know... unless I try cracking this thing open and reconnecting whatever has gotten disconnected -- if Hauppage won't RMA it for me. They seem to be pretty silent about that now though after an initial e-mail exchange. If not, I've got my eye on a KWorld UB435-Q if I can determine that it's a hardware rev. 1 unit somehow since the store doesn't want to take it out of the box to check for me. It's less than half the price of an HVR-950Q at $40, as much as I would love to stay loyal with Hauppage -- this coax connector on my HVR-1600 coming loose, aside. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
On Thu, May 3, 2012 at 12:06 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: But as I mentioned before, it's now completely non-functional due to the coax connector on the card having become loose enough to turn (with some effort, so screwing an female F-connector on/off was still quite doable). Perhaps it was marginal before due to that same problem. I guess I will never know... unless I try cracking this thing open and reconnecting whatever has gotten disconnected -- if Hauppage won't RMA it for me. They seem to be pretty silent about that now though after an initial e-mail exchange. If the F-connector is loose, that can *definitely* explain the problem. Let me know if you have problems getting an RMA. If not, I've got my eye on a KWorld UB435-Q if I can determine that it's a hardware rev. 1 unit somehow since the store doesn't want to take it out of the box to check for me. It's less than half the price of an HVR-950Q at $40, as much as I would love to stay loyal with Hauppage -- this coax connector on my HVR-1600 coming loose, aside. Even if they take it out of the box, you would be unlikely to be able to determine the revision without plugging it in to something and checking the USB ID. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-29 08:09 PM, Devin Heitmueller wrote: I don't know why you're not seeing valid data on femon with the 950q. It should be printing out fine, and it's on the same 0.1 dB scale. Try running just azap and see if the SNR is reported there. $ azap -c ~/last-channel-scan.prev 100-3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 65100 Hz video pid 0x, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK ... Doesn't seem to be useful values. This indeed feels like a marginal signal condition problem, and Andy's assertion is well founded that the mxl5005/s5h1409 isn't exactly the best combo compared to more modern tuners and demodulators (Hauppauge switched to the tda18271 and s5h1411 for the newer revision of the HVR-1600). Well, now that the coax connector has come loose on the digital tuner (i.e. it spins albeit with enough friction that screwing a coax connector on and off is still quite doable but it would seem spins enough to have broken the connection internally and thus the tuner no longer receives signal) maybe it's time to cut my losses here and just consider this HVR-1600 garbage. I've wasted more than enough time on what's turned out to just be marginal hardware. ~sigh~ I wonder if I can still find the supported hardware rev. of the KWorld UB-435 around anywhere. The local computer store has one for $40 but they have no way of telling me if it's the new hardware rev. or the old one. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
On 29-04-12 00:21, Brian J. Murrell wrote: On 12-04-28 04:39 PM, Brian J. Murrell wrote: I typically have one more splitter downstream from that 3 way splitter which is a 4 way splitter to feed all of the tuners on my Mythtv box and introducing that splitter reduces the SNR at the HVR-1600 to between 13c and 13e (31.6 - 31.8 dB). Interestingly enough, I moved the Myth backend to it's usual home, in the basement, right next to the incoming cable signal and replaced that 25' run that I had going to where it was temporarily with a smaller, say 10' run (of RG-59 so still room for improvement) and my SNR at the HVR-1600, even after all of the splitters is now 015c or 34.8 dB. I'm still going to go replacing all of that RG-59 with shorter, custom made lengths of RG6 cables. I can't go too short when making those can I or would even a 6-12 inch cable be perfectly fine? I'm thinking of the runs between that last 4 way splitter and the tuners in the Myth backend. b. Brian, There is no minimum cable length for RF. Although for practical reasons i rarely go below 30 cm (1 '). It should be possible for you to buy drop cables which have a length of 1m5 (about 5') and are commonly used in HE to connect equipment. screw-on F-connectors are another source of problems. Crimping F-connectors are best, but those need a fitting crimp tool. Cheers, Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-29 03:02 AM, Rudy Zijlstra wrote: Brian, Hi Rudy, There is no minimum cable length for RF. Although for practical reasons i rarely go below 30 cm (1 '). Indeed. Especially with RG6 they can get a bit stiff. It should be possible for you to buy drop cables which have a length of 1m5 (about 5') and are commonly used in HE to connect equipment. Yeah, I'm trying to reduce the cable nest and I only have about 6 between the back of the equipment and the wall, where the splitter will be so 1' cables will probably do the trick. screw-on F-connectors are another source of problems. Yes. Crimping F-connectors are best, but those need a fitting crimp tool. Indeed, and I have one. :-) Thanks for the info! b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
On Sun, Apr 29, 2012 at 4:27 PM, James Courtier-Dutton james.dut...@gmail.com wrote: There are two measurements. 1) SNR. This is a measure of the quality of the signal. Bigger is better. 30dB is a good value. Spliters and amplifiers should only slightly reduce the SNR value. 30 dB for ClearQAM is actually a very marginal SNR. It caps out at 40 dB, and as Andy pointed out, it's a logarithmic scale. On a good cable plant, you should expect an SNR between 35 and 40. Anything below 32 and you're very likely to have significant error rates. Don't confuse it with Over-the-Air ATSC, which will typically cap out at 30.0 dB. I don't know why you're not seeing valid data on femon with the 950q. It should be printing out fine, and it's on the same 0.1 dB scale. Try running just azap and see if the SNR is reported there. This indeed feels like a marginal signal condition problem, and Andy's assertion is well founded that the mxl5005/s5h1409 isn't exactly the best combo compared to more modern tuners and demodulators (Hauppauge switched to the tda18271 and s5h1411 for the newer revision of the HVR-1600). The Linux driver support should be on-par with Windows though in terms of performance as I did a bunch of work some time back to analyze the differences which resulted in some fixes. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On Tue, 2012-04-24 at 23:07 -0400, Brian J. Murrell wrote: On 12-04-24 06:42 PM, Andy Walls wrote: Run 'femon' on the cx18's dvb frontend when you have a live QAM capture ongoing. OK. Ran it all evening during the evening capture window. Started it at 20:30, sharp to coincide with the evening's recording from that card also starting at 20:30 sharp. Here's where it found anomalies: $ nl /var/tmp/femon.out | grep -v | ber | unc | grepping out the 0 lines doesn't let one see the trends in Signal to Noise Ratio (SNR) before and after the uncorrectable (unc) block counts. So you can see, since femon prints an output line each second, the number on the left is the seconds since 20:30 and we are looking for any line showing a ber or unc that is non-zero: Cool. First. note the following about the s5h1409 driver for the CX24227 (aka S5H109) QAM/8VSB demodulator: a. the Bit Eror Rate (BER) as returned by the driver is bogus; ignore it. It is just a copy of the uncorrectable block count. b. The signal level is a software computed value based on the SNR value. Ignore signal as redundant information. c. The Signal to Noise Ratio (SNR) should be a hexadecimal value with units of 1/10th of a deciBel (0.1 dB) (centiBels?). E.g. 0x13a = 314 = 31.4 dB I believe Steven calibrated this value to SNR at the RF input of the HVR-1600. (Steven or Devin, correct me if I am wrong.) 1FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) 67status SCVYL | signal 013a | snr 013a | ber 0198 | unc 0198 | FE_HAS_LOCK 313status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 457status SCVYL | signal 013a | snr 013a | ber 026e | unc 026e | FE_HAS_LOCK 802status SCVYL | signal 013c | snr 013c | ber 0265 | unc 0265 | FE_HAS_LOCK 1093status SCVYL | signal 013a | snr 013a | ber 014b | unc 014b | FE_HAS_LOCK 1184status SCVYL | signal 013a | snr 013a | ber 01ca | unc 01ca | FE_HAS_LOCK 1192status SCVYL | signal 013a | snr 013a | ber 0267 | unc 0267 | FE_HAS_LOCK 1385status SCVYL | signal 013c | snr 013c | ber 025d | unc 025d | FE_HAS_LOCK 1435status SCVYL | signal 013c | snr 013c | ber 0268 | unc 0268 | FE_HAS_LOCK 1511status SCVYL | signal 013c | snr 013c | ber 026c | unc 026c | FE_HAS_LOCK 1657status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 1693status SCVYL | signal 013a | snr 013c | ber 026f | unc 026f | FE_HAS_LOCK 1749status SCVYL | signal 013c | snr 013c | ber 0184 | unc 0184 | FE_HAS_LOCK 1796status SCVYL | signal 013a | snr 013a | ber 1a8b | unc 1a8b | FE_HAS_LOCK 1814status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 2028status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 2081status SCVYL | signal 013c | snr 013c | ber 023a | unc 023a | FE_HAS_LOCK 2261status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 2307status SCVYL | signal 013c | snr 013c | ber 0279 | unc 0279 | FE_HAS_LOCK 2318status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 2474status SCVYL | signal 013a | snr 013a | ber 026f | unc 026f | FE_HAS_LOCK 2533status SCVYL | signal 013c | snr 013c | ber 0098 | unc 0098 | FE_HAS_LOCK 2612status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 2627status SCVYL | signal 013c | snr 013c | ber 0108 | unc 0108 | FE_HAS_LOCK 2671status SCVYL | signal 013c | snr 013c | ber 0196 | unc 0196 | FE_HAS_LOCK 2870status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 3084status SCVYL | signal 013c | snr 013c | ber 0274 | unc 0274 | FE_HAS_LOCK 3220status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 3323status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 3406status SCVYL | signal 013c | snr 013c | ber 024f | unc 024f | FE_HAS_LOCK 3433status SCVYL | signal 013c | snr 013a | ber 022a | unc 022a | FE_HAS_LOCK 3946status SCVYL | signal 013c | snr 013c | ber 0270 | unc 0270 | FE_HAS_LOCK 4129status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 4275status SCVYL | signal 013c | snr 013c | ber 0273 | unc 0273 | FE_HAS_LOCK 4284status SCVYL | signal 013c | snr 013c | ber 0267 | unc 0267 | FE_HAS_LOCK 4411status SCVYL | signal 013c | snr
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-28 10:56 AM, Andy Walls wrote: grepping out the 0 lines doesn't let one see the trends in Signal to Noise Ratio (SNR) before and after the uncorrectable (unc) block counts. OK. I have completely reworked the way I use femon. I now start/stop femon along with recordings so I should have a separate femon output for each recording (using Mythtv system events and a couple of recording start/stop scripts, fwiw). So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you have problems. For 256-QAM cable signals, I think that is considered marginal. OK. Good to know. (Can someone else with 256-QAM North American cable please confirm? I only have OTA) Would be great if somebody can. Thanks in advance. When you have no errors, what is the SNR? I'm guessing there are no large swings. From what I recall of the data, no, the SNR was pretty much the same throughout good and bad periods of the recordings. But with my configuration here, we will know for sure soon enough. Hard to tell, given that one of the other digital sub-channels may have been effected and not visible on the channel you were recording. Ahhh. I see. I normally watch DTV live with mplayer, and also have femon open in another window, when performing this sort of test. That's effectively what I am doing with my recordings. When a recording starts, an femon starts and logs. When the recording is done I use mplayer (-nosound -vo null -benchmark, just to make it run as fast as possible) and prune out the per frame counters so that what I am left with is the bits that mplayer complains about in the stream along with the frame count it happened at. The femon output is also included for cross reference. A video or audio glitch, 1 or 2 seconds after a non-zero uncorrectable block count, is usually a good indicator of correlation. That's what I will look for. Well, not the best performer from what I hear. Indeed. I don't have any of these problems with my HVR-950Q. This HVR-1600 was a really good deal though, so I can't totally complain. :-) Speaking of the HVR-950Q, does femon not work with it? I seem to always get zero values across the board trying. But certainly works just fine for many people in many contexts. Yes, and indeed, it works here for the most part even with small glitches some of the time. But some other times, the glitching is bad enough to make a recording more or less useless. OK. There are two ways to go here: 1. We assume your signal is marginal. Take a look here for things to check and fix if needed: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality I will see what I can do with those. As a test, you you might also want to temporarily change your coax wiring setup to reduce the number of splits and connectors before the signal goes into the HVR-1600, and see if things are better. Indeed. That was at the top of my list also, so isolate the rest of the cable plant in here. Every 2-way splitter will drop 3-5 dB of signal. OK. So about splitters. Given that I'm in a house with 4 cable television runs to different rooms, plus a cable modem, plus 4 PVR tuner inputs (so yeah, 9 consumers), what is my best splitter plan/options. Probably ideally I want to split the incoming signal into two, one for the cable modem and one to feed the television consumers. Once I have the feed off to the televisions though, am I best trying to split that into 8, (i.e. equally with an 8-way splitter -- if that's even possible) or would I be better served with some more smaller splits in somewhat of a tree formation? I'm also assuming that all splitters are not of the same quality and that the dollar store ones are likely of inferior quality. But dollar store aside, even amongst reasonable retailers, how can I tell (without having to get all electronics geeky with an oscilliscope and whatnot) what's good and what's bad? Also, splitting 8 ways, am I into amplification/boosting territory or am I likely to just boost noise along with the signal? 2. We assume your signal is too strong, and that it is overdriving the MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227 demodulator. Heh. I wonder if that could be possible given my description above. :-) Your corrective action here would be to attenuate the incoming RF signal with either an inline attenuator, or with additional, properly terminated, splitters. Indeed. Thanks so much for all of the input here. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
One more question... On 12-04-28 10:56 AM, Andy Walls wrote: So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you have problems. For 256-QAM cable signals, I think that is considered marginal. I've never gotten my mind around SNRs and dBs, etc. Generally speaking, am I looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-28 02:36 PM, Brian J. Murrell wrote: One more question... And to answer my own question, and provide some more data... I've never gotten my mind around SNRs and dBs, etc. Generally speaking, am I looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Clearly, bigger numbers are better. When I hook my HVR-1600 directly up to the cable connection coming into the house with a 25 foot cable and a barrel connector the SNR goes up to 148 (32.8 dB) so that's my ceiling. I can't leave it hooked up like this for anything more than a few minutes so I can't be sure that's a high enough SNR for me to get perfect recordings every time. If I add one two way splitter to the incoming cable with one feed going off to my cable modem and one to the HVR-1600, the SNR drops to 145 (32.5 dB). But again, I can't really leave it like that for too long. so splitting that leg of the 2-way split 3 more times through a 3 way splitter reduces the SNR at the HVR-1600 to between 142 and 145 (32.2 - 32.5 dB). I typically have one more splitter downstream from that 3 way splitter which is a 4 way splitter to feed all of the tuners on my Mythtv box and introducing that splitter reduces the SNR at the HVR-1600 to between 13c and 13e (31.6 - 31.8 dB). I have no idea where in these range of values acceptable is though. Given that the HVR-1600 seems to be more sensitive to signal quality that just about anything else in here, I suppose I could feed it more directly from a split closer to the source signal. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
On Sat, 2012-04-28 at 14:08 -0400, Brian J. Murrell wrote: On 12-04-28 10:56 AM, Andy Walls wrote: OK. There are two ways to go here: 1. We assume your signal is marginal. Take a look here for things to check and fix if needed: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality I will see what I can do with those. As a test, you you might also want to temporarily change your coax wiring setup to reduce the number of splits and connectors before the signal goes into the HVR-1600, and see if things are better. Indeed. That was at the top of my list also, so isolate the rest of the cable plant in here. Every 2-way splitter will drop 3-5 dB of signal. OK. So about splitters. Given that I'm in a house with 4 cable television runs to different rooms, plus a cable modem, plus 4 PVR tuner inputs (so yeah, 9 consumers), what is my best splitter plan/options. Probably ideally I want to split the incoming signal into two, one for the cable modem and one to feed the television consumers. Assuming ideal splitters: a 2 way split is a 3 dB signal loss for each leg a 4 way split is a 6 dB signal loss for each leg an 8 way split is a 9 dB signal loss for each leg Signal losses in dB are additive. So for example, a device downstream from a 2-way split and then 4 way split, experiences a minimum of 9 dB of signal loss. Once I have the feed off to the televisions though, am I best trying to split that into 8, (i.e. equally with an 8-way splitter -- if that's even possible) or would I be better served with some more smaller splits in somewhat of a tree formation? With ideal splitters and perfect cable connections, it wouldn't matter. With real-life splitters and cable connectors, the fewer the devices and cable connections you use, the better. I'm also assuming that all splitters are not of the same quality and that the dollar store ones are likely of inferior quality. But dollar store aside, even amongst reasonable retailers, how can I tell (without having to get all electronics geeky with an oscilliscope and whatnot) what's good and what's bad? When looking for splitters as a consumer, you need to ensure frequency range of the splitter covers your needed range. Splitters for terrestrial OTA broadcasts only need to pass signals to about 900 MHz. Splitters for satellite TV need to pass signals to around 2300 MHz (2.3 GHz) or so. For cable you will need to pass signals up to about 1000 MHz (1.0 GHz). You shouldn't woory about splitter performance variabtions on the order of 1 or 2 dB. You can compensate for that with a distribution amplifier and better quality cable and connectors. BTW, I have in the past purchased a brand name, somewhat expensive, 4 way splitter from a Lowes hardware store, only to find one of the outputs didn't pass any signal - it was broken. :( Also, splitting 8 ways, am I into amplification/boosting territory or am I likely to just boost noise along with the signal? Yes you will be amplifying the incoming noise. But you've got to do something to preserve SNR against cable plant losses, which degrade signal but don't reduce noise. Put any distribution amplifier you purchase, as close to where the signal comes into your home as possible. Make sure it is a low noise amplifier. Variable gain is a nice feature, to avoid overdriving your components. BTW, the noise figure of a receiving system (your cable plant and tuners) is dominated by the Noise Figure of it's first amplification stage: http://en.wikipedia.org/wiki/Friis_formulas_for_noise A good, low noise, distribution amplifier can go a long way to helping eliminate other problems. Don't skimp; pay the money for a decent one. Also, you must take steps to reduce other losses and stop signal reflections: good cable, good cable connections, and properly terminate every split/leg. One missing or bad termination results in signal reflections (i.e. additional noise) in your entire cable plant. 2. We assume your signal is too strong, and that it is overdriving the MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227 demodulator. Heh. I wonder if that could be possible given my description above. :-) Probably not. :) Your corrective action here would be to attenuate the incoming RF signal with either an inline attenuator, or with additional, properly terminated, splitters. Indeed. Thanks so much for all of the input here. No problem. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On Sat, 2012-04-28 at 14:36 -0400, Brian J. Murrell wrote: One more question... On 12-04-28 10:56 AM, Andy Walls wrote: So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you have problems. For 256-QAM cable signals, I think that is considered marginal. I've never gotten my mind around SNRs and dBs, etc. Generally speaking, am I looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Higher SNR is better: Higher SNR = lower probability of bit errors Lower SNR = higher probability of bit errors SNR in dB = 10 log (S/N) S : Received signal power in Watts N : Noise power at measurement point in Watts A logarithmic scale (dB) is used to express the quantities in values that are easier for people to comprehend and deal with. Gains and losses in dB are additive. -3 dB corresponds to a drop by a factor of 1/2: 10 * log(1/2) = -3.01 +3 dB corresponds to a gain by a factor of 2:10 * log(2) = 3.01 Regards, Andy Cheers, b. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-28 04:39 PM, Brian J. Murrell wrote: I typically have one more splitter downstream from that 3 way splitter which is a 4 way splitter to feed all of the tuners on my Mythtv box and introducing that splitter reduces the SNR at the HVR-1600 to between 13c and 13e (31.6 - 31.8 dB). Interestingly enough, I moved the Myth backend to it's usual home, in the basement, right next to the incoming cable signal and replaced that 25' run that I had going to where it was temporarily with a smaller, say 10' run (of RG-59 so still room for improvement) and my SNR at the HVR-1600, even after all of the splitters is now 015c or 34.8 dB. I'm still going to go replacing all of that RG-59 with shorter, custom made lengths of RG6 cables. I can't go too short when making those can I or would even a 6-12 inch cable be perfectly fine? I'm thinking of the runs between that last 4 way splitter and the tuners in the Myth backend. b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
On Sun, 2012-04-22 at 23:30 -0400, Brian J. Murrell wrote: Hi, I have an HVR-1600 on a 3GHz dual-core P4 running linux 3.2.0. Whenever I record from clearqam using this card I frequently get small glitches in playback. Playing these same files with mplayer yields things like: demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]Warning MVs not available [mpeg2video @ 0x893a2e0]concealing 66 DC, 66 AC, 66 MV errors demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]invalid cbp at 4 12 [mpeg2video @ 0x893a2e0]Warning MVs not available [mpeg2video @ 0x893a2e0]concealing 198 DC, 198 AC, 198 MV errors [mpeg2video @ 0x893a2e0]ac-tex damaged at 11 24 [mpeg2video @ 0x893a2e0]Warning MVs not available [mpeg2video @ 0x893a2e0]concealing 99 DC, 99 AC, 99 MV errors demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]ac-tex damaged at 27 0 [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 1 [mpeg2video @ 0x893a2e0]ac-tex damaged at 6 2 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]invalid cbp at 15 6 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 4 8 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 21 10 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]ac-tex damaged at 12 15 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]invalid cbp at 14 18 [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 12 20 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 22 [mpeg2video @ 0x893a2e0]invalid cbp at 1 23 [mpeg2video @ 0x893a2e0]ac-tex damaged at 20 24 [mpeg2video @ 0x893a2e0]invalid cbp at 1 25 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 13 29 [mpeg2video @ 0x893a2e0]concealing 990 DC, 990 AC, 990 MV errors demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 - 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]ac-tex damaged at 14 10 [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 10 [mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 2 11 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 24 14 [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 14 [mpeg2video @ 0x893a2e0]ac-tex damaged at 3 18 [mpeg2video @ 0x893a2e0]ac-tex damaged at 16 16 [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 17 [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 18 [mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 9 20 [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 20 [mpeg2video @ 0x893a2e0]ac-tex damaged at 11 22 [mpeg2video @ 0x893a2e0]invalid cbp at 1 22 [mpeg2video @ 0x893a2e0]ac-tex damaged at 8 23 [mpeg2video @ 0x893a2e0]ac-tex damaged at 3 24 [mpeg2video @ 0x893a2e0]invalid cbp at 2 26 [mpeg2video @
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-24 06:42 PM, Andy Walls wrote: Signal level varaition coupled with the HVR-1600's, at times, mediocre digital tuning side: Ahh. Pity. Run 'femon' on the cx18's dvb frontend when you have a live QAM capture ongoing. OK. Ran it all evening during the evening capture window. Started it at 20:30, sharp to coincide with the evening's recording from that card also starting at 20:30 sharp. Here's where it found anomalies: $ nl /var/tmp/femon.out | grep -v | ber | unc | So you can see, since femon prints an output line each second, the number on the left is the seconds since 20:30 and we are looking for any line showing a ber or unc that is non-zero: 1 FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) 67 status SCVYL | signal 013a | snr 013a | ber 0198 | unc 0198 | FE_HAS_LOCK 313 status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 457 status SCVYL | signal 013a | snr 013a | ber 026e | unc 026e | FE_HAS_LOCK 802 status SCVYL | signal 013c | snr 013c | ber 0265 | unc 0265 | FE_HAS_LOCK 1093 status SCVYL | signal 013a | snr 013a | ber 014b | unc 014b | FE_HAS_LOCK 1184 status SCVYL | signal 013a | snr 013a | ber 01ca | unc 01ca | FE_HAS_LOCK 1192 status SCVYL | signal 013a | snr 013a | ber 0267 | unc 0267 | FE_HAS_LOCK 1385 status SCVYL | signal 013c | snr 013c | ber 025d | unc 025d | FE_HAS_LOCK 1435 status SCVYL | signal 013c | snr 013c | ber 0268 | unc 0268 | FE_HAS_LOCK 1511 status SCVYL | signal 013c | snr 013c | ber 026c | unc 026c | FE_HAS_LOCK 1657 status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 1693 status SCVYL | signal 013a | snr 013c | ber 026f | unc 026f | FE_HAS_LOCK 1749 status SCVYL | signal 013c | snr 013c | ber 0184 | unc 0184 | FE_HAS_LOCK 1796 status SCVYL | signal 013a | snr 013a | ber 1a8b | unc 1a8b | FE_HAS_LOCK 1814 status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 2028 status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 2081 status SCVYL | signal 013c | snr 013c | ber 023a | unc 023a | FE_HAS_LOCK 2261 status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 2307 status SCVYL | signal 013c | snr 013c | ber 0279 | unc 0279 | FE_HAS_LOCK 2318 status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 2474 status SCVYL | signal 013a | snr 013a | ber 026f | unc 026f | FE_HAS_LOCK 2533 status SCVYL | signal 013c | snr 013c | ber 0098 | unc 0098 | FE_HAS_LOCK 2612 status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 2627 status SCVYL | signal 013c | snr 013c | ber 0108 | unc 0108 | FE_HAS_LOCK 2671 status SCVYL | signal 013c | snr 013c | ber 0196 | unc 0196 | FE_HAS_LOCK 2870 status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 3084 status SCVYL | signal 013c | snr 013c | ber 0274 | unc 0274 | FE_HAS_LOCK 3220 status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 3323 status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 3406 status SCVYL | signal 013c | snr 013c | ber 024f | unc 024f | FE_HAS_LOCK 3433 status SCVYL | signal 013c | snr 013a | ber 022a | unc 022a | FE_HAS_LOCK 3946 status SCVYL | signal 013c | snr 013c | ber 0270 | unc 0270 | FE_HAS_LOCK 4129 status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 4275 status SCVYL | signal 013c | snr 013c | ber 0273 | unc 0273 | FE_HAS_LOCK 4284 status SCVYL | signal 013c | snr 013c | ber 0267 | unc 0267 | FE_HAS_LOCK 4411 status SCVYL | signal 013c | snr 013c | ber 0270 | unc 0270 | FE_HAS_LOCK 4718 status SCVYL | signal 013c | snr 013c | ber 0204 | unc 0204 | FE_HAS_LOCK 4779 status SCVYL | signal 013c | snr 013c | ber 0181 | unc 0181 | FE_HAS_LOCK 4927 status SCVYL | signal 013c | snr 013c | ber 025e | unc 025e | FE_HAS_LOCK 4973 status SCVYL | signal 013c | snr 013c | ber 0157 | unc 0157 | FE_HAS_LOCK 5024 status SCVYL | signal 013c | snr 013c | ber 024c | unc 024c | FE_HAS_LOCK 5310 status SCVYL | signal 013c | snr 013c | ber 0190 | unc 0190 | FE_HAS_LOCK 5328 status SCVYL | signal 013c | snr 013c | ber 0277 | unc 0277 | FE_HAS_LOCK 5439 status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 5441 status SCVYL | signal 0138 | snr 0138 | ber 024f | unc 024f | FE_HAS_LOCK 5447 status SCVYL | signal 0138 | snr 0138 | ber 0266 | unc 0266 | FE_HAS_LOCK 5885 status SCVYL | signal 013a | snr 013a | ber 00b3 |
