https://wiki.opendigitalradio.org/api.php?action=feedcontributions&user=Andimik&feedformat=atomOpendigitalradio - User contributions [en]2024-03-28T19:48:49ZUser contributionsMediaWiki 1.19.20+dfsg-0+deb7u3https://wiki.opendigitalradio.org/Association_OpendigitalradioAssociation Opendigitalradio2020-04-16T11:26:43Z<p>Andimik: typo fixed</p>
<hr />
<div>L'Association Opendigitalradio a été fondée le 1er Novembre 2012 à Genève.<br />
Sous le nom d’Association OpenDigitalRadio, est constituée une association sans but lucratif, et<br />
jouissant de la personnalité morale, conformément aux dispositions des articles 60ss du Code Civil<br />
Suisse (CCS).<br />
<br />
===Mission===<br />
<br />
L'association a pour but de faciliter et promouvoir le développement de la radio numérique au niveau local. Cela se traduit en terme d’activités par:<br />
*Promouvoir et développer les technologies ouvertes de radiodiffusion numérique.<br />
*Expérimenter et documenter des techniques ouvertes de radiodiffusion numérique.<br />
*Former à la construction et aux déploiement de systèmes ouverts de radio diffusion.<br />
*Proposer des services de radiodiffusion temporaires ou permanents.<br />
*Intégrer des systèmes ouvert prêt pour la radiodiffusion.<br />
<br />
===Comité===<br />
<br />
*Président: [[User:coinchon|Mathias Coinchon]]<br />
*Vice-président: Stanislas Roehrich<br />
*Trésorier: Stéphane Miranda<br />
*Secrétaire: Nicolas Favrod-Coune<br />
<br />
*Software Development: [http://mpb.li Matthias Brändli]<br />
<br />
===Activités courantes===<br />
<br />
*[[Main_Page|Wiki opendigitalradio]] (base d'informations sur les techniques ouvertes de radiodiffusion)<br />
*Collaboration au projet [http://www.digris.ch Digris] (développement de la plateforme, validation)<br />
*Développement de l'intégration du système DAB+<br />
*Exploitation de l'[[Infrastructure FM Lausanne|infrastructure d'émission FM à Lausanne]].<br />
*Exploitation de l'[[Infrastructure FM Genève|infrastructure d'émission FM à Genève]].</div>Andimikhttps://wiki.opendigitalradio.org/DAB_measurementDAB measurement2020-04-16T11:25:15Z<p>Andimik: </p>
<hr />
<div>Measurement & monitoring tools, planning tools.<br />
<br />
==XPADxpert==<br />
The XPADxpert aims to display this information with the help of a DAB(+) recording and let interested persons take a look at what exactly is transmitted and to check for possible bugs. It is written in Java and provided as freeware without any warranty.<br />
<br />
*http://www.basicmaster.de/xpadxpert/<br />
<br />
==ETISnoop==<br />
[[etisnoop]] is a small tool to analyse ETI data.<br />
<br />
==DAB Player==<br />
[http://www.ukwtv.de/cms/downloads-aside/281-dab-player-von-andreas-gsinn.html DAB Player] from Andreas Gsinn is a receiver giving advanced information about the DAB multiplex and programs.<br />
<br />
==Radio mobile==<br />
<br />
[http://www.cplus.org/rmw/english1.html Radio Mobile] is a free software from Roger Coudé that implements Longley-Rice ITM model to estimate DAB coverage. <br />
It can be used with NASA SRTM free terrain model and can use different antenna pattern. The result can be displayed on map or exported as Google Earth format. Model uses terrain height but doesn't take into account buildings and reflections so it is a rough estimation.<br />
<br />
Parameters for estimating DAB coverage should be set to:<br />
*Broadcast, location probability 95%<br />
*Receiver height 1.5m <br />
<br />
[[Image:Coverage estimation EBU.jpg|800px]]</div>Andimikhttps://wiki.opendigitalradio.org/Example_of_the_creation_of_a_multiplex_on_ubuntu_12.04Example of the creation of a multiplex on ubuntu 12.042020-04-16T11:24:43Z<p>Andimik: typo fixed</p>
<hr />
<div>''This is Work in Progress !''<br />
<br />
This is the setup for teh launch of DAB/DAB+ broadcasting of the [SDN] mux including [Radio Galere] in Marseille France.<br />
<br />
This is done on Ubuntu 12.04.1 64 bits using a USPR1 with a WBX daughter card. Our mux is using the 5C frequency.<br />
<br />
<br />
= Installation of components =<br />
<br />
<br />
== Etti drivers for USRP1 Card ==<br />
<br />
<br />
This will add the etti deb source and install the uhd package that contains the driver : <br />
<br />
'''sudo bash -c 'echo "deb http://files.ettus.com/binaries/uhd_unstable/repo/uhd/ubuntu/`lsb_release -cs` `lsb_release -cs` main" > /etc/apt/sources.list.d/ettus.list'<br />
sudo apt-get update<br />
sudo apt-get install -t `lsb_release -cs` uhd'''<br />
<br />
== Gnuradio ==<br />
<br />
We use this PPA which contains prebuilt GNuradio 3.6.0 <br />
<br />
<br />
https://launchpad.net/~roman-moravcik/+archive/gnuradio<br />
<br />
<br />
== Dabmux == <br />
<br />
== Dabmod ==</div>Andimikhttps://wiki.opendigitalradio.org/CRC-Dwap.pyCRC-Dwap.py2020-04-16T11:24:00Z<p>Andimik: typo fixed</p>
<hr />
<div>CRC-Dwap.py is the USRP complex stream or file replayer command developed by Communication Research Center ([[CRC]]) from Canada. It is written in python and is open.<br />
<br />
CRC-Dwap takes complex sample as input, configure the USRP and daughterboard and send it to the USRP that is producing the [[RF]] signal.<br />
<br />
===Remark about frequency argument===<br />
Frequency argument (-f <FREQUENCY>) of CRC-Dwap.py can be either positive or negative. If it is negative, signal will be mirrored. This is useful for use with Basic TX board for example as we use the image frequency for transmission.<br />
For DAB transmission in band III, we generally use:<br />
* BasicTX board: -frequency (negative)<br />
* WBX and RFX400 modified board: frequency (positive)<br />
<br />
===CRC-Dwap.py===<br />
<br />
Usage: CRC-Dwap.py [options] filename1 [-f frequency2 filename2 [...]]<br />
<br />
Options:<br />
-h, --help show this help message and exit<br />
-a, --agc enable agc<br />
-c CLOCKRATE, --clockrate=CLOCKRATE<br />
set USRP clock rate (128e6)<br />
--copy enable real to imag data copy when in real mode<br />
-e ENCODING, --encoding=ENCODING<br />
choose data encoding: [s]igned or [f]loat.<br />
-f FREQUENCY, --frequency=FREQUENCY<br />
set output frequency (222.064e6)<br />
-g GAIN, --gain=GAIN set output pga gain<br />
-l, --list list USRPs and daugtherboards<br />
-m MODE, --mode=MODE mode: 1: real, 2: complex (2)<br />
-o, --osc enable oscilloscope<br />
-r SAMPLINGRATE, --samplingrate=SAMPLINGRATE<br />
set input sampling rate (3200000)<br />
-s, --spectrum enable spectrum analyzer<br />
-u, --usrp enable USRP output</div>Andimikhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2020-04-16T11:22:33Z<p>Andimik: grammar fixed</p>
<hr />
<div><br />
== Creating a contribution chain for a local radio DAB multiplex ==<br />
<br />
Now we have shown how to use a Raspberry Pi to provide a DAB Multiplex stream to an EasyDAB v2 we can create a full contribution chain for a local radio DAB multiplex simply based on low cost Raspberry Pi's : <br />
<br />
[[Image:RaspDAB contribution chain.png|800px]]<br />
<br />
Picture of RaspDAB contribution chain <br />
<br />
On top you see the EasyDAB modulator, which here stands for a full DAB transmitter based on the board, located at some (remote) transmitter site.<br />
<br />
The transmitter receives the the DAB Multiplex stream from the RaspDAB Multiplexer unit, which can be located somewhere else (we call this the Multiplexer site). But it requires a reliable IP connection, preferably by cable/fiber. The 'IP routing' boxes indicate there is likely to be some sort of routing equipment on those IP connections, which should open the correct IP addresses and ports for the connection to be established. Especially if the IP connection is to be using the open Internet you should have some sort of firewall protection on both ends to avoid service interruption due to hacking attempts.<br />
<br />
Also be aware that in the default RaspDAB setup the EasyDAB tries to establish a connection by searching for the IP address of the RaspDAB multiplexer. So you should establish a static IP address for the multiplexer and ensure the EasyDAB's request gets routed correctly to the RaspDAB unit. The same static IP address will be used by the ODR-audioenc program, but with a different port, to connect to the ODR-DABmux multiplexer as well. Each audio encoder requires a different port number, which will be indicated in the DABmux configuration file as well as the invocation of the ODR-audioenc software. They need to be identical ;o) ! For convenience, it might be a good idea to add the DABmultiplexer IP address to the /etc/hosts file, so you can refer to it by name in the configuration files.<br />
<br />
The multiplexer Raspberry Pi can also be used to encode an audio stream of a locally produced station. It is actually quite likely that this unit will be placed at the studio of a local radio station, from which a dedicated IP connection to the transmitter site might already be available. No need to install a separate raspi for the audio encoding !<br />
<br />
Other stations can be added by installing another Raspberry Pi with the ODR audio and PAD encoding software at the site of the playout equipment of those stations. Again, these should be connected to the multiplexer site with reliable IP connections, and the router settings should enable the audio encoders to connect to the multiplexer software.<br />
<br />
While setting up a local DAB contribution chain I have noticed it is possible to run up to 4 ODR-audioenc and 4 ODR-padenc encoders simultaneously on one Raspberry Pi model B v3. As this will only load the Raspberry Pi to about 40%, it should be capable of handling more, but the limitation is the processor's temperature. Without a heath sink on the processor it is likely to get too hot, which wouldn't be good for reliable operation. The load can be reduced a bit if you can supply the audio streams at the correct sampling frequency already. This will avoid having to use the sample rate converter, which is also likely to introduce noticeable audio artefacts, especially when encoding to the lower bitrates. The ODR-DabMux doesn't load the processor very much, so if necessary it can run alongside the maximum 4 audio and pad encoders.<br />
<br />
The audio and pad encoders actually are best located at the radio station's playout site, as this will enable dynamic PAD information to be provided, e.g. the artist and title of the current song, or the current temperature or road information. And having the audio stream created locally will also mean it shouldn't be a problem to have it available for encoding continuously. During the development of the RaspDAB chain receiving audio streams over the internet proved to be the most likely cause of service interruption, causing the encoders to halt operation as they couldn't re-establish the connection in time. Even the supervisor deamon wasn't able to ensure the service restarted, so manual intervention was required to bring the station back on air. One coarse solution is to include a crontab command to stop and restart the encoder at a fixed moment in time, but this will interrupt the service as well, so is best done during the night.<br />
<br />
So if you would like to create a multiplex with e.g. 16 stations, you will need at least 4 Raspberry Pi's with the ODR software installed. All will run 4 audio and 4 PAD encoders, plus one of those will also run the DABmux software. But it is highly recommended investing in a separate Raspberry Pi for each station that is to be carried in the mux, such that problems with the audio encoder halting operation can be avoided.</div>Andimikhttps://wiki.opendigitalradio.org/DRM_trial_II_in_SottensDRM trial II in Sottens2020-04-16T11:20:04Z<p>Andimik: grammar fixed</p>
<hr />
<div>[[Image:pylone2.jpg|right|350px]]<br />
===Introduction===<br />
Following the [http://www.coinchon.com/DRM_Sottens_fr.html amateur radio DRM trial on the phased out shortwave antenna in Sottens in 2004], it has been decided to make another amateur radio DRM trial but this time on the 188m MW antenna that has just been phased out on 31.12.2010.<br />
<br />
<br />
===Transmission schedule===<br />
<br />
The tests happened on 13th February 2011 and 20th February 2011 with 15 minutes periods on the following times (same for both Sundays):<br />
*20h-20h15 CET (19h-19h15 UTC) TX on 7.180 MHz<br />
*21h-21h15 CET (20h-20h15 UTC) on 3.780 MHz<br />
<br />
We used the narrowest band so 4.5kHz and high robustness to transmit slides.<br />
<br />
Please send your reception reports to [mailto:sottens@hb9mm.com sottens@hb9mm.com]<br />
<br />
[http://www.opendigitalradio.org/files/he3om_orig.mp3 Original audio loop transmitted]<br />
<br />
===Setup===<br />
<br />
'''[http://www.youtube.com/watch?v=LwOQJY9xzSc Video of a short tour of the room]'''<br />
<br />
[[Image:Setup1.jpg|200px]] <br />
[[Image:Setup2.jpg|200px]]<br />
[[Image:First stage.jpg|200px]]<br />
[[Image:Final stage.jpg|200px]]<br />
[[Image:Power out.jpg|200px]]<br />
[[Image:Transmission laptop.jpg|200px]]<br />
[[Image:Gnuradio.jpg|200px]]<br />
[[Image:Reception monitor.jpg|200px]]<br />
[[Image:Dream receiver.jpg|200px]]<br />
[[Image:Commercial DRM receiver.jpg|200px]]<br />
<br />
<br />
*[http://www.drm-sender.de Spark software] (free full licence gracefully offered by Michael Feilen)<br />
*[[USRP]] with LFTX daughterboard<br />
*[http://www.minicircuits.com Mini-circuits] Gali74+ amplifier<br />
*Preamplifier recycled from the bin by Yves HB9DTX: ENI modell-300, 40 dB from 40 kHz to 110 Mhz, 1-2W max output power<br />
*Amateur radio linear amplifier.<br />
<br />
<br />
Mode used: <br />
*4.5kHz, Mode B, MSC 16QAM, EEP code rate 0.5, AAC audio at 4.8kbit/s<br />
*4.5kHz, Mode B, MSC 64QAM, EEP code rate 0.5, AAC Audio, MOT Slideshow at 2.56 kbits/s<br />
<br />
===Report===<br />
<br />
The signal has been received in various places in Europe and even in Sweden and Latvia. It is impressive considering the low transmitted power compared to normal broadcast DRM transmission that use normally kilowatts and also considering the antenna that is not designed for such frequencies.<br />
<br />
See also: <br />
*Reports on DRM RX forum: http://www.drmrx.org/forum/showthread.php?t=2307<br />
*[https://picasaweb.google.com/hb9hli/SoireeDRMASottens#slideshow/5582217595984040226 Pictures by HB9HLI]<br />
*[http://hb9hli.wordpress.com/2011/02/21/soiree-drm-a-sottens/ Article by HB9HLI (in french)]<br />
<br />
===Credits===<br />
<br />
Credits to Yves HB9DTX, Stan from Maxxima, the [http://www.hb9mm.com HB9MM amateur radio club] and Swisscom for lending for a month such a great antenna. At least Sottens will have gone digital before dying. It shows also that DRM transmission can be done with limited equipment (apart from antenna), an interesting thing for local or community radio.<br />
Mathias HB9UFQ<br />
<br />
===See also===<br />
*HB9MM special operation in Sottens: http://www.hb9mm.com/sottens<br />
*[http://www.drmrx.org/receiver_mods.html Receiver modification] to catch DRM transmissions using [http://drm.sourceforge.net Dream] or [http://nt.eit.uni-kl.de/static/diorama/index.html Diorama] or [http://www.dsp4swls.de/sodira/sodiraeng.html SODIRA] or any other commercial software radio receiver.</div>Andimikhttps://wiki.opendigitalradio.org/Basic_TXBasic TX2020-04-16T11:15:32Z<p>Andimik: grammar fixed</p>
<hr />
<div>[[Image:BasicTX.jpg|thumbnail|USRP Basic TX daughterboard]]<br />
<br />
This USRP RF daughterboard take the signals from the D/A converters and provide the output with SMA connectors via transformers (2 output channels). It doesn't use any active components, what you get after the transformer is what you get from the D/A converter. This board can be used to drive an external quadrature modulator or to generate directly RF signals<br />
<br />
The D/A converter of the USRP is at 128MHz so it is possible to generate frequencies up to 64MHz. However, because of the absence of filtering, there are harmonics centered around 128MHz and around 256MHz (and higher but components get much weaker). This is the reason why it is possible to generate signals in VHF bands.<br />
<br />
For example to generate a signal at 225MHz, the baseband signal will be at 31 MHz and the harmonics at 128-31=97MHz; 128+31=159Mhz; '''256-31=225MHz'''; 256+31=287MHz. <br />
Because we use a "soustractive" harmonic, the signal is mirrored so it is necessary to generate a mirrored baseband signal so that it have it corrected. This can be done by adding a "-" sign to the frequency argument in gnuradio or [[CRC-Dwap.py]].<br />
<br />
<br />
==DAB tests with Basic TX==<br />
<br />
[[Image:dab_s_1.jpg |thumbnail|USRP with BasicTX]]<br />
Test with the BasicTX: On the picture you see the board installed inside the USRP, TX A port (Upper right)<br />
<br />
When we generate a signal on this board we have measured a total power of 18 uW. (with 50 ohm load 0 dB of gain in the gnuradio module)<br />
<br />
As we use one DA from the TX A port (USRP have two DA's with balanced output on each port) we get a real signal at the output, meaning that you get every harmonics and image frequency till they go in the noise floor (bandwidth of the onboard transformer used to unbalance and adapt the output inpedance)<br />
<br />
<br />
This is a typical output spectrum of the BasicTX. <br />
Note the red marker showing the desired working frequency in the Band III (see [[Band 3 Channels]]) (exact value: 12C @227.360 Mhz during the measurement).<br />
To filter the lower and stronger peaks will required more than 80 dB of attenuation and the same for the next upper peak ! The picture show the spectrum from 0 to 750 Mhz<br />
<br />
[[Image:dab_s_24.jpg]]<br />
<br />
<br />
'''So ! this will required further filtering before applying any pre amplifier stage... '''<br />
<br />
The same now but with a first filtering trial... we still have too much unwanted carriers near the working band !!! TBC...<br />
<br />
[[Image:dab_s_25.jpg]]</div>Andimikhttps://wiki.opendigitalradio.org/IntroductionIntroduction2020-04-16T11:14:44Z<p>Andimik: typos fixed</p>
<hr />
<div><big> <b>Open and easy digital broadcasting techniques based on software radio - because digital radio transmission and development must also become democratized. </b></big><br />
<br />
Broadcasting is sometime considered, by the new generations, as a dying media that will be soon completely superseeded by Internet. However, it stays an efficient and sustainable way to reach masses without intermediaries but just using radio spectrum directly (despite the fact that the use spectrum is subject to licence). For these reasons and apart from the big public or private broadcasters interests, it has still an interest for local communities. In particular, it offers anonymous listening and is free-to-air (no subscription needed) what is important when considering net neutrality, operators problems.<br />
<br />
In radio, Analog transmission using AM, FM is still very popular but may be replaced in the future by digital techniques such as [http://www.worlddab.org/introduction_to_digital_broadcasting/dab_digital_radio DAB], [http://www.worlddab.org/introduction_to_digital_broadcasting/dab_plus_digital_radio DAB+], [http://www.worlddab.org/introduction_to_digital_broadcasting/dmb_-_mobile_television T-DMB], [http://www.hdradio.com HD Radio], [http://www.drm.org/ DRM30] (Digital Radio Mondiale, for LF, MF and HF) or [http://www.drm.org/ DRM+] (for VHF). <br />
In television, analog transmission using NTSC, PAL or SECAM is being stopped worldwide and replaced by ATSC, ISDB-T, DVB-T, DVB-T2, DVB-H (for mobile) or other digital satellite or cable transmission techniques.<br />
<br />
Transmitting using these technologies usually requires complex and costly equipment out of reach of individuals. However, since the democratization of software defined radio (SDR), a new field of possibilities opens for experimentation, micro networks, etc. In the longer term also if software based radio become also democratized in common receivers, it could even be possible to develop personalized broadcasting system based on free/open technologies for example. The combination of personal (Internet,..) networks and broadcast also offer interesting possibilities (see [http://www.imdalliance.org/ IMDA] and [http://www.radiodns.org/ RadioDNS]).<br />
<br />
So this website will focus on tips, tricks and techniques to produce and receive digital broadcast signals. Most of the content is based on development from research centers, groups or individuals that did the "real work". The objective of this website is to follow developments, integrate them and show applications.<br />
<br />
The current wiki is not enabled with write access by default in order to avoid spam. Please contact us if you would like to participate and get write access.</div>Andimikhttps://wiki.opendigitalradio.org/How_to_install_CRC_DAB%2B_transmission_chain_from_scratch_in_Ubuntu_11.04How to install CRC DAB+ transmission chain from scratch in Ubuntu 11.042020-04-16T11:12:33Z<p>Andimik: grammar fixed</p>
<hr />
<div>Howto by Ulrik Brinck on CRC DAB+ installation on Ubuntu 11.04<br />
===Introduction===<br />
<br />
How to install all the needed software for transmitting DAB+ from scratch on Ubuntu 11.04. Some of it was absolutely not straight-forward in this Linux distro, but with good help from particularly Pascal Charest in the mailing list (thank you Pascal!), I succeeded in the end. So here, I will describe step-by-step how it can be done.<br />
<br />
'''Addition, 2013''': This setup has been reported '''not''' to work with the latest generation of the WBX board (WBX revision 3).<br />
<br />
===Notes===<br />
<br />
Please note:<br />
* The OS in my case is Ubuntu 11.04, 32 bit version, standard version (not the server version). Hardware is Ettus USRP1 and WBX daughterboard. I have not tried it with other OS or hardware.<br />
* I only intend to describe how to install all the software, not how to use it after installation. But how to use it is pretty much the same as on the mmbTools live cd, based on Ubuntu 9.04. Note however, that crc-dabmod, crc-dwap.py and crc-dabplus are installed with their names in lower case, so they must be called with lower case names also in your shell script.<br />
* You will need to know how to unpack a tarball (.tar.gz og .tar.bz2 file). For tar.gz it's "tar xvzf package.tar.gz", and for tar.bz2 it's "tar xvjf package.tar.bz2".<br />
* I installed on a brand new Ubuntu 11.04 installation after installing all the OS updates offered by the Update Manager.<br />
* There might be some of it which can be done in an easier way, but I'm not that experienced with Linux, and this is what worked for me.<br />
<br />
====Step 0: Update your system====<br />
Begin with "sudo apt-get update" to make sure that you can install all that you need.<br />
<br />
====Step 1: Installation of Gnuradio 3.3.0====<br />
This is needed for USRP1 with WBX.<br />
# First "sudo apt-get build-dep gnuradio" (takes quite some time).<br />
# Then go to this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall and install all the dependencies as mentioned in the first step there (for Ubuntu 11.04). Do NOT continue with the next step (Installing GNU Radio) on that page. Instead -<br />
# Download and unpack this file: http://ftp.gnu.org/gnu/gnuradio/gnuradio-3.3.0.tar.gz (by default it goes to a "Downloads" folder in your homedir, this is fine).<br />
# Before you can compile it, you will need to apply a patch as described here: http://lists.nongnu.org/archive/html/discuss-gnuradio/2011-05/msg00108.html But it was not so easy to apply the patch directly from that page, so you might want to just patch it manually instead (in fact, that's what I did) : To patch it manually, open ~/Downloads/gnuradio-3.3.0/usrp2/host/lib/usrp2.cc with a text editor. In line 41, 43 and 73 change "usrp2::usrp2" into just "usrp2". That's all, then save and close.<br />
# Now you can compile it as described in the file ~/Downloads/gnuradio-3.3.0/INSTALL . It's "./configure", "make", "make check" and "sudo make install".<br />
# Then back to this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall and scroll down to "Configuring USRP support" and perform the steps mentioned there. I chose to reboot the pc after this, to be absolutely sure that the USRP support would work. Note: The section also mentions that an UHD driver can be installed from the ettus.com homepage, but you don't need to do that.<br />
# At the end of the "Configuring USRP support" section of that page, there are some test you can perform to test that the USRP is available to Ubuntu. The "./usrp_benchmark_usb.py" test fails, but it doesn't matter in our case. The "./test_usrp_standard_tx" should however go well and a.o. show that your daughterboard is WBX (if that is actually what it is).<br />
<br />
====Step 2: Crc-DabMod and CRC-Dwap.py====<br />
# Download CRC-DabMod from the CRC homepage, http://mmbtools.crc.ca/content/view/44/71/ , unpack it and compile as described in ~/Downloads/crc-dabmod-0.2.0/INSTALL . It's "./configure --disable-debug", "make" and "sudo make install".<br />
# Then go here http://mmbtools.crc.ca/content/view/37/63/ and download CRC-Dwap.py for Gnuradio 3.3 .<br />
# Navigate to /usr/local/bin and replace the existing crc-dwap.py with the new one that you have just downloaded (rename it into crc-dwap.py (lower case) so that it's name becomes exactly the same as the old one). Then set it's permissions: "sudo chmod a+x crc-dwap.py".<br />
<br />
====Step 3: Crc-DabMux and Libfec====<br />
# First some necessary software: "sudo apt-get install devscripts". Note: This will also install a mail server (postfix) and ask you for a configuration, but, unless you actually want a mail server, you can just select "OK" and then "No configuration" (do not just close the terminal window).<br />
# And "sudo apt-get install debhelper" (you might already have this).<br />
# Go to http://mmbtools.crc.ca/content/view/39/65/ and download and unpack CRC-DabMux and Libfec 3.0.1-2.<br />
# Inside the Libfec 3.0.1-2 package are some more packages and a README file. Be sure to do EXACTLY as described in that README file. After that, also do "sudo dpkg -i ../libfec3-dev_3.0.1-*.deb" (thanks to Chaim Zax for this addition).<br />
# Compile CRC-DabMux as described in ~/Downloads/crc-dabmux-0.3.0.4/INSTALL. It's just the usual way, "./configure", "make" and "sudo make install".<br />
<br />
====Step 4: Buffer software====<br />
On the mmbTools live cd, the "bfr" buffer is used between CRC-DabMux and CRC-DabMod. But on this Ubuntu 11.04 system, my experience is, that bfr sometimes stops working and hangs the whole system. Instead I use mbuffer, which works better for me:<br />
# "sudo apt-get install mbuffer".<br />
<br />
====Step 5: CRC-DabPlus====<br />
Note: CRC-DabPlus is not free, because of HE-AAC royalty, but can be bought from CRC. If you don't have or want CRC-DabPlus, you can skip this step.<br />
Note: Together with CRC-DabPlus came HASP (for the software protection dongle) and Libfec. You already installed Libfec in step 3, so you don't have to do it again now.<br />
* Install HASP as described in the README-html which came with CRC-DabPlus (sudo dpkg -i *.deb).<br />
* As mentioned on http://opendigitalradio.org/index.php/CRC-dabplus there is a bit more to do, and for me it was a bit different in Ubuntu 11.04, this is what works for me: Open /etc/rc.local with a text editor (with root privileges, for example "sudo gedit /etc/rc.local") and insert the following lines before the existing "exit 0":<br />
sudo mount --bind /dev/bus /proc/bus<br />
sudo ln -s /sys/kernel/debug/usb/devices /proc/bus/usb/devices<br />
sudo /usr/sbin/aksusbd restart<br />
<br />
* Insert the dongle in an empty USB slot and reboot the computer. License for CRC-DabPlus is now ready.<br />
* Install CRC-DabPlus as described in the README.html.<br />
<br />
====Step 6: AudioScience ASI504x sound cards====<br />
In the README.html which came with CRC-DabPlus is described how to use it together with AudioScience sound cards. It also tells how to install the AudioScience cards, but this is NOT necessary in Ubuntu 11.04. It already works "out of the box". However, the GUI sound control panel does not work correctly with these cards, so if you need to change its configuration, you must use the non-GUI alsamixer (type "alsamixer" in a terminal window).<br />
<br />
That's it. Now you're ready to set up your DAB multiplex.</div>Andimikhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2020-04-16T11:11:42Z<p>Andimik: grammar fixed</p>
<hr />
<div>Coverage planning usually require complex and expensive tools to predict wave propagation using terrain models.<br />
<br />
However since many years, Roger Coudé has developed a planning software for amateur radio, implementing the Longley-Rice model and using public terrain height maps. This software can also be used to make prediction of broadcast coverage.<br />
<br />
*[http://www.cplus.org/rmw/english1.html Radio Mobile website]<br />
<br />
Example for FM broadcast coverage prediction:<br />
*[http://www.emetteurs.ch/coverage_maps/maps.html Coverage estimation of some private FM stations in Switzerland]<br />
<br />
Transmitter maker Nautel has on their website a coverage prediction tool that can be used after registration:<br />
*[http://www.nautel.com/support/technical-resources/rf-toolkit/ Nautel RF toolkit coverage prediction]<br />
It appears to be based on the [http://www.ve2dbe.com/english1.html Radio Mobile website by Roger Coudé]. The limitation is that the antenna directivity diagram cannot be included, but for omni-directional transmissions this is quite handy. And it allowes estimations at the actual band III frequencies, which the Radio Mobile website doesn't.<br />
<br />
The directivity diagram can be included in the model available on the Canadian Communications Research Center's website:<br />
*[http://lrcov.crc.ca/main/ CRC CovWeb]<br />
This requires registration as well, and is not as detailed as the Nautel results, but very useful with directional transmissions.</div>Andimikhttps://wiki.opendigitalradio.org/RaspDAB/Install_the_OpenDigitalRadio_softwareRaspDAB/Install the OpenDigitalRadio software2020-04-16T11:11:01Z<p>Andimik: grammar fixed</p>
<hr />
<div>After you have logged in as the new user (let's assume ' odr'), it is time to install the OpenDigitalRadio software.<br />
<br />
As the modulation of the DAB signal will be performed by the EasyDAB board, it is not necessary to install ODR-DabMod and related packages. I have modified the debian.sh script such that just the non-modulation related programs are installed, and called it raspdab.sh. You can find it in the github repository. Download it and save it in the home directory of the new user.<br />
<br />
Before running the script we have to make sure it can download the various software packages. By default, the location of those packages is not enabled in the raspbian /etc/apt/sources.list file. So we have to edit that file. Open a terminal console window and type:<br />
<br />
$ sudo nano /etc/apt/sources.list<br />
<br />
This opens the sources file with the nano editor - it will look familiar since you also used it to give the new user superuser rights.<br />
<br />
Uncomment (that is, remove the '#' in front of) the 3rd line, that starts with deb-src so the system can get to the debian source files. Save (CTRL-O) and exit (CTRL-X).<br />
<br />
Let's first see if there are updates, so type<br />
<br />
$ sudo apt-get update<br />
<br />
You will see the system contacting the software repositories and download any updates that are required.<br />
<br />
== RaspDAB script ==<br />
<br />
By default, the script will not run, so we have to make it executable. Assuming you operate from the home directory, enter<br />
<br />
$ chmod +x raspdab.sh<br />
<br />
This will not give any feedback, but you can check was successful by issuing<br />
<br />
$ ls -l<br />
<br />
which lists the contents of the home directory. Raspdab.sh should stand out and have 3 times an x in front of it, showing it is executable.<br />
<br />
Finally, we can start the script by typing<br />
<br />
$ ./raspdab.sh<br />
<br />
It will first do some checks and ask whether or not you are sure what you are about to do. If you want to continue, press ENTER.<br />
<br />
You can go and do something else, as it is a lengthy process (about 2 hours, depending on your internet speed) downloading all packages, compiling those and installing them. But be sure to check every once in a while, as you will have to provide the user password a couple of times.<br />
<br />
Once the script is ready you will have a new directory dab in the home directory in which the ODR software is located. You can check the availability of the programs by running them with the -h option, which will show the help information, e.g.<br />
<br />
$ odr-audioenc -h<br />
<br />
Now the fun starts ! Let's see how to encode using ODR-AudioEnc !</div>Andimikhttps://wiki.opendigitalradio.org/Farsync_cardFarsync card2020-04-16T11:09:55Z<p>Andimik: typo fixed</p>
<hr />
<div>==Use with ODR-DabMux==<br />
<br />
To use the Farsync card with the ODR-DabMux multiplexer, the raw output has to be used:<br />
raw://<device name><br />
<br />
<device name> is the name of the device under linux.<br />
<br />
Usually, it is <br />
raw://sync0<br />
<br />
See below for more information on the farsync card on Linux.<br />
<br />
==Some information about the FarSite FarSync TE1 card==<br />
<br />
http://www.farsite.com/synchronous_X.21_RS422_V.35_RS530_PCI_PCIe_cards/farsync_e1_G.703_G.704_pci_card_linux_windows.shtml<br />
<br />
The TE1e model is preferred because the external clock input will allow you to connect a reference to avoid clock drift between audio encoders, multiplexer and modulators.<br />
<br />
About clock sources: [[Media:TE1eExtSyncClockConfigForSFN-V2.pdf]]<br />
<br />
<br />
On 05. Nov 2013, Kevin Curtis (FarSite) has communicated the following to the mmbTools mailing list:<br />
<br />
===Driver versions.===<br />
We try our best to keep up with the new Kernel releases, but this is sometimes an impossible task, so we now just try and keep up with the Ubuntu releases instead. However, if you do not find a release of the drivers that is compatible with the Kernel version that you need to work with, then please email support@farsite.com and will will do our best to resolve your issue.<br />
<br />
===Driver version compatibility===<br />
Each new release of the FarSync driver usually adds new functionality, and this normally means that the fstioc_info structure, which is used to pass configuration/ststus information between the farsync driver and an application, is changed also. We add new configuration/status fields to the end of the structure. In order to save you having to rebuild your application, say for example the CRC-DabMux tool, each time we make a release we have made it possible to tell the driver to be compatible with a specific previous version of the fstioc_info structure. This can be done in various ways. For example:<br />
<br />
* specify the base fstioc_info structure version at module load time. This is then the default value for all API sessions. If there is not a value set at module load time, then the structure version is assumed to be the latest version.<br />
* use the farutil <device> set_iocver <version> command. This will set the base version for a give FarSync port, e.g. sync0.<br />
* the application can use the ioctl(FSTCMD) with the command value of FSTCMD_SET_VERSION<br />
<br />
In the case of the MMB Tools I suspect you would use the first option and select the structure version at module load time.<br />
<br />
We have been using version numbers since 1.09.xx and for the FarSync base 2.1.x release the version numbers and their meanings are as follows:<br />
<br />
* 0 - compatible with versions 1.07.xx to 1.09.02<br />
* 1 - compatible with version 1.09.03 and 1.09.04<br />
* 2 - compatible with version 1.09.05<br />
* 3 - compatible with version 2.0.x<br />
* 4 - compatible with version 2.1.x<br />
<br />
===Setting the version with the module runtime parameter===<br />
<br />
The farsync and fsflex drivers can be passed a module load time parameter called fst_iocinfo_version. Depending on how the module is loaded the value can specified in one of two ways:<br />
<br />
when using modprobe to load the kernel modules, add the following lines to the /etc/modprobe.conf file<br />
options farsync fst_iocinfo_version=<value><br />
options fsflex fst_iocinfo_version=<value><br />
<br />
when using insmod to load the kernel module, append the parameter to the insmod command, for example<br />
insmod farsync.ko fst_iocinfo_version=2<br />
insmod fsflex.ko fst_iocinfo_version=2<br />
<br />
===Setting the version using the farutil command===<br />
<br />
When using the farutil command to set the compatibility version number please make sure that it is used before the FarSync port has been opened for use. When you have set the value you can check it has been set correctly. Here is an example:<br />
<br />
farutil sync0 set_iocver 3<br />
farutil sync0 get_iocver <br />
<br />
<br />
===Setting the version using the ioctl(FSTCMD)===<br />
If you want to be sure that your application will always work with a given version of the structure you can add the following to the initialisation section of your code:<br />
<br />
static void<br />
do_set_iocver (int version)<br />
{<br />
static struct fstioc_cmd my_cmd;<br />
unsigned char iocinfo_version;<br />
<br />
iocinfo_version = version;<br />
printf("Requesting IOC Info structure version to be %d\n",<br />
iocinfo_version);<br />
my_cmd.command = FSTCMD_SET_VERSION;<br />
my_cmd.version = 1;<br />
my_cmd.input_data_len=1;<br />
my_cmd.status = 0x55555555;<br />
my_cmd.data_ptr = &iocinfo_version;<br />
req.ifr_data = (char *)&my_cmd;<br />
if (ioctl(sock, FSTCMD, &req))<br />
{<br />
perror("Error in setting IOC Info version number\n");<br />
exit(0);<br />
}<br />
if (my_cmd.status == 0xaaaaaaaa)<br />
{<br />
printf("IOC Info version set to %d\n", iocinfo_version);<br />
}<br />
else<br />
{<br />
printf("Error processing IOC Info version. Status is %x\n", my_cmd.status);<br />
}<br />
}<br />
<br />
<br />
How do I know what my device names are called?<br />
You can use the command "cat /proc/farsync"<br />
<br />
# more /proc/farsync <br />
FarSync OEM Driver version 2.0.8 - Patch Level 00 - Build -b191<br />
2 Cards found<br />
sync0-sync1:(K4739218) FarSync T2U IRQ193, 2 ports, State: Running <br />
sync2-sync2:(K5329089) FarSync TE1 IRQ185, 1 ports, State: Running <br />
Total number of ports = 3<br />
<br />
Note also that the State should be Running, and if it not this value there may have been a problem loading the card with it firmware. Consult the Trouble Shooting Guide on the product CD for more help in this case.<br />
<br />
===Versions of FarSync TE1 cards.===<br />
We now have three versions of the FarSync TE1 card as follows:<br />
<br />
* TE1: A single port PCI card with an RJ48 and BNC tx and rx connector.<br />
* TE1R: A single port PCI card with a RJ48 connector only<br />
* TE1e: A single port PCI Express with an RJ48 and BNC tx and rx connector with an external clock input of up to 10mhz through a SMA connector is supported to allow synchronisation of the output data clock, to, for example, a GPS source.<br />
<br />
<br />
===Compilation Errors on install===<br />
If you are installing the FarSync drivers and encounter compilation errors when building the driver, then check to see if there is a later version of the driver for download on our website. If there is a later version then please use this one.<br />
<br />
If there are still compilation errors, check to see if there are any patches for this version of the driver on our website. If there are please install them.<br />
<br />
If there are still compilation errors then contact support@farsite.com<br />
<br />
The farsync drivers and latest patches can be found at http://farsite.com/custsupp/Download_FarSync_software.htm<br />
<br />
===Application Stability Issues===<br />
If your application crashes as soon as it is started, then it may have been compiled for an earlier version of the FarSync driver. Loading the farsync module specifying the correct fstioc_info version will probably resolve the issue.</div>Andimikhttps://wiki.opendigitalradio.org/Demonstration_of_open_source_digital_transmission_chain_at_IBCDemonstration of open source digital transmission chain at IBC2020-04-16T11:08:54Z<p>Andimik: typos fixed</p>
<hr />
<div>A full digital radio chain from studio to receivers has been demonstrated by EBU at IBC 2010 in Amsterdam.<br />
The demo was including<br />
* FM & RadioDNS using Gnuradio for FM RDS Stereo transmission and [http://code.google.com/p/ebu-radiovis-server/ EBU open radiovis server]<br />
* DAB/DAB+ & RadioDNS using [http://mmbtools.crc.ca/ CRC MMBtools]<br />
* DAB & Slideshow using [http://mmbtools.crc.ca/ CRC MMBtools]<br />
* DRM & Slideshow using [http://www.drm-sender.de/ Spark]<br />
<br />
A license was granted by the Netherlands regulation organism. An EIRP of 10 Watt was covering the site.<br />
Everything was included in a single 8 cores computer (2x 4 cores CPU's). Sound processing, Audio encoding & DMB, Multiplexing, Modulation, pre-filtering for the DAB signal, + FM with RDS and DRM ! <br />
<br />
Various receivers from smartphones to more classic devices were displayed during this setup to demonstrate the content produced on site (audio + enriched metadada like picture & text). A real small radio station was built on the stand using a Visual Radio production platform developed by EBU and based on Musicmaster music scheduling. <br />
<br />
EBU plan also to release the source code for the Visual Radio platform and the RadioVIS development on the Chumby (open wifi/FM receiver device).<br />
<br />
=== Event pictures: ===<br />
<br />
*The demo in action<br />
[[Image:Unknown IMG 9941-radio.jpg|500px]]<br />
<br />
*Building the setup, adjustments & debugging...<br />
<br />
[[Image:IMG_0376.jpg]]<br />
<br />
<br />
<br />
*The antenna for the Band III. (we were operating on the channel 10A)<br />
<br />
[[Image:IMG_0379.jpg]]<br />
<br />
<br />
<br />
*The setup<br />
<br />
[[Image:IMG_0412.jpg]]<br />
<br />
<br />
<br />
* The transmission platform: Software Radio Defined Everywhere ! DAB in-a-box<br />
<br />
[[Image:IMG_0386.jpg]]<br />
<br />
<br />
<br />
*A closer look: PC, USRP's (3x, the third one was on the back) amplifier and mask filter.<br />
<br />
[[Image:IMG_0407.jpg]]<br />
<br />
<br />
<br />
*Mask filter (to meet CEPT spectrum mask requirements for DAB).<br />
<br />
[[Image:IMG_0408.jpg]]<br />
<br />
<br />
<br />
*One of the 3 views (screen) on the unique machine, this one is the DAB screen.<br />
(Audio capture with Jack, Sound processing, audio encoder, DAB multiplexing and COFDM modulation with pre filtering)<br />
<br />
[[Image:IMG_0409.jpg]]<br />
<br />
<br />
<br />
*EBU Visual Radio Production platform !<br />
<br />
[[Image:IMG_0400.jpg]]<br />
<br />
<br />
<br />
*Live from IBC2010 !<br />
<br />
[[Image:IMG_0401.jpg]]<br />
<br />
<br />
<br />
*DAB with packet mode MOT slideshow on the Iriver B20.<br />
<br />
[[Image:IMG_0395.jpg]]<br />
<br />
<br />
<br />
*FM with RadioDNS on the Sony-Ericson Xperia (developed by Global Labs).<br />
<br />
[[Image:IMG_0396.jpg]]<br />
<br />
<br />
<br />
*FM with RadioDNS on the Nokia N900 (developed by Global Labs).<br />
<br />
[[Image:IMG_0397.jpg]]<br />
<br />
<br />
<br />
*FM with RadioDNS on Chumby One (developed by EBU).<br />
<br />
[[Image:IMG_0404.jpg]]<br />
<br />
<br />
<br />
*DAB with RadioDNS on Pure Sensia.<br />
<br />
[[Image:IMG_0402.jpg]]<br />
<br />
<br />
<br />
*DAB with RadioDNS on Pure Sensia.<br />
<br />
[[Image:IMG_0403.jpg]]<br />
<br />
<br />
<br />
*DAB with RadioDNS on Pure Sensia with live pics from the stand.<br />
<br />
[[Image:IMG_0405.jpg]]<br />
<br />
<br />
<br />
*DAB on Iphone via a 'Broadcast Hotspot' from Argo One<br />
(Digital receiver with WiFi AP to relay the free to air broadcast signal on a tuner-less device)<br />
<br />
[[Image:IMG_0399.jpg]]<br />
<br />
<br />
<br />
*DRM with SlideShow.<br />
<br />
[[Image:IMG_0387.jpg]]<br />
<br />
<br />
For more information, please contact Mathias Coinchon (coinchon at ebu.ch)</div>Andimikhttps://wiki.opendigitalradio.org/RaspDAB/Go_on_air_with_the_EasyDab_boardRaspDAB/Go on air with the EasyDab board2020-04-16T11:07:23Z<p>Andimik: typos fixed</p>
<hr />
<div>Now we can get the EasyDab v2 board to get on air ! But don't be too enthusiastic and operate it without an antenna or 50 ohm dummy load on the RF output: this could damage the output amplifier ! So connect a 50 ohm coax cable with e.g. short (about 36 cm) vertical antenna.<br />
<br />
You may need to create a small subLAN with an extra router, if only to be able to access the web interface of the board only once to set the IP address you plan to use in the future. The first time the board is powered up it will have a default IP address of 192.168.2.4, and you need to be able to access it. So start a PC which is on the same subLAN and start a webbrowser that you point to 192.168.2.4. If the EasyDab board can be reached it should respond by asking for a user ID and Password, which are both 'admin' by default. Once you provide that you should have access to the web interface to control the operation of the board. Do a check to confirm the firmware version of the board is the latest one (see http://tipok.org.ua/node/46 for information on the latest version and to check for any changes since this document was last updated).<br />
<br />
The first part of the control page is about the Network Settings. You can set<br />
<br />
IP address : put here the fixed address that you want to use to access the board's web interface in the future;<br />
netmask : typically 255.255.255.0 for a LAN;<br />
gateway : the IP address of the device through which other addresses outside the LAN can be reached;<br />
MAC address : unless you have a special reason to change this, just leave as is;<br />
Connection mode : for this example we use TCP-Client. The board will request a connection to the DabMux program;<br />
Remote IP : the IP address of the Raspberry Pi on which you operate the DabMux program. This can be on the same LAN or on another address, even over the Internet;<br />
Remote port : the port number that you have selected in the mux configuration file for the ZeroMQ handshake.<br />
<br />
For this project we enable the ZeroMQ Client Handshake and select no delayed TCP ACK.<br />
<br />
The next part of the interface page determines the output of the RF frontend.<br />
<br />
The first setting is the amplitude, that can be set in 256 steps. For the best output do not put this too high, as we should ensure the signal is clean and as close as possible within the limits of the spectrum mask in the DAB specification. Next you can set the frequency. Do this according to the list of DAB channels. The next three settings will be discussed as a later moment. For now, we leave these as is. And finally in this part the status of the output is shown: active or not.<br />
<br />
In the processing part most settings are to enable Single Frequency Network mode when 2 or more transmitter need to be synchronized to a GPS clock. The only setting we need to care about for now is the setting whether or not the board is equipped with additional buffer RAM. If it is, do enable these so more buffer capacity is available. The processing part also has some information on the state of the buffer and some flags about the processing.<br />
<br />
The user name and password to access the webinterface can be set in the Authentication part. If you want to access the board over the Internet you better select something else than 'admin' and 'admin'.<br />
<br />
Once you have set everything to your liking, click on 'apply config', which will load these settings. But in order to activate them you will need to restart the board as well.<br />
<br />
The restart will also change its IP address to the one you selected. Make sure the network address you selected for the Raspberry Pi can be reached from the EasyDab board, over a LAN connection or even through the Internet. If you have the ODR-DabMux and ODR-AudioEnc active on the Raspberry Pi the EasyDab should be able to reach it and after about 10 to 20 seconds start to transmit on the DAB channel you set. Your DAB ensemble is on air !<br />
<br />
Now, if you want to add Program Associated Data, let's see how to use ODR-PadEnc.</div>Andimikhttps://wiki.opendigitalradio.org/Ideas_for_projectsIdeas for projects2020-04-16T11:06:25Z<p>Andimik: typos fixed</p>
<hr />
<div>==Ideas for potential future projects==<br />
<br />
This is a small collection of ideas for developments or research that serves as a reminder, a starting point, and an incentive (e.g. for students).<br />
<br />
These projects are part of the more long-term view of the tools, they are not planned yet. If you would be interested in working on such a project,<br />
or if you have other ideas, please get in touch with us using the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
<br />
===ODR-DabMod on FPGA===<br />
Summary:<br />
It is a challenging, and therefore interesting idea in its own respect, to get ODR-DabMod to run on an FPGA platform.<br />
Some parts would run on a processor, other parts would be accelerated in custom logic.<br />
This would make it possible to use the USRP embedded devices as standalone DAB exciters.<br />
The USRP E300 looks promising (Xilinx Zynq).<br />
<br />
Keywords: ODR-DabMod, FPGA, signal processing, USRP embedded series, USRP E300, Verilog/VHDL, C++<br />
<br />
Proposed by: mpb [[User:hb9egm]]<br />
<br />
Date: at RadioHack 2013 (Feb 2013)<br />
<br />
Remarks: piratfm is doing something in that direction<br />
<br />
<br />
===Digital Predistortion===<br />
Summary:<br />
Power amplifiers are not entirely linear.<br />
The first step is to look into the possibilities and constraints given by the usual PC (dabmod) + USRP scenario for static predistortion.<br />
Then, research has to be done about the possibilities to do dynamic predistortion.<br />
<br />
Keywords: ODR-DabMod, modulation, signal processing, C++<br />
<br />
Proposed by: MC [[User:coinchon]], mpb [[User:hb9egm]]<br />
<br />
Date: July 2014<br />
<br />
Remarks:<br />
<br />
<br />
===Dynamic Multiplex Reconfiguration===<br />
Summary:<br />
The title says it all. Add support for this feature. This will probably require a substantial amount of refactoring of ODR-DabMux, and therefore<br />
give the opportunity to make other things better. Requires a good understanding of the DAB standard and the ODR-DabMux implementation.<br />
<br />
Keywords: ODR-DabMux, DAB standard, C++<br />
<br />
Proposed by: mpb [[User:hb9egm]]<br />
<br />
Date: July 2014<br />
<br />
Remarks:<br />
<br />
<br />
===Web-based GUI===<br />
Summary:<br />
To setup a transmission chain composed of programmes from mmbTools requires writing of several configuration files by hand, and some juggling with the right scripts.<br />
A web-based GUI could simplify the setup greatly.<br />
<br />
Keywords: GUI, web-based administration<br />
<br />
Proposed by: Sergio Sagliocco from CSP.it<br />
<br />
Date: June 2014<br />
<br />
Remarks: Sergio is working on something here<br />
<br />
<br />
===(template for new ideas, please copy-paste)===<br />
Summary:<br />
Describe the idea briefly<br />
<br />
Keywords: list of keywords (e.g. modulation, signal processing, monitoring)<br />
<br />
Proposed by:<br />
<br />
Date:<br />
<br />
Remarks:</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T11:02:26Z<p>Andimik: /* Request DLS text file re-read */ Grammar fixed</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while choosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore, it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set independent of each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitly signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore, the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However, a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the broadcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However, in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore, since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T11:02:02Z<p>Andimik: /* Request slides dir re-read */ Grammar fixed</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while choosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore, it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set independent of each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitly signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore, the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However, a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the broadcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However, in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T11:01:19Z<p>Andimik: /* Usage of DL Plus */ Typos and Grammar fixed</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while choosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore, it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set independent of each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitly signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore, the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However, a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the broadcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T11:00:15Z<p>Andimik: /* Service signalling */ Typo fixed</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while choosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore, it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set independent of each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitly signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the brodcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T10:59:52Z<p>Andimik: /* PAD generation modes */ Grammar fix</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while choosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore, it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set independent of each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitely signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the brodcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T10:58:51Z<p>Andimik: /* PAD lengths */ Grammar fix</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while choosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set indepentent from each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitely signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the brodcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-04-16T10:57:12Z<p>Andimik: /* Dynamic Label Segment (DLS) */ Grammar fixed</p>
<hr />
<div>The '''ODR-PadEnc''' encodes ''Program Associated Data (PAD)'' which gets embedded into MP2/AAC audio frames. It supports the transmission of DLS texts and MOT Slideshow slides. Initially called mot-encoder, the tool was contributed by CSP [http://rd.csp.it]; further improvements were made by the OpenDigitalradio team, and it has been renamed to ODR-PadEnc.<br />
<br />
It can be used with [[ODR-AudioEnc]] and with the legacy tools [[Toolame-DAB]] and [[FDK-AAC-DABplus]].<br />
<br />
== Installation ==<br />
<br />
Get the sources from the repository https://github.com/Opendigitalradio/ODR-PadEnc<br />
<br />
./bootstrap<br />
./configure<br />
make<br />
sudo make install<br />
<br />
== Usage ==<br />
Please call odr-padenc without parameters to see all available options.<br />
<br />
The communication between odr-padenc and the audio encoder is done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
Example 1: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6<br />
<br />
Example 2: Transmission of MOT Slideshow using 34 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -d ./slides -p 34<br />
<br />
Example 3: Transmission of DLS texts (file content encoded as UTF-8; after internal conversion, transmit encoded as EBU Complete Latin based repertoire) and MOT Slideshow using 58 bytes PAD:<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58<br />
<br />
Example 3a: Like example 3. However instead of the burst mode the uniform mode is used (due to the 20ms frame length, the related audio here must be AAC-LC with 48 kHz; see the respective row in [[#Using_DLS_and_MOT_SLS_together|this table]]):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -d ./slides -p 58 -f 20<br />
<br />
Example 4: Transmission of DLS texts (file content encoded as UTF-8; transmit without conversion) using 6 bytes PAD (short X-PAD):<br />
odr-padenc -o /tmp/pad.fifo -t dls.txt -p 6 -C<br />
<br />
If you do offline encoding of a DAB programme, it makes sense to use <code>-s 0</code> - otherwise odr-padenc waits (by default) 10 realtime seconds before transmitting the next DL or slide.<br />
<br />
== Supported services ==<br />
<br />
=== Dynamic Label Segment (DLS) ===<br />
DLS texts (according to ETSI EN 300 401, ch. 7.4.5.2) can be embedded into PAD and are read from a specific file. This file is read everytime before the text is prepared for transmission, therefore it can be replaced in the meantime to change the transmitted text.<br />
The specification limits the size of a DLS text to at most 128 bytes - depending on the selected charset this byte amount can be used to transmit up to 128 characters.<br />
<br />
Dynamic Label Plus (also called DL Plus; according to ETSI TS 102 980) allows annotating parts of a DLS text with certain tags and is supported since commit c1599cb. To enable DL Plus, the DLS text within DLS text file must be prepended by a parameter block which contains the desired settings (see below).<br />
<br />
==== Using multiple DLS texts ====<br />
Instead of using only one file, multiple files can be used as well (e.g. to regularly switch between artist/title and the station claim). After the specified sleep delay is over, the DLS transmission switches to the next file. To use this feature, the respective commandline option has to be specified once for every file.<br />
<br />
=== MOT Slideshow (MOT SLS) ===<br />
The MOT Slideshow (according to ETSI EN 301 234 and ETSI TS 101 499) allows the transmission of slides in JPEG or PNG format. The images in a specified folder are therefore transmitted one after another, until all images have been processed and the procedure repeats. If one image does not fulfill the 50 KB file size limit, has progressive coding or is larger than the recommendation of a 320x240 px resolution, it is shrinked (while keeping the aspect ratio) before transmission and converted to JPEG (since commit 5f2817a: to JPEG or PNG, whichever is smaller) to fulfill the mentioned requirements.<br />
<br />
Optionally a slide can be accompanied by further parameters (e.g. to use a categorized Slideshow) since commit be6d1b7. This parameters reside in a separate file suffixed with <code>.sls_params</code> (case-sensitive). So when the image filename is <code>test.jpg</code>, the corresponding parameters file has to be named <code>test.jpg.sls_params</code>. Currently the following parameters can be used (see below):<br />
* CategoryID/SlideID<br />
* CategoryTitle<br />
* ClickThroughURL<br />
* AlternativeLocationURL<br />
<br />
==== Using DLS and MOT SLS together ====<br />
<br />
When both DLS and SLS are used and currently a slide is transmitted, since commit 222e277 every 50 PADs the DLS is inserted ('''Note:''' As the PAD generation/output currently happens as a burst, the DLS text will not be updated between two adjacent slides!). This way a listener will get DLS much earlier after switching to a service, compared to the previous situation where the slide transmission was not interrupted for DLS insertion. Depending on the used audio encoding, DLS is inserted in the following intervals:<br />
<br />
{| class="wikitable"<br />
! System<br />
! Codec<br />
! Sample rate [kHz]<br />
! Frame/AU length [ms]<br />
! AUs per Superframe<br />
! Interval [ms]<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2<br />
| 48<br />
| 24<br />
| N/A<br />
| 1200<br />
|- style="background:#EEE0E0"<br />
| '''DAB'''<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| N/A<br />
| 2400<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 48<br />
| 20<br />
| 6<br />
| 1000<br />
|-<br />
| '''DAB+'''<br />
| AAC-LC (= AAC without SBR)<br />
| 32<br />
| 30<br />
| 4<br />
| 1500<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 48<br />
| 40<br />
| 3<br />
| 2000<br />
|-<br />
| '''DAB+'''<br />
| HE-AAC (= AAC with SBR)<br />
| 32<br />
| 60<br />
| 2<br />
| 3000<br />
|}<br />
<br />
Note that regarding this table and (HE-)AAC, it doesn't matter whether PS (Parametric Stereo) is used or not. Note also that the product of the AU length and the AUs per Superframe always results in 120ms.<br />
<br />
== PAD lengths ==<br />
Since commit ae63fc5, the PAD length can be set to a value between 8 and 196 bytes per frame (using Variable Size X-PAD). In addition, 6 bytes per frame (using Short X-PAD) can be used. The PAD length must be set to the same value both at odr-padenc and audio encoder command line.<br />
In the future the PAD length will have to be set at a single location only.<br />
<br />
Note: The audio encoders do not check if a chosen PAD length leaves enough remaining space for the audio itself. So this must be considered while chosing the PAD length.<br />
<br />
== PAD generation modes ==<br />
ODR-PadEnc supports two PAD generation modes. From the beginning the ''burst'' mode has been supported, but it has certain disadvantages. Since version 2.3.0 the ''uniform'' mode is available and the recommended mode.<br />
<br />
Note: In the figures below, PAD is shown in green, audio frames in blue and overflows in red.<br />
<br />
=== Burst mode ===<br />
The burst mode pre-generates and outputs all PAD (one slide and intermittent DLS texts, or one DLS text) at once. After that, the encoder sleeps for the specified amount of time, the sleep time (e.g. 10 seconds). So the generated output looks like the following:<br />
<br />
[[Image:PAD generation - burst mode.svg|400px]]<br />
<br />
The sleep time has to be long enough so that the audio encoder can process all PADs before the next PAD generation burst takes place - however this way the available PAD bandwidth is not completely used (and instead given back to the audio encoder):<br />
<br />
[[Image:PAD mapping - burst mode.svg|400px]]<br />
<br />
If the sleep time is too short, the audio encoder has not yet processed all PADs until the next PAD generation burst. Thus updated slides/DLS texts are delayed and sometime the PAD queue will overflow:<br />
<br />
[[Image:PAD mapping - burst mode - overflow.svg|400px]]<br />
<br />
So by definition, the burst mode cannot completely utilize the available PAD bandwidth. Furthermore it is not possible to update the DLS text between two PAD generation bursts, as the respective PADs have already been generated - but an update may be desired e.g. on a new song. Since the introduction of the uniform mode, there is no longer a reason to use the burst mode.<br />
<br />
=== Uniform mode (recommended) ===<br />
In the uniform mode the actual audio frame length defines the gap between two adjacent PADs:<br />
<br />
[[Image:PAD generation - uniform mode.svg|400px]]<br />
<br />
This way there is no unused PAD bandwidth and the PAD generation also cannot overflow:<br />
<br />
[[Image:PAD mapping - uniform mode.svg|400px]]<br />
<br />
The uniform mode just requires to specify the audio frame length which can be read from the above table.<br />
<br />
Insertion intervals for slides and labels can be set indepentent from each other. It is also possible to specify how often the label is inserted.<br />
<br />
If the slides interval "0" is used, the next slide is inserted just after the previous one has been transmitted. This is useful e.g. for stations that transmit just a logo slide.<br />
<br />
An initial burst count can be set to ensure that an audio encoder has enough PADs available e.g. in case the audio encoder encodes DAB+ Superframes at once and hence needs all related PADs.<br />
<br />
If a slide/label is still in transmission when the transmission of the next one is scheduled, the new transmission is skipped and a warning is shown. In this case it makes sense to increase the PAD length or to instead decrease the slide size or label insertion interval (<code>-L</code>).<br />
<br />
This new PAD encoder does not require any changes on the audio encoder side. Only in case of MP2, a recent revision of ODR-AudioEnc has to be used (commit ce25f2c or later), as it fixes a problem with PADs that solely consist of the F-PAD.<br />
<br />
== Service signalling ==<br />
DLS does not need any explicit signalling.<br />
<br />
MOT SLS must be explicitely signalled within the FIC by using the FIG 0/13 (''User application information''). In [[ODR-DabMux]], since v0.7.3 the parameter ''figtype'' within the mux file is used for this - please take a look at the example mux file. Note: Some receivers will display a transmitted MOT SLS even without explicit signalling.<br />
<br />
== Communication with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the brodcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Andimikhttps://wiki.opendigitalradio.org/ODR-AudioEncODR-AudioEnc2020-04-16T10:54:01Z<p>Andimik: typos fixed</p>
<hr />
<div>'''ODR-AudioEnc''' is a DAB and a DAB+ encoder, replacing [[Toolame-DAB]] and [[FDK-AAC-DABplus]] respectively.<br />
<br />
The DAB encoder is derived from libtoolame-dab. toolame-02l has been converted to a shared library libtoolame-dab.<br />
<br />
The DAB+ encoder is using the fdk-aac library the Fraunhofer FDK AAC code from Android, patched for 960-transform and proper header and firecode.<br />
<br />
The main tool is '''odr-audioenc''', which can encode from a file or pipe source, all inputs supported by libVLC or an ALSA soundcard, and encode to a ZeroMQ output compatible with [[ODR-DabMux]], to a file or to standard output. The VLC ALSA input supports experimental '''sound card clock drift compensation''', that can compensate for imprecise sound card clocks.<br />
<br />
'''DAB MOT Slideshow and DLS''' support is possible thanks to [[ODR-PadEnc]]<br />
<br />
For detailed usage, see the usage screen of the different tools.<br />
<br />
<br />
Its development is public : http://github.com/Opendigitalradio/ODR-AudioEnc and releases are available as git tags. The git master branch always points to the latest release, the next branch is where development happens. <br />
<br />
== Installation ==<br />
===Prerequisites===<br />
<br />
The ODR-AudioEnc package depends on libfec, boost-thread, boost-system, alsa and ZeroMQ.<br />
For instructions on how to install these, please see [[ODR-DabMux#Prerequisites]]<br />
<br />
The [[mot-encoder]] optionally needs ImageMagick's magick_wand to be able to resize pictures.<br />
<br />
===Building===<br />
<br />
See https://github.com/Opendigitalradio/ODR-AudioEnc#how-to-build<br />
<br />
==Usage==<br />
<br />
Several usage scenarios are shown in<br />
https://github.com/Opendigitalradio/ODR-AudioEnc#how-to-use<br />
<br />
===Problem solving===<br />
<br />
In the case you are using '''ZeroMQ between the encoder and odr-dabmux''', and you see errors that the size of the data is wrong, then the configured bitrate in the mux probably doesn't correspond to the bitrate given to the encoder. Make sure they are identical.<br />
<br />
If you are using a '''pipe between the encoder and odr-dabmux''', and you see a lot of errors like this:<br />
<2> ERROR: Incomplete DAB+ frame! 136 != 360<br />
<5> reach end of file -> rewinding<br />
<2> ERROR: Can't rewind file<br />
<6> ETI frame number: 228<br />
<br />
Then the stream has to be buffered before giving it to muxer, this additional buffer installed between encoder and fifo. To calculate proper block size for mbuffer ("-s" parameter), the table below may be used:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
!DAB+ Stream bitrate, kbps<br />
!Block size, bytes<br />
|-<br />
|16<br />
|240<br />
|-<br />
|24<br />
|360<br />
|-<br />
|32<br />
|480<br />
|-<br />
|48<br />
|720<br />
|-<br />
|56<br />
|840<br />
|-<br />
|64<br />
|960<br />
|-<br />
|72<br />
|1080<br />
|-<br />
|128<br />
|1920<br />
|-<br />
|160<br />
|2400 <br />
|}<br />
<br />
In example above, for stream with bitrate 24 kbps, mbuffer size set to 360 bytes. This trick helping to solve problem.<br />
<br />
==Historical notes==<br />
<br />
The encoders were renamed at version 0.2.0. The aac-enc testing program disappeared, but its code is still in src/.<br />
The aac-enc-dabplus and aac-enc-dabplus-zmq were renamed to dabplus-enc-file and dabplus-enc-file-zmq. dabplus-enc-alsa-zmq appeared in v0.2.0.<br />
<br />
In v0.2.2, dabplus-enc-file-zmq received support for output to file and pipe, making dabplus-enc-file obsolete, which has therefore been removed.<br />
<br />
In v0.4.0, lots of code redundancy between different encoder variants has been merged into '''dabplus-enc'''. The old tools '''dabplus-enc-file-zmq''', '''dabplus-enc-alsa-zmq''' and all this has been replaced by a single encoder.<br />
<br />
Some of the ''encode-'' scripts available in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux repository] might still make use of the old names.<br />
<br />
In September 2016, FDK-AAC-DABplus was split in three: ODR-AudioEnc, fdk-aac and ODR-PadEnc, for ease of maintainability and packaging, to clarify the licence situation a bit, and in the hope that the DAB+ modification to fdk-aac could be given upstream.</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2020-04-16T10:48:11Z<p>Andimik: /* ETI conversion to http */ ni2http was renamed to ni2out</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised (see ETSI: EN 300 799) output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2 Mbit/s synchronous stream. The Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
WorldDAB developed an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface), which is specified in ETSI: TS 102 693.<br />
<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be encapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex encapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by encapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
A list of (known) DAB streams over satellite can be found at https://github.com/piratfm/eti-tools#satellite-dab-feeds . All of them are not encrypted.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2out application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developed by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.<br />
* [https://github.com/Opendigitalradio/etisnoop etisnoop]: The ETISnoop analyser decodes a RAW ETI file and prints out its contents in YAML for easier analysis.<br />
* [https://github.com/Opendigitalradio/dablin dablin]: Plays eti files from file or stdin, the GTK GUI version supports Dynamic Label and MOT Slideshow (if applicable).<br />
* [https://github.com/JvanKatwijk/eti-stuff eti-stuff]: A collection of programmes to generate ETI files from various hardware like RTLSDR sticks, Airspy, etc.<br />
* [https://github.com/Opendigitalradio/dabtools dabtools (forked)]: dab2eti receives a DAB ensemble and outputs an ETI stream to stdout, unfortunately only for RTLSDR sticks</div>Andimikhttps://wiki.opendigitalradio.org/EtisnoopEtisnoop2020-04-16T10:42:50Z<p>Andimik: /* Usage */ missing -e added</p>
<hr />
<div>==ETISnoop==<br />
<br />
ETISnoop is a small tool developed by CSP.it and Opendigitalradio that can '''decode some FIC information''' from a ETI file, '''extract the AAC data''' from a subchannel and '''decode it to a wav''' file. <br />
<br />
It is on Github: https://github.com/Opendigitalradio/etisnoop<br />
<br />
===Compilation===<br />
<br />
It requires libfaad2 and a C++ compiler with complete C++11 support.<br />
<br />
To compile etisnoop:<br />
<br />
git clone https://github.com/Opendigitalradio/etisnoop.git<br />
cd etisnoop<br />
./bootstrap.sh # Only needed if you do not have a release containing a ./configure script<br />
./configure<br />
make<br />
sudo make install<br />
<br />
===Usage===<br />
<br />
The tool can show ETI information, decode the FIG carousel and extract a DAB+ stream<br />
<br />
Usage: etisnoop [options] [(-i|-I) filename]<br />
<br />
-i the file contains RAW ETI<br />
-I the file contains FIC<br />
-v increase verbosity (can be given more than once)<br />
-d N decode subchannel N into .msc file and if DAB+, decode to .wav file<br />
-s <filename.yaml><br />
statistics mode: decode all subchannels and measure audio level, write statistics to file<br />
-n N stop analysing after N ETI frames<br />
-f analyse FIC carousel (no YAML output)<br />
-r analyse FIG rates in FIGs per second<br />
-R analyse FIG rates in frames per FIG<br />
-w decode CRC-DABMUX and ODR-DabMux watermark.<br />
-e decode frames with SYNC error and decode FIGs with invalid CRC<br />
-F <type>/<ext><br />
add FIG type/ext to list of FIGs to display.<br />
if the option is not given, all FIGs are displayed.<br />
<br />
<br />
<br />
<br />
Example:<br />
<br />
% ./etisnoop -i ../eti/funk.raw.eti -v | head -n50<br />
SYNC: ff 07 3a b6 <br />
ERR: ff [No error] <br />
Sync FSYNC: 07 3a b6 [OK] <br />
LDATA<br />
FC - Frame Characterization field: 00 81 10 7a <br />
FCT - Frame Count: 00 [0] <br />
FICF - Fast Information Channel Flag [1 - FIC Information are present] <br />
NST - Number of streams [1] <br />
FP - Frame Phase: 00 [0] <br />
MID - Mode Identity: 02 [Mode 2] <br />
FL - Frame Length [122 words] <br />
STC - Stream Characterisation<br />
STC - Stream Characterisation: 28 00 48 30 [Stream number 0] <br />
SCID - Sub-channel Identifier [10] <br />
SAD - Sub-channel Start Address [0] <br />
TPL - Sub-channel Type and Protection Level [0x12 - Unequal Error Protection. Table switch 0, UEP index 2] <br />
STL - Sub-channel Stream Length [48 => 128 kbit/s] <br />
EOH - End Of Header: 00 00 16 7c <br />
MNSC - Multiplex Network Signalling Channel: 00 00 <br />
Header CRC: 16 7c [CRC OK] <br />
FIC Data (96 bytes)<br />
FIG 0 [5 bytes]: 00 c0 00 00 00 <br />
FIG 0/0: C/N=0 OE=0 P/D=0: c0 00 00 00 <br />
Ensamble ID=0xc000 (Country id=12, Ensamble reference=0), Change flag=0, Alarm flag=0, CIF Count=0/0<br />
FIB CRC: ea f1 [FIB CRC OK] <br />
FIG 0 [5 bytes]: 08 00 33 00 0a <br />
FIG 0/8: C/N=0 OE=0 P/D=0: 00 33 00 0a <br />
FIB CRC: a2 9f [FIB CRC OK] <br />
FIG 1 [21 bytes]: 01 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
FIG 1/1: OE=0, Charset=0: 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
Service ID 0x0033 label: "Funk", Short label mask: 0xFF00<br />
FIB CRC: 6f b3 [FIB CRC OK] <br />
Stream Data: ff fc 84 00 bc f1 21 22 22 44 44 33 33 22 22 22 22 24 92 40 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 00 00 00 00 00 51 8b 8b 00 00 [0] <br />
EOF: bf 2d ff ff <br />
CRC: bf 2d [CRC OK] <br />
RFU: ff ff <br />
TIST - Time Stamp: ff 40 a0 00 [256 ms] <br />
-------------------------------------------------------------------------------------------------------------<br />
<br />
==Acknowledgements==<br />
Many thanks to the team from CSP.it : http://rd.csp.it</div>Andimikhttps://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2019-04-10T20:19:33Z<p>Andimik: /* Command line arguments */</p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available ad interim on http://mpb.li<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [[http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface]] (ETI) stream as input and outputs a complex baseband stream of interlaced 16 bits I/Q samples with a default sampling frequency of 2.048MHz. It can also directly communicate to the Ettus USRPs using the UHD driver.<br />
<br />
The USRP1 will require resampling to 3.2Msps, which will requires high CPU usage but cannot be avoided. Newer USRPs have a more flexible clocking system.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.54. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd, don't forget to also install the -dev package from your distribution.<br />
<br />
If you want to use the zeromq inputs or outputs, you need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
<br />
Build and install according to the instructions in the README.<br />
<br />
test with:<br />
odr-dabmod -h<br />
<br />
to update to latest upstream:<br />
git pull<br />
<br />
and do the bootstrap configure make again.<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: through command line arguments or with a configuration file:<br />
<br />
===Command line arguments===<br />
<br />
Example with command-line interface:<br />
odr-dabmod ./racor.eti -l -g1 -r3200000<br />
<br />
This modulates the racor.eti file, performs OFDM modulation on baseband at a sampling frequency of 3.2Msamples/sec. Output is sent to the standard output. It can be redirected into a file, or piped into a baseband player ([[CRC-Dwap.py]]).<br />
<br />
When using a USRP, the integrated UHD output can be used. This requires the definition and usage of a configuration file.<br />
<br />
===Configuration file===<br />
<br />
Take the example configuration from GitHub: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini example.ini]<br />
<br />
The '''input''' section defines if you want to read a file or ETI over ZeroMQ. The ZeroMQ must point to a odr-dabmux ZeroMQ output.<br />
The '''modulator''' section sets parameters for the modulator which are described below.<br />
<br />
'''firfilter''' enables the filter that was previously done in the baseband player. It reduces out of band energy, and will increase signal quality, and reduce energy waste in the mask filter. The filter taps can be generated with the helper script in doc/fir-filter<br />
<br />
For each possible output, there is a section: '''outputuhd''' and '''outputfile'''. '''outputfile''' only defines the filename. '''outputuhd''' is more interesting: it defines the device flags, the TX frequency, the PGA gain, and what clocking source you want to use. In case of refclk loss, it is possible to make the modulator crash so as to avoid transmitting a corrupt signal, maybe even on the wrong frequency.<br />
<br />
The parameter<br />
device=master_clock_rate=32768000,type=b100<br />
is valid for USRP B100, and the master_clock_rate allows us to avoid resampling the 2048000sps signal. It is used as UHD device parameter without modification. There are other USRPs supported: See [[DAB hardware]]<br />
<br />
The txgain can be modified while the modulator runs by enabling the '''remotecontrol'''<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
odr-dabmod -C modulator.ini<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for regular USRP1 only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Andimikhttps://wiki.opendigitalradio.org/Introduction_on_DAB/DAB%2BIntroduction on DAB/DAB+2018-07-23T20:35:25Z<p>Andimik: </p>
<hr />
<div>==Introduction==<br />
DAB, DAB+ and T-DMB European digital radio and mobile television standards share the same transmission system. It's based on [http://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing OFDM] modulation and uses 1.5MHz of spectrum in the VHF television band 3 (or L-band in SHF). A transmitter is broadcasting a set of programmes, called a multiplex or ensemble. The system has been designed for mobile use and is robust up to 300km/h.<br />
<br />
With the development of the '''mmbTools''' by [http://mmbtools.crc.ca CRC] and opendigitalradio, it is now possible to run a full transmission infrastructure on a laptop running Linux and using a [http://en.wikipedia.org/wiki/USRP USRP] as [[RF]] hardware (with [[wikipedia:gnuradio|gnuradio]]) or any other similar device.<br />
<br />
The transmission chain can be divided in 4 parts:<br />
*The '''Encoder''' encodes the audio source to [[wikipedia:MPEG-1 Audio Layer II|MPEG-2 Layer II]] for DAB, [[wikipedia:High-Efficiency Advanced Audio Coding|MPEG-4 HE-AACv2]] for DAB+ or video in MPEG-4 H.264 for T-DMB.<br />
*The '''Multiplexer''' gathers different streams, produces necessary signalling and outputs a single 2048kbit/s stream in ETI format ([[Ensemble Transport Interface]]).<br />
*The '''Modulator''' takes the ETI stream and produces a complex I/Q [[wikipedia:baseband|baseband]] OFDM signal ready for up-conversion to the desired radio frequency.<br />
*The '''[[RF]] transmission''' is performed by the [[USRP]], a [[HackRF One]] or a similar device.<br />
<br />
The ODR-Tools comprises two encoders: [[Toolame]] and [[fdk-aac-dabplus]]; it includes a multiplexer [[ODR-DabMux]] and a modulator [[ODR-DabMod]].<br />
<br />
Thanks to the modular approach from these tools it is possible to interface them with other implementations and tools.<br />
<br />
==How to get started==<br />
<br />
===Prerequisites===<br />
<br />
Let's say you want to learn about DAB transmission and set up a laboratory transmitter that you can use to experiment, gain better understanding, test ideas, evaluate receivers or do measurements. <br />
<br />
A will need:<br />
<br />
* Some Linux system knowledge.<br />
* A recent PC running Debian stable: http://debian.org<br />
* A [[USRP]] (B200, B100, USRP2 and USRP1 are tested to work. The others should be fine too, no guarantees.)<br />
* To read documentation: <br />
** Read http://en.wikipedia.org/wiki/Digital_audio_broadcasting.<br />
** Have a look at ETSI EN 300 401 to understand DAB better.<br />
** Maybe also ETSI ETS 300 799 defines the [[ETI]] interface between multiplexer and modulator.<br />
** Read the guide http://mpb.li/pub/mmbtools.pdf which is still a work in progress.<br />
** Read the pages about the ODR-mmbTools listed below.<br />
* To install the required tools on the Debian Linux PC. The [[Installer scripts]] will simplify this a lot.<br />
* Have a look at the example mux and mod configurations in the respective doc/ folders and in mmbtools-aux.<br />
* And of course, a DAB receiver.<br />
<br />
=== Step-by-step ===<br />
<br />
The best way to discover these scripts is to start step-by-step. Once you have installed the tools, work your way up from the encoder to the multiplexer, and finally to the I/Q modulator.<br />
<br />
# Using [[fdk-aac-dabplus]], prepare one or more AAC-encoded .dabp audio files using some .wav files.<br />
# Create a configuration file for [[ODR-DabMux]], using [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini doc/example.mux] as a base. Use the .dabp files as input and limit the duration of the ETI file to a few thousand frames (a couple of minutes worth of data).<br />
# Using [[ODR-DabMux]] with this configuration, create a RAW ETI file containing your multiplex.<br />
# If you want, compile [[etisnoop]] and analyse the ETI file.<br />
# Use [[ODR-DabMod]] to modulate this ETI file and create an I/Q file.<br />
<br />
Once this works, try to get all tools running simultaneously, interconnected using ZeroMQ.<br />
<br />
Good luck, and '''don't transmit''' without a license !<br />
<br />
Other users and developers are reachable on the crc-mmbtools google group:<br />
https://groups.google.com/forum/#!forum/crc-mmbtools</div>Andimikhttps://wiki.opendigitalradio.org/EtisnoopEtisnoop2018-07-23T20:29:18Z<p>Andimik: /* ETISnoop */ Typo</p>
<hr />
<div>==ETISnoop==<br />
<br />
ETISnoop is a small tool developed by CSP.it and Opendigitalradio that can '''decode some FIC information''' from a ETI file, '''extract the AAC data''' from a subchannel and '''decode it to a wav''' file. <br />
<br />
It is on Github: https://github.com/Opendigitalradio/etisnoop<br />
<br />
===Compilation===<br />
<br />
It requires libfaad2 and a C++ compiler with complete C++11 support.<br />
<br />
To compile etisnoop:<br />
<br />
git clone https://github.com/Opendigitalradio/etisnoop.git<br />
cd etisnoop<br />
./bootstrap.sh # Only needed if you do not have a release containing a ./configure script<br />
./configure<br />
make<br />
sudo make install<br />
<br />
===Usage===<br />
<br />
The tool can show ETI information, decode the FIG carousel and extract a DAB+ stream<br />
<br />
Usage: etisnoop [options] [(-i|-I) filename]<br />
<br />
-i the file contains RAW ETI<br />
-I the file contains FIC<br />
-v increase verbosity (can be given more than once)<br />
-d N decode subchannel N into .msc file and if DAB+, decode to .wav file<br />
-s <filename.yaml><br />
statistics mode: decode all subchannels and measure audio level, write statistics to file<br />
-n N stop analysing after N ETI frames<br />
-f analyse FIC carousel (no YAML output)<br />
-r analyse FIG rates in FIGs per second<br />
-R analyse FIG rates in frames per FIG<br />
-w decode CRC-DABMUX and ODR-DabMux watermark.<br />
-F <type>/<ext><br />
add FIG type/ext to list of FIGs to display.<br />
if the option is not given, all FIGs are displayed.<br />
<br />
<br />
<br />
Example:<br />
<br />
% ./etisnoop -i ../eti/funk.raw.eti -v | head -n50<br />
SYNC: ff 07 3a b6 <br />
ERR: ff [No error] <br />
Sync FSYNC: 07 3a b6 [OK] <br />
LDATA<br />
FC - Frame Characterization field: 00 81 10 7a <br />
FCT - Frame Count: 00 [0] <br />
FICF - Fast Information Channel Flag [1 - FIC Information are present] <br />
NST - Number of streams [1] <br />
FP - Frame Phase: 00 [0] <br />
MID - Mode Identity: 02 [Mode 2] <br />
FL - Frame Length [122 words] <br />
STC - Stream Characterisation<br />
STC - Stream Characterisation: 28 00 48 30 [Stream number 0] <br />
SCID - Sub-channel Identifier [10] <br />
SAD - Sub-channel Start Address [0] <br />
TPL - Sub-channel Type and Protection Level [0x12 - Unequal Error Protection. Table switch 0, UEP index 2] <br />
STL - Sub-channel Stream Length [48 => 128 kbit/s] <br />
EOH - End Of Header: 00 00 16 7c <br />
MNSC - Multiplex Network Signalling Channel: 00 00 <br />
Header CRC: 16 7c [CRC OK] <br />
FIC Data (96 bytes)<br />
FIG 0 [5 bytes]: 00 c0 00 00 00 <br />
FIG 0/0: C/N=0 OE=0 P/D=0: c0 00 00 00 <br />
Ensamble ID=0xc000 (Country id=12, Ensamble reference=0), Change flag=0, Alarm flag=0, CIF Count=0/0<br />
FIB CRC: ea f1 [FIB CRC OK] <br />
FIG 0 [5 bytes]: 08 00 33 00 0a <br />
FIG 0/8: C/N=0 OE=0 P/D=0: 00 33 00 0a <br />
FIB CRC: a2 9f [FIB CRC OK] <br />
FIG 1 [21 bytes]: 01 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
FIG 1/1: OE=0, Charset=0: 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
Service ID 0x0033 label: "Funk", Short label mask: 0xFF00<br />
FIB CRC: 6f b3 [FIB CRC OK] <br />
Stream Data: ff fc 84 00 bc f1 21 22 22 44 44 33 33 22 22 22 22 24 92 40 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 00 00 00 00 00 51 8b 8b 00 00 [0] <br />
EOF: bf 2d ff ff <br />
CRC: bf 2d [CRC OK] <br />
RFU: ff ff <br />
TIST - Time Stamp: ff 40 a0 00 [256 ms] <br />
-------------------------------------------------------------------------------------------------------------<br />
<br />
==Acknowledgements==<br />
Many thanks to the team from CSP.it : http://rd.csp.it</div>Andimikhttps://wiki.opendigitalradio.org/DAB_receptionDAB reception2018-07-23T20:25:30Z<p>Andimik: /* Software Defined DAB Receiver (complete software receiver) */ Changed qt-dab and welle.io link and text</p>
<hr />
<div>__NOTOC__<br />
<br />
This side informs you about a concept of a open source DAB receiver.<br />
<br />
==Existing open DAB/DAB+/T-DMB software receiver==<br />
[[Image:Phon3b small.jpg|100px|right]]<br />
<br />
===Software Defined DAB Receiver (complete software receiver)===<br />
*[https://github.com/JvanKatwijk/qt-dab Qt-DAB] (running on Linux, MacOS and Windows, using RTL2832 based USB dongles, Airspy, SDRplay, HackRF, file input)<br />
*[http://www.welle.io welle.io] (running on Linux, MacOS, Android and Windows, using RTL2832 based USB dongles, file input and Airspy dongles)<br />
*[http://www.zsn.zhaw.ch/de/engineering/zsn/projekte/gnu-radio.html DAB receiver for gnuradio] (by Zurich School of Engineering, documentation in German)<br />
<br />
===Software defined DAB receiver (up to logical layer)===<br />
*[[Gnuradio DAB constellation using gr-dab and USRP]]<br />
*[https://github.com/andrmuel/gr-dab Gnuradio blocks for DAB reception] (developments from Andreas Mueller, ETHZ)<br />
**[http://www.0x7.ch/text/dab-report.pdf Documentation] any other information on http://www.0x7.ch/text/#index3h2<br />
*[https://www.cgran.org/browser/projects/dabp/trunk Under construction gnuradio project on DAB+ reception on CGRAN]<br />
<br />
===Software defined DAB receiver (from logical layer up to application layer)===<br />
====Openmokast====<br />
<br />
Open Receiver project from CRC using RDI streams from DAB baseband receivers/decoders.<br />
*http://www.openmokast.org<br />
<br />
Receiver for the Psion Wavefinder<br />
*[http://sourceforge.net/projects/opendab/ OpenDAB]<br />
<br />
<br />
<br />
==Open source DAB receiver (concept)==<br />
===Goal===<br />
To develop libraries to cover all parts of a full DAB and DAB+ SDR receiver.<br />
*Well defined library APIs<br />
*Easy to use APIs<br />
*Cross platform support (x86, arm, Linux, Windows, etc.)<br />
<br />
<br />
===Requirements===<br />
*Based on the SDR-J code<br />
*Use of C++11 to use the threading feature<br />
*Multicore support<br />
*cmake as build environment<br />
<br />
<br />
===Architecture===<br />
[[File:DAB_Receiver_Concept.png|800px]]<br />
{| class="wikitable"<br />
|-<br />
! Library Name<br />
! Purpose<br />
|-<br />
| [[libsdrsource]]<br />
|<br />
Interface to different SDR devices<br />
|-<br />
| [[libdabdemod]]<br />
|<br />
*OFDM demodulation<br />
*Frequency synchronization<br />
*Time synchronization<br />
*Output of the digital DAB stream<br />
|-<br />
|libdabdecode<br />
|<br />
*DAB and DAB+ frame decoding (FIC, Superframes etc.)<br />
*CRC correction<br />
*Output of MPEG or ACC stream<br />
|-<br />
| End user program<br />
|<br />
*Place holder for GUIs<br />
*There can be a QT GUI, a GTK GUI or a Kodi plugin<br />
|}<br />
<br />
===API description===<br />
*TBD <br />
<br />
<br />
===To be discussed===<br />
*Naming of libraries<br />
*APIs<br />
<br />
<br />
===GUI Wishlist===<br />
*Easy to use<br />
*Channel scan<br />
*High DPI support<br />
*libnotify support</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T20:18:03Z<p>Andimik: WorldDMB -> WorldDAB, incapsulation -> encapsulation</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised (see ETSI: EN 300 799) output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2 Mbit/s synchronous stream. The Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
WorldDAB developed an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface), which is specified in ETSI: TS 102 693.<br />
<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be encapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex encapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by encapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
A list of (known) DAB streams over satellite can be found at https://github.com/piratfm/eti-tools#satellite-dab-feeds . All of them are not encrypted.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developed by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.<br />
* [https://github.com/Opendigitalradio/etisnoop etisnoop]: The ETISnoop analyser decodes a RAW ETI file and prints out its contents in YAML for easier analysis.<br />
* [https://github.com/Opendigitalradio/dablin dablin]: Plays eti files from file or stdin, the GTK GUI version supports Dynamic Label and MOT Slideshow (if applicable).<br />
* [https://github.com/JvanKatwijk/eti-stuff eti-stuff]: A collection of programmes to generate ETI files from various hardware like RTLSDR sticks, Airspy, etc.<br />
* [https://github.com/Opendigitalradio/dabtools dabtools (forked)]: dab2eti receives a DAB ensemble and outputs an ETI stream to stdout, unfortunately only for RTLSDR sticks</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T20:13:08Z<p>Andimik: /* Tools */ Grammar</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
A list of (known) DAB streams over satellite can be found at https://github.com/piratfm/eti-tools#satellite-dab-feeds . All of them are not encrypted.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developed by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.<br />
* [https://github.com/Opendigitalradio/etisnoop etisnoop]: The ETISnoop analyser decodes a RAW ETI file and prints out its contents in YAML for easier analysis.<br />
* [https://github.com/Opendigitalradio/dablin dablin]: Plays eti files from file or stdin, the GTK GUI version supports Dynamic Label and MOT Slideshow (if applicable).<br />
* [https://github.com/JvanKatwijk/eti-stuff eti-stuff]: A collection of programmes to generate ETI files from various hardware like RTLSDR sticks, Airspy, etc.<br />
* [https://github.com/Opendigitalradio/dabtools dabtools (forked)]: dab2eti receives a DAB ensemble and outputs an ETI stream to stdout, unfortunately only for RTLSDR sticks</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T20:12:36Z<p>Andimik: /* Tools */ added etisnoop, dablin, dabtools and eti-stuff</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
A list of (known) DAB streams over satellite can be found at https://github.com/piratfm/eti-tools#satellite-dab-feeds . All of them are not encrypted.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developed by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.<br />
* [https://github.com/Opendigitalradio/etisnoop etisnoop]: The ETISnoop analyser decodes a RAW ETI file and prints out its contents in YAML for easier analysis.<br />
* [https://github.com/Opendigitalradio/dablin dablin]: Plays eti files from file or stdin, the GTK GUI version supports Dynamic Label and MOT Slideshow (if applicable).<br />
* [https://github.com/JvanKatwijk/eti-stuff eti-stuff]: A collection of programmes to generate ETI files from various hardware like RTLSDR sticks, Airspy, etc.<br />
* [https://github.com/Opendigitalradio/dabtools dabtools (forked)]: dab2eti receives a DAB ensemble and output an ETI stream to stdout, unfortunately only for RTLSDR sticks</div>Andimikhttps://wiki.opendigitalradio.org/Introduction_on_DAB/DAB%2BIntroduction on DAB/DAB+2018-07-23T19:57:34Z<p>Andimik: /* Step-by-step */ Wrong link</p>
<hr />
<div>==Introduction==<br />
DAB, DAB+ and T-DMB European digital radio and mobile television standards share the same transmission system. It's based on [http://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing OFDM] modulation and uses 1.5MHz of spectrum in the VHF television band 3 (or L-band in SHF). A transmitter is broadcasting a set of programmes, called a multiplex or ensemble. The system has been designed for mobile use and is robust up to 300km/h.<br />
<br />
With the development of the '''mmbTools''' by [http://mmbtools.crc.ca CRC] and opendigitalradio, it is now possible to run a full transmission infrastructure on a laptop running linux and using a [http://en.wikipedia.org/wiki/USRP USRP] as [[RF]] hardware (with [[wikipedia:gnuradio|gnuradio]]) or any other similar device.<br />
<br />
The transmission chain can be divided in 4 parts:<br />
*The '''Encoder''' encodes the audio source to [[wikipedia:MPEG-1 Audio Layer II|MPEG-2 Layer II]] for DAB, [[wikipedia:High-Efficiency Advanced Audio Coding|MPEG-4 HE-AACv2]] for DAB+ or video in MPEG-4 H.264 for T-DMB.<br />
*The '''Multiplexer''' gathers different streams, produces necessary signalling and outputs a single 2048kbit/s stream in ETI format ([[Ensemble Transport Interface]]).<br />
*The '''Modulator''' takes the ETI stream and produce a complex I/Q [[wikipedia:baseband|baseband]] OFDM signal ready for upconversion to the desired radio frequency.<br />
*The '''[[RF]] transmission''' is performed by the [[USRP]] or a similar device.<br />
<br />
The mmbTools comprises two encoders: [[Toolame]] and [[fdk-aac-dabplus]]; it includes a multiplexer [[ODR-DabMux]] and a modulator [[ODR-DabMod]].<br />
<br />
Thanks to the modular approach from these tools it is possible to interface them with other implementations and tools.<br />
<br />
==How to get started==<br />
<br />
===Prerequisites===<br />
<br />
Let's say you want to learn about DAB transmission and set up a laboratory transmitter that you can use to experiment, gain better understanding, test ideas, evaluate receivers or do measurements. <br />
<br />
A will need:<br />
<br />
* Some linux system knowledge.<br />
* A recent PC running Debian stable: http://debian.org<br />
* A [[USRP]] (B200, B100, USRP2 and USRP1 are tested to work. The others should be fine too, no guarantees.)<br />
* To read documentation: <br />
** Read http://en.wikipedia.org/wiki/Digital_audio_broadcasting.<br />
** Have a look at ETSI EN 300 401 to understand DAB better.<br />
** Maybe also ETSI ETS 300 799 defines the [[ETI]] interface between multiplexer and modulator.<br />
** Read the guide http://mpb.li/pub/mmbtools.pdf which is still a work in progress.<br />
** Read the pages about the ODR-mmbTools listed below.<br />
* To install the required tools on the debian PC. The [[Installer scripts]] will simplify this a lot.<br />
* Have a look at the example mux and mod configurations in the respective doc/ folders and in mmbtools-aux.<br />
* And of course, a DAB receiver.<br />
<br />
=== Step-by-step ===<br />
<br />
The best way to discover these scripts is to start step-by-step. Once you have installed the tools, work your way up from the encoder to the multiplexer, and finally to the I/Q modulator.<br />
<br />
# Using [[fdk-aac-dabplus]], prepare one or more AAC-encoded .dabp audio files using some .wav files.<br />
# Create a configuration file for [[ODR-DabMux]], using [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini doc/example.mux] as a base. Use the .dabp files as input and limit the duration of the ETI file to a few thousand frames (a couple of minutes worth of data).<br />
# Using [[ODR-DabMux]] with this configuration, create a RAW ETI file containing your multiplex.<br />
# If you want, compile [[etisnoop]] and analyse the ETI file.<br />
# Use [[ODR-DabMod]] to modulate this ETI file and create an I/Q file.<br />
<br />
Once this works, try to get all tools running simultaneously, interconnected using ZeroMQ.<br />
<br />
Good luck, and '''don't transmit''' without a licence !<br />
<br />
Other users and developers are reachable on the crc-mmbtools google group:<br />
https://groups.google.com/forum/#!forum/crc-mmbtools</div>Andimikhttps://wiki.opendigitalradio.org/Introduction_on_DAB/DAB%2BIntroduction on DAB/DAB+2018-07-23T19:56:41Z<p>Andimik: /* Introduction */ Added the word ensemble and hint for similar devices</p>
<hr />
<div>==Introduction==<br />
DAB, DAB+ and T-DMB European digital radio and mobile television standards share the same transmission system. It's based on [http://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing OFDM] modulation and uses 1.5MHz of spectrum in the VHF television band 3 (or L-band in SHF). A transmitter is broadcasting a set of programmes, called a multiplex or ensemble. The system has been designed for mobile use and is robust up to 300km/h.<br />
<br />
With the development of the '''mmbTools''' by [http://mmbtools.crc.ca CRC] and opendigitalradio, it is now possible to run a full transmission infrastructure on a laptop running linux and using a [http://en.wikipedia.org/wiki/USRP USRP] as [[RF]] hardware (with [[wikipedia:gnuradio|gnuradio]]) or any other similar device.<br />
<br />
The transmission chain can be divided in 4 parts:<br />
*The '''Encoder''' encodes the audio source to [[wikipedia:MPEG-1 Audio Layer II|MPEG-2 Layer II]] for DAB, [[wikipedia:High-Efficiency Advanced Audio Coding|MPEG-4 HE-AACv2]] for DAB+ or video in MPEG-4 H.264 for T-DMB.<br />
*The '''Multiplexer''' gathers different streams, produces necessary signalling and outputs a single 2048kbit/s stream in ETI format ([[Ensemble Transport Interface]]).<br />
*The '''Modulator''' takes the ETI stream and produce a complex I/Q [[wikipedia:baseband|baseband]] OFDM signal ready for upconversion to the desired radio frequency.<br />
*The '''[[RF]] transmission''' is performed by the [[USRP]] or a similar device.<br />
<br />
The mmbTools comprises two encoders: [[Toolame]] and [[fdk-aac-dabplus]]; it includes a multiplexer [[ODR-DabMux]] and a modulator [[ODR-DabMod]].<br />
<br />
Thanks to the modular approach from these tools it is possible to interface them with other implementations and tools.<br />
<br />
==How to get started==<br />
<br />
===Prerequisites===<br />
<br />
Let's say you want to learn about DAB transmission and set up a laboratory transmitter that you can use to experiment, gain better understanding, test ideas, evaluate receivers or do measurements. <br />
<br />
A will need:<br />
<br />
* Some linux system knowledge.<br />
* A recent PC running Debian stable: http://debian.org<br />
* A [[USRP]] (B200, B100, USRP2 and USRP1 are tested to work. The others should be fine too, no guarantees.)<br />
* To read documentation: <br />
** Read http://en.wikipedia.org/wiki/Digital_audio_broadcasting.<br />
** Have a look at ETSI EN 300 401 to understand DAB better.<br />
** Maybe also ETSI ETS 300 799 defines the [[ETI]] interface between multiplexer and modulator.<br />
** Read the guide http://mpb.li/pub/mmbtools.pdf which is still a work in progress.<br />
** Read the pages about the ODR-mmbTools listed below.<br />
* To install the required tools on the debian PC. The [[Installer scripts]] will simplify this a lot.<br />
* Have a look at the example mux and mod configurations in the respective doc/ folders and in mmbtools-aux.<br />
* And of course, a DAB receiver.<br />
<br />
=== Step-by-step ===<br />
<br />
The best way to discover these scripts is to start step-by-step. Once you have installed the tools, work your way up from the encoder to the multiplexer, and finally to the I/Q modulator.<br />
<br />
# Using [[fdk-aac-dabplus]], prepare one or more AAC-encoded .dabp audio files using some .wav files.<br />
# Create a configuration file for [[ODR-DabMux]], using [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini doc/example.mux] as a base. Use the .dabp files as input and limit the duration of the ETI file to a few thousand frames (a couple of minutes worth of data).<br />
# Using [[ODR-DabMux]] with this configuration, create a RAW ETI file containing your multiplex.<br />
# If you want, compile [[ETISnoop]] and analyse the ETI file.<br />
# Use [[ODR-DabMod]] to modulate this ETI file and create an I/Q file.<br />
<br />
Once this works, try to get all tools running simultaneously, interconnected using ZeroMQ.<br />
<br />
Good luck, and '''don't transmit''' without a licence !<br />
<br />
Other users and developers are reachable on the crc-mmbtools google group:<br />
https://groups.google.com/forum/#!forum/crc-mmbtools</div>Andimikhttps://wiki.opendigitalradio.org/EtisnoopEtisnoop2018-07-23T19:54:33Z<p>Andimik: /* Compilation */ There is a make install ...</p>
<hr />
<div>==ETISnoop==<br />
<br />
ETISnoop is a small too developed by CSP.it and Opendigitalradio that can '''decode some FIC information''' from a ETI file, '''extract the AAC data''' from a subchannel and '''decode it to a wav''' file. It is on github: https://github.com/Opendigitalradio/etisnoop<br />
<br />
===Compilation===<br />
<br />
It requires libfaad2 and a C++ compiler with complete C++11 support.<br />
<br />
To compile etisnoop:<br />
<br />
git clone https://github.com/Opendigitalradio/etisnoop.git<br />
cd etisnoop<br />
./bootstrap.sh # Only needed if you do not have a release containing a ./configure script<br />
./configure<br />
make<br />
sudo make install<br />
<br />
===Usage===<br />
<br />
The tool can show ETI information, decode the FIG carousel and extract a DAB+ stream<br />
<br />
Usage: etisnoop [options] [(-i|-I) filename]<br />
<br />
-i the file contains RAW ETI<br />
-I the file contains FIC<br />
-v increase verbosity (can be given more than once)<br />
-d N decode subchannel N into .msc file and if DAB+, decode to .wav file<br />
-s <filename.yaml><br />
statistics mode: decode all subchannels and measure audio level, write statistics to file<br />
-n N stop analysing after N ETI frames<br />
-f analyse FIC carousel (no YAML output)<br />
-r analyse FIG rates in FIGs per second<br />
-R analyse FIG rates in frames per FIG<br />
-w decode CRC-DABMUX and ODR-DabMux watermark.<br />
-F <type>/<ext><br />
add FIG type/ext to list of FIGs to display.<br />
if the option is not given, all FIGs are displayed.<br />
<br />
<br />
<br />
Example:<br />
<br />
% ./etisnoop -i ../eti/funk.raw.eti -v | head -n50<br />
SYNC: ff 07 3a b6 <br />
ERR: ff [No error] <br />
Sync FSYNC: 07 3a b6 [OK] <br />
LDATA<br />
FC - Frame Characterization field: 00 81 10 7a <br />
FCT - Frame Count: 00 [0] <br />
FICF - Fast Information Channel Flag [1 - FIC Information are present] <br />
NST - Number of streams [1] <br />
FP - Frame Phase: 00 [0] <br />
MID - Mode Identity: 02 [Mode 2] <br />
FL - Frame Length [122 words] <br />
STC - Stream Characterisation<br />
STC - Stream Characterisation: 28 00 48 30 [Stream number 0] <br />
SCID - Sub-channel Identifier [10] <br />
SAD - Sub-channel Start Address [0] <br />
TPL - Sub-channel Type and Protection Level [0x12 - Unequal Error Protection. Table switch 0, UEP index 2] <br />
STL - Sub-channel Stream Length [48 => 128 kbit/s] <br />
EOH - End Of Header: 00 00 16 7c <br />
MNSC - Multiplex Network Signalling Channel: 00 00 <br />
Header CRC: 16 7c [CRC OK] <br />
FIC Data (96 bytes)<br />
FIG 0 [5 bytes]: 00 c0 00 00 00 <br />
FIG 0/0: C/N=0 OE=0 P/D=0: c0 00 00 00 <br />
Ensamble ID=0xc000 (Country id=12, Ensamble reference=0), Change flag=0, Alarm flag=0, CIF Count=0/0<br />
FIB CRC: ea f1 [FIB CRC OK] <br />
FIG 0 [5 bytes]: 08 00 33 00 0a <br />
FIG 0/8: C/N=0 OE=0 P/D=0: 00 33 00 0a <br />
FIB CRC: a2 9f [FIB CRC OK] <br />
FIG 1 [21 bytes]: 01 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
FIG 1/1: OE=0, Charset=0: 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
Service ID 0x0033 label: "Funk", Short label mask: 0xFF00<br />
FIB CRC: 6f b3 [FIB CRC OK] <br />
Stream Data: ff fc 84 00 bc f1 21 22 22 44 44 33 33 22 22 22 22 24 92 40 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 00 00 00 00 00 51 8b 8b 00 00 [0] <br />
EOF: bf 2d ff ff <br />
CRC: bf 2d [CRC OK] <br />
RFU: ff ff <br />
TIST - Time Stamp: ff 40 a0 00 [256 ms] <br />
-------------------------------------------------------------------------------------------------------------<br />
<br />
==Acknowledgements==<br />
Many thanks to the team from CSP.it : http://rd.csp.it</div>Andimikhttps://wiki.opendigitalradio.org/EtisnoopEtisnoop2018-07-23T19:50:24Z<p>Andimik: /* Usage */ update of etisnoop help text</p>
<hr />
<div>==ETISnoop==<br />
<br />
ETISnoop is a small too developed by CSP.it and Opendigitalradio that can '''decode some FIC information''' from a ETI file, '''extract the AAC data''' from a subchannel and '''decode it to a wav''' file. It is on github: https://github.com/Opendigitalradio/etisnoop<br />
<br />
===Compilation===<br />
<br />
There is only a very simple makefile, so no ''make install'' and similar. It requires libfaad2.<br />
<br />
To compile etisnoop:<br />
<br />
git clone https://github.com/Opendigitalradio/etisnoop.git<br />
cd etisnoop<br />
make<br />
<br />
===Usage===<br />
<br />
The tool can show ETI information, decode the FIG carousel and extract a DAB+ stream<br />
<br />
Usage: etisnoop [options] [(-i|-I) filename]<br />
<br />
-i the file contains RAW ETI<br />
-I the file contains FIC<br />
-v increase verbosity (can be given more than once)<br />
-d N decode subchannel N into .msc file and if DAB+, decode to .wav file<br />
-s <filename.yaml><br />
statistics mode: decode all subchannels and measure audio level, write statistics to file<br />
-n N stop analysing after N ETI frames<br />
-f analyse FIC carousel (no YAML output)<br />
-r analyse FIG rates in FIGs per second<br />
-R analyse FIG rates in frames per FIG<br />
-w decode CRC-DABMUX and ODR-DabMux watermark.<br />
-F <type>/<ext><br />
add FIG type/ext to list of FIGs to display.<br />
if the option is not given, all FIGs are displayed.<br />
<br />
<br />
<br />
Example:<br />
<br />
% ./etisnoop -i ../eti/funk.raw.eti -v | head -n50<br />
SYNC: ff 07 3a b6 <br />
ERR: ff [No error] <br />
Sync FSYNC: 07 3a b6 [OK] <br />
LDATA<br />
FC - Frame Characterization field: 00 81 10 7a <br />
FCT - Frame Count: 00 [0] <br />
FICF - Fast Information Channel Flag [1 - FIC Information are present] <br />
NST - Number of streams [1] <br />
FP - Frame Phase: 00 [0] <br />
MID - Mode Identity: 02 [Mode 2] <br />
FL - Frame Length [122 words] <br />
STC - Stream Characterisation<br />
STC - Stream Characterisation: 28 00 48 30 [Stream number 0] <br />
SCID - Sub-channel Identifier [10] <br />
SAD - Sub-channel Start Address [0] <br />
TPL - Sub-channel Type and Protection Level [0x12 - Unequal Error Protection. Table switch 0, UEP index 2] <br />
STL - Sub-channel Stream Length [48 => 128 kbit/s] <br />
EOH - End Of Header: 00 00 16 7c <br />
MNSC - Multiplex Network Signalling Channel: 00 00 <br />
Header CRC: 16 7c [CRC OK] <br />
FIC Data (96 bytes)<br />
FIG 0 [5 bytes]: 00 c0 00 00 00 <br />
FIG 0/0: C/N=0 OE=0 P/D=0: c0 00 00 00 <br />
Ensamble ID=0xc000 (Country id=12, Ensamble reference=0), Change flag=0, Alarm flag=0, CIF Count=0/0<br />
FIB CRC: ea f1 [FIB CRC OK] <br />
FIG 0 [5 bytes]: 08 00 33 00 0a <br />
FIG 0/8: C/N=0 OE=0 P/D=0: 00 33 00 0a <br />
FIB CRC: a2 9f [FIB CRC OK] <br />
FIG 1 [21 bytes]: 01 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
FIG 1/1: OE=0, Charset=0: 00 33 46 75 6e 6b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 <br />
Service ID 0x0033 label: "Funk", Short label mask: 0xFF00<br />
FIB CRC: 6f b3 [FIB CRC OK] <br />
Stream Data: ff fc 84 00 bc f1 21 22 22 44 44 33 33 22 22 22 22 24 92 40 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 6d b5 b6 db 6d b6 d6 c5 b1 6c 5b 1b 6d b6 db 6d f3 e7 cf 9f 3e 7c f9 ad 6b 5a d6 db 5b 6d b6 db 6d 6c 5b 16 c5 b1 b6 db 6d b6 df 3e 7c f9 f3 e7 cf 9a d6 b5 ad 00 00 00 00 00 51 8b 8b 00 00 [0] <br />
EOF: bf 2d ff ff <br />
CRC: bf 2d [CRC OK] <br />
RFU: ff ff <br />
TIST - Time Stamp: ff 40 a0 00 [256 ms] <br />
-------------------------------------------------------------------------------------------------------------<br />
<br />
==Acknowledgements==<br />
Many thanks to the team from CSP.it : http://rd.csp.it</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T19:41:37Z<p>Andimik: /* Tools */ Typo</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
A list of (known) DAB streams over satellite can be found at https://github.com/piratfm/eti-tools#satellite-dab-feeds . All of them are not encrypted.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developed by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.</div>Andimikhttps://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2018-07-23T18:42:28Z<p>Andimik: /* Prerequisites */ Boost version minimum according to https://github.com/Opendigitalradio/ODR-DabMod/blob/master/INSTALL</p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available ad interim on http://mpb.li<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [[http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface]] (ETI) stream as input and outputs a complex baseband stream of interlaced 16 bits I/Q samples with a default sampling frequency of 2.048MHz. It can also directly communicate to the Ettus USRPs using the UHD driver.<br />
<br />
The USRP1 will require resampling to 3.2Msps, which will requires high CPU usage but cannot be avoided. Newer USRPs have a more flexible clocking system.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.54. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd, don't forget to also install the -dev package from your distribution.<br />
<br />
If you want to use the zeromq inputs or outputs, you need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
<br />
Build and install according to the instructions in the README.<br />
<br />
test with:<br />
odr-dabmod -h<br />
<br />
to update to latest upstream:<br />
git pull<br />
<br />
and do the bootstrap configure make again.<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: through command line arguments or with a configuration file:<br />
<br />
===Command line arguments===<br />
<br />
Example with command-line interface:<br />
ord-dabmod ./racor.eti -l -g1 -r3200000<br />
<br />
This modulates the racor.eti file, performs OFDM modulation on baseband at a sampling frequency of 3.2Msamples/sec. Output is sent to the standard output. It can be redirected into a file, or piped into a baseband player ([[CRC-Dwap.py]]).<br />
<br />
When using a USRP, the integrated UHD output can be used. This requires the definition and usage of a configuration file.<br />
<br />
===Configuration file===<br />
<br />
Take the example configuration from GitHub: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini example.ini]<br />
<br />
The '''input''' section defines if you want to read a file or ETI over ZeroMQ. The ZeroMQ must point to a odr-dabmux ZeroMQ output.<br />
The '''modulator''' section sets parameters for the modulator which are described below.<br />
<br />
'''firfilter''' enables the filter that was previously done in the baseband player. It reduces out of band energy, and will increase signal quality, and reduce energy waste in the mask filter. The filter taps can be generated with the helper script in doc/fir-filter<br />
<br />
For each possible output, there is a section: '''outputuhd''' and '''outputfile'''. '''outputfile''' only defines the filename. '''outputuhd''' is more interesting: it defines the device flags, the TX frequency, the PGA gain, and what clocking source you want to use. In case of refclk loss, it is possible to make the modulator crash so as to avoid transmitting a corrupt signal, maybe even on the wrong frequency.<br />
<br />
The parameter<br />
device=master_clock_rate=32768000,type=b100<br />
is valid for USRP B100, and the master_clock_rate allows us to avoid resampling the 2048000sps signal. It is used as UHD device parameter without modification. There are other USRPs supported: See [[DAB hardware]]<br />
<br />
The txgain can be modified while the modulator runs by enabling the '''remotecontrol'''<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
odr-dabmod -C modulator.ini<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for regular USRP1 only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Andimikhttps://wiki.opendigitalradio.org/DAB_hardwareDAB hardware2018-07-23T18:39:50Z<p>Andimik: /* HackRF */ added Hack RF basic description</p>
<hr />
<div>==EasyDAB==<br />
<br />
A recent solution to generate a DAB signal has been developed by Sergiy from Kyiv, Ukraine. It is called EasyDAB v2, see http://tipok.org.ua/node/46 . The DAB modulation has been programmed in an FPGA, such that just the multiplexing and audio/PAD encoding needs to be added. A 'cookbook' description of a complete DAB transmission chain based on this board and a Raspberry Pi can be found on the [[RaspDAB]] page. <br />
<br />
==Ettus USRP==<br />
<br />
The Ettus [http://ettus.com] [[USRP]] devices are used to transmit DAB signals generated by [[ODR-DabMod]]. We are mostly using the B200 model.<br />
<br />
There are several devices on the market:<br />
<br />
===USRP B200===<br />
It is the cheapest USRP, and is probably the best choice for both experimentation and transmissions with the ODR-mmbTools. It lacks shielding, but the Hammond enclosure 1455L1601 (Farnell product number 427-2882) fits well. Host connection: USB 2.0 or 3.0. Luckily, the native DAB sample-rate of 2048000 does not require USB 3.0 speeds.<br />
<br />
Be wary about USB 3.0: some host controllers are not very well supported. [http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks Ettus Benchmarks]<br />
<br />
Some [[USRP B200 Measurements]] are available.<br />
<br />
===The original USRP, a.k.a. USRP1===<br />
This is the one that has been used in the beginning, before the UHD driver replaced libusrp, and is still on the market today because it's the only usrp that supports two daughterboards.<br />
While it's been used a lot, it's lack of 1PPS and 10MHz reference clock inputs, and less flexible clock generation requiring resampling on the host makes it less attractive than it's successors. They connect to the host using USB 2.0.<br />
<br />
===USRP2 and USRP N2xx===<br />
The networked series connect to the PC using 1Gbps Ethernet. They can be used successfully with [[ODR-DabMod]] through the UHD driver.<br />
<br />
===USRP B100 (product is end of life)===<br />
The successor of the USRP1. The kit with the WBX daughterboard was a perfect starting point, but it's not available anymore. The B200 is a good replacement.<br />
<br />
<br />
<br />
===USRP E1xx===<br />
Contains an embedded ARM processor that cannot be taken advantage of by the ODR-mmbTools. Call for volunteers: If you want to port [[ODR-DabMod]] to the USRP E100, doing the modulation on the ARM and the FPGA, please get in touch with us !<br />
<br />
==HackRF One==<br />
<br />
The [[HackRF One]] is an SDR platform by Great Scott Gadgets which can be used to transmit DAB signals generated by [[ODR-DabMod]]. It can be used both for the VHF III band and the L-Band.<br />
<br />
Note that the format should be signed 8 bit (s8), not unsigned (u8) which is commonly used by RTLSDR dongles.<br />
<br />
For more information see https://greatscottgadgets.com/hackrf/<br />
<br />
==Daughterboards for USRP and Analog Parts==<br />
<br />
Find in this section some hardware experiment done with USRP RF front end like daughterboards or external devices (filters, power amplifiers). <br />
<br />
The following Ettus daughterboards can be used for transmission in [[Band 3 Channels|VHF band III]]: <br />
<br />
[[Basic TX]], [[RFX400 daughterboard modification|RFX400]] (after modification) or preferably the new [[WBX]] daughterboard.<br />
<br />
*[[Example of RF amplifier for DAB]] for VHF band III (never connect to an antenna without a license !)<br />
*[[RFX400 daughterboard modification]] to operate in VHF Band III (around 200MHz)<br />
*[[WBX daughterboard]] wide band coverage<br />
*[[DAB in L Band]] test with the WBX daughterboard<br />
*[[Filter]] to kill harmonics<br />
*[[Carrier Shaping]] Mask<br />
*[[Antenna]] for digital radio broadcasting<br />
<br />
==Fighting USRP-related problems==<br />
While the USRP devices can be used for stable operation in many situations, it is sometimes tricky to find the right configuration and system settings to achieve good results.<br />
Here are some hints and remarks to increase reliability.<br />
<br />
* Make sure you use released versions of UHD and GNURadio, and not just the latest git checkout<br />
* Compile the mmbTools with the correct ./configure options<br />
* Monitor for USRP Underruns [http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQGen] <br />
* Disable all useless services on your machine<br />
* Disable CPU frequency scaling<br />
* Try different USB ports, or even USB controllers for bus-connected USRPs<br />
* Try to change the num_send_frame=128,send_frame_size=1024 UHD options</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T18:31:58Z<p>Andimik: /* ETI satellite distribution */ Added piratfm's overview of DAB feeds via satellite</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
A list of (known) DAB streams over satellite can be found at https://github.com/piratfm/eti-tools#satellite-dab-feeds . All of them are not encrypted.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developped by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T18:28:08Z<p>Andimik: /* ETI conversion to http */ ni2http</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developped by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.</div>Andimikhttps://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2018-07-23T18:26:20Z<p>Andimik: /* Description */ wrong link</p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available ad interim on http://mpb.li<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [[http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface]] (ETI) stream as input and outputs a complex baseband stream of interlaced 16 bits I/Q samples with a default sampling frequency of 2.048MHz. It can also directly communicate to the Ettus USRPs using the UHD driver.<br />
<br />
The USRP1 will require resampling to 3.2Msps, which will requires high CPU usage but cannot be avoided. Newer USRPs have a more flexible clocking system.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.42. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd, don't forget to also install the -dev package from your distribution.<br />
<br />
If you want to use the zeromq inputs or outputs, you need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
<br />
Build and install according to the instructions in the README.<br />
<br />
test with:<br />
odr-dabmod -h<br />
<br />
to update to latest upstream:<br />
git pull<br />
<br />
and do the bootstrap configure make again.<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: through command line arguments or with a configuration file:<br />
<br />
===Command line arguments===<br />
<br />
Example with command-line interface:<br />
ord-dabmod ./racor.eti -l -g1 -r3200000<br />
<br />
This modulates the racor.eti file, performs OFDM modulation on baseband at a sampling frequency of 3.2Msamples/sec. Output is sent to the standard output. It can be redirected into a file, or piped into a baseband player ([[CRC-Dwap.py]]).<br />
<br />
When using a USRP, the integrated UHD output can be used. This requires the definition and usage of a configuration file.<br />
<br />
===Configuration file===<br />
<br />
Take the example configuration from GitHub: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini example.ini]<br />
<br />
The '''input''' section defines if you want to read a file or ETI over ZeroMQ. The ZeroMQ must point to a odr-dabmux ZeroMQ output.<br />
The '''modulator''' section sets parameters for the modulator which are described below.<br />
<br />
'''firfilter''' enables the filter that was previously done in the baseband player. It reduces out of band energy, and will increase signal quality, and reduce energy waste in the mask filter. The filter taps can be generated with the helper script in doc/fir-filter<br />
<br />
For each possible output, there is a section: '''outputuhd''' and '''outputfile'''. '''outputfile''' only defines the filename. '''outputuhd''' is more interesting: it defines the device flags, the TX frequency, the PGA gain, and what clocking source you want to use. In case of refclk loss, it is possible to make the modulator crash so as to avoid transmitting a corrupt signal, maybe even on the wrong frequency.<br />
<br />
The parameter<br />
device=master_clock_rate=32768000,type=b100<br />
is valid for USRP B100, and the master_clock_rate allows us to avoid resampling the 2048000sps signal. It is used as UHD device parameter without modification. There are other USRPs supported: See [[DAB hardware]]<br />
<br />
The txgain can be modified while the modulator runs by enabling the '''remotecontrol'''<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
odr-dabmod -C modulator.ini<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for regular USRP1 only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Andimikhttps://wiki.opendigitalradio.org/DAB_hardwareDAB hardware2018-07-23T18:23:28Z<p>Andimik: /* HackRF */ typo</p>
<hr />
<div>==EasyDAB==<br />
<br />
A recent solution to generate a DAB signal has been developed by Sergiy from Kyiv, Ukraine. It is called EasyDAB v2, see http://tipok.org.ua/node/46 . The DAB modulation has been programmed in an FPGA, such that just the multiplexing and audio/PAD encoding needs to be added. A 'cookbook' description of a complete DAB transmission chain based on this board and a Raspberry Pi can be found on the [[RaspDAB]] page. <br />
<br />
==Ettus USRP==<br />
<br />
The Ettus [http://ettus.com] [[USRP]] devices are used to transmit DAB signals generated by [[ODR-DabMod]]. We are mostly using the B200 model.<br />
<br />
There are several devices on the market:<br />
<br />
===USRP B200===<br />
It is the cheapest USRP, and is probably the best choice for both experimentation and transmissions with the ODR-mmbTools. It lacks shielding, but the Hammond enclosure 1455L1601 (Farnell product number 427-2882) fits well. Host connection: USB 2.0 or 3.0. Luckily, the native DAB sample-rate of 2048000 does not require USB 3.0 speeds.<br />
<br />
Be wary about USB 3.0: some host controllers are not very well supported. [http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks Ettus Benchmarks]<br />
<br />
Some [[USRP B200 Measurements]] are available.<br />
<br />
===The original USRP, a.k.a. USRP1===<br />
This is the one that has been used in the beginning, before the UHD driver replaced libusrp, and is still on the market today because it's the only usrp that supports two daughterboards.<br />
While it's been used a lot, it's lack of 1PPS and 10MHz reference clock inputs, and less flexible clock generation requiring resampling on the host makes it less attractive than it's successors. They connect to the host using USB 2.0.<br />
<br />
===USRP2 and USRP N2xx===<br />
The networked series connect to the PC using 1Gbps Ethernet. They can be used successfully with [[ODR-DabMod]] through the UHD driver.<br />
<br />
===USRP B100 (product is end of life)===<br />
The successor of the USRP1. The kit with the WBX daughterboard was a perfect starting point, but it's not available anymore. The B200 is a good replacement.<br />
<br />
<br />
<br />
===USRP E1xx===<br />
Contains an embedded ARM processor that cannot be taken advantage of by the ODR-mmbTools. Call for volunteers: If you want to port [[ODR-DabMod]] to the USRP E100, doing the modulation on the ARM and the FPGA, please get in touch with us !<br />
<br />
==HackRF==<br />
<br />
[[HackRF]] SDR platform<br />
<br />
==Daughterboards for USRP and Analog Parts==<br />
<br />
Find in this section some hardware experiment done with USRP RF front end like daughterboards or external devices (filters, power amplifiers). <br />
<br />
The following Ettus daughterboards can be used for transmission in [[Band 3 Channels|VHF band III]]: <br />
<br />
[[Basic TX]], [[RFX400 daughterboard modification|RFX400]] (after modification) or preferably the new [[WBX]] daughterboard.<br />
<br />
*[[Example of RF amplifier for DAB]] for VHF band III (never connect to an antenna without a license !)<br />
*[[RFX400 daughterboard modification]] to operate in VHF Band III (around 200MHz)<br />
*[[WBX daughterboard]] wide band coverage<br />
*[[DAB in L Band]] test with the WBX daughterboard<br />
*[[Filter]] to kill harmonics<br />
*[[Carrier Shaping]] Mask<br />
*[[Antenna]] for digital radio broadcasting<br />
<br />
==Fighting USRP-related problems==<br />
While the USRP devices can be used for stable operation in many situations, it is sometimes tricky to find the right configuration and system settings to achieve good results.<br />
Here are some hints and remarks to increase reliability.<br />
<br />
* Make sure you use released versions of UHD and GNURadio, and not just the latest git checkout<br />
* Compile the mmbTools with the correct ./configure options<br />
* Monitor for USRP Underruns [http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQGen] <br />
* Disable all useless services on your machine<br />
* Disable CPU frequency scaling<br />
* Try different USB ports, or even USB controllers for bus-connected USRPs<br />
* Try to change the num_send_frame=128,send_frame_size=1024 UHD options</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T18:22:38Z<p>Andimik: /* ETI satellite distribution */ Added GSE and EDI</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* The Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
* May be other than pure DVB-S or DVB-S2 (for example DVB-GSE).<br />
* May be EDI.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) eti_ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developped by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T18:19:19Z<p>Andimik: /* ETI conversion to http */ Typo fixed</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (ready to icecast2) eti_ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developped by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T18:18:22Z<p>Andimik: /* Tools */ Added tsniv2ni</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (realy to icecast2) eti_ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developped by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: ETI extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.<br />
* [https://github.com/newspaperman/tsniv2ni tsniv2ni]: Converts TS ETI V.11 streams to ETI NI G.703.</div>Andimikhttps://wiki.opendigitalradio.org/Ensemble_Transport_InterfaceEnsemble Transport Interface2018-07-23T18:13:37Z<p>Andimik: /* ETI Layers */</p>
<hr />
<div>The Ensemble Transport Interface (ETI) is a standardised output stream from a DAB/DAB+/T-DMB multiplexer. It consists of a 2Mbit/s synchronous stream. Network adaptation is defined for G.703 lines (E1) that is the typical physical interface used between the multiplexer and DAB OFDM modulator.<br />
The ETI stream can also be recorded to a file for capture and replay.<br />
<br />
Recently WorldDMB developped an adaptation of ETI for IP, called EDI (Encapsulated DAB Interface). <br />
<br />
ETI is standardized at ETSI: EN 300 799<br />
<br />
===ETI Layers===<br />
The main layer is ETI-LI, it contains 24 ms frame of DAB multiplex data. This logical frame may be incapsulated into:<br />
* ETI-NI (G.703) - The simplest transport interface (just added sync words at the beginning and padding at the end). It has a fixed packet size of 6144 Bytes, and fixed bitrate of 2 Mbit/s.<br />
* ETI-NI (V.11) - Same as G.703 but with variable frame size and bitrate.<br />
* ETI-NA (G.704) - More complex incapsulation method for E1/T1 interface. Has a fixed bitrate of 2 Mbit/s (with all overhead) and Reed-Solomon forwarded error correction code 226 or 235 of 240 bytes. The packet size is fixed to 5592 or 5376 bytes (depending of error correction mode). This layer is used for satellite distribution of DAB stream.<br />
<br />
===ETI satellite distribution===<br />
Some provides are distributing ETI streams by incapsulation of it into MPEG-TS. That streams may also be:<br />
* Not bit-aligned to transport stream.<br />
* May be inverted.<br />
* Transport stream may be simulated by adding only 0x47 TS-sync byte at the beginning of each 188 byte packed, and the rest of it - is ETI-NA.<br />
<br />
===ETI conversion to http===<br />
To convert ETI-NI stream to HTTP (realy to icecast2) eti_ni2http application from eti-tools may be used.<br />
<br />
===Tools===<br />
* [http://mmbtools.crc.ca/content/view/25/49/ CRC ETI Streamer]: tool developped by [[CRC]] for replaying ETI file on an E1/G.703 card<br />
* [https://github.com/piratfm/eti-tools eti-tools]: eti extractor from MPEG-TS and NA-to-NI converter and HTTP-icecast streamer.</div>Andimik