test

test

[Jed]

this is a test

Test

[Raymond Jender]

Am I getting out to the mailing list?  I received an email from
majordomo containing a lot of errors?

Thanks,

Ray

test

[desmono]

test

test

[Guilherme Longo]

just a test.

Re: test

[Bob Ingraham]

Come listen to a story about a named Jed...

------Original Message------
From: Jed
Sender: linux-media-owner@vger.kernel.org
To: Linux Media Mailing List
Sent: Sep 13, 2009 10:03 AM
Subject: test

this is a test
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Sent from my Verizon Wireless BlackBerry

[PATCH] add new frequency table for Strasbourg, France

[Benjamin Zores]

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

Hi,

Attached patch updates the current dvb-t/fr-Strasbourg file with
relevant transponders frequency values.

Please commit,

Ben

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dvb-t_fr-Strasbourg.diff --]
[-- Type: text/x-diff; name="dvb-t_fr-Strasbourg.diff", Size: 2437 bytes --]

# HG changeset patch
# User Benjamin Zores <ben@geexbox.org>
# Date 1237053058 -3600
# Node ID 492ed381071e5aeffbbde990a069f3beb46e5dc7
# Parent  fe5a6f79468e5317e394f78ccf98dbe63a83e004
new frequency table for Strasbourg, France

diff -r fe5a6f79468e -r 492ed381071e util/scan/dvb-t/fr-Strasbourg
--- a/util/scan/dvb-t/fr-Strasbourg	Fri Mar 13 14:35:20 2009 +0100
+++ b/util/scan/dvb-t/fr-Strasbourg	Sat Mar 14 18:50:58 2009 +0100
@@ -1,30 +1,17 @@
-# Strasbourg - France (DVB-T transmitter of Strasbourg ( Nondéfini ) )
-# Strasbourg - France (signal DVB-T transmis depuis l'émetteur de Nondéfini )
+# Strasbourg - France (DVB-T transmitter of Strasbourg (Nordheim))
+# contributed by Benjamin Zores <ben@geexbox.org>
 #
-# ATTENTION ! Ce fichier a ete construit automatiquement a partir
-# des frequences obtenues sur : http://www.tvnt.net/multiplex_frequences.htm
-# en Avril 2006. Si vous constatez des problemes et voulez apporter des
-# modifications au fichier, envoyez le fichier modifie a
-# l'adresse linux-dvb@linuxtv.org (depot des fichiers d'init dvb)
-# ou a l'auteur du fichier :
-# Nicolas Estre <n_estre@yahoo.fr>
+# Strasbourg - Nordheim: 22 47 48 51 61 69
+# See http://www.tvnt.net/V2/pages/342/medias/pro-bo-doc-tk-frequences_tnt.pdf
 #
 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
-#### Strasbourg - Nondéfini ####
-#R1
-#T FREQ1 8MHz AUTO NONE QAM64 8k AUTO NONE
-#R2
-#T FREQ2 8MHz AUTO NONE QAM64 8k AUTO NONE
-#R3
-#T FREQ3 8MHz AUTO NONE QAM64 8k AUTO NONE
-#R4
-#T FREQ4 8MHz AUTO NONE QAM64 8k AUTO NONE
-#R5
-#T FREQ5 8MHz AUTO NONE QAM64 8k AUTO NONE
-#R6
-#T FREQ6 8MHz AUTO NONE QAM64 8k AUTO NONE
-##############################################################
-# en Avril 2006, l'emetteur pour Strasbourg n'etait pas defini
-#  Vous devez donc modifier les frequences manuellement.
-# SVP Renvoyez le fichier mis a jour aux contacts ci-dessus.
-##############################################################
+T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE
+T 618167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 682167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 690167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 698167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 714167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 722167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 786167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 794167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

Re: [PATCH] add new frequency table for Strasbourg, France

[BOUWSMA Barry]

On Sat, 14 Mar 2009, Benjamin Zores wrote:

> Attached patch updates the current dvb-t/fr-Strasbourg file with
> relevant transponders frequency values.

