[linux-dvb] (no subject)

[linux-dvb] (no subject)

[ldvb]

Hi!

Maybe, somebody could help...
I have the next list of transponders params:
S 11605700 V 44948000 5/6
S 11043300 H 44948000 5/6
(at Orion-express sat, www.orion-express.ru)

and TT-budget card.
Bitrate is approx. 67Mbit.
V-transponder works well.
For the H, there are problems:
Tuner status:  Signal Lock Carrier VITERBI Sync
Signal Strength = 70% SNR = 67% BER = efc Uncorrected Blocks = 3
Signal Strength = 70% SNR = 67% BER = d80 Uncorrected Blocks = 25
Signal Strength = 70% SNR = 67% BER = c77 Uncorrected Blocks = 7
Signal Strength = 70% SNR = 67% BER = d2f Uncorrected Blocks = 0
Signal Strength = 70% SNR = 67% BER = de6 Uncorrected Blocks = 2
Signal Strength = 70% SNR = 67% BER = d9c Uncorrected Blocks = 0
Signal Strength = 70% SNR = 67% BER = ce7 Uncorrected Blocks = 1

The same card used with Hotbird works well with horizontal polarization 
(bitrate approx. 35Mbit).
Cable and receivers are good (checked by another dvb hardware on the 
same cable).

Thanx!


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] (no subject)

[Vladimir Prudnikov]

What TT card have you got?
I'm unable to lock to any of Orion Express transponders with TT S2-3200.

Please contact me so that we can try together in case you got the same  
card.

Regards,
Vladimir

On Mar 14, 2008, at 4:29 PM, ldvb@ns.bog.msu.ru wrote:

>
> Hi!
>
> Maybe, somebody could help...
> I have the next list of transponders params:
> S 11605700 V 44948000 5/6
> S 11043300 H 44948000 5/6
> (at Orion-express sat, www.orion-express.ru)
>
> and TT-budget card.
> Bitrate is approx. 67Mbit.
> V-transponder works well.
> For the H, there are problems:
> Tuner status:  Signal Lock Carrier VITERBI Sync
> Signal Strength = 70% SNR = 67% BER = efc Uncorrected Blocks = 3
> Signal Strength = 70% SNR = 67% BER = d80 Uncorrected Blocks = 25
> Signal Strength = 70% SNR = 67% BER = c77 Uncorrected Blocks = 7
> Signal Strength = 70% SNR = 67% BER = d2f Uncorrected Blocks = 0
> Signal Strength = 70% SNR = 67% BER = de6 Uncorrected Blocks = 2
> Signal Strength = 70% SNR = 67% BER = d9c Uncorrected Blocks = 0
> Signal Strength = 70% SNR = 67% BER = ce7 Uncorrected Blocks = 1
>
> The same card used with Hotbird works well with horizontal  
> polarization
> (bitrate approx. 35Mbit).
> Cable and receivers are good (checked by another dvb hardware on the
> same cable).
>
> Thanx!
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] (no subject)

[ldvb]

On Fri, 14 Mar 2008, Vladimir Prudnikov wrote:

> What TT card have you got?
> I'm unable to lock to any of Orion Express transponders with TT S2-3200.
I have GI-SS3 (TT budget S-1401)
Works fine with Orion (famous for max bitrate of 68Mbits).
Seems that Mantis-based card could not do the same. Maybe, I'm mistaken.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] (no subject)

[Vladimir Prudnikov]

How does it work with Orion if it doesn't have a CI?

Regards,
Vladimir

On Mar 14, 2008, at 5:39 PM, ldvb@ns.bog.msu.ru wrote:

>
>
> On Fri, 14 Mar 2008, Vladimir Prudnikov wrote:
>
>> What TT card have you got?
>> I'm unable to lock to any of Orion Express transponders with TT  
>> S2-3200.
> I have GI-SS3 (TT budget S-1401)
> Works fine with Orion (famous for max bitrate of 68Mbits).
> Seems that Mantis-based card could not do the same. Maybe, I'm  
> mistaken.
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT budget S-1401 Horizontal transponder fails

[ldvb]

On Fri, 14 Mar 2008, Vladimir Prudnikov wrote:

> How does it work with Orion if it doesn't have a CI?
>>> What TT card have you got?
>>> I'm unable to lock to any of Orion Express transponders with TT S2-3200.
>> I have GI-SS3 (TT budget S-1401)
There are several free channels to view. Also, I have STB with irdeto 
card. Errors in the cahnnel were detected visually first.
But it is possible to detect the problem with the stream directly: one can 
get the full TS from the card, and get statistics for BER (shown in my 
first message).

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[ldvb]

Hi again!

Could somebody help with ideas, why there are mistakes in the channel when 
using H pol. on the TT S-1401 card (while V works fine)?
I do not know where and how to start digging the problem.
On Windows everything is fine.
Frequencies: H is 11043, V is 11606, symb. rate 44948.
Total bitrate is approx. 68Mbit.

Thanx!


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] TT-budget S-1401 issues. Horizontal transponder fails

[ldvb]

Hi again!

New experiment with TT-budget S-1401 shows the next result:
using 2 boxes - one with Linux for error detection and one with Windows 
for control. Both are connected via the passive splitter to the sat. So, 
on Windows ProgDVB is running, controlling the  transponder. And it works 
fine, without errors, showing the free prog. Linux box with the similar 
card shows errors in the stream (at the same time):
Tuner status:  Signal Lock Carrier VITERBI Sync
Signal Strength = 59% SNR = 66% BER = 138c Uncorrected Blocks = 9

Note: strength on the windows box is 78% (10db from 88 were eaten by the 
splitter). Seems, that the problem is not with diseqc control.
Any ideas?

Thanx!


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

ldvb@ns.bog.msu.ru wrote:
> Could somebody help with ideas, why there are mistakes in the channel when 
> using H pol. on the TT S-1401 card (while V works fine)?
> I do not know where and how to start digging the problem.
> On Windows everything is fine.
> Frequencies: H is 11043, V is 11606, symb. rate 44948.
> Total bitrate is approx. 68Mbit.

If the same machine/card/cable works with windows, and does not work
with the linux driver, there must be an issue in the driver.

Unfortunately, this is a common problem because most vendors do not
support linux. So many drivers are sub-optimal.

Sorry, if you want to have your problem fixed, you have dig through the
register programming of the frontend driver. Use an i2c sniffer and
compare the register settings of the the windows driver with those of
the linux driver...

If you want to experiment with some parameters, you might have a look at
changeset
  http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239
Maybe you can find a better register setting which fixes your problem.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[ldvb]

On Thu, 20 Mar 2008, Oliver Endriss wrote:

> Sorry, if you want to have your problem fixed, you have dig through the
> register programming of the frontend driver. Use an i2c sniffer and
> compare the register settings of the the windows driver with those of
> the linux driver...
> If you want to experiment with some parameters, you might have a look at
> changeset
>  http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239
> Maybe you can find a better register setting which fixes your problem.

Increased baseband cut-off helps! (tda826*.c)
so, making it
buf[6] = 0xfe;
solves the problem.
Maybe, I'll check other values.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Hartmut Hackmann]

Hi,

ldvb@ns.bog.msu.ru schrieb:
> On Thu, 20 Mar 2008, Oliver Endriss wrote:
> 
>> Sorry, if you want to have your problem fixed, you have dig through the
>> register programming of the frontend driver. Use an i2c sniffer and
>> compare the register settings of the the windows driver with those of
>> the linux driver...
>> If you want to experiment with some parameters, you might have a look at
>> changeset
>>  http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239
>> Maybe you can find a better register setting which fixes your problem.
> 
> Increased baseband cut-off helps! (tda826*.c)
> so, making it
> buf[6] = 0xfe;
> solves the problem.
> Maybe, I'll check other values.
> 
This might be right! I could not get good information regarding the
transponder bandwidths. We might need to make this depend on the
symbol rate or a module parameter.
Can we grind this out after easter?

Best regards
  Hartmut

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Hi Hartmut,

Hartmut Hackmann wrote:

> This might be right! I could not get good information regarding the
> transponder bandwidths. We might need to make this depend on the
> symbol rate or a module parameter.


You can calculate the tuner bandwidth from the transponder symbol rate
(in Mbaud) for DVB-S:

BW = (1 + RO) * SR/2 + 5) * 1.3


Regards,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Hartmut Hackmann]

Hi, Manu

Manu Abraham schrieb:
> Hi Hartmut,
> 
> Hartmut Hackmann wrote:
> 
>> This might be right! I could not get good information regarding the
>> transponder bandwidths. We might need to make this depend on the
>> symbol rate or a module parameter.
> 
> 
> You can calculate the tuner bandwidth from the transponder symbol rate
> (in Mbaud) for DVB-S:
> 
> BW = (1 + RO) * SR/2 + 5) * 1.3
> 
> 
> Regards,
> Manu
> 
Thanks for the hint. So we should be able to tune this according to the
expected symbol rate - good.

