| Message ID | 49BBEFC3.5070901@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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 -- 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
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 -- 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
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 -- 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
> > 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. Please find also the remark inside the file: "(9) The frequency in MHz channel n is defined as: center frequency = 306 + 8 n + 0.166 d, n is between 21 and 69, d can take the values -1, 0, 1, 2 or 3 depending on the needs planning." -- 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
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 -- 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
> 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. -- 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
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 -- 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
Benjamin Zores schrieb: > 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 > If you manually edited the frequencies, we can stop searching here. This is definitely wrong. If somebody wrote something like this to linuxtv wiki, we should remove that lines. -- 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
(sorry for not answering sooner, I got distracted by good weather and the need to replenish my reserve of beer, depleted during the long wintry weather) On Tue, 17 Mar 2009, Benjamin Zores wrote: > > 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 > Here it goes. > See attachment. Thanks -- except, um, somehow the attachments got mangled in the process of being MIMEd. It seems your mailer (Thunderbird) has chosen to tag the files as something like text/xemacs (similar, I can't remember exactly what) and performed some strange irreversible conversion of much of the binary data into character 0x3f, which breaks `dvbsnoop'. I attempted to convert those characters to the padding used to fill out the 188-byte Transport Stream packet, but it still was not enough, as that's not the only character that got mangled. Here's your ARD multiplex (722MHz) dumped after my conversion: from file: /tmp/hexrev ------------------------------------------------------------ 0000: 47 40 10 17 00 40 ff 52 30 38 ff 00 00 ff 05 40 G@...@.R08.....@ 0010: 03 41 52 44 ff 40 38 01 21 14 ff 3a 5a 0b 04 35 .ARD.@8.!..:Z..5 0020: 45 40 1f 41 3b ff ff ff ff 41 0c 00 ff 01 00 02 E@.A;....A...... 0030: 01 00 03 01 00 06 01 62 1d ff 03 ff ff 40 04 1c .......b.....@.. 0040: ff 40 04 4d ff 40 04 66 19 40 04 7e ff 40 04 ff .@.M.@.f.@.~.@.. 0050: ff 40 04 ff 57 40 29 ff 74 08 ff ff ff ff ff ff .@..W@).t....... [...] And here's how it should have looked (the sequential number is different, but the others should be similar or identical): from file: /tmp/ard-fs-DVB_T-17.Mar.2009-04h-NIT.ts ------------------------------------------------------------ 0000: 47 40 10 1e 00 40 f0 52 30 38 d7 00 00 f0 05 40 G@...@.R08.....@ 0010: 03 41 52 44 f0 40 38 01 21 14 f0 3a 5a 0b 04 35 .ARD.@8.!..:Z..5 0020: 45 40 1f 41 3b ff ff ff ff 41 0c 00 e0 01 00 02 E@.A;....A...... 0030: 01 00 03 01 00 06 01 62 1d ff 03 df d2 40 04 1c .......b.....@.. 0040: db 40 04 4d af 40 04 66 19 40 04 7e 83 40 04 8a .@.M.@.f.@.~.@.. 0050: b8 40 04 af 57 40 29 df 74 08 ff ff ff ff ff ff .@..W@).t....... It appears anything above 0x80 (decimal 128, or with high-bit set) is converted by Chunderbird to the 0x3f -- that is, any non-US-ASCII value gets mangled. So I'll ask, can you send the files again, but first make them ASCII-safe, either by `uuencode' or `xxd' or some base64 encoder, before attaching them? And send them directly to me, no need to bother the whole list with them. (Or if you have access to a different mailer which will attach the files as simple octet-stream, that will work with no need to pre-encode) One more question, can you receive anything at 858MHz, channel 69? I have this listed in the frequency allocations from several sources for Strasbourg. If not, I may be able to check myself in the next month or so, if I remember... Thanks! barry bouwsma -- 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
2009/3/14, Benjamin Zores <benjamin.zores@gmail.com>: > Hi, > > Attached patch updates the current dvb-t/fr-Strasbourg file with > relevant transponders frequency values. I've removed the 167k offset, added channel 69 and committed the file. > Please commit, > > Ben Thanks, Christoph -- 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
# 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