Hi,

I have a problem with some of these values.  Well, to be truthful,
all of these values.  I don't have a good 'net connection to be
able to check these things online at the moment, so I'm going to
have to go by some possibly-outdated downloads...

First, every frequency is given an offset from the nominal centre
frequency of the 8MHz envelope.  I am aware this is common in the
UK where the switchover is happening gradually so as not to
interfere with adjacent analogue services, and I also know that
last I checked, the number of french analogue services I could
receive weakly had dropped, but at least one was still visible.

I've also read in a forum that complete analogue switchoff is
planned Real Soon Now with a corresponding increase in ERP from
the Alsace transmitters, but I don't know details.

My mailer doesn't include the attachment in the reply, so I've
had to paste the lines below...

+T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

I have some recent german Bundesnetzagentur (BNetzA) data, and
this lists the Nordheim frequencies as
TVDRStrasbourg                    22   482.000KT
that is, no offset.  I still have not wrapped my head around
the meaning of the `KT' status field.  The rest of the fields
match what I predicted earlier (pasted from my file created
for the neighbouring part of germany):
### In the west to southwest, one may receive a number of broadcasts from
### the Alsace in France.  These are horizontally polarised.
###  Strasbourg Nordheim        22-47-48-51-61-69
# ACHTUNG!  file fr-Strasbourg contains no content!  FIXME!
### need to verify FEC 2/3 + GI 1/32 (MFN), fix freqs
# T 482000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K22
# T 682000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K47
# T 690000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K48
# T 714000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K51
# T 794000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K61
# T 858000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K69


Now, back to your diffs...

+T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE

This frequency looks very suspicious, as it is (without
the offset) in use with different parameters by a Single-
Frequency Network along the Hoch- and Oberrhein, including
a non-directional 50kW tower at the Totenkopf, Vogtsburg/
Kaiserstuhl, and somewhat closer at Baden Baden Fremserberg,
which should blast well into much of the Alsace.  Certainly,
when I was within walking distance of the Totenkopf but
within the Rhein valley, I had no problems receiving the
analogue french broadcasts with a simple indoor antenna.
These may have been from Colmar, much closer.

I can't imagine that the french would either try to
re-use this frequency or attempt to jam it...


+T 618167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

My BNetzA data lists an additional frequency that neither
your list, nor mine, includes:
TVDRStrasbourg                    40   626.000K4
As I said, I don't know how to interpret the `K4' status
field to match up with today's reality.

Your frequency, however, is different, and matches a
second frequency used non-directionally from the
Totenkopf (but this time, not in a SFN with Baden Baden).
However, nearly all the modulation parameters bear no
similarity to the ones you give.

My BNetzA data lists another additional allocation:
TVDRStrasbourg                    46   674.000K4
This, like the above, is a 47dBW non-directional field,
with multiplex labels such as F___F__00428, which should
be situated 3 metres higher up the tower from the other
existing frequencies, all of which are directional with
about 40dBW, reduced by 6dBW -- somewhere I've saved graphs
of the directional pattern, but I can't find them now --
the reduced strength is usually towards germany.


+T 682167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 690167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

These match the BNetzA data, and my predictions, apart
from the offset.  The analogue BNetzA data lists two
frequencies for a `Strasbourg', one being for `Strasbourg
Port Du Rhin', with the geographic data and antenna data
matching the latter.  No analogue frequencies are presently
shown for the Alsace Strasbourg (or Elsaß, Straßburg), though
one is listed for Mulhouse, which is probably what I was
seeing a year or so ago, so I'm not sure whether an offset
is really needed, as I have not been paying much attention
to the process of switching on the digital, and eventually
switching off the remaining analogue frequencies in this
area...  (For example, Colmar is assigned digital frequencies
with vertical polarisation, directional, and about 20dBW less 
power toward germany, but I know only of Mulhouse and Strasbourg 
being in operation)


+T 698167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

