[linux-dvb] new DVB-T initial tuning for fr-nantes

[linux-dvb] new DVB-T initial tuning for fr-nantes

[matpic]

[-- Attachment #1.1: Type: text/plain, Size: 870 bytes --]

hello
As from today (18/05/2010) there is new frequency since analogic signal
is stopped and is now only numeric.


guard-interval has to be set to AUTO or scan find anything
 (1/32, 1/16, 1/8 ,1/4 doesn't work)


# Nantes - France
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 538000000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 490000000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 546000000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 658000000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 682000000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 738000000 8MHz 2/3 NONE QAM64 8k AUTO NONE
#same frequency + offset 167000000 for some hardware DVB-T tuner
T 538167000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 546167000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 658167000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 682167000 8MHz 2/3 NONE QAM64 8k AUTO NONE
T 738167000 8MHz 2/3 NONE QAM64 8k AUTO NONE






[-- Attachment #1.2: Type: text/html, Size: 1225 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[BOUWSMA Barry]

On wto (wtorek) 18.maj (maj) 2010, 15:05:00, matpic wrote:

Salut!

> hello
> As from today (18/05/2010) there is new frequency since analogic signal
> is stopped and is now only numeric.
> guard-interval has to be set to AUTO or scan find anything
>  (1/32, 1/16, 1/8 ,1/4 doesn't work)

I do not have the CSA data at hand, but I understand that
presently use is made of single transmitter sites, in a MFN
(Multi-Frequency Network) and thus a guard interval of 1/32 should
be correct.

(I understand though that some filler transmitters may be in
planning so that a small SFN may be put in service, but I am
not clear as to these details...  I must research this.)


> #same frequency + offset 167000000 for some hardware DVB-T tuner

It was my understanding that the different offsets above or
below the nominal centre frequency is a result of mixed digital
and legacy analogue services co-broadcasting, in order to avoid
interference with adjacent channels.

So I am wondering whether, in the absence of local analogue
services, this offset is no longer employed?

I am afraid that I am not following the conversion to TNT so
closely to know if a whole geographic region, in this case the
Loire, is having the remaining analogue services shut down all
at once, or if it is being done on a site-by-site basis, with
the potential for interference to a more remote but still
operational analogue transmitter.

In any case, all but one of the new frequencies appear to be
very different from the ones previously used before today.


Merci, for reporting this change!

barry bouwsma

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[Christophe Thommeret]

Le mardi 18 mai 2010 16:25:56, BOUWSMA Barry a écrit :
> On wto (wtorek) 18.maj (maj) 2010, 15:05:00, matpic wrote:
> 
> Salut!
> 
> > hello
> > As from today (18/05/2010) there is new frequency since analogic signal
> > is stopped and is now only numeric.
> > guard-interval has to be set to AUTO or scan find anything
> > 
> >  (1/32, 1/16, 1/8 ,1/4 doesn't work)
> 
> I do not have the CSA data at hand, but I understand that
> presently use is made of single transmitter sites, in a MFN
> (Multi-Frequency Network) and thus a guard interval of 1/32 should
> be correct.
> 
> (I understand though that some filler transmitters may be in
> planning so that a small SFN may be put in service, but I am
> not clear as to these details...  I must research this.)
> 
> > #same frequency + offset 167000000 for some hardware DVB-T tuner
> 
> It was my understanding that the different offsets above or
> below the nominal centre frequency is a result of mixed digital
> and legacy analogue services co-broadcasting, in order to avoid
> interference with adjacent channels.
> 
> So I am wondering whether, in the absence of local analogue
> services, this offset is no longer employed?
> 
> I am afraid that I am not following the conversion to TNT so
> closely to know if a whole geographic region, in this case the
> Loire, is having the remaining analogue services shut down all
> at once, or if it is being done on a site-by-site basis, with
> the potential for interference to a more remote but still
> operational analogue transmitter.
> 
> In any case, all but one of the new frequencies appear to be
> very different from the ones previously used before today.
> 
> 
> Merci, for reporting this change!
> 
> barry bouwsma

All analogic services are all closed at once.
I guess the "offset" is there to help some (buggy?) devices, like cinergy T2, 
not to reflect a real frequency offset.

-- 
Christophe Thommeret

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[Christophe Thommeret]

Le mardi 18 mai 2010 16:39:56, Christophe Thommeret a écrit :
> Le mardi 18 mai 2010 16:25:56, BOUWSMA Barry a écrit :
> > On wto (wtorek) 18.maj (maj) 2010, 15:05:00, matpic wrote:
> > 
> > Salut!
> > 
> > > hello
> > > As from today (18/05/2010) there is new frequency since analogic signal
> > > is stopped and is now only numeric.
> > > guard-interval has to be set to AUTO or scan find anything
> > > 
> > >  (1/32, 1/16, 1/8 ,1/4 doesn't work)
> > 
> > I do not have the CSA data at hand, but I understand that
> > presently use is made of single transmitter sites, in a MFN
> > (Multi-Frequency Network) and thus a guard interval of 1/32 should
> > be correct.
> > 
> > (I understand though that some filler transmitters may be in
> > planning so that a small SFN may be put in service, but I am
> > not clear as to these details...  I must research this.)
> > 
> > > #same frequency + offset 167000000 for some hardware DVB-T tuner
> > 
> > It was my understanding that the different offsets above or
> > below the nominal centre frequency is a result of mixed digital
> > and legacy analogue services co-broadcasting, in order to avoid
> > interference with adjacent channels.
> > 
> > So I am wondering whether, in the absence of local analogue
> > services, this offset is no longer employed?
> > 
> > I am afraid that I am not following the conversion to TNT so
> > closely to know if a whole geographic region, in this case the
> > Loire, is having the remaining analogue services shut down all
> > at once, or if it is being done on a site-by-site basis, with
> > the potential for interference to a more remote but still
> > operational analogue transmitter.
> > 
> > In any case, all but one of the new frequencies appear to be
> > very different from the ones previously used before today.
> > 
> > 
> > Merci, for reporting this change!
> > 
> > barry bouwsma
> 
> All analogic services are all closed at once.
> I guess the "offset" is there to help some (buggy?) devices, like cinergy
> T2, not to reflect a real frequency offset.

BTW, analogic shut down has happened (18 may, 00:00) for the entire french 
region "Pays de Loire", so a lot of transmitters are affected.
"fr-Laval" now uses these freqs:

714000000
570000000
770000000
762000000
650000000
786000000

-- 
Christophe Thommeret

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[Christoph Pfister]

Hi,

2010/5/18 BOUWSMA Barry <freebeer.bouwsma@gmail.com>:
> On wto (wtorek) 18.maj (maj) 2010, 15:05:00, matpic wrote:
>
> Salut!
>
>> hello
>> As from today (18/05/2010) there is new frequency since analogic signal
>> is stopped and is now only numeric.
>> guard-interval has to be set to AUTO or scan find anything
>>  (1/32, 1/16, 1/8 ,1/4 doesn't work)

Strange. Maybe a different parameter is wrong? (AUTO for one parameter
may cause that other parameters are implicitly set to AUTO as well).

> I do not have the CSA data at hand, but I understand that
> presently use is made of single transmitter sites, in a MFN
> (Multi-Frequency Network) and thus a guard interval of 1/32 should
> be correct.
>
> (I understand though that some filler transmitters may be in
> planning so that a small SFN may be put in service, but I am
> not clear as to these details...  I must research this.)

Ok, I've committed it with 1/32 (for now) :-)

>> #same frequency + offset 167000000 for some hardware DVB-T tuner
<snip>

answered by hftom.

> Merci, for reporting this change!
>
> barry bouwsma

Thanks,

Christoph

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[Damien Bally]

Hi all

There's also a new transponder called L8 today on channel 56 (QAM16) for
local TV, so the fr-Nantes should look like this :

# Nantes - France
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 682000000 8MHz AUTO NONE QAM64 8k AUTO NONE
T 490000000 8MHz AUTO NONE QAM64 8k AUTO NONE
T 546000000 8MHz AUTO NONE QAM64 8k AUTO NONE
T 738000000 8MHz AUTO NONE QAM64 8k AUTO NONE
T 658000000 8MHz AUTO NONE QAM64 8k AUTO NONE
T 538000000 8MHz AUTO NONE QAM64 8k AUTO NONE
T 754000000 8MHz AUTO NONE QAM16 8k AUTO NONE



_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[BOUWSMA Barry]

On śro (środa) 19.maj (maj) 2010, 20:50:00, Damien Bally wrote:

> There's also a new transponder called L8 today on channel 56 (QAM16) for
> local TV, so the fr-Nantes should look like this :
> 
> # Nantes - France
> # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy

> T 754000000 8MHz AUTO NONE QAM16 8k AUTO NONE

One thing that would be good to do -- for someone who is in the
area served by a transmitter -- rather than use «AUTO» for the
FEC and Guard Interval values above, would be to perform a NIT
scan on the appropriate frequencies.

This should give as a result the actual transmitter frequency
and other parameters in use, and perhaps related ones from other
sites.

These values are configured by the broadcaster and are therefore
not guaranteed to be 100% accurate, but it is more likely that
they know the values they are using -- these values can be used
to locate other transmitter frequencies, as is the well-known
case for DVB-S satellite NIT tables.

I'll give an example using one satellite transponder, because this
machine I am using does not presently have a DVB-T (TNT) receiver
attached that works...

beer@herbert:/tmp/ntp-dev-4.2.5p183/ntpdate$ /home/beer/bin/dvbstream   -s 27500  -p v  -f 12525  -I 2  -D 4   -n 2 -o:/tmp/NIT.ts   16

(small file is written with NIT data)

beer@herbert:/tmp/ntp-dev-4.2.5p183/ntpdate$ dvbsnoop -s ts -tssubdecode -if /tmp/NIT.ts    | less

Here the data I see is specific to this satellite, but you should
see similar data for the particular terrestrial channel you tune
in your case...

                  Frequency: 19211520 (=  12.52500 GHz)
                  Orbital_position: 565 (=  23.5)
                  West_East_flag: 1 (0x01)  [= EAST]
                  Polarisation: 1 (0x01)  [= linear - vertical]
                  Kind: 0 (0x00)  [= DVB-S]
                  fixed ('00'): 0 (0x00)
                  Modulation_type: 1 (0x01)  [= QPSK]
                  Symbol_rate: 2576384 (=  27.5000)
                  FEC_inner: 3 (0x03)  [= 3/4 conv. code rate]

and
                  Frequency: 19227904 (=  12.56500 GHz)
                  Orbital_position: 565 (=  23.5)
                  West_East_flag: 1 (0x01)  [= EAST]
                  Polarisation: 0 (0x00)  [= linear - horizontal]
                  Kind: 0 (0x00)  [= DVB-S]
                  fixed ('00'): 0 (0x00)
                  Modulation_type: 1 (0x01)  [= QPSK]
                  Symbol_rate: 2576384 (=  27.5000)
                  FEC_inner: 2 (0x02)  [= 2/3 conv. code rate]

and
                  Frequency: 18323200 (=  11.79700 GHz)
                  Orbital_position: 565 (=  23.5)
                  West_East_flag: 1 (0x01)  [= EAST]
                  Polarisation: 0 (0x00)  [= linear - horizontal]
                  Kind: 0 (0x00)  [= DVB-S]
                  fixed ('00'): 0 (0x00)
                  Modulation_type: 1 (0x01)  [= QPSK]
                  Symbol_rate: 2576384 (=  27.5000)
                  FEC_inner: 3 (0x03)  [= 3/4 conv. code rate]

and
                  Frequency: 18372096 (=  11.85600 GHz)
                  Orbital_position: 565 (=  23.5)
                  West_East_flag: 1 (0x01)  [= EAST]
                  Polarisation: 0 (0x00)  [= linear - horizontal]
                  Kind: 0 (0x00)  [= DVB-S]
                  fixed ('00'): 0 (0x00)
                  Modulation_type: 1 (0x01)  [= QPSK]
                  Symbol_rate: 2576384 (=  27.5000)
                  FEC_inner: 4 (0x04)  [= 5/6 conv. code rate]

and some more transponders used by this provider (CS Link).


I know that at least one of my DVB-T receivers will tune into
the services on a particular channel even when I feed it the
wrong values, but apparently not all devices are capable of
this.

In the event a particular receiver requires «AUTO» and will
not work even with the ideally-correct values as given from
PID 16, then this should probably be brought to the attention
of a responsible developer to be fixed, rather than avoiding
the inclusion of the wrong values in the frequency lists.
Similarly a 167kHz frequency offset when such is not used
by the actual transmitter.

After all, the proper 1/32 (if correct) Guard Interval value
will tell me that use is made of a MFN, while 1/4 tells me
that there may be a large area covered by multiple transmitter
sites on the same frequency.  Or in the case of Paris, 1/8
tells me there is a smaller SFN configuration.

Also, the FEC rate together with the modulation 16/64-QAM
will tell me how much the expected combined data rate available
for all services will be, as well as how far removed from the
transmitter one can receive a signal at a given transmitter
power, and what sort of antenna effort will be necessary for a 
strong clean signal towards the fringes of reception.

Perhaps not very important for a normal user, but good things
to know when troubleshooting or providing recommendations for
reception, from afar -- the fact that I could receive the
analogue scrambled Canal+ is no guarantee I can now receive
any of the present TNT services (I can't).


merci
barry bouwsma

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

RE: [linux-dvb] new DVB-T initial tuning for fr-nantes

[Thierry LELEGARD]

> One thing that would be good to do -- for someone who is in the
> area served by a transmitter -- rather than use «AUTO» for the
> FEC and Guard Interval values above, would be to perform a NIT
> scan on the appropriate frequencies.
> 
> This should give as a result the actual transmitter frequency
> and other parameters in use, and perhaps related ones from other
> sites.
> 
> These values are configured by the broadcaster and are therefore
> not guaranteed to be 100% accurate, but it is more likely that
> they know the values they are using -- these values can be used
> to locate other transmitter frequencies, as is the well-known
> case for DVB-S satellite NIT tables.

Unfortunately, the terrestrial delivery descriptors are completely
wrong in the NIT of the French terrestrial network. The NIT is the
same all over the country, which is not appropriate in a terrestrial
network, and the frequency, FEC and guard interval are wrong. The
same TS will have distinct frequencies (of course) on different
transmitters but also distinct FEC and guard interval (actually,
two combinations are used: either 2/3 & 1/32 or 3/4 & 1/8).

Recently, many transmitters have changed the modulation parameters
while staying on the same frequency. It is very difficult to keep
up to date. Between the moment when you submit a patch with the
new parameters and the moment you get the file in your distro,
the parameters may have changed again.

I think that in such a moving environment, the "AUTO" choice is
definitely better.

-Thierry

Re: [linux-dvb] new DVB-T initial tuning for fr-nantes

[Christoph Pfister]

2010/5/20 Thierry LELEGARD <tlelegard@logiways.com>:
>> One thing that would be good to do -- for someone who is in the
>> area served by a transmitter -- rather than use «AUTO» for the
>> FEC and Guard Interval values above, would be to perform a NIT
>> scan on the appropriate frequencies.

You can also try to query the actual parameters from the frontend (but
that's again a different story).

<snip>
> I think that in such a moving environment, the "AUTO" choice is
> definitely better.

I still dislike "AUTO" in the dvb-apps repo, but I don't want to
invest more time in these things (you should be using autoscan
anyway).

> -Thierry

Thanks (committed Damien's version),

Christoph