Best regards
  Hartmut

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

ldvb@ns.bog.msu.ru wrote:
> 
> On Thu, 20 Mar 2008, Oliver Endriss wrote:
> 
> > Sorry, if you want to have your problem fixed, you have dig through the
> > register programming of the frontend driver. Use an i2c sniffer and
> > compare the register settings of the the windows driver with those of
> > the linux driver...
> > If you want to experiment with some parameters, you might have a look at
> > changeset
> >  http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239
> > Maybe you can find a better register setting which fixes your problem.
> 
> Increased baseband cut-off helps! (tda826*.c)
> so, making it
> buf[6] = 0xfe;
> solves the problem.
> Maybe, I'll check other values.

Hm - buf[6] is not the baseband cut-off.

I guess you changed buf[5] back to 0xff, correct?

Could you please find out the _minimum_ value required?
You might try 0xff, 0xf7, 0xef, 0xe7, 0xdf, 0xd7, 0xcf, 0xc7 and so on.

The symbol rate of the transponder is 44948000, right?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

Hi,

Manu Abraham wrote:
> Hi Hartmut,
> 
> Hartmut Hackmann wrote:
> 
> > This might be right! I could not get good information regarding the
> > transponder bandwidths. We might need to make this depend on the
> > symbol rate or a module parameter.
> 
> You can calculate the tuner bandwidth from the transponder symbol rate
> (in Mbaud) for DVB-S:
> 
> BW = (1 + RO) * SR/2 + 5) * 1.3

Apparently I need some lessons in signal theory. ;-)
What does R0 stand for?

Do we have to select a higher cut-off value to compensate for the LNB
drift and other stuff like that?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[ldvb]

On Thu, 20 Mar 2008, Hartmut Hackmann wrote:

>> buf[6] = 0xfe;
>> solves the problem.
>> Maybe, I'll check other values.
> This might be right! I could not get good information regarding the
> transponder bandwidths. We might need to make this depend on the
> symbol rate or a module parameter.
> Can we grind this out after easter?
Yes!
would be good to have automatic update, depending on rate, but module 
param... or, maybe, better, over ioctl, to make it possible to switch 
transponders without computer reboot?

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[ldvb]

On Fri, 21 Mar 2008, Oliver Endriss wrote:

>> solves the problem.
>> Maybe, I'll check other values.
>
> Hm - buf[6] is not the baseband cut-off.
> I guess you changed buf[5] back to 0xff, correct?
ah! sorry!
//      buf[5] = 0x77; // baseband cut-off 19 MHz
         buf[5] = 0xf1; // new: baseband cut-off ?MHz
         buf[6] = 0xfe; // baseband gain 9 db + no RF attenuation

> Could you please find out the _minimum_ value required?
> You might try 0xff, 0xf7, 0xef, 0xe7, 0xdf, 0xd7, 0xcf, 0xc7 and so on.
> The symbol rate of the transponder is 44948000, right?
yes.


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[ldvb]

On Fri, 21 Mar 2008, Oliver Endriss wrote:

> Could you please find out the _minimum_ value required?
> You might try 0xff, 0xf7, 0xef, 0xe7, 0xdf, 0xd7, 0xcf, 0xc7 and so on.
So, some statistics:
(Freq: 11043, Horizontal, bitrate 44948)

ff:
Tuner status:  Signal Lock Carrier VITERBI Sync
Signal Strength = 58% SNR = 89% BER = 0 Uncorrected Blocks = 0
 		(strength is flashing, 58-59, more 59)
f7,ef,e7,df,d7,cf:
Signal Strength = 59% SNR = 89% BER = 0 Uncorrected Blocks = 0
 	(with cf SNR is flashing, 88-89, more 88)
c7,bf:
Signal Strength = 59% SNR = 88% BER = 0 Uncorrected Blocks = 0
 	(with bf SNR is flashing, 87-88, more 88)
b7,af:
Signal Strength = 59% SNR = 87% BER = 0 Uncorrected Blocks = 0
 	(with b7 SNR is 87, rare - 88, with af - 87-86, more 87)
a7,a0:
Signal Strength = 59% SNR = 86% BER = 0 Uncorrected Blocks = 0
 	(a7,a0: SNR=85-87, more 86)
9a:
Signal Strength = 59% SNR = 85% BER = 0 Uncorrected Blocks = 0
 	(9a: SNR rare 84)
97:
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0 (!!!!!!!)
 	(Very rare small BER counts) (!!!!!!!!!!!)
95:
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 3 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 83% BER = 0 Uncorrected Blocks = 0

8f:
Signal Strength = 59% SNR = 80% BER = 25 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = b Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 6 Uncorrected Blocks = 0

8c:
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 3 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 8 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0

8b:
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 12 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 0 Uncorrected Blocks = 0

8a:
Signal Strength = 59% SNR = 79% BER = 8 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 79% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 79% BER = 6 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = f Uncorrected Blocks = 0
Signal Strength = 59% SNR = 79% BER = 0 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 80% BER = 7 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 79% BER = d Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 3f3 Uncorrected Blocks = 0

87:
Signal Strength = 59% SNR = 75% BER = 6c Uncorrected Blocks = 0
Signal Strength = 59% SNR = 75% BER = 60 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 75% BER = 54 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 76% BER = 45 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 76% BER = 6f Uncorrected Blocks = 0
Signal Strength = 59% SNR = 76% BER = 61 Uncorrected Blocks = 0

7f:
Signal Strength = 58% SNR = 71% BER = 246 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 327 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 72% BER = 28c Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 1dd Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 1ff Uncorrected Blocks = 0

7c:
Signal Strength = 59% SNR = 71% BER = 29d Uncorrected Blocks = 0

7a:
Signal Strength = 59% SNR = 71% BER = 2d6 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 72% BER = 30a Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 2e8 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 308 Uncorrected Blocks = 0

79:
Signal Strength = 59% SNR = 71% BER = 2ad Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 26e Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 323 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 295 Uncorrected Blocks = 0

78:
Signal Strength = 59% SNR = 71% BER = 236 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 2c2 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 2d8 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 223 Uncorrected Blocks = 0
Signal Strength = 59% SNR = 71% BER = 203 Uncorrected Blocks = 0

77:(!!!!!!!!!!!!!!!!!!!)
Signal Strength = 59% SNR = 67% BER = dd8 Uncorrected Blocks = 3b
Signal Strength = 58% SNR = 67% BER = dc4 Uncorrected Blocks = 4
Signal Strength = 58% SNR = 67% BER = cff Uncorrected Blocks = 3
Signal Strength = 59% SNR = 67% BER = e16 Uncorrected Blocks = 3
Signal Strength = 58% SNR = 67% BER = e19 Uncorrected Blocks = 1
Signal Strength = 58% SNR = 67% BER = 118e Uncorrected Blocks = 16


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Hi Oliver,

Oliver Endriss wrote:
> Hi,
> 
> Manu Abraham wrote:
>> Hi Hartmut,
>>
>> Hartmut Hackmann wrote:
>>
>>> This might be right! I could not get good information regarding the
>>> transponder bandwidths. We might need to make this depend on the
>>> symbol rate or a module parameter.
>> You can calculate the tuner bandwidth from the transponder symbol rate
>> (in Mbaud) for DVB-S:
>>
>> BW = (1 + RO) * SR/2 + 5) * 1.3
> 
> Apparently I need some lessons in signal theory. ;-)
> What does R0 stand for?

RO stands for Rolloff. This isn't anything big, but just defines the
sharpness of the bandwidth curve. You can think how a filter's bandwidth
would look like, when it is plotted out. This is just a filter
characteristic.

Normally why you need this is not new. Traditionally for old PLL based
tuners, this used to be in hardware, ie a LC component in the pre
stages, prior to the tuner.

With the arrival of Silicon Tuners, things do have changed. These things
have been made software configurable. There are advantages and
disadvantages to this. Well, there's so much that can talked about it,
but well let me not make it too long.

For Broadcast applications, ie all TV signals that we receive RO = 35%
We do have other rolloff as well, but generally the others are not used
in broadcast apps, but for professional purposes. When you have a lower
rolloff, what happens is that the filter is more of a tuned filter and
considered narrower slightly.

The advantage of a narrower filter is that since the edges fall of
sharply, lesser power is wasted, but brings in the disadvantage that the
spectrum is a bit more congested, but alternatibvely somebody could just
argue as well, you can pack in more into the entire spectrum.


> Do we have to select a higher cut-off value to compensate for the LNB
> drift and other stuff like that?

