Re: [linux-media] Re: [linux-media] stb0899: no lock on dvb-s2 transponders in SCR environment
Hi, Am 27.04.2013 16:51, schrieb Klaus Schmidinger: On 27.04.2013 14:14, Reinhard Nissl wrote: Hi, my stb0899 card works properly on dvb-s and dvb-s2 transponders when using a direct port on my sat multiswitch. When using a SCR port on that multiswitch and changing VDR's config files accordingly, it only locks on dvb-s transponders. A SCR converts the selected transponder's frequency after the LNB (IF1) to a fixed frequency (for example 1076 MHz) by mixing the signal with a local oscialator frequency above IF1 so that the lower sideband of the mixing product appears at 1076 MHz. The lower sideband's spectrum is mirrored compared to the upper sideband, which is identical to the original spectrum on the original IF1. Could that be the reason why the stb0899 cannot lock on dvb-s2 transponders in an SCR environment? Any ideas on how to get a lock on dvb-s2 transponders? Just wanted to let you know that I can confirm the problem with the stb0899. On my TT S2-6400 I can receive DVB-S and DVB-S2 just fine with SCR. During development of SCR support for VDR I guess I did all tests with the 6400, so I didn't come across this problem. However, as a reaction to your posting I explicitly tested it with my budget cards, and there I indeed can only tune to DVB-S transponders. No idea how to solve this, though... Well, as mentioned above, it really has to do with the lower side band, which is mirrored compared to the original spectrum. The phase of the Q component of the signal is usually 90 ° behind the I component. Due to the mirroring, the phase changes its sign which means, the Q component is now 90 ° ahead of the I component with the result that the decoded symbols do not match the expected code points. To fix the phase relationship between I and Q component, I and Q inputs need to be swapped. This can done by enabling inversion. I first thought that VDR's channel parameter inversion could do the trick, but it looks to me like it is either not supported by the driver or does/means something different (have to learn alot more about mixing and signal processing regarding DVB). Anyway, digging through the code I found that the driver supports inversion and that this behaviour is a compiled in configuration option for the TT-3200 board. The driver even supports automatic inversion, so that's the way I got it finally working for now (see attached patch). Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de --- pci/ttpci/budget-ci.c.orig 2013-05-05 13:18:16.203930908 +0200 +++ pci/ttpci/budget-ci.c 2013-05-05 13:18:26.576914170 +0200 @@ -1280,7 +1280,7 @@ static struct stb0899_config tt3200_conf .demod_address = 0x68, .xtal_freq = 2700, - .inversion = IQ_SWAP_ON, /* 1 */ + .inversion = IQ_SWAP_AUTO, /* 2 */ .lo_clk = 7650, .hi_clk = 9900,
stb0899: no lock on dvb-s2 transponders in SCR environment
Hi, my stb0899 card works properly on dvb-s and dvb-s2 transponders when using a direct port on my sat multiswitch. When using a SCR port on that multiswitch and changing VDR's config files accordingly, it only locks on dvb-s transponders. A SCR converts the selected transponder's frequency after the LNB (IF1) to a fixed frequency (for example 1076 MHz) by mixing the signal with a local oscialator frequency above IF1 so that the lower sideband of the mixing product appears at 1076 MHz. The lower sideband's spectrum is mirrored compared to the upper sideband, which is identical to the original spectrum on the original IF1. Could that be the reason why the stb0899 cannot lock on dvb-s2 transponders in an SCR environment? Any ideas on how to get a lock on dvb-s2 transponders? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de -- 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: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
Hi, Am 16.08.2012 00:10, schrieb Mauro Carvalho Chehab: The patch seems to be working. Anyway, for it to be merged, you'll need to be sending it together with your SOB (Signed-off-by), and using the -p1 format e. g. something like: --- a/drivers/media/dvb/frontends/stb0899_drv.c 2012-08-14 21:59:59.0 +0200 +++ b/drivers/media/dvb/frontends/stb0899_drv.c 2012-08-14 21:29:17.0 +0200 as otherwise developer's scripts won't get it right. I hope I got it right this time ;-) Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de stb0899: return internally tuned frequency via get_frontend. Signed-off-by: Reinhard NiÃl diff --git a/drivers/media/dvb-frontends/stb0899_drv.c b/drivers/media/dvb-frontends/stb0899_drv.c index 5d7f8a9..79e29de 100644 --- a/drivers/media/dvb-frontends/stb0899_drv.c +++ b/drivers/media/dvb-frontends/stb0899_drv.c @@ -1563,6 +1563,7 @@ static int stb0899_get_frontend(struct dvb_frontend *fe) dprintk(state->verbose, FE_DEBUG, 1, "Get params"); p->symbol_rate = internal->srate; + p->frequency = internal->freq; return 0; }
Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
Hi, Am 14.08.2012 22:15, schrieb Reinhard Nissl: Hi, Am 14.08.2012 14:05, schrieb Manu Abraham: My other device, a STB0899, always reports the set frequency. So it seems driver dependent whether it reports the actually locked frequency found by the zig-zag-algorithm or just the set frequency to tune to. The STV0299 blindly sets the value based on a software zigzag (due to simpler hardware), but this might not be accurate enough. On the other hand, the STB0899 internally does zig-zag in hardware for DVB-S2, and partly in software for DVB-S. In any event, the get_frontend callback should return the value that is read from the demodulator registers, rather than the cached original value that which was requested to be tuned. The stb0899 returns only the cached value IIRC. Maybe I will fix this soon, or maybe you can send a patch. See the attached patch. This is what I get after the patch: Sat.Pol.BandFreq (MHz) SetFreq (MHz) GetDelta (MHz) S19,2EHL1074410748,4744,474 S19,2EHL1077310777,9444,944 S19,2EHL1083210836,9534,953 S19,2EHL1086110868,7747,774 S19,2EHL1092010924,3124,312 S19,2EHL1102311026,8273,827 S19,2EHL1117011175,4235,423 S19,2EHL1124311248,4525,452 S19,2EHL1130211307,3715,371 S19,2EHL1136111366,4275,427 S19,2EHL1142011425,4735,473 S19,2EHL1146411468,8764,876 S19,2EHL1149311498,4215,421 S19,2EHL1152311529,0806,080 S19,2EHL1158211586,9424,942 S19,2EHL1161111618,7857,785 S19,2EHL1164111645,9514,951 S19,2EHL1167011675,4505,450 S19,2EHH1171911724,9705,970 S19,2EHH1175811763,9755,975 S19,2EHH1179711802,9785,978 S19,2EHH1183611841,9725,972 S19,2EHH1187511880,9515,951 I'll have to let VDR "travel" across the transponders several times to see whether I get similar results for the previously mentioned transponder on the stv0299 device. Please have a look at http://home.vrweb.de/~rnissl/test/tune2.pdf For the topmost samples (S13.0E, Band H, Pol. V) it seems like there is an average offset of 6.7 MHz. One can see the temperature dependent drift of the LNB between night and day (ambient temperature 12.55 °C vs. 28.35 °C) by the "bars" which are created of co-located samples. BTW: x-axis enumerates transponders (which VDR could get a lock for) in the corresponding band ordered by increasing frequency. To get all bands in one diagram, each band adds an additional offset of 10 MHz, so simply ignore the ten's digit. While the S13.0E transponders look good besides a single transponder which shows a wider range of frequency offsets, the S19.2E transponders in the high bands show a similar wide range for several "highest" frequency transponders. I have no idea why this also happens for almost any S19.2E low band vertical transponder. Can anyone explain that for example by driver or device limitations? I hope the offsets from 4.7 MHz to 6.7 MHz are not an issue of the STB0899 device. If I recall correctly, I had tuning issues also on my 9 year old TechniSat receiver, e. g. Pro7 on S19.2E was working in the morning but not in the evening, and adjusting diseqc settings to compensate for about 5 MHz solved the issue. Recently I ordered a recent TechniSat receiver and it tunes awfully slow -- I'll now try to tweak diseqc settings and see if things get better ;-) Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de -- 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: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
Hi, Am 14.08.2012 14:05, schrieb Manu Abraham: My other device, a STB0899, always reports the set frequency. So it seems driver dependent whether it reports the actually locked frequency found by the zig-zag-algorithm or just the set frequency to tune to. The STV0299 blindly sets the value based on a software zigzag (due to simpler hardware), but this might not be accurate enough. On the other hand, the STB0899 internally does zig-zag in hardware for DVB-S2, and partly in software for DVB-S. In any event, the get_frontend callback should return the value that is read from the demodulator registers, rather than the cached original value that which was requested to be tuned. The stb0899 returns only the cached value IIRC. Maybe I will fix this soon, or maybe you can send a patch. See the attached patch. This is what I get after the patch: Sat.Pol.BandFreq (MHz) Set Freq (MHz) Get Delta (MHz) S19,2E H L 10744 10748,474 4,474 S19,2E H L 10773 10777,944 4,944 S19,2E H L 10832 10836,953 4,953 S19,2E H L 10861 10868,774 7,774 S19,2E H L 10920 10924,312 4,312 S19,2E H L 11023 11026,827 3,827 S19,2E H L 11170 11175,423 5,423 S19,2E H L 11243 11248,452 5,452 S19,2E H L 11302 11307,371 5,371 S19,2E H L 11361 11366,427 5,427 S19,2E H L 11420 11425,473 5,473 S19,2E H L 11464 11468,876 4,876 S19,2E H L 11493 11498,421 5,421 S19,2E H L 11523 11529,080 6,080 S19,2E H L 11582 11586,942 4,942 S19,2E H L 11611 11618,785 7,785 S19,2E H L 11641 11645,951 4,951 S19,2E H L 11670 11675,450 5,450 S19,2E H H 11719 11724,970 5,970 S19,2E H H 11758 11763,975 5,975 S19,2E H H 11797 11802,978 5,978 S19,2E H H 11836 11841,972 5,972 S19,2E H H 11875 11880,951 5,951 I'll have to let VDR "travel" across the transponders several times to see whether I get similar results for the previously mentioned transponder on the stv0299 device. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de --- /usr/src/linux-3.1.10-1.16/drivers/media/dvb/frontends/stb0899_drv.c 2012-08-14 21:59:59.0 +0200 +++ stb0899_drv.c 2012-08-14 21:29:17.0 +0200 @@ -1596,6 +1596,7 @@ static int stb0899_get_frontend(struct d dprintk(state->verbose, FE_DEBUG, 1, "Get params"); p->u.qpsk.symbol_rate = internal->srate; + p->frequency = internal->freq; return 0; }
STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
Hi, it seems that my 9 years old LNBs got some drift over time, as tuning takes quite a while until I get a lock. So I thought I could compensate this offset by adjusting VDR's diseqc.conf. Therefore I first hacked some logging into VDR's tuner code to read and output the above mentioned property once it got a lock after tuning. As VDR's EPG scanner travels over all transponders when idle, I get offset values for all transponders and can then try to find some average offset to put into diseqc.conf. So here are several "travel" results for a single transponder ordered by Delta: Sat.Pol.BandFreq (MHz) Set Freq (MHz) Get Delta (MHz) S13,0E H H 11938 11930,528 -7,472 S13,0E H H 11938 11936,294 -1,706 S13,0E H H 11938 11938,917 0,917 S13,0E H H 11938 11939,158 1,158 S13,0E H H 11938 11939,906 1,906 S13,0E H H 11938 11939,965 1,965 S13,0E H H 11938 11940,029 2,029 S13,0E H H 11938 11940,032 2,032 S13,0E H H 11938 11940,103 2,103 S13,0E H H 11938 11940,112 2,112 S13,0E H H 11938 11940,167 2,167 S13,0E H H 11938 11941,736 3,736 S13,0E H H 11938 11941,736 3,736 S13,0E H H 11938 11941,736 3,736 S13,0E H H 11938 11942,412 4,412 S13,0E H H 11938 11943,604 5,604 S13,0E H H 11938 11943,604 5,604 S13,0E H H 11938 11943,604 5,604 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,472 7,472 S13,0E H H 11938 11945,777 7,777 S13,0E H H 11938 11945,777 7,777 S13,0E H H 11938 11945,777 7,777 S13,0E H H 11938 11945,777 7,777 I really wonder why Delta varies that much, and there are other transponders in the same band which have no larger deltas then 3 MHz. So is it at all possible to determine LNB drift in that way? My other device, a STB0899, always reports the set frequency. So it seems driver dependent whether it reports the actually locked frequency found by the zig-zag-algorithm or just the set frequency to tune to. Thanks in advance for any replies. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de -- 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