This is not listed in the BNetzA data, but tramples on
a multiplex out of Baden Baden (see 618MHz above with the
same content, except that the SFN MUX is BW00864 from
Baden Baden and BW00835 from Vogtsburg, which may be
reflected by different NIT contents).


+T 714167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

This (apart from the offset) matches the BNetzA frequency
data.


+T 722167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

Again, this frequency is in use from the Totenkopf, but
with very different parameters, and so is unlikely to be
reused for a MFN in so short a distance.


+T 786167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

This frequency is in use with similar contents to the above
from the Fremserberg, with SFN MUX BW00865, or BW00840 from
Vogtsburg/Kaiserstuhl.


+T 794167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

This matches the BNetzA data.  In addition, that data includes
an additional frequency in the range 61-69:
TVDRStrasbourg                    69   858.000AT
Again, with a different `AT' status.

I know that in some lands, the 61-69 range, or parts thereof,
are to be reassigned from DVB-T to something else, but with
all the different lands and plans, I can't remember the
details...



Sorry for the delay, and lack of checking against current
TNT sources, as well as quoting some Bundesnetzagentur data
without fully understanding the details.

barry bouwsma

Re: [PATCH] add new frequency table for Strasbourg, France

[Benjamin Zores]

BOUWSMA Barry wrote:

> First, every frequency is given an offset from the nominal centre
> frequency of the 8MHz envelope.  I am aware this is common in the
> UK where the switchover is happening gradually so as not to
> interfere with adjacent analogue services, and I also know that
> last I checked, the number of french analogue services I could
> receive weakly had dropped, but at least one was still visible.

These were discovered through w_scan application.

> +T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> 
> I have some recent german Bundesnetzagentur (BNetzA) data, and
> this lists the Nordheim frequencies as
> TVDRStrasbourg                    22   482.000KT
> that is, no offset.

I've read on some page from linuxtv wiki that most of transponders files
needed to be added a 167k offset to work.
Honnestly, it works fine with or without this offset for me.

> +T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE
> 
> This frequency looks very suspicious, as it is (without
> the offset) in use with different parameters by a Single-
> Frequency Network along the Hoch- and Oberrhein, including
> a non-directional 50kW tower at the Totenkopf, Vogtsburg/
> Kaiserstuhl, and somewhat closer at Baden Baden Fremserberg,
> which should blast well into much of the Alsace.  Certainly,
> when I was within walking distance of the Totenkopf but
> within the Rhein valley, I had no problems receiving the
> analogue french broadcasts with a simple indoor antenna.
> These may have been from Colmar, much closer.

I do receive both French and German channels.
So obviously, some come from Nordheim antenna while others
are likely to come from Germany but I don't know how to differenciate these.

I have some table frequency list here:
http://www.tvnt.net/V2/pages/342/medias/pro-bo-doc-tk-frequences_tnt.pdf

See the "Canal" array, page 20 for "Strasbourg".
I don't know how to determine transponders frequencies from this list.

Ben

Re: [PATCH] add new frequency table for Strasbourg, France

[wk]

Benjamin Zores wrote:
> BOUWSMA Barry wrote:
>
>> First, every frequency is given an offset from the nominal centre
>> frequency of the 8MHz envelope.  I am aware this is common in the
>> UK where the switchover is happening gradually so as not to
>> interfere with adjacent analogue services, and I also know that
>> last I checked, the number of french analogue services I could
>> receive weakly had dropped, but at least one was still visible.
>
> These were discovered through w_scan application.
>
>> +T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
>>
If that information was found by w_scan, that information was found by 
parsing the NIT ot this channel.
Current w_scan doesn't use +/-167k offsets.
Since in Germany no transmitter uses any freq offsets, the information 
comes from the French one.

And for France finding that freq offsets is quite normal.

--wk

Re: [PATCH] add new frequency table for Strasbourg, France

[BOUWSMA Barry]

On Mon, 16 Mar 2009, wk wrote:

> Benjamin Zores wrote:
> > BOUWSMA Barry wrote:
> > 
> > > First, every frequency is given an offset from the nominal centre
> > > frequency of the 8MHz envelope.  I am aware this is common in the
> > > UK where the switchover is happening gradually so as not to
> > > interfere with adjacent analogue services, and I also know that
> > > last I checked, the number of french analogue services I could
> > > receive weakly had dropped, but at least one was still visible.
> > 
> > These were discovered through w_scan application.

Then there must be something ``wrong'' with `w_scan' making
incorrect assumptions about the data which it's parsing.