The "5" in there, is in fact implies +/-5Mhz for the LNB drift (5 Mhz on
either side off the offset. A LNB can drift in either direction at
different periods of the day, depending on the temperature. This drift
can cause an acquisition to fail, or an already acquired LOCK to fail on
a very general note). The drift is standard and is specified in one of
the ETSI specifications, one which i read a while back but don't
remember the specification number.


Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Manu Abraham wrote:
> Hi Oliver,
> 
> Oliver Endriss wrote:
>> Hi,
>>
>> Manu Abraham wrote:
>>> Hi Hartmut,
>>>
>>> Hartmut Hackmann wrote:
>>>
>>>> This might be right! I could not get good information regarding the
>>>> transponder bandwidths. We might need to make this depend on the
>>>> symbol rate or a module parameter.
>>> You can calculate the tuner bandwidth from the transponder symbol rate
>>> (in Mbaud) for DVB-S:
>>>
>>> BW = (1 + RO) * SR/2 + 5) * 1.3
>> Apparently I need some lessons in signal theory. ;-)
>> What does R0 stand for?
> 
> RO stands for Rolloff. This isn't anything big, but just defines the
> sharpness of the bandwidth curve. You can think how a filter's bandwidth
> would look like, when it is plotted out. This is just a filter
> characteristic.
> 
> Normally why you need this is not new. Traditionally for old PLL based
> tuners, this used to be in hardware, ie a LC component in the pre
> stages, prior to the tuner.
> 
> With the arrival of Silicon Tuners, things do have changed. These things
> have been made software configurable. There are advantages and
> disadvantages to this. Well, there's so much that can talked about it,
> but well let me not make it too long.
> 
> For Broadcast applications, ie all TV signals that we receive RO = 35%
> We do have other rolloff as well, but generally the others are not used
> in broadcast apps, but for professional purposes. When you have a lower
> rolloff, what happens is that the filter is more of a tuned filter and
> considered narrower slightly.
> 
> The advantage of a narrower filter is that since the edges fall of
> sharply, lesser power is wasted, but brings in the disadvantage that the
> spectrum is a bit more congested, but alternatibvely somebody could just
> argue as well, you can pack in more into the entire spectrum.
> 
> 
>> Do we have to select a higher cut-off value to compensate for the LNB
>> drift and other stuff like that?
> 
> The "5" in there, is in fact implies +/-5Mhz for the LNB drift (5 Mhz on
> either side off the offset. A LNB can drift in either direction at
> different periods of the day, depending on the temperature. This drift
> can cause an acquisition to fail, or an already acquired LOCK to fail on
> a very general note). The drift is standard and is specified in one of
> the ETSI specifications, one which i read a while back but don't
> remember the specification number.
> 

I just looked at the tuner (TDA8262) datasheet, it says:

The internal circuitry performs the Zero-IF quadrature frequency
conversion and two in-phase (IP/IN) and two quadrature(QP/QN) output
signals can directly be used to feed a Satellite Demodulator and Decoder
circuit (SDD). Low pass filter cut-off frequency can be adjusted from 5
MHz to 36 MHz in 32 steps. This allows a large flexibility in the SDD
input. 10 gain values are present at output amplifier to compensate
cut-off frequency adjustment and single output application.




Maybe, the best thing to do is divide the spectrum into 32 parts with
the lower end at 5MHz and the upper end at 36Mhz equi-distantly. I don't
know  why it is done in steps as mentioned in there, but i think it is
due to a NCO (Numerically Controlled Oscillator) which has 32 steps.

With these different steps, based on the calculation, you can slightly
optimize the offset if needed for the ones at the end of the spectrum,
from what you calculated out.

Also note that, the tuner can do 5 - 36 Mhz, so 45 MSPS will be at the
very last block and in the case of almost all silicon tuners will need a
bit of care to handle properly, also you might see a higher BER in some
cases when the filter cannot be pushed to what extend it needs to be.

I took a look at the driver, tda826x.c, just saw how simple that driver
looks. No wonder ... Even with the vendors, there are just a few people
who can really explain all the aspects.

(RF and math can sometimes be considered as drinking and driving on a
much lighter aspect, when used "properly", anyone who looks at it, won't
understand what's going on and what would happen next, in most cases,
unless you are in the same state, where you might tend to be in the same
harmonic. Maybe that's why some people claim that beer provides a much
higher level of success. ;-) )

The worst part in there is that, like all Silicon tuners, gain also
plays a significant part. Normally the vendor provides what gain is
required for each step, but the datasheet doesn't seem to specify that
any place. Normally the higher gain will be applied to the lower SR, and
the lower gain to the higher SR. Maybe you can experiment with the gain
distribution with regards to the SR.

The reason to have a gain distribution, is to avoid the demodulator
getting saturated somehow. The "somehow" part is a bit device specific.

There's so much math going on within the demodulator. In fact a
demodulator is nothing but a device doing a transform from one domain to
the other, as it's core functionality although there are other features
too in a demodulator.

Additionally, it looks like the VCO needs calibration too .. The
calibration helps the VCO to remain within the defined limits, rather
than with some unknown offset to a tuned frequency. All of which seems
to be missing from the driver. Our drivers are far away from being
sub-optimal even. It isn't doing anything what is the bare minimum even.
It looks like the driver is a 1:1 register dump from an existing windows
driver for a particular frequency, symbol rate and rolloff.. :-(

The datasheet is also a bit cryptic. It looks to me, at first glance
that the VCO needs to be calibrated for that specific step, wait for
that specific VCO comparator settling time, then attempt a tune with the
relevant step. This might help to reduce the BER as seen by the
demodulator, what i saw in another post by somebody else.

Well it is not easy too, but far from it. .. So can't blame anyone for
it. Also with all this done, it needs some tinkering practically, to
reach the best what is possible within the resources available.

Regards,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Matthias Schwarzott]

On Freitag, 21. März 2008, Oliver Endriss wrote:
> Hi,
>
> Manu Abraham wrote:
> > Hi Hartmut,
> >
> > Hartmut Hackmann wrote:
> > > This might be right! I could not get good information regarding the
> > > transponder bandwidths. We might need to make this depend on the
> > > symbol rate or a module parameter.
> >
> > You can calculate the tuner bandwidth from the transponder symbol rate
> > (in Mbaud) for DVB-S:
> >
> > BW = (1 + RO) * SR/2 + 5) * 1.3
>
> Apparently I need some lessons in signal theory. ;-)
> What does R0 stand for?
>
> Do we have to select a higher cut-off value to compensate for the LNB
> drift and other stuff like that?
>
Zarlink zl1003x datasheet (avail on net) tells this:
fbw = (alpha * symbol rate) / (2.0 * 0.8) + foffset

where alpha is roll-off 1.35 for dvb-s and 1.20 for DSS

The manual suggests to use highest possible bandwidth for aquiring a lock.
And after that read back the offset from the demod and adjust the tuner then.

Regards
Matthias

-- 
Matthias Schwarzott (zzam)

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Hi Mathias,

Matthias Schwarzott wrote:
> Zarlink zl1003x datasheet (avail on net) tells this:
> fbw = (alpha * symbol rate) / (2.0 * 0.8) + foffset
> 
> where alpha is roll-off 1.35 for dvb-s and 1.20 for DSS
> 
> The manual suggests to use highest possible bandwidth for aquiring a lock.
> And after that read back the offset from the demod and adjust the tuner then.


There are some small differences between some of the demodulators. Most
of the Intel DVB-S demods have a striking feature, which are found in
few other demods only. This was seen on the Zarlink and Microtune
devices, from where it originated from.

Other vendors also have implementations similar to this such as Fujitsu
and the newer devices from STM. This involves more complexity within the
demodulator core.

They are capable of doing Auto SR. ie, you request the maximum possible,
the demod gives you a SR offset and you can re-adjust the BW filter on
the tuner.

This feature is also more popularly known as "Blindscan", where you need
to just know the frequency of the signal only. This is the basic feature
upon which Blindscan is built upon. Most demods can accomodate a SR
tolerance of around +/-5% only, greater than which they will fail to
acquire. Since the sampling frequency aka Nyquist sampling rate depends
directly on the Symbol rate (SR) in which case you need to know the
Symbol Rate, which is used to set up the tuner BW filter too.

In this regard, you cannot apply the logic that's available for a Auto
SR capable demodulator to a standard demodulator.

Regards,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Matthias Schwarzott]

