From d3e242095e79a1930141b3f3a1394d0e4993dcf3 Mon Sep 17 00:00:00 2001 From: "Matthias P. Braendli" Date: Thu, 30 Jul 2015 22:05:01 +0200 Subject: Fix minor mistakes, start SFN chapter --- Makefile | 3 +- figures/txchain-sfn.pdf | Bin 0 -> 17894 bytes figures/txchain-sfn.svg | 567 ++++++++++++++++++++++++++++++++++++++++++++++++ interfaces.tex | 8 +- mmbtools.tex | 1 + scenarios.tex | 3 +- sfn.tex | 149 +++++++++++++ 7 files changed, 725 insertions(+), 6 deletions(-) create mode 100644 figures/txchain-sfn.pdf create mode 100644 figures/txchain-sfn.svg create mode 100644 sfn.tex diff --git a/Makefile b/Makefile index 543f8e9..c782044 100644 --- a/Makefile +++ b/Makefile @@ -3,7 +3,8 @@ includes = introduction.tex \ interfaces.tex \ scenarios.tex \ appendix.tex \ - systemenvironments.tex + systemenvironments.tex \ + sfn.tex bib = dab.bib diff --git a/figures/txchain-sfn.pdf b/figures/txchain-sfn.pdf new file mode 100644 index 0000000..2cd10a4 Binary files /dev/null and b/figures/txchain-sfn.pdf differ diff --git a/figures/txchain-sfn.svg b/figures/txchain-sfn.svg new file mode 100644 index 0000000..63a1508 --- /dev/null +++ b/figures/txchain-sfn.svg @@ -0,0 +1,567 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + ... + MultiplexerODR-DabMux + + + + ModulatorODR-DabMod + + + + USRP + + + + + Includes timestampsinto ETI stream + + + + + + ModulatorODR-DabMod + + + + USRP + + + IP Network + + + USRP + Timestandard + + + 10MHz & 1PPS + 10MHz & 1PPS + + + + Several km + + + Timestandard + + Multiplex operator + + Transmitter site #2 + + Transmitter site #1 + + diff --git a/interfaces.tex b/interfaces.tex index 41bf72d..512bde2 100644 --- a/interfaces.tex +++ b/interfaces.tex @@ -24,7 +24,7 @@ The DAB+ programme is encoded to \filename{prog2.dabp}. The extension other AAC encoded audio, it makes sense to use a special extension. The command is: \begin{lstlisting} -dabplus-enc -i prog2.wav -b 88 -a o prog2.dabp +dabplus-enc -i prog2.wav -b 88 -o prog2.dabp \end{lstlisting} These resulting files can then be used with ODR-DabMux to create an ETI file. @@ -188,7 +188,7 @@ buffer is empty. Then the multiplexer will enter prebuffering, and wait again until the buffer is full enough. This will create an audible interruption, whose length corresponds to the prebuffering. -Or the sound card clock is a bit slow, and the buffer will be filled up faster +Or the sound card clock is a bit fast, and the buffer will be filled up faster than data is consumed by the multiplexer. At some point, the buffer will hit the maximum size, and one superframe will be discarded. This also creates an audible glitch. @@ -204,7 +204,7 @@ insures that the encoder outputs the AAC bitstream at the nominal rate, aligned to the NTP-synchronised system time, and not to the sound card clock. The sound card clock error is compensated for inside the encoder. -Complete examples of such a setup are given in the Scenarios. +Complete examples of such a setup are given in the scenarios. \subsubsection{Authentication Support} In order to be able to use the Internet as contribution network, some form of @@ -240,3 +240,5 @@ input but instead of using files, FIFOs, also called ``named pipes'' are created first using \texttt{mkfifo}. This setup is deprecated in favour of the ZeroMQ interface. + +% vim: spl=en spell tw=80 et diff --git a/mmbtools.tex b/mmbtools.tex index 0ab988b..c279eec 100644 --- a/mmbtools.tex +++ b/mmbtools.tex @@ -200,6 +200,7 @@ clock_config_t}, \include{interfaces} \include{scenarios} \include{systemenvironments} +\include{sfn} \appendix \include{appendix} diff --git a/scenarios.tex b/scenarios.tex index cd5f4f3..eeb3c55 100644 --- a/scenarios.tex +++ b/scenarios.tex @@ -329,5 +329,4 @@ the DAB or \dabplus encoder has to be moved to the programme originator's premises, and should directly encode the audio signal coming from the studios. This is illustrated in ``Studio C'' in figure~\ref{fig:txchain-with-encoders}. - -\subsection{Single-Frequency Networks} +% vim: spl=en spell tw=80 et diff --git a/sfn.tex b/sfn.tex new file mode 100644 index 0000000..febdc1f --- /dev/null +++ b/sfn.tex @@ -0,0 +1,149 @@ +\section{Single-Frequency Networks} +\subsection{Requirements} +The DAB standard has been designed to enable the creation of transmission +networks where several transmitters share the same frequency, and send the same +signal synchronously. Such networks are called ``Single-Frequency Networks''. +Each transmitter needs to be fed the same multiplex stream, which must include +timing information required for synchronisation. This timing information implies +that a time reference must be installed at each transmitter. + +The requirements for a SFN can therefore be summarised in three points: +\begin{itemize} + \item The signal must be \emph{identical} for each transmitter. This + requires a common multiplexers, and a distribution network that carries + the ETI to all modulators. + \item All transmitters must transmit on the \emph{same frequency}. The modulators + require a frequency reference. + \item The signal must be transmitted at the \emph{same time}, which requires + a time reference at each site. It also implies that the ETI stream must + contain timestamps. +\end{itemize} + + +The figure~\ref{fig:txchain-sfn} shows a SFN setup with two transmitters. + +\begin{figure}[h] + \includegraphics[width=\textwidth]{figures/txchain-sfn.pdf} + \caption{This outline for a SFN shows two transmission sites.} + \label{fig:txchain-sfn} +\end{figure} + +\sidenote{Explain requirements on system time, NTP} + +\subsection{Multiplexer Configuration} +On the ODR-DabMux configuration, there are not many options that are specific to +an SFN setup. +Most importantly, the timestamp feature must be enabled using the ``tist'' option in +the ``general'' section. + +Furthermore, it is recommended to use the ZeroMQ transport between the +multiplexer and the modulators, which can be enabled in the ``outputs'' section. +Care has to be taken to have an output that slows ODR-DabMux down to nominal +rate. The ZeroMQ output alone does not enforce this. The following listing shows +the relevant options we just covered. + +\begin{lstlisting} +general { + tist true + ... +} + +... + +outputs { + ; Accept connections on all interfaces, on port 9100 + zmq "zmq+tcp://*:9100" + ; This throttles muxing down to nominal rate + throttle "simul://" +} +\end{lstlisting} + +\subsection{Modulator Configuration} +Since the modulator has to ensure that the three SFN requirements are satisfied, +its configuration is more complex. + +We will assume, in this explanation, that one of the following USRP devices is +used: USRP2, USRP B100, USRP B200. Other devices also support the necessary time +and frequency synchronisation, but they have not been well tested. These USRP +devices can accept different sources for the reference clock: +\begin{itemize} + \item The default ``internal'' source uses the non-disciplined + clock generator inside the USRP. It is not suitable for SFN. + \item The ``external'' source corresponds to the SMA connector on + the USRP. A 10MHz signal from an external source must be connected to + it. + \item The optional GPSDO that can be mounted inside the USRP, and is + selected as source with the ``gpsdo'' setting. +\end{itemize} + +For the time reference, the ``pps\_source'' option is used. Possible values are +``none'', ``external'' and ``gpsdo'', with analogous meaning as for the +reference clock. + +In case the USRP is connected to external references, the relevant configuration +would be as follows: + +\begin{lstlisting} +[uhdoutput] +refclk_source=external +pps_source=external +\end{lstlisting} + +These settings alone do not tell the modulator to enable synchronisation of the +transmission, they only select how the USRP is configured. To enable timestamp +decoding and the frame synchronisation logic in ODR-DabMod, the following +settings must also be set: + +\begin{lstlisting} +[delaymanagement] +synchronous=1 + +; The constant offset to be added to the TIST, in seconds +offset=2.0 +\end{lstlisting} + +The ``offset'' setting deserves some further explanations. The ETI data stream +contains TIST information, from which a time-stamp for each ETI frame can be +derived. Each ETI frame ($24$\ms interval) is therefore associated with a +precise point in time that defines the time of transmission of the corresponding +transmission frame.\footnote{It is slightly more complex, because one + transmission frame is composed of several ETI frames in some + transmission modes, but the principle stays the same. It suffices for this + explanation that we can derive the transmission time from the TIST +information.} The TIST information is set to current time at ETI frame +generation, and does not take in account the propagation delay across the +distribution network. Therefore, we need to add an offset, called $\delta$, to +the TIST to define transmission time. + +\[ +t_{transmission} = t_{TIST} + \delta +\] + +If this offset is set to a higher value, there will be a bigger delay (measured +in absolute time) between the point in time a frame is multiplexed and the point +in time the frame is transmitted. More frames therefore will be buffered in +the ODR-DabMod ZeroMQ input, increasing robustness against network latency +fluctuations. + +The offset already has two functions: it compensates for network delay and +allows a trade-off between delay and robustness. But it also serves a third +purpose: When doing coverage planning for an SFN, it is necessary to be able to +control the relative delay between transmitters in the order of milliseconds. +This tuning of relative delay is included in the ``offset'' setting. We can +therefore rewrite the above equation as: + +\[ + t_{transmission} = t_{TIST} + \delta_{network} + \delta_{planning} +\] +\[ + \delta = \delta_{network} + \delta_{planning} +\] + +\sidenote{Explain relationship with ZeroMQ max buffer size} + +\subsection{Using Ettus GPSDO} +\subsection{Using ODR LEA-M8F GPSDO board} + +\sidenote{Give example} + +% vim: spl=en spell tw=80 et -- cgit v1.2.3