It would be too easy for me to look at the source of `w_scan'
and see what it might be doing wrong.  Too easy.  So of course,
I'd rather do something else, like look at the raw data it's
using -- the NIT data of the french muxen, in case there is
something within that being processed in error.

The fact that while germany makes much use of SFNs which need
to transmit coördinated frequencies and data, while each site
in france uses different frequencies from its neighbours,
would mean that any NIT data would need to be generated
individually for each transmitter site, unless the entire
pool of available frequencies allocated to france (or to the
particular mux operator/composition) is listed within the
NIT table from a central site, which is then distributed to
all the transmitters.

For me to see the NIT contents, I'd have to ask the original
poster if it would be possible to make a short recording of
PID 16 on each of the five or six frequencies in use from
Nordheim (these would be chans 22-47-48-51-61-69 based on
data I downloaded in 2006), and either mail them to me, or
run `dvbsnoop -s ts -tssubdecode -if /name/of/recorded.ts 16'
to get a text parsing of the NIT table contents.

Usually three seconds is enough to see at least one full set
of NIT data, though sometimes ten or more seconds would be
needed.

This will give me the other half of what `w_scan' is working
on, something which I am not able at present to see myself.


> > > +T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> > > 
> If that information was found by w_scan, that information was found by parsing
> the NIT ot this channel.

This data is correct.  It's the other mangled data from the
german SFNs that is incorrect, and without looking at the
`w_scan' code until later, I have a couple ideas about what
it could be doing wrong.


> Since in Germany no transmitter uses any freq offsets, the information comes
> from the French one.
> And for France finding that freq offsets is quite normal.

I did notice that a few scanfiles other than uk-foo did
include such offsets.  I agree that the frequencies listed
in the initial scan files should be as accurate as possible
with technical details -- I presume the BNetzA data is based
on the nominal assigned allocations rather than the (perhaps
temporary?) current practice.

Which makes me wonder, as these offsets are used in the case
of a simulcast phase, will they still remain in effect after
analogue switchoff, or will they be dropped at the time when
powers of the DVB-T broadcasts will be increased?


What has disturbed me is how this offset has been applied
across the board by `w_scan', as have the guard interval and
modulation type (with one exception), to the received german
frequencies, yet the NIT data from said german frequencies
appears nowhere.  In particular, the ZDFmobil mux:

> +T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE
   wrong^^^^^^  ok  ok      correct!  WRONG

Here is what one sees with `dvbsnoop' on the NIT data, which
appears that it's generated for each SFN Cell, as opposed to
being centrally generated once:
(working my way backwards from bottom to the top)
A list of frequencies used by ZDFmobil...
                  DVB-DescriptorTag: 98 (0x62)  [= frequency_list_descriptor]
                  descriptor_length: 101 (0x65)
                  reserved_1: 63 (0x3f)
                  coding_type: 3 (0x03)  [= terrestrial]
                     Centre_frequency: 02d34440  (= 474000.000 kHz)
                     Centre_frequency: 02df7940  (= 482000.000 kHz)
[...]
                     Centre_frequency: 04a32240  (= 778000.000 kHz)

A list of Cell IDs and frequencies (the same frequency is shared
by distant cells)...
                  DVB-DescriptorTag: 109 (0x6d)  [= cell_frequency_list_descriptor]
                  descriptor_length: 40 (0x28)
                  Cell:
                     cell_id: 515 (0x0203)
                     Center frequency: 0x0365c040 (= 570000.000 kHz)
                     subcell_info_loop_length: 0 (0x00)
                  Cell:
                     cell_id: 560 (0x0230)
                     Center frequency: 0x038a5f40 (= 594000.000 kHz)
                     subcell_info_loop_length: 0 (0x00)