On Freitag, 21. März 2008, Manu Abraham wrote:
> Hi Mathias,
>
> Matthias Schwarzott wrote:
> > Zarlink zl1003x datasheet (avail on net) tells this:
> > fbw = (alpha * symbol rate) / (2.0 * 0.8) + foffset
> >
> > where alpha is roll-off 1.35 for dvb-s and 1.20 for DSS
> >
> > The manual suggests to use highest possible bandwidth for aquiring a
> > lock. And after that read back the offset from the demod and adjust the
> > tuner then.
>
> There are some small differences between some of the demodulators. Most
> of the Intel DVB-S demods have a striking feature, which are found in
> few other demods only. This was seen on the Zarlink and Microtune
> devices, from where it originated from.
>
> Other vendors also have implementations similar to this such as Fujitsu
> and the newer devices from STM. This involves more complexity within the
> demodulator core.
>
> They are capable of doing Auto SR. ie, you request the maximum possible,
> the demod gives you a SR offset and you can re-adjust the BW filter on
> the tuner.
>
> This feature is also more popularly known as "Blindscan", where you need
> to just know the frequency of the signal only. This is the basic feature
> upon which Blindscan is built upon. Most demods can accomodate a SR
> tolerance of around +/-5% only, greater than which they will fail to
> acquire. Since the sampling frequency aka Nyquist sampling rate depends
> directly on the Symbol rate (SR) in which case you need to know the
> Symbol Rate, which is used to set up the tuner BW filter too.
>
I meant not doing auto SR for demod, but just setting tuner to maximum BW and 
programming demod as usual (with setting SR). And then read offset freq. from 
demod (that is basically the full foffset).
So we can calc the real needed bandwidth filter to get the signal through or 
even retune to get the signal more near to zero-IF.
Maybe this even require a thread to follow drift.

> In this regard, you cannot apply the logic that's available for a Auto
> SR capable demodulator to a standard demodulator.
>
Does only auto SR capable demods offer reading freq. offset back?

Regards,
Matthias



-- 
Matthias Schwarzott (zzam)

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Matthias Schwarzott wrote:
> On Freitag, 21. März 2008, Manu Abraham wrote:
>> Hi Mathias,
>>
>> Matthias Schwarzott wrote:
>>> Zarlink zl1003x datasheet (avail on net) tells this:
>>> fbw = (alpha * symbol rate) / (2.0 * 0.8) + foffset
>>>
>>> where alpha is roll-off 1.35 for dvb-s and 1.20 for DSS
>>>
>>> The manual suggests to use highest possible bandwidth for aquiring a
>>> lock. And after that read back the offset from the demod and adjust the
>>> tuner then.
>> There are some small differences between some of the demodulators. Most
>> of the Intel DVB-S demods have a striking feature, which are found in
>> few other demods only. This was seen on the Zarlink and Microtune
>> devices, from where it originated from.
>>
>> Other vendors also have implementations similar to this such as Fujitsu
>> and the newer devices from STM. This involves more complexity within the
>> demodulator core.
>>
>> They are capable of doing Auto SR. ie, you request the maximum possible,
>> the demod gives you a SR offset and you can re-adjust the BW filter on
>> the tuner.
>>
>> This feature is also more popularly known as "Blindscan", where you need
>> to just know the frequency of the signal only. This is the basic feature
>> upon which Blindscan is built upon. Most demods can accomodate a SR
>> tolerance of around +/-5% only, greater than which they will fail to
>> acquire. Since the sampling frequency aka Nyquist sampling rate depends
>> directly on the Symbol rate (SR) in which case you need to know the
>> Symbol Rate, which is used to set up the tuner BW filter too.
>>
> I meant not doing auto SR for demod, but just setting tuner to maximum BW and 
> programming demod as usual (with setting SR). And then read offset freq. from 
> demod (that is basically the full foffset).

I followed you,

You wanted to do:

1*) Set Tuner to max avail BW (BW directly proportional to SR and RO,
nothing to do with frequency)

2*) You ask the tuner to tune to a frequency

3*) Request the demodulator to acquire at the Nyquist rate (SR involved)

4*) After acquisition and the transform applied internally by the demod,
you get a frequency offset


with the slight change to (1*) Auto SR devices and normal devices, just
do the same thing altogether.

> So we can calc the real needed bandwidth filter to get the signal through or 
> even retune to get the signal more near to zero-IF.
> Maybe this even require a thread to follow drift.


With what math will you calculate BW from Carrier frequency ? AFAIK,
Bandwidth implies Symbols per Second or Symbol Rate and is independant
of frequency.

BW also known as Symbol Frequency according to Shannons Channel capacity
theorem as in:

http://en.wikipedia.org/wiki/Shannon-Hartley_theorem
http://en.wikipedia.org/wiki/Channel_capacity
http://en.wikipedia.org/wiki/Bit_rate

>> In this regard, you cannot apply the logic that's available for a Auto
>> SR capable demodulator to a standard demodulator.
>>
> Does only auto SR capable demods offer reading freq. offset back?


Almost all demods offer a freq offset readback. But how will you set up
the tuner bandwidth filter with a frequency offset readback ?

Anything that i am missing here ?

The tuner bandwidth filter depends upon the available SR, rather than
frequency. It has got nothing to do with the carrier frequency offset
that which is retrieved back from the demodulator.


Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Matthias Schwarzott]

On Freitag, 21. März 2008, Manu Abraham wrote:
> Matthias Schwarzott wrote:
> > On Freitag, 21. März 2008, Manu Abraham wrote:
> >> Hi Mathias,
> >>
> >> Matthias Schwarzott wrote:
> >>> Zarlink zl1003x datasheet (avail on net) tells this:
> >>> fbw = (alpha * symbol rate) / (2.0 * 0.8) + foffset
> >>>
> >>> where alpha is roll-off 1.35 for dvb-s and 1.20 for DSS
> >>>
> >>> The manual suggests to use highest possible bandwidth for aquiring a
> >>> lock. And after that read back the offset from the demod and adjust the
> >>> tuner then.
> >>
> >> There are some small differences between some of the demodulators. Most
> >> of the Intel DVB-S demods have a striking feature, which are found in
> >> few other demods only. This was seen on the Zarlink and Microtune
> >> devices, from where it originated from.
> >>
> >> Other vendors also have implementations similar to this such as Fujitsu
> >> and the newer devices from STM. This involves more complexity within the
> >> demodulator core.
> >>
> >> They are capable of doing Auto SR. ie, you request the maximum possible,
> >> the demod gives you a SR offset and you can re-adjust the BW filter on
> >> the tuner.
> >>
> >> This feature is also more popularly known as "Blindscan", where you need
> >> to just know the frequency of the signal only. This is the basic feature
> >> upon which Blindscan is built upon. Most demods can accomodate a SR
> >> tolerance of around +/-5% only, greater than which they will fail to
> >> acquire. Since the sampling frequency aka Nyquist sampling rate depends
> >> directly on the Symbol rate (SR) in which case you need to know the
> >> Symbol Rate, which is used to set up the tuner BW filter too.
> >
> > I meant not doing auto SR for demod, but just setting tuner to maximum BW
> > and programming demod as usual (with setting SR). And then read offset
> > freq. from demod (that is basically the full foffset).
>
> I followed you,
>
> You wanted to do:
>
> 1*) Set Tuner to max avail BW (BW directly proportional to SR and RO,
> nothing to do with frequency)
>
> 2*) You ask the tuner to tune to a frequency
>
> 3*) Request the demodulator to acquire at the Nyquist rate (SR involved)
>
> 4*) After acquisition and the transform applied internally by the demod,
> you get a frequency offset
>
>
> with the slight change to (1*) Auto SR devices and normal devices, just
> do the same thing altogether.
>
> > So we can calc the real needed bandwidth filter to get the signal through
> > or even retune to get the signal more near to zero-IF.
> > Maybe this even require a thread to follow drift.
>
> With what math will you calculate BW from Carrier frequency ? AFAIK,
> Bandwidth implies Symbols per Second or Symbol Rate and is independant
> of frequency.
>
> BW also known as Symbol Frequency according to Shannons Channel capacity
> theorem as in:
>
> http://en.wikipedia.org/wiki/Shannon-Hartley_theorem
> http://en.wikipedia.org/wiki/Channel_capacity
> http://en.wikipedia.org/wiki/Bit_rate
>
Ack, BW does not depend on frequency.

I just mean this:

Having a signal with BW=20MHz at some frequency. Then tuning to this frequency 
and setting tuner BW to 20MHz will let the signal pass fine.
Same for setting BW to maximum (around 35MHz).

BUT: If LNB or other components drifted away by 5MHz the signal will be cut 
off. Same yelds for larger steps of the tuner so tuned frequency != center 
frequency of signal.
So you need to either tune to another frequency if possible - or enlarge BW of 
tuner by freq. offset (here: 5MHz).


As tuning algo, we also can just start at maximum BW setting and decrease it 
until we reach signal BW + offset between signal center and tuned frequency.
Being too narrow here requires tracking offset changes to not loose lock.

Or a lot simpler: Just add a margin of maybe 5MHz to BW.

Regards
Matthias

