Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Scanning satellite for programs?



On Sun, Nov 21, 2004 at 12:48:20PM +0100, mws@twisted-brains.org wrote:

> >1.) Is the "LNB-type" (that is, LO/HI-offsets and switch frequency)
> >    dependent _only_ on the LNB?  Thus, having identical LNB's for Astra
> >    and Amos, I can use default LNB-type (UNIVERSAL)?
> 
> The LOF ( LocalOscillatorFrequency) is LNB and not Satellite depending. So
> if you have got the same LNB for Amos than for Astra just take the same 
> (e.g default) settings. 

OK.

> >2.) My assumption is that the scan-utility (after tuning to the initial
> >    transponder) reads information about other transponders from this
> >    transponder.  Where can I find information how this is encoded?
> 
> In a PAT there can/should be an entry for the NIT which stands for Network 
> Information Table. Normally it is sended on PID 0x10 on a Transponder.
> There you can find Network/Transponder information and also links to other 
> NIT tranponders. Information about PAT can be found in ISO-13818-1 and alle 
> the NIT stuff including the descriptors is described in ETSI 300468 which 
> is available for free @ www.etsi.org - download a standard 

OK.

> >3.) A nice-to-have would be that the scan-utility would try to find the
> >    "initial" transponder by itself.  Obviously, if this would be easy,
> >    it would already have been done ;-).  But somehow I'm failing to
> >    understand the problem.  Why is it that difficult to succesively
> >    try all possible frequencies until finding a valid signal?
> 
> It would be not that difficult at all, but very timeconsuming if you would 
> try each possible frequency with each possible symbol rate. On the Dbox2 you
> can select this as an option for DVB-C scan. even if on cable systems there 
> are much less transponder than on a satellite e.g. this "bruteforce" scan 
> takes long time >30min 

Hmm, I think waiting for half an hour is better than not finding anything
at all ;-)

This looks to be O(n^2) on the first glance.  But I think there is pretty
much room for optimizations (please correct me if I write nonsense):

1. You need not to probe _every_ frequency.  As soon as you find any
   arbitrary transponder, the information about other transponders can
   be read from there.

2. There seem to be a lot of tolerance on the frequency.  I just tried to
   check the tolerancy: With szap, I can tune for "superl rtl" on the range
   12171..12204.  This is a frequency range of about 34MHz.  This might
   vary with the signal quality (size of the dish, single/multi-feed),
   but I would still expect that probing in 10 or 20MHz steps would be
   sufficient.

3. The frequencies (at least on astra) seem to be assigned in about 41MHz
   steps in the hi-band and in about 166MHz-steps in the lo-band.  So when
   probing in 10MHz steps, there should be a pretty high  probability to
   find a transponder after about 5..20 probes.

4. There seem to be some standard numbers for the symbol rate. 70% of the
   entries in my channels.conf have 27500.  12% have 22000.  So probing only
   for those two symrates would probably speed up scanning further.


Putting those pieces together, probing for 2 symrates on about 20
frequencies should be enough to find the first transponder.

> >4.) Why is the symbol-rate specification needed to tune to a transponder?
> 
> symbolrate is the description of how many symbols are transmitted per 
> second on this transponder. e.g. if you have 27500 as symbolrate would mean 
> a bitrate of 55Megabit/sec.
> This information is needed to perform a correct "SYNC" on the transponder 
> signal. 

So the symrate is some sort of baudrate?  Does a list of all the valid
symrates exist?  Would it be to autodetect the symrate?


Thanks for your Answer.

-- 
Please visit and sign and http://www.ffii.org
-- Josef Wolf -- jw@raven.inka.de --




Home | Main Index | Thread Index