[...]

Modulation for the particular Cell of interest:
                  Center frequency: 0x0365c040 (= 570000.000 kHz)
                  Bandwidth: 0 (0x00)  [= 8 MHz]
                  priority: 1 (0x01)  [= HP (high priority) or Non-hierarch.]
[...]
                  Constellation: 1 (0x01)  [= 16-QAM]
                  Hierarchy information: 0 (0x00)  [= non-hierarchical (native interleaver)]
                  Code_rate_HP_stream: 1 (0x01)  [= 2/3]
                  Code_rate_LP_stream: 0 (0x00)  [= 1/2]
                  Guard_interval: 3 (0x03)  [= 1/4]
                  Transmission_mode: 1 (0x01)  [= 8k mode]
                  Other_frequency_flag: 1 (0x01)
                  reserved_2: 4294967295 (0xffffffff)

A list of Service IDs...
Geographic info for each Cell ID...
               DVB-DescriptorTag: 108 (0x6c)  [= cell_list_descriptor]
               descriptor_length: 58 (0x3a)
               Cell:
                  cell_id: 515 (0x0203)
                  cell_latitude: 18841 (0x4999)  [= 51.748 degree]
                  cell_longitude: 2169 (0x0879)  [= 11.914 degree]
                  cell_extend_of_latitude: 545 (0x0221)  [= 1.496 degree]
                  cell_extend_of_longitude: 710 (0x02c6)  [= 3.900 degree]
                  subcell_info_loop_length: 0 (0x00)
[...]
Note that the Cell ID does not match the ``SFN-Kenner'' in the
BNetzA data, which is BW00837 for this particular ZDFmobil SFN.
               Cell:
                  cell_id: 519 (0x0207)
                  cell_latitude: 17233 (0x4351)  [= 47.331 degree]
                  cell_longitude: 1304 (0x0518)  [= 7.163 degree]
                  cell_extend_of_latitude: 667 (0x029b)  [= 1.831 degree]
                  cell_extend_of_longitude: 333 (0x014d)  [= 1.829 degree]
                  subcell_info_loop_length: 0 (0x00)
I believe this is the particular SFN which can be received in
Strasbourg, with the given lat+long. coördinates placing the
start of the cell somewhere in the area of Basel -- the
details for Baden Baden Fremserberg are something like
48N45'10" 08E12'08" 525+174m, more or less.

As you see, an independent parsing of the 570MHz NIT data will
in no way be able to come up with the incorrect guard interval
shown several screens above.  Similarly, the frequency offset.

The other thing about a frequency offset in use at Nordheim, is
the adjacent german channels without offset, so that if I were
to believe the offset of all the french channels, in the case
where they are adjacent to a nearby german channel, there would
be some frequency overlap in theory -- I don't know exactly how
much of the allocated 8MHz bandwidth is actually used by the
COFDM carriers:

+T 682167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 690167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 698167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE <= SWR mux Baden Baden
 wrong^^^^^^          wrong^^^^^ wrong^^
+T 714167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 722167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE <= ARD mux Freiburg

+T 786167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE <= ARD mux Baden Baden
+T 794167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

The last is not a problem with the offset, as it would just
increase the separation between the two -- Baden Baden does
not employ the offset.

What I'm wanting to say here, is that while I'll gladly
accept that the use of an offset by the french transmitters
on some frequencies may well be, I would expect that the
above adjacent channels would not use such an offset.