-- 
Matthias Schwarzott (zzam)

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Matthias Schwarzott wrote:
> On Freitag, 21. März 2008, Manu Abraham wrote:
>> Matthias Schwarzott wrote:
>>> On Freitag, 21. März 2008, Manu Abraham wrote:
>>>> Hi Mathias,
>>>>
>>>> Matthias Schwarzott wrote:
>>>>> Zarlink zl1003x datasheet (avail on net) tells this:
>>>>> fbw = (alpha * symbol rate) / (2.0 * 0.8) + foffset
>>>>>
>>>>> where alpha is roll-off 1.35 for dvb-s and 1.20 for DSS
>>>>>
>>>>> The manual suggests to use highest possible bandwidth for aquiring a
>>>>> lock. And after that read back the offset from the demod and adjust the
>>>>> tuner then.
>>>> There are some small differences between some of the demodulators. Most
>>>> of the Intel DVB-S demods have a striking feature, which are found in
>>>> few other demods only. This was seen on the Zarlink and Microtune
>>>> devices, from where it originated from.
>>>>
>>>> Other vendors also have implementations similar to this such as Fujitsu
>>>> and the newer devices from STM. This involves more complexity within the
>>>> demodulator core.
>>>>
>>>> They are capable of doing Auto SR. ie, you request the maximum possible,
>>>> the demod gives you a SR offset and you can re-adjust the BW filter on
>>>> the tuner.
>>>>
>>>> This feature is also more popularly known as "Blindscan", where you need
>>>> to just know the frequency of the signal only. This is the basic feature
>>>> upon which Blindscan is built upon. Most demods can accomodate a SR
>>>> tolerance of around +/-5% only, greater than which they will fail to
>>>> acquire. Since the sampling frequency aka Nyquist sampling rate depends
>>>> directly on the Symbol rate (SR) in which case you need to know the
>>>> Symbol Rate, which is used to set up the tuner BW filter too.
>>> I meant not doing auto SR for demod, but just setting tuner to maximum BW
>>> and programming demod as usual (with setting SR). And then read offset
>>> freq. from demod (that is basically the full foffset).
>> I followed you,
>>
>> You wanted to do:
>>
>> 1*) Set Tuner to max avail BW (BW directly proportional to SR and RO,
>> nothing to do with frequency)
>>
>> 2*) You ask the tuner to tune to a frequency
>>
>> 3*) Request the demodulator to acquire at the Nyquist rate (SR involved)
>>
>> 4*) After acquisition and the transform applied internally by the demod,
>> you get a frequency offset
>>
>>
>> with the slight change to (1*) Auto SR devices and normal devices, just
>> do the same thing altogether.
>>
>>> So we can calc the real needed bandwidth filter to get the signal through
>>> or even retune to get the signal more near to zero-IF.
>>> Maybe this even require a thread to follow drift.
>> With what math will you calculate BW from Carrier frequency ? AFAIK,
>> Bandwidth implies Symbols per Second or Symbol Rate and is independant
>> of frequency.
>>
>> BW also known as Symbol Frequency according to Shannons Channel capacity
>> theorem as in:
>>
>> http://en.wikipedia.org/wiki/Shannon-Hartley_theorem
>> http://en.wikipedia.org/wiki/Channel_capacity
>> http://en.wikipedia.org/wiki/Bit_rate
>>
> Ack, BW does not depend on frequency.
> 
> I just mean this:
> 
> Having a signal with BW=20MHz at some frequency. Then tuning to this frequency 
> and setting tuner BW to 20MHz will let the signal pass fine.
> Same for setting BW to maximum (around 35MHz).
> 
> BUT: If LNB or other components drifted away by 5MHz the signal will be cut 
> off. Same yelds for larger steps of the tuner so tuned frequency != center 
> frequency of signal.
> So you need to either tune to another frequency if possible - or enlarge BW of 
> tuner by freq. offset (here: 5MHz).
> 
> 
> As tuning algo, we also can just start at maximum BW setting and decrease it 
> until we reach signal BW + offset between signal center and tuned frequency.
> Being too narrow here requires tracking offset changes to not loose lock.
> 
> Or a lot simpler: Just add a margin of maybe 5MHz to BW.

I guess this is what you mean:



>> 1*) Set Tuner to max avail BW (BW directly proportional to SR and RO,
>> nothing to do with frequency)
>>
>> 2*) You ask the tuner to tune to a frequency
>>
>> 3*) Request the demodulator to acquire at the Nyquist rate (SR involved)
>>
>> 4*) After acquisition and the transform applied internally by the demod,
>> you get a frequency offset



instead of 2*) you have an offsetted center freq (fc). In this case,
what happens is that, your tuner is not at the center and in fact will
waste bandwidth.

In such a circumstance, you want to compensate for this in 1*) by
choosing an excess bandwidth.

This will help, to acquire a LOCK. Things do look well.Now, we have a
larger problem at hand.

The whole point of about bandwidth limiting is to avoid excess
bandwidth, since that excess bandwidth is not really accounted for.

The demodulator might not be able to "walk through" the excess bandwidth.

In such cases, you will just see this as a higher BER (when locked) or
taking a longer time for a "demod LOCK" to acquire. Or even worser, for
the steps which are at the end of the spectrum, and supposing that there
exists a narrow channel adjacent to this slot, Your demod will have a
tendency to LOCK to the adjacent slot or to your required slot, over
which you will have little control over.

This is a problem that people regularly come up with, with most of our
drivers. It's a hard to sort out problem.

The proper solution for this problem, would be to apply the deviation to
center freq. to 2*) rather than (increasing bandwidth) to 1*). While
holding BW the same. (Bandwidth remains the same, it is that which your
frequency is offsetted. Move the center frequency around, rather than
increasing the BW to compensate for the freq. offset)

NOTE: With swzigzag in dvb_frontend, it assumes 1*) and 2*) are the
same. ie drift is added directly to the frequency offset. Also, when you
fix this bug, many frontends will be broken and will not tune. Applies
only to satellite delivery, AFAICT.

Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

Hi Manu,

Manu Abraham wrote:
> Manu Abraham wrote:
> > Hi Oliver,
> > 
> > Oliver Endriss wrote:
> >> Hi,
> >>
> >> Manu Abraham wrote:
> >>> Hi Hartmut,
> >>>
> >>> Hartmut Hackmann wrote:
> >>>
> >>>> This might be right! I could not get good information regarding the
> >>>> transponder bandwidths. We might need to make this depend on the
> >>>> symbol rate or a module parameter.
> >>> You can calculate the tuner bandwidth from the transponder symbol rate
> >>> (in Mbaud) for DVB-S:
> >>>
> >>> BW = (1 + RO) * SR/2 + 5) * 1.3
> >> Apparently I need some lessons in signal theory. ;-)
> >> What does R0 stand for?
> > 
> > RO stands for Rolloff. This isn't anything big, but just defines the
> > sharpness of the bandwidth curve. You can think how a filter's bandwidth
> > would look like, when it is plotted out. This is just a filter
> > characteristic.
> > 
> > Normally why you need this is not new. Traditionally for old PLL based
> > tuners, this used to be in hardware, ie a LC component in the pre
> > stages, prior to the tuner.
> > 
> > With the arrival of Silicon Tuners, things do have changed. These things
> > have been made software configurable. There are advantages and
> > disadvantages to this. Well, there's so much that can talked about it,
> > but well let me not make it too long.
> > 
> > For Broadcast applications, ie all TV signals that we receive RO = 35%
> > We do have other rolloff as well, but generally the others are not used
> > in broadcast apps, but for professional purposes. When you have a lower
> > rolloff, what happens is that the filter is more of a tuned filter and
> > considered narrower slightly.
> > 
> > The advantage of a narrower filter is that since the edges fall of
> > sharply, lesser power is wasted, but brings in the disadvantage that the
> > spectrum is a bit more congested, but alternatibvely somebody could just
> > argue as well, you can pack in more into the entire spectrum.

Thank you for these detailed explanations. This stuff is sometimes hard
to understand for someone who only deals with electronics as a hobby.
;-)

> >> Do we have to select a higher cut-off value to compensate for the LNB
> >> drift and other stuff like that?
> > 
> > The "5" in there, is in fact implies +/-5Mhz for the LNB drift (5 Mhz on
> > either side off the offset. A LNB can drift in either direction at
> > different periods of the day, depending on the temperature. This drift
> > can cause an acquisition to fail, or an already acquired LOCK to fail on
> > a very general note). The drift is standard and is specified in one of
> > the ETSI specifications, one which i read a while back but don't
> > remember the specification number.

Ok, some calculations according your formula

> >>> BW = (1 + RO) * SR/2 + 5) * 1.3

45 MSPS:
BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46

-> cutoff 36 MHz (maximum value supported)

27 MSPS:
BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2

-> cutoff 31 MHz

22 MSPS:
BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8

-> cutoff 26 MHz

Are these calculations correct, or did I miss something here?

> I just looked at the tuner (TDA8262) datasheet, it says:
> 
> The internal circuitry performs the Zero-IF quadrature frequency
> conversion and two in-phase (IP/IN) and two quadrature(QP/QN) output
> signals can directly be used to feed a Satellite Demodulator and Decoder
> circuit (SDD). Low pass filter cut-off frequency can be adjusted from 5
> MHz to 36 MHz in 32 steps.

