dvb-t config for Ukraine_Kiev (ua)

#file for dvb-apps/util/scan/dvb-t/ua-kiev
#T freq bw fec_hi fec_lo mod transmission-mode guard-interval
hierarchy

T 634000000 8MHz AUTO   NONE    QAM64   8k                AUTO          NONE
T 650000000 8MHz AUTO   NONE    QAM64   8k                AUTO          NONE
T 714000000 8MHz AUTO   NONE    QAM64   8k                AUTO          NONE
T 818000000 8MHz AUTO   NONE    QAM64   8k                AUTO          NONE

#dvbt.conf channels list for Ukraine_Kiev (for
dvb-apps/util/szap/channels-conf/dvb-t/ua-kiev)

UT-1:634000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:4111:4112:1 RADA:634000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:4131:4132:3

5 KANAL:650000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:4311:4312:1 MEGASPORT:650000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:4321:4322:2 TET:650000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:4331:4332:3 OTV:650000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:4341:4342:4 ICTV:650000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:4351:4352:5

KDRTRK:714000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:1011:1012:1 KULTURA:714000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:1031:1032:3 UR1:714000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:0:1111:11 UR2:714000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:0:1121:12 UR3:714000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:0:1131:13

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I think the following parameters can be used in place of `AUTO' for all the above...
FEC 2/3
Guard Interval 1/32

Can you verify this by parsing the NIT info on PID 16 (PID 0x10) on all frequencies? This matches the results from 650MHz below...

Particularly as I read that there's apparently a SFN, making me wonder about the guard interval...

thanks

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Posting an update to the list...

Actually, I have found another site; apparently at 634MHz, the FEC used may be 3/4, while 2/3 is used for all others, and all have GI 1/32...
www.dvbtonline.com

What you would need to do, is to use something like dvbsnoop -s ts -tssubdecode -if [foo] 16' after using something like dvbstream' to record from each frequency, writing to file -o:[foo]' -- or using tzap' to tune each frequency, and `dvbsnoop' on the tuner output directly.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Hello Dmitry, I hope you are able to keep warm this winter :-)

I am sending a copy of my reply to several of your messages to the mailing list, in case someone else is able to help, and in the unlikely event that what I write might be useful to someone else. I hope that is okay for you...

To give a bit of context to this question, I had read that some of the frequencies in use in Kiev/Kиïв were part of a Single- Frequency Network (SFN). That is where the same frequency is used by several transmitters relatively close to each other to cover a larger area than can be reached from a single site.

This works because one of the features of DVB-T is the Guard Interval, which allows the receiver to make use of reflections, echoes, multipath interference, or for a SFN, signals received from additional transmitters which appear as a long echo.

I am not an expert on this, but as I understand it, the maximum distance between separate transmitters on the same frequency which send the same programmes is determined by the guard interval. In countries where use is made of a Multiple-Frequency Network (MFN) such as France for the most part, the smallest guard interval is used, allowing for a higher available bitrate from the 8MHz channel bandwidth, with the drawback that there are more frequencies in use, and it is likely that one can receive the same programming two or three or more times in one location between different transmitters.

In contrast, in Germany (see the de-BW list which I posted to this mailing list some weeks or months ago), the same frequency is in use at several widely-spaced transmitters, but not so far apart that one cannot receive more than one at some locations. For this, a guard interval is chosen that is much larger, say, 1/4 instead of 1/32, but this also means that less overall bitrate is available on a particular 8MHz channel.

Hinted at in the de-BW list is that in Switzerland use is also made of several SFNs, consisting there of some higher-power transmitters on a particular frequency, supplemented by many lower-power transmitters on the order of kilowatts, due to the terrain making it difficult to cover the many valleys that the high-power transmitter fails to reach. The large number of filler transmitters makes it impractical to list them all with the redundant info in the way that I did in de-BW, though a list can be downloaded in case specific information is needed to properly site a receiving antenna.

With analogue broadcasting, this SFN use was not possible, as more than one transmitter on the same frequency results in the familiar interference that could be seen where multiple low-power filler transmitters were received.

For readers in ATSC-land, this can be a difficult concept to grasp, as for the most part, all stations are independent of each other and use a single high-power transmitting site, so as I understand from reading gripes on Slashdot (which is the closest I care to come to understanding details of ATSC), there is no provision made for handling multiple transmitters, and as a result, multipath interference or other echo sources, and reception is nowhere near as robust as the case I've experienced where a virtually unwatchable analogue frequency is turned into a clear DVB-T signal, and a literally unwatchable frequency is turned into mostly-clear DVB-T. That is, for US-types, there is no concept of a national broadcaster (with, say, vague tuning info, like, 97 to 99 FM' as opposed to a specific frequency, 88.3 on your FM dial'). But I digress...