Also, that I can't trust the `w_scan' output, as it's clearly
botched the german channels in all cases, and I'd rather see
the raw or `dvbsnoop'ified NIT tables in their entirety (no
guarantee they'll be correct, though -- it's interesting to
me that the SWR NIT table gives data for the mythical 730MHz
channel, those presently in service being ### SWR-BW multiplex; 
K39, K40, K41, K49, K50 -- also listed are
                     Centre_frequency: 03104d40  (= 514000.000 kHz)
                     Centre_frequency: 03aefe40  (= 618000.000 kHz)
                     Centre_frequency: 03bb3340  (= 626000.000 kHz)
                     Centre_frequency: 03c76840  (= 634000.000 kHz)
                     Centre_frequency: 04291040  (= 698000.000 kHz)
The same is true for the ARD mux:  the listed frequency is not
correct for that actually tuned, and the list of frequencies is
out of date (missing some, as well as some not in use).  Both
these muxen are assembled by SWR, while the ZDFmobil mux is
national.  Who should be the recipient of the pointy finger of
blame, I cannot say, but I imagine this would wreak havoc with
any scanning application without human input.

There should be a closing parenthesis on the above, but now
that I look at it, it seems important enough not to be
footnoted into oblivion, and I need to dig out my recordings
from 2006 and see if the SWR/ARD NIT tables have changed at
all since then.

Carry on...


Anyway, to the original poster, Benjamin, can you make a short
recording of, oh, say, ten seconds, of just PID 16 of only the
five or six french muxen which you receive, and somehow deliver
them to me?  File sizes should be something like
-rw-r--r--   1 beer  666      19552 2009-03-17 03:21 zdf-fs-DVB_T-17.Mar.2009-03h.ts
-rw-r--r--   1 beer  666      26696 2009-03-17 04:07 bw-fs-DVB_T-17.Mar.2009-04h.ts
-rw-r--r--   1 beer  666       7332 2009-03-17 04:13 ard-fs-DVB_T-17.Mar.2009-04h.ts
(that's five seconds, or 30 secs for SWR)

If you need a commandline to do this, just ask -- I use a
script with the german parameters, sort of like
/home/beer/bin/dvbstream  ${DVB_T}  -T  \
    -f 570000000   -I 0   -qam 16  -gi 4  -cr 2_3    -bw 8  -tm 8  \
    -crlp 1_2   -hy NONE   \
    -o:${RECROOT:-/opt}/Partial_Transport_Streams/zdf-fs-DVB_T-${DATE}.ts  \
    0  16 $*

merci vielmal

barry bouwsma

Re: [PATCH] add new frequency table for Strasbourg, France

[wk]

> Then there must be something ``wrong'' with `w_scan' making
> incorrect assumptions about the data which it's parsing.
>
>   
No - i do not think so.
All of the frequencies found are with 166kHz offset.
w_scan does not use any of these 166k offsets, that means this frequency 
data was transmitted as exactly such a number in some NIT w_scan parsed.

w_scan calculates DVB-T center freqs as "center freq = (306000000 + 
channel * 8000000) Hz" for this range.
And NIT parsing is the same as dvbscan.

> What has disturbed me is how this offset has been applied
> across the board by `w_scan',
Again, w_scan does not use these offsets.

Some dvbsnoop output as suggested and additional some scan with service 
names (either dvbscan or w_scan), vdr channels.conf would be fine, would 
really help to see whats going on here.

Re: [PATCH] add new frequency table for Strasbourg, France

[Benjamin Zores]

wk wrote:
> 
>> Then there must be something ``wrong'' with `w_scan' making
>> incorrect assumptions about the data which it's parsing.
>>
>>   
> No - i do not think so.
> All of the frequencies found are with 166kHz offset.
> w_scan does not use any of these 166k offsets, that means this frequency 
> data was transmitted as exactly such a number in some NIT w_scan parsed.
> 
> w_scan calculates DVB-T center freqs as "center freq = (306000000 + 
> channel * 8000000) Hz" for this range.
> And NIT parsing is the same as dvbscan.
> 
>> What has disturbed me is how this offset has been applied
>> across the board by `w_scan',
> Again, w_scan does not use these offsets.

Again, I've added these offsets to w_scan results as it was written in 
linuxtv wiki.

Ben

test

[C Khmer1]

_________________________________________________________________
Non solo posta: scopri i nuovi servizi Windows Live.
http://clk.atdmt.com/GBL/go/136430530/direct/01/

test

[sinter.salt]

check

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01