(See table 14 in the datasheet.)

> This allows a large flexibility in the SDD 
> input. 10 gain values are present at output amplifier to compensate
> cut-off frequency adjustment and single output application.
> 
> 
> 
> 
> Maybe, the best thing to do is divide the spectrum into 32 parts with
> the lower end at 5MHz and the upper end at 36Mhz equi-distantly. I don't
> know  why it is done in steps as mentioned in there, but i think it is
> due to a NCO (Numerically Controlled Oscillator) which has 32 steps.
> 
> With these different steps, based on the calculation, you can slightly
> optimize the offset if needed for the ones at the end of the spectrum,
> from what you calculated out.

Afaics a simple pre-calculated lookup table with 32 entries should do
the job. At least for the cut-off frequency.

> Also note that, the tuner can do 5 - 36 Mhz, so 45 MSPS will be at the
> very last block and in the case of almost all silicon tuners will need a
> bit of care to handle properly, also you might see a higher BER in some
> cases when the filter cannot be pushed to what extend it needs to be.
> 
> I took a look at the driver, tda826x.c, just saw how simple that driver
> looks. No wonder ... Even with the vendors, there are just a few people
> who can really explain all the aspects.
> 
> (RF and math can sometimes be considered as drinking and driving on a
> much lighter aspect, when used "properly", anyone who looks at it, won't
> understand what's going on and what would happen next, in most cases,
> unless you are in the same state, where you might tend to be in the same
> harmonic. Maybe that's why some people claim that beer provides a much
> higher level of success. ;-) )

Ah - now I understand why our drivers work surprisingly well. We ignore
all math due to lack of support from the vendors, and rely on the
assumption that the chip designers had enough beer. :-)

> The worst part in there is that, like all Silicon tuners, gain also
> plays a significant part. Normally the vendor provides what gain is
> required for each step, but the datasheet doesn't seem to specify that
> any place. Normally the higher gain will be applied to the lower SR, and
> the lower gain to the higher SR. Maybe you can experiment with the gain
> distribution with regards to the SR.
> 
> The reason to have a gain distribution, is to avoid the demodulator
> getting saturated somehow. The "somehow" part is a bit device specific.
> 
> There's so much math going on within the demodulator. In fact a
> demodulator is nothing but a device doing a transform from one domain to
> the other, as it's core functionality although there are other features
> too in a demodulator.
> 
> Additionally, it looks like the VCO needs calibration too .. The
> calibration helps the VCO to remain within the defined limits, rather
> than with some unknown offset to a tuned frequency. All of which seems
> to be missing from the driver. Our drivers are far away from being
> sub-optimal even. It isn't doing anything what is the bare minimum even.
> It looks like the driver is a 1:1 register dump from an existing windows
> driver for a particular frequency, symbol rate and rolloff.. :-(

After reading the comments in the driver, I think this is a valid
assumption...

> The datasheet is also a bit cryptic. It looks to me, at first glance
> that the VCO needs to be calibrated for that specific step, wait for
> that specific VCO comparator settling time, then attempt a tune with the
> relevant step. This might help to reduce the BER as seen by the
> demodulator, what i saw in another post by somebody else.
> 
> Well it is not easy too, but far from it. .. So can't blame anyone for
> it. Also with all this done, it needs some tinkering practically, to
> reach the best what is possible within the resources available.

Obviously there is no public datasheet for the TDA10086,
and I don't have a TT-1401 card either. :-(

Changeset http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239 was the result
of combining patches from the ML, more or less educated guessing and
some testing done by a user.

I don't know what register 0x02 exactly does. The tests showed that
value 0x35 was required for reliable tuning, while 0x00 was required to
redurce BER after establishing the lock...

The driver is just a hack, but this is all we have atm.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Manu Abraham]

Hi Oliver,

Oliver Endriss wrote:
> Hi Manu,
> 
> Manu Abraham wrote:
>> Manu Abraham wrote:
>>> Hi Oliver,
>>>
>>> Oliver Endriss wrote:
>>>> Hi,
>>>>
>>>> Manu Abraham wrote:
>>>>> Hi Hartmut,
>>>>>
>>>>> Hartmut Hackmann wrote:
>>>>>
>>>>>> This might be right! I could not get good information regarding the
>>>>>> transponder bandwidths. We might need to make this depend on the
>>>>>> symbol rate or a module parameter.
>>>>> You can calculate the tuner bandwidth from the transponder symbol rate
>>>>> (in Mbaud) for DVB-S:
>>>>>
>>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
>>>> Apparently I need some lessons in signal theory. ;-)
>>>> What does R0 stand for?
>>> RO stands for Rolloff. This isn't anything big, but just defines the
>>> sharpness of the bandwidth curve. You can think how a filter's bandwidth
>>> would look like, when it is plotted out. This is just a filter
>>> characteristic.
>>>
>>> Normally why you need this is not new. Traditionally for old PLL based
>>> tuners, this used to be in hardware, ie a LC component in the pre
>>> stages, prior to the tuner.
>>>
>>> With the arrival of Silicon Tuners, things do have changed. These things
>>> have been made software configurable. There are advantages and
>>> disadvantages to this. Well, there's so much that can talked about it,
>>> but well let me not make it too long.
>>>
>>> For Broadcast applications, ie all TV signals that we receive RO = 35%
>>> We do have other rolloff as well, but generally the others are not used
>>> in broadcast apps, but for professional purposes. When you have a lower
>>> rolloff, what happens is that the filter is more of a tuned filter and
>>> considered narrower slightly.
>>>
>>> The advantage of a narrower filter is that since the edges fall of
>>> sharply, lesser power is wasted, but brings in the disadvantage that the
>>> spectrum is a bit more congested, but alternatibvely somebody could just
>>> argue as well, you can pack in more into the entire spectrum.
> 
> Thank you for these detailed explanations. This stuff is sometimes hard
> to understand for someone who only deals with electronics as a hobby.
> ;-)
> 
>>>> Do we have to select a higher cut-off value to compensate for the LNB
>>>> drift and other stuff like that?
>>> The "5" in there, is in fact implies +/-5Mhz for the LNB drift (5 Mhz on
>>> either side off the offset. A LNB can drift in either direction at
>>> different periods of the day, depending on the temperature. This drift
>>> can cause an acquisition to fail, or an already acquired LOCK to fail on
>>> a very general note). The drift is standard and is specified in one of
>>> the ETSI specifications, one which i read a while back but don't
>>> remember the specification number.
> 
> Ok, some calculations according your formula
> 
>>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
> 
> 45 MSPS:
> BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
> 
> -> cutoff 36 MHz (maximum value supported)
> 
> 27 MSPS:
> BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
> 
> -> cutoff 31 MHz
> 
> 22 MSPS:
> BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
> 
> -> cutoff 26 MHz
> 
> Are these calculations correct, or did I miss something here?


It looks fine, just round it off to the next integer. ie always round it
up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
well, since at the last step, you will not need an offset, since it
would be the last step in the spectrum.

>> I just looked at the tuner (TDA8262) datasheet, it says:
>>
>> The internal circuitry performs the Zero-IF quadrature frequency
>> conversion and two in-phase (IP/IN) and two quadrature(QP/QN) output
>> signals can directly be used to feed a Satellite Demodulator and Decoder
>> circuit (SDD). Low pass filter cut-off frequency can be adjusted from 5
>> MHz to 36 MHz in 32 steps.
> 
> (See table 14 in the datasheet.)

yep


>> This allows a large flexibility in the SDD 
>> input. 10 gain values are present at output amplifier to compensate
>> cut-off frequency adjustment and single output application.
>>
>>
>>
>>
>> Maybe, the best thing to do is divide the spectrum into 32 parts with
>> the lower end at 5MHz and the upper end at 36Mhz equi-distantly. I don't
>> know  why it is done in steps as mentioned in there, but i think it is
>> due to a NCO (Numerically Controlled Oscillator) which has 32 steps.
>>
>> With these different steps, based on the calculation, you can slightly
>> optimize the offset if needed for the ones at the end of the spectrum,
>> from what you calculated out.
> 
> Afaics a simple pre-calculated lookup table with 32 entries should do
> the job. At least for the cut-off frequency.

That's possible, since you need only 32 precomputed entries, rather than
continuous values. That would be much better too, without any runtime
overheads. Just the table needs to be done nice.

>> Also note that, the tuner can do 5 - 36 Mhz, so 45 MSPS will be at the
>> very last block and in the case of almost all silicon tuners will need a
>> bit of care to handle properly, also you might see a higher BER in some
>> cases when the filter cannot be pushed to what extend it needs to be.
>>
>> I took a look at the driver, tda826x.c, just saw how simple that driver
>> looks. No wonder ... Even with the vendors, there are just a few people
>> who can really explain all the aspects.
>>
>> (RF and math can sometimes be considered as drinking and driving on a
>> much lighter aspect, when used "properly", anyone who looks at it, won't
>> understand what's going on and what would happen next, in most cases,
>> unless you are in the same state, where you might tend to be in the same
>> harmonic. Maybe that's why some people claim that beer provides a much
>> higher level of success. ;-) )
> 
> Ah - now I understand why our drivers work surprisingly well. We ignore
> all math due to lack of support from the vendors, and rely on the
> assumption that the chip designers had enough beer. :-)

