new DVB-T initial tuning for fr-nantes

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

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead [email protected] [email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

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

Salut!

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.)

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 [email protected] [email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

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

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

Hi,

2010/5/18 BOUWSMA Barry <[email protected]>:

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

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

<snip>

answered by hftom.

Thanks,

Christoph

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 [email protected] [email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

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 [email protected] [email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

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

2010/5/20 Thierry LELEGARD <[email protected]>:

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

<snip>

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).

Thanks (committed Damien's version),

Christoph