[linux-dvb] Kaffeine universal DVB-T scan file

Mauro Borghi mauro.borghi at telecomitalia.it
Tue Apr 17 13:22:38 CEST 2007


Hello,

Christoph Pfister wrote:
> Hi,
>
> Am Montag, 16. April 2007 11:54 schrieb Mauro Borghi:
>   
>> Dear Christoph, all,
>>
>> Christoph Pfister wrote:
>>     
>>> Hi,
>>>
>>> 2007/4/14, P. van Gaans <w3ird_n3rd at gmx.net>:
>>>       
>>>> Say you live in The Netherlands. Frequencies change here all the time,
>>>> and QAM settings and stuff also change all the time. Say you're living
>>>> on the border, like me. I receive channels from The Netherlands and
>>>> Belgium at the same time, but there's no scan file for that. There will
>>>> also always be locations missing in the list.
>>>>
>>>> And what if you simply have no clue about where you live? Nobody thinks
>>>> of them! Then again, nobody knows where they are ;-)
>>>>
>>>> So here is the solution: a file that'll make Kaffeine scan all UHF
>>>> channels with "AUTO" for the QAM and other stuff, will be sufficient in
>>>> most countries although scanning takes a bit longer.
>>>>
>>>> I hope it makes it into some next version of Kaffeine :).
>>>>
>>>> Pim
>>>>         
>>> <snip>
>>>
>>> There are enough cases where such a file doesn't work (think of
>>> offsets, 7 mhz transponders etc). Responsible for such complete
>>> scannings are the apps (kaffeine has auto scan which does pretty much
>>> the same as your file does and it tries offsets iirc).
>>>
>>> Christoph
>>>       
>> I think dvb-t scan files should be organized in 3 "levels":
>> 1. specific location
>> 2. specific country
>> 3. most general case
>>
>> For 1. the scan will be fast, because only frequencies known to be
>> active will be scanned - and most params will be known.
>>
>> For 2., we should refer to the frequency allocation plan of a given
>> country, so that all possible frequencies (and bandwidths) are listed -
>> with other params left to autodetection.
>>     
>
> Hmm ... imho this is either a summation of 1. (means we need to know all 
> transmitters; would make sense e.g. in places where you can receive data from 
> different broadcasters) or 3. (I don't see how the the number of 
> possibilities is significantly reduced for a specific country without knowing 
> all transmitters).
>
>   
For example the freq allocation plan for Italy is as follows:

# ch  center-f   bw
chD   177500000  7MHz
chE   186000000  7MHz
chF   194500000  7MHz
chG   203500000  7MHz
chH   212500000  7MHz
chH1  219500000  7MHz
chH2  226500000  7MHz
# (gap between VHF and UHF channels)
ch21  474000000  8MHz
ch22  482000000  8MHz
ch23  490000000  8MHz
ch24  498000000  8MHz
ch25  506000000  8MHz
# ... (add rows from ch26 to ch65) ...
ch66  834000000  8MHz
ch67  842000000  8MHz
ch68  850000000  8MHz

I do not actually know if and how much the allocation plans differ for 
other countries - but I suspect there are some differences: some might 
not use 7MHz channels, some might not use VHF freqs, some countries 
might have slightly different center frequencies for some channels.
Probably Europe is quite harmonized now...

The allocation plan for Italy can be easily translated into a scan file 
which is suitable for any location in Italy. I agree it's not optimized, 
but you are sure you're going to get all available muxes, even during 
years when dvb-t is still being deployed - with analog switch-off yet to 
come.

>> 3. should be the union of all known center frequencies used somewhere,
>> listed more than once if other params may change (e.g. bandwidth 6 or 7
>> or 8 MHz). The scan will probably be very slow, but the goal is to
>> maximize the chance to get all available muxes.
>>     
>
> I'm a bit sceptical about the practical implementation of that and whether it 
> would work reliably ...
>
>   
>> When the scan file for your specific location  (1.) is not present or
>> does not work, you can try 2., and if 2. is not enough you could try 3.
>>
>> Cheers,
>> Mauro.
>>     
>
> Christoph
>   

Ciao,
Mauro.




More information about the linux-dvb mailing list