lol.

>> The worst part in there is that, like all Silicon tuners, gain also
>> plays a significant part. Normally the vendor provides what gain is
>> required for each step, but the datasheet doesn't seem to specify that
>> any place. Normally the higher gain will be applied to the lower SR, and
>> the lower gain to the higher SR. Maybe you can experiment with the gain
>> distribution with regards to the SR.
>>
>> The reason to have a gain distribution, is to avoid the demodulator
>> getting saturated somehow. The "somehow" part is a bit device specific.
>>
>> There's so much math going on within the demodulator. In fact a
>> demodulator is nothing but a device doing a transform from one domain to
>> the other, as it's core functionality although there are other features
>> too in a demodulator.
>>
>> Additionally, it looks like the VCO needs calibration too .. The
>> calibration helps the VCO to remain within the defined limits, rather
>> than with some unknown offset to a tuned frequency. All of which seems
>> to be missing from the driver. Our drivers are far away from being
>> sub-optimal even. It isn't doing anything what is the bare minimum even.
>> It looks like the driver is a 1:1 register dump from an existing windows
>> driver for a particular frequency, symbol rate and rolloff.. :-(
> 
> After reading the comments in the driver, I think this is a valid
> assumption...
> 
>> The datasheet is also a bit cryptic. It looks to me, at first glance
>> that the VCO needs to be calibrated for that specific step, wait for
>> that specific VCO comparator settling time, then attempt a tune with the
>> relevant step. This might help to reduce the BER as seen by the
>> demodulator, what i saw in another post by somebody else.
>>
>> Well it is not easy too, but far from it. .. So can't blame anyone for
>> it. Also with all this done, it needs some tinkering practically, to
>> reach the best what is possible within the resources available.
> 
> Obviously there is no public datasheet for the TDA10086,
> and I don't have a TT-1401 card either. :-(
> 
> Changeset http://linuxtv.org/hg/v4l-dvb/rev/8a19aa788239 was the result
> of combining patches from the ML, more or less educated guessing and
> some testing done by a user.
> 
> I don't know what register 0x02 exactly does. The tests showed that
> value 0x35 was required for reliable tuning, while 0x00 was required to
> redurce BER after establishing the lock...

the register 1x defines 1) reference divider 2) the VCO frequency ratio
The reference divider looks at the step size.

The VCO calibration might make things a bit better, but before starting
to play around with that, i would suggest to check whether the basic
changes themselves help.

What we have here is a generic datasheet for the tuner chip. The step
size, is in fact dictated by external components: Normally an external
tuner manufacturer specifies what step size is ideal for their tuner
implementation, due to external component variations, from the reference
design.

The VCO ratio i don't have a clue exactly, as what it would be doing,
maybe it implies that there is a frequency multiplier/scaler for the
oscillator, don't have a real idea on it, will have a detailed look at
it, when mind is a bit more clear.


Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

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

Hi,

Manu Abraham wrote:
> Oliver Endriss wrote:
> ...
> > Ok, some calculations according your formula
> > 
> >>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
> > 
> > 45 MSPS:
> > BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
> > 
> > -> cutoff 36 MHz (maximum value supported)
> > 
> > 27 MSPS:
> > BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
> > 
> > -> cutoff 31 MHz
> > 
> > 22 MSPS:
> > BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
> > 
> > -> cutoff 26 MHz
> > 
> > Are these calculations correct, or did I miss something here?
> 
> 
> It looks fine, just round it off to the next integer. ie always round it
> up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
> well, since at the last step, you will not need an offset, since it
> would be the last step in the spectrum.
> ...
> > Afaics a simple pre-calculated lookup table with 32 entries should do
> > the job. At least for the cut-off frequency.
> 
> That's possible, since you need only 32 precomputed entries, rather than
> continuous values. That would be much better too, without any runtime
> overheads. Just the table needs to be done nice.

Now I found some time to come back to this issue,

I prepared a small patch to set the cutoff according to Manu's formula.
The calculation is simple enough for integer arithmetic, so it is not
worth to prepare a lookup-table.

@ldvb:
Please test and report whether it works for you.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

