[linux-dvb] scan command returning wrong FEC ?
robert_s at gmx.net
Mon Dec 17 11:27:38 CET 2007
From: "Simon G" <linuxtv at simong.net>
Unfortunately neither is a full transport stream - both files only
contained PIDs 0x0418 and 0x0419, so it's useless for analysis :(
Anyway, here's how the system works:
In case of an SFN (single-frequency network), the multiplex is generated at
one place and SFN MIPs (megaframe initialization packets) are inserted
which contain a GPS time synchronization offset and the transmission
parameters to use. The transmission towers will then transmit the signal
GPS time synchronized using the specified transmission parameters. In case
of an MFN (multi-frequency network) where only one transmission tower is
used, the transmission parameters are configured there.
In any case, the DVB-T signal contains TPS (transmission parameter
signalling) which contains the modulation type, FEC rates, hierarchy alpha,
guard interval and transmission mode. In effect, the receiver only needs to
know the carrier frequency and the channel bandwidth, and can autodetect
all other parameters. So it does no harm if it is given a wrong FEC rate -
at worst, it will take a little longer to lock the channel as the receiver
first needs to receive the TPS, whereas it might be able to lock faster if
it is given all the right parameters.
The transmission parameters given in the NIT are really only
informational - they SHOULD be correct but it doesn't harm if they aren't.
What actually affects the reception is the parameters given in the SFN MIP
(as it influences which parameters the transmission tower uses) and the TPS
(as they influence what the receiver will use). Now it'd be interesting to
see what happens if the transmission tower puts incorrect values in the TPS
bits, but I think that's quite unlikely to ever happen...
e-mail: robert_s at gmx.net
More information about the linux-dvb