Anyway, a guard interval of 1/32 would be used by a single transmitter, or perhaps two closeby transmitters on the same frequency, whereas for a Single-Frequency Network (SFN), I would expect to see a different value, depending on the size of the coverage area, like 1/8 as in Paris, or 1/4 as used for the national and regional broadcasters in Germany. This is why I was somewhat confused by the conflict of seeing the use of SFN to refer to Kiev, while seeing 1/32 given as a guard interval. But I am completely unfamiliar with the DVB-T network in and near Kiev or throughout the Ukraine.

That was much more than I needed to write about that...

Thank you, and the same to you!

This shows that you were able to able to tune with success to 634MHz and list the available programmes, so at least `scan' was able to lock onto that frequency with the given parameters. (the other available frequencies were listed in your following message)

However, for some reason, `mplayer' was not able to lock onto the same frequency.

[much snipped]

In this verbose output from `mplayer', the frequency is correct, while the other strange values are only relevant for satellite DVB-S, and can probably be ignored...

I am not sure if the lack of any values here means anything, because I've never needed to debug DVB-T tuning with `mplayer', as it has ``just worked'' for me...

The `bandwidth' value seems wrong, while it is correct in the tuning file above, but that may not mean anything...

Again, there is some problem being able to lock onto this frequency. Which seems strange, because `scan' appeared to be able to list the services.

However, this might be easier -- at least in my outdated dvbstream' the default FFT transmission mode is 2k, while it should be specified as 8k for Kiev, so you will need to add -tm 8' to your above command line.

Try that and see if it works...

The other parameters seem to be correct, at least as seen in a quick g00gle result:
paбoтaeт в ДMB-диaпaзoнe нa 51 TBK 714 MΓц, мoщнocть дo 1 ĸBт;
пapaмeтpы COFDM мoдyляции: 64-QAM, FFT 8K, Code Rate 2/3, Guard Intervals 1/32, Bandwidth 8 MΓц.

If you edit your channels.conf file to use these values at 714MHz for channels
51 | 714,0 | KΓTPK, 1+1, 24, Toниc, Kyльтypa, Enter-φильм, УP-1, УP-2/Πpoминь, УP-3/Kyльтypa
in place of `AUTO' and try that, maybe that will work.

I think there are some tuners that require specific values and will not work with `AUTO', although there are many that will work...

hope this is helpful
barry bouwsma
some random 8-bit chars to make sure this gets tagged as utf-8... „…™ψöžא

_______________________________________________
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

Hi Dmitry, thank you for your mail!

I am posting part of it to the linux-dvb list, in case someone there can give more or better information than I do...

Off-topic here, but to explain --
In the more-than-ten years since I last used the mail program I am using now, the language and multi-lingual support has greatly improved -- back then, it would make no effort to try and display your Cyrillic characters, be they in KOI8-U, or ISO-8859-5, or whatever - if I had selected to display, say 8859-1, or 8859-2 for Czech.

But today, even with my use of the text console and no windowing system, I can display Cyrillic, Polish, Slovak, French, Hebrew, Greek -- all at the same time. Yay!

However, when I sent out a message with Greek characters, I saw in my local copy of it, that it was sent as 8859-7. But I do not know if many mailers are able to understand how to convert from that and display properly with a Unicode font.

The same way, when I sent the Ukranian text, it could be that some people in western europe, or outside europe entirely, might not see the characters correctly, because my mailer was set up to use the smallest possible unique character set tagging, rather than UTF-8 which has become far more common now (yes, I should fix my mailer configuration).

So, in order to give the message a UTF-8 character set tagging, so that it could be displayed simply by any utf-8-aware xterm with a -10646 font, or on a text console with Unicode enabled and a font that uses as many possible characters in the 512 that are available, with a mailer that does not know how to convert from 8859-x into Unicode, I needed to insert a few German and Greek and Hebrew characters that are not common to 8859-5.

And that is why I did not send only the Cyrillic characters, in case some mailer fails, and displays them as western-european or something else, the way I used to see things...

This is easy to set up with X as there are plenty of -10646 fonts available in the years since I contributed an 8859-2 font; for the very nice large font of a 25x80 text console on a nice large monitor that does not strain my eyes, I like SCREEN_FONT=/usr/local/src/fonty-rg-0.5/LatCyrGr-16.psf.gz that makes many useful g00gle results readable to me.

Again, sorry for going off-topic for so long...

Now, to your question, which maybe some linux-dvb reader can offer more help...

Yes, this is very possible.

The one thing to be certain of, is that you are not using a USB-1 device, as the bandwidth of USB 1 is less than most DVB-T multiplexes today -- usually you can fit at least two services without problems, though, over USB 1.