[-- Attachment #2: tda826x_cutoff.diff --]
[-- Type: text/x-diff, Size: 1398 bytes --]

diff -r 8f1c4ba078eb linux/drivers/media/dvb/frontends/tda826x.c
--- a/linux/drivers/media/dvb/frontends/tda826x.c	Wed Mar 26 17:41:21 2008 +0100
+++ b/linux/drivers/media/dvb/frontends/tda826x.c	Thu Apr 10 22:17:48 2008 +0200
@@ -76,12 +76,23 @@ static int tda826x_set_params(struct dvb
 	struct tda826x_priv *priv = fe->tuner_priv;
 	int ret;
 	u32 div;
+	u32 ksyms;
+	u32 bandwidth;
 	u8 buf [11];
 	struct i2c_msg msg = { .addr = priv->i2c_address, .flags = 0, .buf = buf, .len = 11 };
 
 	dprintk("%s:\n", __FUNCTION__);
 
 	div = (params->frequency + (1000-1)) / 1000;
+
+	/* BW = (1 + RO) * SR/2 + 5) * 1.3      [SR in MSPS, BW in MHz] */
+	/* with R0 = 0.35 and some transformations: */
+	ksyms = params->u.qpsk.symbol_rate / 1000;
+	bandwidth = (878 * ksyms + 6500000) / 1000000 + 1;
+	if (bandwidth < 5)
+		bandwidth = 5;
+	else if (bandwidth > 36)
+		bandwidth = 36;
 
 	buf[0] = 0x00; // subaddress
 	buf[1] = 0x09; // powerdown RSSI + the magic value 1
@@ -90,7 +101,7 @@ static int tda826x_set_params(struct dvb
 	buf[2] = (1<<5) | 0x0b; // 1Mhz + 0.45 VCO
 	buf[3] = div >> 7;
 	buf[4] = div << 1;
-	buf[5] = 0x77; // baseband cut-off 19 MHz
+	buf[5] = ((bandwidth - 5) << 3) | 7; /* baseband cut-off */
 	buf[6] = 0xfe; // baseband gain 9 db + no RF attenuation
 	buf[7] = 0x83; // charge pumps at high, tests off
 	buf[8] = 0x80; // recommended value 4 for AMPVCO + disable ports.

[-- Attachment #3: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[hermann pitton]

Hi,

Am Donnerstag, den 10.04.2008, 22:40 +0200 schrieb Oliver Endriss:
> Hi,
> 
> Manu Abraham wrote:
> > Oliver Endriss wrote:
> > ...
> > > Ok, some calculations according your formula
> > > 
> > >>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
> > > 
> > > 45 MSPS:
> > > BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
> > > 
> > > -> cutoff 36 MHz (maximum value supported)
> > > 
> > > 27 MSPS:
> > > BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
> > > 
> > > -> cutoff 31 MHz
> > > 
> > > 22 MSPS:
> > > BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
> > > 
> > > -> cutoff 26 MHz
> > > 
> > > Are these calculations correct, or did I miss something here?
> > 
> > 
> > It looks fine, just round it off to the next integer. ie always round it
> > up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
> > well, since at the last step, you will not need an offset, since it
> > would be the last step in the spectrum.
> > ...
> > > Afaics a simple pre-calculated lookup table with 32 entries should do
> > > the job. At least for the cut-off frequency.
> > 
> > That's possible, since you need only 32 precomputed entries, rather than
> > continuous values. That would be much better too, without any runtime
> > overheads. Just the table needs to be done nice.
> 
> Now I found some time to come back to this issue,
> 
> I prepared a small patch to set the cutoff according to Manu's formula.
> The calculation is simple enough for integer arithmetic, so it is not
> worth to prepare a lookup-table.
> 
> @ldvb:
> Please test and report whether it works for you.
> 
> CU
> Oliver
> 

I'm not asked, but give you a report anyway.

On Hotbird 13.0E it makes no difference for me.

Cheers,
Hermann



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Hartmut Hackmann]

Hi,

Oliver Endriss schrieb:
> Hi,
> 
> Manu Abraham wrote:
>> Oliver Endriss wrote:
>> ...
>>> Ok, some calculations according your formula
>>>
>>>>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
>>> 45 MSPS:
>>> BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
>>>
>>> -> cutoff 36 MHz (maximum value supported)
>>>
>>> 27 MSPS:
>>> BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
>>>
>>> -> cutoff 31 MHz
>>>
>>> 22 MSPS:
>>> BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
>>>
>>> -> cutoff 26 MHz
>>>
>>> Are these calculations correct, or did I miss something here?
>>
>> It looks fine, just round it off to the next integer. ie always round it
>> up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
>> well, since at the last step, you will not need an offset, since it
>> would be the last step in the spectrum.
>> ...
>>> Afaics a simple pre-calculated lookup table with 32 entries should do
>>> the job. At least for the cut-off frequency.
>> That's possible, since you need only 32 precomputed entries, rather than
>> continuous values. That would be much better too, without any runtime
>> overheads. Just the table needs to be done nice.
> 
> Now I found some time to come back to this issue,
> 
> I prepared a small patch to set the cutoff according to Manu's formula.
> The calculation is simple enough for integer arithmetic, so it is not
> worth to prepare a lookup-table.
> 
> @ldvb:
> Please test and report whether it works for you.
> 
> CU
> Oliver
> 
I intended to do the same.
Since I have a patch for tda10086 which needs public testing as well, i
would like to propose this:
I do a static check and integrate the patch in my repository together
with my patch and ask for public testing.
Hope this will not overstress the few testers we have ;-)

Best regards
   Hartmut

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

hermann pitton wrote:
> Hi,
> 
> Am Donnerstag, den 10.04.2008, 22:40 +0200 schrieb Oliver Endriss:
> > Hi,
> > 
> > Manu Abraham wrote:
> > > Oliver Endriss wrote:
> > > ...
> > > > Ok, some calculations according your formula
> > > > 
> > > >>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
> > > > 
> > > > 45 MSPS:
> > > > BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
> > > > 
> > > > -> cutoff 36 MHz (maximum value supported)
> > > > 
> > > > 27 MSPS:
> > > > BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
> > > > 
> > > > -> cutoff 31 MHz
> > > > 
> > > > 22 MSPS:
> > > > BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
> > > > 
> > > > -> cutoff 26 MHz
> > > > 
> > > > Are these calculations correct, or did I miss something here?
> > > 
> > > 
> > > It looks fine, just round it off to the next integer. ie always round it
> > > up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
> > > well, since at the last step, you will not need an offset, since it
> > > would be the last step in the spectrum.
> > > ...
> > > > Afaics a simple pre-calculated lookup table with 32 entries should do
> > > > the job. At least for the cut-off frequency.
> > > 
> > > That's possible, since you need only 32 precomputed entries, rather than
> > > continuous values. That would be much better too, without any runtime
> > > overheads. Just the table needs to be done nice.
> > 
> > Now I found some time to come back to this issue,
> > 
> > I prepared a small patch to set the cutoff according to Manu's formula.
> > The calculation is simple enough for integer arithmetic, so it is not
> > worth to prepare a lookup-table.
> > 
> > @ldvb:
> > Please test and report whether it works for you.
> > 
> > CU
> > Oliver
> > 
> 
> I'm not asked, but give you a report anyway.

;-)

> On Hotbird 13.0E it makes no difference for me.

Are you saying that you did not have any problems without the patch,
and is works with the patch, too?

I do not expect a big difference for common symbol rates like 22 MSPS
or 27.5 MSPS, but it will probably make a difference for high or low
symbol rates.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[Oliver Endriss]

Hartmut Hackmann wrote:
> Hi,
> 
> Oliver Endriss schrieb:
> > Hi,
> > 
> > Manu Abraham wrote:
> >> Oliver Endriss wrote:
> >> ...
> >>> Ok, some calculations according your formula
> >>>
> >>>>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
> >>> 45 MSPS:
> >>> BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
> >>>
> >>> -> cutoff 36 MHz (maximum value supported)
> >>>
> >>> 27 MSPS:
> >>> BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
> >>>
> >>> -> cutoff 31 MHz
> >>>
> >>> 22 MSPS:
> >>> BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
> >>>
> >>> -> cutoff 26 MHz
> >>>
> >>> Are these calculations correct, or did I miss something here?
> >>
> >> It looks fine, just round it off to the next integer. ie always round it
> >> up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
> >> well, since at the last step, you will not need an offset, since it
> >> would be the last step in the spectrum.
> >> ...
> >>> Afaics a simple pre-calculated lookup table with 32 entries should do
> >>> the job. At least for the cut-off frequency.
> >> That's possible, since you need only 32 precomputed entries, rather than
> >> continuous values. That would be much better too, without any runtime
> >> overheads. Just the table needs to be done nice.
> > 
> > Now I found some time to come back to this issue,
> > 
> > I prepared a small patch to set the cutoff according to Manu's formula.
> > The calculation is simple enough for integer arithmetic, so it is not
> > worth to prepare a lookup-table.
> > 
> > @ldvb:
> > Please test and report whether it works for you.
> > 
> > CU
> > Oliver
> > 
> I intended to do the same.

If I had been aware of that, I would have done something else. ;-)
My time is rather limited these days...

> Since I have a patch for tda10086 which needs public testing as well, i
> would like to propose this:
> I do a static check and integrate the patch in my repository together
> with my patch and ask for public testing.
> Hope this will not overstress the few testers we have ;-)

Ok. Since I don't have the hardware I ran the code with common symbol
rates. The results looked ok.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TDA10086 fails? DiSEqC bad? TT S-1401 Horizontal transponder fails

[hermann pitton]

Hi,

Am Freitag, den 11.04.2008, 23:29 +0200 schrieb Oliver Endriss:
> hermann pitton wrote:
> > Hi,
> > 
> > Am Donnerstag, den 10.04.2008, 22:40 +0200 schrieb Oliver Endriss:
> > > Hi,
> > > 
> > > Manu Abraham wrote:
> > > > Oliver Endriss wrote:
> > > > ...
> > > > > Ok, some calculations according your formula
> > > > > 
> > > > >>>>> BW = (1 + RO) * SR/2 + 5) * 1.3
> > > > > 
> > > > > 45 MSPS:
> > > > > BW = ((1 + 0.35) * 45/2 + 5) * 1.3 = 46
> > > > > 
> > > > > -> cutoff 36 MHz (maximum value supported)
> > > > > 
> > > > > 27 MSPS:
> > > > > BW = ((1 + 0.35) * 27/2 + 5) * 1.3 = 30,2
> > > > > 
> > > > > -> cutoff 31 MHz
> > > > > 
> > > > > 22 MSPS:
> > > > > BW = ((1 + 0.35) * 22/2 + 5) * 1.3 = 25,8
> > > > > 
> > > > > -> cutoff 26 MHz
> > > > > 
> > > > > Are these calculations correct, or did I miss something here?
> > > > 
> > > > 
> > > > It looks fine, just round it off to the next integer. ie always round it
> > > > up, rather than rounding it down. For the cutoff at 36MHz, it is fine as
> > > > well, since at the last step, you will not need an offset, since it
> > > > would be the last step in the spectrum.
> > > > ...
> > > > > Afaics a simple pre-calculated lookup table with 32 entries should do
> > > > > the job. At least for the cut-off frequency.
> > > > 
> > > > That's possible, since you need only 32 precomputed entries, rather than
> > > > continuous values. That would be much better too, without any runtime
> > > > overheads. Just the table needs to be done nice.
> > > 
> > > Now I found some time to come back to this issue,
> > > 
> > > I prepared a small patch to set the cutoff according to Manu's formula.
> > > The calculation is simple enough for integer arithmetic, so it is not
> > > worth to prepare a lookup-table.
> > > 
> > > @ldvb:
> > > Please test and report whether it works for you.
> > > 
> > > CU
> > > Oliver
> > > 
> > 
> > I'm not asked, but give you a report anyway.
> 
> ;-)
> 
> > On Hotbird 13.0E it makes no difference for me.
> 
> Are you saying that you did not have any problems without the patch,
> and is works with the patch, too?
> 
> I do not expect a big difference for common symbol rates like 22 MSPS
> or 27.5 MSPS, but it will probably make a difference for high or low
> symbol rates.
> 
> CU
> Oliver
> 

There is only one transponder slightly above 27.5 MSPS (29), IIRC.

With the current scan file, derived from lyngsat data, but likely still
not perfect, the first kaffeine scan under old conditions with current
weather, returned 1357 TV services and 505 radio services on 109
transponders.

With the patch applied last night, sorry I also have a neerd cold ;),
a first run returned 1323 TV services and 491 radio services.

A next scan came to 1355 for TV and 504 for radio.

Some more showed that it is about 15 more or less services on several
scans as average.

That lead me to that first conclusion for my conditions.

BTW, since Hartmut has a problem within his location to set up a dish
with sufficient reception, this was a problem here too, drop me a note
and I try to move the CTX948 to you. With Mauro I had a problem to get
something to him as normal parcel in Frankfurt, but then went well on
the last minute. To Hartmut one is lost as simple letter, not such a
clever idea, if it does not fit in the letter box, but should not happen
again.

Cheers,
Hermann











_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb