DvbDream Community

to use in future instead of this XML draft which was planned in past. (it was neither programmer-friendly nor user-friendly)

Here is a basic draft if you would like to help & share your ideas on

* This format is more human readable, also more programmer and user friendly than any XML one
* I've used 3 charecter names for each mux parameter names because it looks neat. (otherwise with exact names, it was difficult to read, and it looked like a mess to me)
* Simple and flexible, Now I think that there is no need to obsess with ugly XML, Flexibility always possible.


SIMPLE SAMPLE:



--------------------------

---MUX PARAMETERS---

nam: StringTransponder Name/No (for ex, TP1, TP2, TP3, ... ) UHF/VHF Channel Name/No for Terrestrial and Cable - (for ex, CH01, CH02, CH03, ...)
mod: String Modulation Type

SATELLITE MODULATIONS:
QPSK, 8PSK, 16APSK, 32APSK, TURBO_QPSK, TURBO_8PSK

CABLE MODULATIONS:
QAM4, QAM16, QAM32, QAM64, QAM128, QAM256, 8VSB (ATSC only ?)

TERRESTRIAL MODULATIONS:
COFDM (enough?), 8VSB (ATSC only ?)

frq: Integer Frequency in KHz, valid values 50000 - 16000000 (enough? 50Mhz - 16Ghz)
pol: String Satellite Only Polarization V, H, L, R
syr: Integer Satellite and Cable Only Symbol rate in KSymbol/second, valid values 0-100000
grd: Terrestrial Only ? Guard Interval, valid values ???
inv: String Terrestrial Only ? Spectral Inversion, valid values yes/no
bwt: Integer Terrestrial Only Bandwidth in Mhz valid values 6,7,8 (DVBT & ATSC)
fec: String 1/2, 1/3, 1/4, 2/3, 2/5, 3/4, 3/5, 4/5, 5/6, 7/8, 8/9, 9/10 (enough? the values currently in use )


-- Extra Information --
These are the optional information to be hold in the same file per mux.
inf: String Provider and/or channel description for the transponder (just to display to user during scan)
tvr: Boolean Does the transponder(mux) include TV/Radio channels? (valid values yes,no)
fed: Boolean Does the transponder(mux) include feed channels? (valid values yes,no)
dat: Boolean Does the transponder(mux) include data channels? (valid values yes,no)
ipd: String Decimal pid values for internet services (possible usage on grabber softwares) for ex, ipd=1001, 1232,1420
net: Boolean suitable for NIT search? (valid values yes,no)

* Only "Inf" is strongly recommended since DVB applications could display this info in their transponder lists , next to the frequencies. i.e. user would be able to see what that transponder contains before trying to scan.
* As you can notice, not all parameters should be used in all network types.
* I'm not sure about all DVB-T/C and ATSC parameters and other possible DVB-S2 parameters, Please let me know if anything is missed

-- Header Information --
type: String The type of the list, valid values satellite/terrestrial/cable
name: String
for satellite, Satellite Name
for terrestrial and cable, Country Name

subname: String
for satellite, Satellite Position (4 digit SatcoDx code, i.e. 19.2°E = 0192 or 61.5°W = 2985)
for terrestrial, Region Name, for ex "Berlin" or "Winterhill"
for cable, Provider Name (The name of the cable company)
muxs: Integer Number of muxes included in the file.


yet another ugly draft

There's no such thing as TURBO_xxx modulation. The TURBO thing refers to FEC type, not modulation.

Of course there's no FEC type in the draft, so you'd have to add it. Here are some values:

Viterbi/Reed-Solomon (DVB-S)
LDPC/BCH (DVB-S2)
Turbo/Reed-Solomon (proprietary)

Note, there are many possible flavors of Turbo code. When you select "TURBO" you really mean "whatever this vendor means". For the purpose of transponder files, it probably should be called "dishn** proprietary" (or maybe "Broadcom Advanced" as the authors call it).

Also, you might want to add a parameter for roll-off factor:

0.35 - DVB-S, DVB-S2
0.25 - DVB-S2, dishn**
0.20 - DVB-S2

It usually does not matter, but it is possible in some cases to fail to lock if wrong rolloff is set.