[linux-dvb] Kaffeine universal DVB-T scan file
mauro.borghi at telecomitalia.it
Tue Apr 17 13:22:38 CEST 2007
Christoph Pfister wrote:
> Am Montag, 16. April 2007 11:54 schrieb Mauro Borghi:
>> Dear Christoph, all,
>> Christoph Pfister wrote:
>>> 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 :).
>>> 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).
>> 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
>> 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.
More information about the linux-dvb