The special ``PID'' of 8192 is used by, for example, `dvbstream' meaning to send the entire datastream with all PIDs to its output. It will also do all the tuning for you.

Or, if you know all the PIDs that are used on a particular frequency, you can usually list all of them of interest, up to the limit of the hardware PID filter, if there is one.

This can save some space, as PID 8191 usually takes up some bandwidth for null packets to fill the available bandwidth, and there may be unneeded services, such as data, teletext, or whatever, that you do not care about.

For example, here is what I would use to record three of the RTVi services which are sometimes FTA on Hotbirds:

/home/beer/bin/dvbstream  ${OPERA1}  -T  \
    -s 27500   -p h   -f 12322   -I 2   -D 2  \
    -o:${RECROOT:-/opt}/Partial_Transport_Streams/detskii_mir-fs-${DATE}.ts  \
    0 44  -v 45  -a 46   40 41 42  47 48 49   $*

(I am actually guessing that the last 6 PIDs are correct, as I only recorded the one service...)

Then you only need to select which programme you wish during playback with your media player (you may need to record some additional PIDs to see the service name). Or you can split the three services into three separate files.

I use the 8192' PID when I want the entire stream, but if you want to use tzap' or similar, then whatever program you use after that needs to set all the PIDs -- for example, `dvbtraffic' after I've tuned to a DVB-H multiplex... -PID--FREQ-----BANDWIDTH-BANDWIDTH-

0000    20 p/s     3 kb/s    31 kbit        0
0011     3 p/s     0 kb/s     5 kbit       17
0012    23 p/s     4 kb/s    35 kbit       18
0015     1 p/s     0 kb/s     2 kbit       21
0020    19 p/s     3 kb/s    29 kbit       32
[snip]
1fff  1533 p/s   281 kb/s  2306 kbit     8191
2000  6609 p/s  1213 kb/s  9940 kbit     8192

Other people would have to suggest programs which are able to do this for you, as I only know about `dvbstream' and have not tried using anything else...

barry bouwsma
(as always, writing too much)

_______________________________________________
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

Hi Barry,

Am Samstag, den 17.01.2009, 01:41 +0100 schrieb BOUWSMA Barry:

don't take it serious.

I wonder how much longer people will buy shark cadavers produced in the UK, until they realize that it are only shark cadavers.

Cheers,
Hermann

Hello Dmitry, I am pleased that I was able to help you!

But there is one thing that caught my interest, so I am again posting this question to the -dvb mailing list, and I guess to linux-media too:

To the readers of the list, and of linux-media, the default of `dvbstream' here is to use FFT transmission mode 2k, as was introduced in the UK, and it's clear how UK-centric this utility is based on the above line. (UK not meaning UA or Ukraine)

Now as part of DSO in the UK, the multiplexes are slowly to convert from 2k to 8k, and most other parts of the world are presently using 8k.

In fact, as I `grep' the latest dvb-apps scan files, only the UK sites listed seem to be using 2k, for now.

Does anyone familiar with DVB-T know whether 2k transmission mode is used elsewhere in the world?

If not, would it not be reasonable to default to 8k for this code, to make it applicable to the parts of the UK that have switched as well as most of the rest of the world?

Reading the CVS RCS files, this doesn't seem to have been updated for several years, and presumably distributed binary packages are using the UK defaults, the code of which seems unchanged from 2002, so I imagine this could use reworking.

It is indeed my pleasure. While I have not made a visit to your country, with the closest being in Košice, SK, I prefer to think that we are in the same part of the world, with much in common...

Now, back to the original subject of this message, a scanfile for Kиïв, with proper modulation values...

Can you run the following commands for me, then send me the files in /tmp/stream-* so that I can verify the modulation?

These will record three seconds worth of the NIT data with the modulation, into several small files in /tmp, for all the different multiplexes.

First, the command you used above to stream 5 ĸaнaл :

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
-f 650000000 -o:/tmp/stream-650.ts -n 3 16

Now try it with the other frequencies and see if you still can lock:

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 3_4 -bw 8 \
-f 634000000 -o:/tmp/stream-634.ts -n 3 16

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
-f 714000000 -o:/tmp/stream-714.ts -n 3 16

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
-f 818000000 -o:/tmp/stream-818.ts -n 3 16

And last, a frequency where the services are in MPEG-4:

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
-f 682000000 -o:/tmp/stream-682.ts -n 3 16

If you have success, then you can send me all the files in /tmp/stream-*.ts, and I will look at them, make sure that all the data in the scanfile is correct, and confirm it to Christoph Pfister...

thanks,
barry bouwsma