linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
@ 2012-08-14  8:53 Reinhard Nissl
  2012-08-14 11:10 ` Antti Palosaari
  2012-08-14 12:05 ` Manu Abraham
  0 siblings, 2 replies; 7+ messages in thread
From: Reinhard Nissl @ 2012-08-14  8:53 UTC (permalink / raw)
  To: linux-media

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.	Band	Freq (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:rnissl@gmx.de

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
  2012-08-14  8:53 STV0299: reading property DTV_FREQUENCY -- what am I expected to get? Reinhard Nissl
@ 2012-08-14 11:10 ` Antti Palosaari
  2012-08-14 12:05 ` Manu Abraham
  1 sibling, 0 replies; 7+ messages in thread
From: Antti Palosaari @ 2012-08-14 11:10 UTC (permalink / raw)
  To: Reinhard Nissl; +Cc: linux-media

On 08/14/2012 11:53 AM, Reinhard Nissl wrote:
> 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.    Band    Freq (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.

That is tricky part. I recently explained that too when Mauro added 
get_afc() callback:
http://www.spinics.net/lists/linux-media/msg51308.html

It should return actual frequency frontend is tuned (I am not sure about 
DVB-S as there is IF/LNB). But the way DVBv5 API is implemented, using 
cache, you never know if it is same value you set or some real value 
tuner is listening. You can never trust APIv5 get values - those are 1) 
just same you have set or 2) those could be values updated by driver.

>
> Thanks in advance for any replies.
>
> Bye.

regards
Antti


-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
  2012-08-14  8:53 STV0299: reading property DTV_FREQUENCY -- what am I expected to get? Reinhard Nissl
  2012-08-14 11:10 ` Antti Palosaari
@ 2012-08-14 12:05 ` Manu Abraham
  2012-08-14 20:15   ` Reinhard Nissl
  1 sibling, 1 reply; 7+ messages in thread
From: Manu Abraham @ 2012-08-14 12:05 UTC (permalink / raw)
  To: Reinhard Nissl; +Cc: linux-media

Hi,

On Tue, Aug 14, 2012 at 2:23 PM, Reinhard Nissl <rnissl@gmx.de> wrote:
> 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.    Band    Freq (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.


The LNB drift is due to the cheap RC oscillator in standard LNB's which are
temperature dependant. So, the oscillator frequency that you might experience
at mid-day, might not be same as that at midnight. The capacitors are ceramic
capacitors, so there isn't likely the chance of the capacitor changing
it's value
too much over time, but there exists other issues such as parasitic
capacitances
when the LNB shell looses it's hermetic seal.

I have seen the drift overlapping another transponder with the stv0299 in some
scenarios, but don't see how this can be fixed reliably.

>
> 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.


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.

Regards,
Manu

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
  2012-08-14 12:05 ` Manu Abraham
@ 2012-08-14 20:15   ` Reinhard Nissl
  2012-08-15 14:41     ` Reinhard Nissl
  2012-08-15 22:10     ` Mauro Carvalho Chehab
  0 siblings, 2 replies; 7+ messages in thread
From: Reinhard Nissl @ 2012-08-14 20:15 UTC (permalink / raw)
  To: Manu Abraham; +Cc: linux-media

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

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.	Band	Freq (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:rnissl@gmx.de

[-- Attachment #2: stb0899_drv-report-internal-freq-via-get_frontend.diff --]
[-- Type: text/x-patch, Size: 375 bytes --]

--- /usr/src/linux-3.1.10-1.16/drivers/media/dvb/frontends/stb0899_drv.c	2012-08-14 21:59:59.000000000 +0200
+++ stb0899_drv.c	2012-08-14 21:29:17.000000000 +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;
 }

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
  2012-08-14 20:15   ` Reinhard Nissl
@ 2012-08-15 14:41     ` Reinhard Nissl
  2012-08-15 22:10     ` Mauro Carvalho Chehab
  1 sibling, 0 replies; 7+ messages in thread
From: Reinhard Nissl @ 2012-08-15 14:41 UTC (permalink / raw)
  To: Manu Abraham; +Cc: linux-media

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.    Band    Freq (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.

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:rnissl@gmx.de

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
  2012-08-14 20:15   ` Reinhard Nissl
  2012-08-15 14:41     ` Reinhard Nissl
@ 2012-08-15 22:10     ` Mauro Carvalho Chehab
  2012-08-18 12:59       ` Reinhard Nissl
  1 sibling, 1 reply; 7+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-15 22:10 UTC (permalink / raw)
  To: Reinhard Nissl; +Cc: Manu Abraham, linux-media

Em 14-08-2012 17:15, Reinhard Nissl escreveu:
> 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.    Band    Freq (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.

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.000000000 +0200
+++ b/drivers/media/dvb/frontends/stb0899_drv.c	2012-08-14 21:29:17.000000000 +0200

as otherwise developer's scripts won't get it right.

Thanks,
Mauro.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?
  2012-08-15 22:10     ` Mauro Carvalho Chehab
@ 2012-08-18 12:59       ` Reinhard Nissl
  0 siblings, 0 replies; 7+ messages in thread
From: Reinhard Nissl @ 2012-08-18 12:59 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Manu Abraham, linux-media

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

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.000000000 +0200
> +++ b/drivers/media/dvb/frontends/stb0899_drv.c	2012-08-14 21:29:17.000000000 +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:rnissl@gmx.de

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: stb0899_drv-report-internal-freq-via-get_frontend-git.diff --]
[-- Type: text/x-patch; name="stb0899_drv-report-internal-freq-via-get_frontend-git.diff", Size: 555 bytes --]

stb0899: return internally tuned frequency via get_frontend.

Signed-off-by: Reinhard Nißl <rnissl@gmx.de>

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;
 }

^ permalink raw reply related	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-08-18 13:00 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-14  8:53 STV0299: reading property DTV_FREQUENCY -- what am I expected to get? Reinhard Nissl
2012-08-14 11:10 ` Antti Palosaari
2012-08-14 12:05 ` Manu Abraham
2012-08-14 20:15   ` Reinhard Nissl
2012-08-15 14:41     ` Reinhard Nissl
2012-08-15 22:10     ` Mauro Carvalho Chehab
2012-08-18 12:59       ` Reinhard Nissl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).