https://wiki.opendigitalradio.org/api.php?action=feedcontributions&user=Glokhoff&feedformat=atomOpendigitalradio - User contributions [en]2024-03-28T18:51:55ZUser contributionsMediaWiki 1.19.20+dfsg-0+deb7u3https://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2021-01-18T08:05:28Z<p>Glokhoff: Include information about the order in which slides are included in the slideshow, as I have been wondering about this myself for quite some time...</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 />
Version 3 uses a socket to communicate, and is compatible with [[ODR-AudioEnc]] version 3 and with [[ODR-SourceCompanion]] version 1.<br />
<br />
Version 2 uses a fifo and is compatible with older versions of [[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 using UNIX domain sockets that are in /tmp. You do not need to prepare those beforehand. It is necessary to give the same identifier to both odr-padenc and the audio encoder so that they can communicate. In the following examples, this identifier will be 'myprogramme'<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):<br />
odr-padenc -o myprogramme -t dls.txt<br />
<br />
Example 2: Transmission of MOT Slideshow:<br />
odr-padenc -o myprogramme -d ./slides<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:<br />
odr-padenc -o myprogramme -t dls.txt -d ./slides<br />
<br />
The PAD length is specified in the audio encoder, and odr-padenc will automatically handle a possible change in PAD length if you restart the encoder with a different setting.<br />
<br />
<br />
In previous versions (v2 and earlier), communication between odr-padenc and the audio encoder was done via a FIFO. The FIFO needs to be created first by calling e.g.:<br />
mkfifo /tmp/pad.fifo<br />
<br />
In this case, you need to set the same pad length for both tools<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 shrunk (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 />
===== MOT Slide order =====<br />
<br />
The slides are included in the slideshow according to their filename. Therefore, it may be useful to indicate the order in the filename, e.g.<br />
<br />
* 001_station_logo.jpg<br />
* 002_show_promo.jpg<br />
* 003_website_promo.jpg<br />
* 004_station_logo.jpg<br />
* 005_social_media_promo.jpg<br />
* ..... etc.<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.<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 in version 3 ==<br />
ODR-PadEnc version 3 removed the ''burst'' mode, and implements only a mode where PAD data is generated at each request from the audio encoder.<br />
<br />
== PAD generation modes in version 2 ==<br />
ODR-PadEnc version 2 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 protocol ==<br />
This describes the protocol that was in use over the fifo since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab) until the switchover to sockets.<br />
<br />
The sockets-based [[bidirectional PAD communication protocol]] uses the same response format.<br />
<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>Glokhoffhttps://wiki.opendigitalradio.org/Main_PageMain Page2020-09-27T09:33:46Z<p>Glokhoff: Introduced the new discussion forum on groups.io</p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
<div style="font-size:282%">Opendigitalradio.org</div><br />
<br />
<br />
<P><br />
<br />
<BIG><br />
Open techniques for Digital Radio Broadcasting<br />
</BIG><br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="width:100%; border:1px solid #ddcef2; background:#faf5ff; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#faf5ff; color:#000"<br />
! <h2 style="margin:0; background:#ddcef2; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Background</h2><br />
|-<br />
|style="color:#000;"|<br />
Open digital broadcasting techniques based on software defined radio. Digital radio transmission and development must also become democratized for experimenters and small broadcasters. Opendigitalradio.org wiki is about creating a community for documenting and exchanging experimentations and gather information about existing small-scale DAB projects. Please read [[Introduction]] for more information.<br />
'''[[Association Opendigitalradio|Opendigitalradio is a non-profit association based in Switzerland]]''' (page in french), offering also a broadcast infrastructure for temporary radio stations.<br />
<br />
This wiki is also the home of the '''ODR-mmbTools''', the continuation of the CRC-mmbTools from [http://mmbtools.crc.ca CRC]. Please see [[Introduction on DAB/DAB+]]<br />
<br />
Have a look at the [http://opendigitalradio.github.io/mmbtools-doc/mmbtools.pdf guide]<br />
<br />
<br />
[[News|Older news]]<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="border:1px solid #cef2e0; background:#f5fffa; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5fffa; color:#000"<br />
! <h2 style="margin:0; background:#cef2e0; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">DAB/DAB+ transmission</h2><br />
|-<br />
|style="color:#000;"|<br />
[[Image:Logo mmb.png|right]]<br />
*[[Introduction on DAB/DAB+]]<br />
*[[DAB/DAB+ encoding]]: MPEG Layer II or HE-AAC encoding, slideshow encoding<br />
*[[DAB multiplexing]]: putting together DAB/DAB+/DMB programs<br />
*[[DAB modulation]]: create the baseband COFDM modulation<br />
*[[DAB hardware]]: software radio peripheral, filtering, amplification<br />
|-<br />
|}<br />
<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5fffa; color:#000"<br />
! <h2 style="margin:0; background:#cef2e0; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Real cases, examples</h2><br />
|-<br />
|style="color:#000;"|<br />
<br />
The ODR-mmbTools are used in several real-world 24/7 broadcasts, as shown on http://www.opendigitalradio.org/software<br />
<br />
A recipe for a low cost DAB transmission chain for local broadcasts based on the ODR-mmbTools is the [[RaspDAB]] description.<br />
<br />
Older presentations:<br />
*[http://www.slideshare.net/radioradioradio/local-dab-broadcasting Presentation] and [[WorldDMB GA 2010 Open DAB demonstration|demonstration]] of the full open source DAB transmission solution at 2010 WorldDMB General Assembly in Belfast<br />
*[[First licensed open dab transmission]] for Label Suisse Festival 17-19 September 2010 Lausanne.<br />
*[[Demonstration of open source digital transmission chain at IBC]], Stand 10.D21 (EBU), 10-14 September 2010<br />
*[[DAB scripts examples]]<br />
*[[Installer scripts]] for '''Debian'''<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="border:1px solid #f2e0ce; background:#fffaf5; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#fffaf5; color:#000"<br />
! <h2 style="margin:0; background:#f2e0ce; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Other digital systems, transmission and reception</h2><br />
|-<br />
|style="color:#000;"|<br />
*[[DAB reception]] (Openmokast and others)<br />
*[[DAB measurement]] (measurement&monitoring tools, planning tools).<br />
*[[DRM/DRM+ Digital Radio Mondiale]], digital radio system for AM bands (LW, MW and SW) and all VHF bands (FM band and others). <br />
*[[FM RDS transmission]] (not really a digital system except RDS ;)<br />
*[[Crazy techniques using a VGA card as radio peripheral]]<br />
*[[Coverage planning]]<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="width:100%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; color:#000"<br />
! <h2 style="margin:0; background:#cedff2; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Contacts</h2><br />
|-<br />
|style="color:#000;"|<br />
Please follow the odr-mmbtools discussion on groups.io for bug reports, solutions and updates. See the webiste https://groups.io/g/odr-mmbtools how to subscribe. This is the follow up of the crc-mmbtools mailing list on googlegroups (https://groups.google.com/g/crc-mmbtools) , which is still available to check for solutions to older problems.<br />
<br />
Follow us on '''Twitter''': http://twitter.com/opendigiradio to get informed, involved or for any questions. Find us [http://www.facebook.com/opendigitalradio also on '''Facebook''']<br />
<br />
Email: broadcast at opendigitalradio.org<br />
|-<br />
|}<br />
|}</div>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2020-09-27T08:59:37Z<p>Glokhoff: Update of the website URLs, CRC Covweb removed (no longer available), antenna pattern editor added</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 a prediction of broadcast coverage, including the use of directional antenna systems and VHF band III. It requires some time to get used to the way of working, but is definitely worth the effort.<br />
<br />
*[https://www.ve2dbe.com/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 />
*[https://support.nautel.com/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. <br />
<br />
To generate the antenna pattern model from specification documentation one can use the antenna pattern editor from <br />
*[https://www.wireless-planning.com/ Center of Telecommunication Technologies in Novosibirsk, Russia]</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2017-09-13T09:01:35Z<p>Glokhoff: /* Creating a contribution chain for a local radio DAB multiplex */</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 continuosly. 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 to invest 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>Glokhoffhttps://wiki.opendigitalradio.org/DAB_hardwareDAB hardware2017-07-06T17:57:53Z<p>Glokhoff: </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 plaftorm<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>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Automate_operation_with_SupervisorRaspDAB/Automate operation with Supervisor2017-07-06T17:43:20Z<p>Glokhoff: </p>
<hr />
<div>== Installing Supervisor ==<br />
<br />
It is time to make the operation automatic, such that when you power up the Raspberry Pi it will start the encoders and the multiplexer and deliver a multiplexed stream to the EasyDAB board.<br />
<br />
To do so we use a software package called supervisor (extended information can be found at http://supervisord.org). We first need to install it with<br />
<br />
$ sudo apt-get install supervisor<br />
<br />
This will probably also install python-meld3 as it needs that package to function correctly.<br />
<br />
== Supervisor configuration files folder ==<br />
<br />
In this manual we will put the supervisor configuration files in a folder config in the user's home directory. If you want to put this elsewhere you need to make appropriate changes to the commands shown here. You can do this from a terminal window with<br />
<br />
$ mkdir config<br />
<br />
or from the graphical file manager. In this folder we make 2 subfolders, supervisor and mux:<br />
<br />
$ chdir config<br />
$ mkdir supervisor<br />
$ mkdir mux<br />
<br />
Again, you can also do this with the graphical filemanager.<br />
<br />
Now we can make the configuration file for program srv1 (the name is arbitrary, you can use your own names to make identification of the stations easy). Do this for all stations that you want include in the ensemble.<br />
<br />
== The contents of the configuration file ==<br />
<br />
Now let's have a look at the configuration file for the encoders. The following are examples:<br />
<br />
[program:enc-srv1]<br />
# DAB encoding using odr-audioenc<br />
command=/usr/local/bin/odr-audioenc -v [URL of audio stream] -C 200 -b 64 -r 48000 -c 2 -o tcp://localhost:59001 -D -L --audio-resampler=samplerate -L --src-converter-type=0 -p 58 -P /tmp/srv1-pad.fifo<br />
autostart=true<br />
autorestart=true<br />
startretries=100<br />
priority=10<br />
stderr_logfile=/var/log/supervisor/enc-srv1.log<br />
stdout_logfile=/var/log/supervisor/enc-srv1.log<br />
<br />
[program:pad-srv1]<br />
# PAD encoding using odr-padenc<br />
command=/usr/local/bin/odr-padenc -o /tmp/srv1-pad.fifo -p 58 -t /home/[UserID]/PAD/srv1/DLS/DLS1.txt -d /home/[UserID]/PAD/srv1/MOT<br />
autostart=true<br />
autorestart=true<br />
startretries=100<br />
priority=10<br />
stderr_logfile=/var/log/supervisor/pad-srv1.log<br />
stdout_logfile=/var/log/supervisor/pad-srv1.log<br />
<br />
So you define a name for the program that supervisor uses to identify the process it governs. In this case 2 programs, the audio encoder and PAD encoder for station srv1.<br />
<br />
You declare the command line as if you would invoke the program from a command line in a terminal window. Note that we don't use the more verbose reporting, as this would all be put in the log file, which is not necessary. The next 2 lines tell the supervisor program to start the program automatically, and also restart it when it stops. The number of startretries may seem high, but this is to ensure the audio encoder makes a sufficient number of retries when the connection to the stream server is temporarily lost. Then you can declare the priority, which in our case should all be the same - perhaps with the exception of the multiplexer. And you provide the location of the log files, in this case just one file in which both error and normal log messages are collected.<br />
<br />
Make similar files for each station, and put these in the config/supervisor folder.<br />
<br />
The configuration file for the multiplexer is similar:<br />
<br />
[program:mux]<br />
command=/usr/local/bin/odr-dabmux -e /home/[UserID]/config/mux/dab.mux<br />
autostart=true<br />
autorestart=true<br />
priority=100<br />
stderr_logfile=/var/log/supervisor/mux.log<br />
stdout_logfile=/var/log/supervisor/mux.log<br />
<br />
Note we give this priority 100 to delay the start of the multiplexer to give the processor time to start the NTP protocol and update the time.<br />
<br />
== Creating symbolic links ==<br />
<br />
For each radio program that will be part of the multiplex ensemble you need to create a symbolic link into the /etc/supervisor/conf.d/ folder. This is where supervisor will look for the configuration files. Providing symbolic links will point the program to the files we just created, so supervisor will know the parameters for the audio and PAD encoders and the multiplexer.<br />
<br />
Now we can make the symbolic links (assuming 'odr' is your username):<br />
<br />
$ sudo ln -s /home/odr/config/supervisor/srv1.conf /etc/supervisor/conf.d/srv1.conf<br />
<br />
for the configuration file for program srv1. You should do this for all stations you want to include in the multiplex and the multiplex program configuration file itself.<br />
<br />
== Getting Supervisor to work ==<br />
<br />
For every change you make to the configuration files you need to call supervisorctl to reread and update its configuration:<br />
<br />
$ sudo supervisorctl reread<br />
$ sudo supervisorctl update<br />
<br />
This will start supervisord and install it as a deamon, so it will automatically start from now on and start/restart the programs. All services are launched from supervisor, you don't need to start them manually anymore.<br />
<br />
To show status of all services :<br />
<br />
$ sudo supervisorctl status<br />
<br />
To [stop|start|restart] a service :<br />
<br />
$ sudo supervisorctl [stop|start|restart] service-name<br />
<br />
To apply change after change anything in /home/[UserID]/config/supervisor/ file you need to call supervisor to reread and update configuration.<br />
<br />
If you simply type<br />
<br />
sudo supervisorctl<br />
<br />
this will not revert to the command prompt, but you will be able to monitor the supervisor status and issue the commands directly.<br />
<br />
Supervisor redirects all logs from the tools to files in /var/log/supervisor/ You may need to ensure yourself that this directory exists. The logs will get rotated according to the policy defined by your distribution. More details in the child logging section of the documentation. Please refer to the official supervisor documentation for more details.<br />
<br />
If you have correctly installed all programs and configured them correctly you will now have a micro DAB transmitter, with the audio encoding, PAD encoding and multiplexer in a single Raspberry Pi and the modulator in the EasyDAB v2 board, that will automatically start to encode and multiplex and subsequently modulate and transmit the DAB ensemble as soon as you provide a supply voltage. It may take about a minute for the whole process to start, but once it does it will continue until you remove the supply voltage again.</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-06T17:37:29Z<p>Glokhoff: </p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the [[RaspDAB/Requirements|RaspDAB Requirements]] whether you have everything you need<br />
# [[RaspDAB/Install Raspbian on the SD card|Install Raspbian on the SD card]]<br />
# [[RaspDAB/Some steps to increase security and create a new user|Some steps to increase security and create a new user]]<br />
# [[RaspDAB/Install the OpenDigitalRadio software|Install the OpenDigitalRadio software]]<br />
# [[RaspDAB/Get ODR-AudioEnc to operate|Get ODR-AudioEnc to operate]]<br />
# [[RaspDAB/Use ODR-DabMux to generate the multiplex|Use ODR-DabMux to generate the multiplex]]<br />
# [[RaspDAB/Go on air with the EasyDab board|Go on air with the EasyDab board]]<br />
# [[RaspDAB/Add Program Associated Data with ODR-PadEnc|Add Program Associated Data with ODR-PadEnc]]<br />
# [[RaspDAB/Automate operation with Supervisor|Automate operation with Supervisor]]<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: [[RaspDAB/The RaspDAB contribution chain|The RaspDAB contribution chain]]<br />
* Xtra 2: [[RaspDAB/The RaspDAB transmitter|The RaspDAB transmitter]]<br />
<br />
NOTE: this description is derived from https://github.com/glokhoff/RaspDAB , which will have the latest version. Please post comments or questions using the Github Issues reporting system - G. Lokhoff<br />
<br />
[[Image:20170222_120621.jpg|800px]]</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_transmitterRaspDAB/The RaspDAB transmitter2017-07-06T17:35:22Z<p>Glokhoff: </p>
<hr />
<div>Once you know how to generate a DAB signal with the RaspDAB set up you'll be interested to know how to get it amplified so you can reach a wider audience. The block diagram of a basic DAB transmitter is shown below:<br />
<br />
[[Image:RaspDAB_transmitter.png|800px]]<br />
We'll discuss this from bottom to top, starting with the EasyDAB board which you will have come familiar with. Actually this set up is pretty general, so in stead of the EasyDAB board you could also use a HackRF or any other solution to generate the DAB RF signal. All of these "DAB Modulators" will receive the ETI stream from the ODR-DABmux software multiplexer, and construct the DAB signal based on information in the multiplex definition. Typically the RF signal is still at a pretty low level, some tens of milliwatts.<br />
<br />
Before actually amplifying the signal, we better make sure we don't amplify unwanted signals. These would just interfere, and due to the inherent unlinearity of the amplifiers lead to additional intermodulation distortion. Therefore a band pass filter is to be used between the DAB modulator and the RF pre-amplifier, letting just the DAB signal pass and filter out - to the extent possible - anything else. As you will see later, this is not as easy as it sounds...<br />
<br />
In the actual RaspDAB transmitter that was built as part of this project there is an additional 10 dB attentuator after the band pass filter, to enable a better granularity in amplitude setting of the EasyDAB board. The pre-amplifier stage used has a fixed amplification factor, and to keep operating in the linear amplification range we need to attentuate the signal. Otherwise we would introduce intermodulation distortion too easily, and that is something we like to avoid as much as possible. A clean DAB signal at moderate power is better than a distorted one at 'high power', as much of that 'power' will be in signals that interfere with the signal you want to receive, and will only make the error correction less effective as it will have to correct errors introduced by unwanted signals from the transmitter itself rather than interference from the environment. So you waste a lot of power and will get a worse result. In developing the transmitter it is important to inspect the spectrum of the signal after every stage, to ensure you keep it 'clean'.<br />
<br />
The pre-amplifier is to pump the DAB RF signal up to a level suitable for the RF power amplifier. Typically this ranges from some hunderds of milliwatt to some watts, depending on the RF power stage used. Nowadays these RF power stages use advanced MOSFETs, which are capable of amplifying the signal by some 25 to 30 dB at high power. To keep them operating in the linear range one should set the quiescent current (the current flowing through the amplifier when no RF signal is applied) to a value that maximizes the distance between the top of the DAB signal and the 'shoulders'.<br />
<br />
[[Image:RaspDAB_spectrum_1.jpg|800px]]<br />
<br />
DAB spectrum with 30 dB shoulder distance<br />
<br />
To illustrate what is meant by this take a look at the spectrum shown above. You see the top of the DAB spectrum is flat, with steep sides going down about 30 dB, at which point the 'shoulders' start. This was an early inspection of the transmitter's output, before the quiescent current was optimized. The 'needles' reaching down are due to the synchronization 'null' signal of the DAB signal. After optimization of the 'shoulder distance' and using a spectrum analyzer with a sufficient dynamic range (which are not that easy to find...) the spectrum looked like this:<br />
<br />
[[Image:RaspDAB_spectrum_2.jpg|800px]]<br />
<br />
RaspDAB Transmitter spectrum<br />
<br />
You see the DAB signal flat top, with the noise at the bottom at about -75 dB relative to the top. The horizontal scale is 1 MHz/division. Let's compare this with the theoretical DAB spectrum from the DAB specification [1]:<br />
<br />
[[Image:Theoretical_DAB_spectrum.PNG|800px]]<br />
<br />
Theoretical DAB spectrum<br />
<br />
Compared to the 30 dB shoulder distance of the first photograph, the second one is with 40 dB shoulder distance actually pretty close to the theoretical spectrum ! So carefull optimization really is necessary, as this will improve the signal to noise ratio and improve reception.<br />
<br />
Before you can put the signal on air, still some filtering is necessary. First of all a Low Pass Filter to remove any harmonics that may be present at twice, three, four...etc. times the center frequency. Typically this is where the signal leaves the enclosure of what is referred to as the 'DAB transmitter'. But then there's the 'Spectrum Mask Filter'...<br />
<br />
In the DAB specification [1] the recommended spectrum mask is shown in section 15.4:<br />
<br />
[[Image:DAB_spectrum_mask.PNG|800px]]<br />
<br />
DAB Spectrum Mask<br />
<br />
You see 2 limits indicated: a critical and a non-critical one. According to the specification "The solid line mask shall apply to VHF transmitters in critical areas for adjacent channel interference. The dotted line mask shall apply to VHF transmitters in other circumstances." These masks mean that you should stay below the levels indicated for the frequencies shown. What is considered a critical vs. a non-critical situation is up to the radiocommunications regulator of your country...<br />
<br />
As the theoretical DAB spectrum shows, it is actually not possible to satisfy the mask requirements without a mask filter. So you need a filter with a wide (1.54 MHz) flat pass band and then very steep edges to filter out the components beyound +/- 0.97 MHz of the center frequency. Typically cavity filters are use for this, which are rather bulky specialist contraptions, and are therefore located outside of the 'DAB transmitter' enclosure. If the transmitter has been designed and optimized carefully it might be possible to reduce the spurious signal levels enough to be able to satisfy the non-critical mask requirements with a helical filter design.<br />
<br />
After the mask filter the signal can be fed to the antenna, which requires a description of it's own.<br />
<br />
Reference: [1] http://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_transmitterRaspDAB/The RaspDAB transmitter2017-07-06T17:32:49Z<p>Glokhoff: </p>
<hr />
<div>Once you know how to generate a DAB signal with the RaspDAB set up you'll be interested to know how to get it amplified so you can reach a wider audience. The block diagram of a basic DAB transmitter is shown below:<br />
<br />
[[Image:RaspDAB_transmitter.png|800px]]<br />
We'll discuss this from bottom to top, starting with the EasyDAB board which you will have come familiar with. Actually this set up is pretty general, so in stead of the EasyDAB board you could also use a HackRF or any other solution to generate the DAB RF signal. All of these "DAB Modulators" will receive the ETI stream from the ODR-DABmux software multiplexer, and construct the DAB signal based on information in the multiplex definition. Typically the RF signal is still at a pretty low level, some tens of milliwatts.<br />
<br />
Before actually amplifying the signal, we better make sure we don't amplify unwanted signals. These would just interfere, and due to the inherent unlinearity of the amplifiers lead to additional intermodulation distortion. Therefore a band pass filter is to be used between the DAB modulator and the RF pre-amplifier, letting just the DAB signal pass and filter out - to the extent possible - anything else. As you will see later, this is not as easy as it sounds...<br />
<br />
In the actual RaspDAB transmitter that was built as part of this project there is an additional 10 dB attentuator after the band pass filter, to enable a better granularity in amplitude setting of the EasyDAB board. The pre-amplifier stage used has a fixed amplification factor, and to keep operating in the linear amplification range we need to attentuate the signal. Otherwise we would introduce intermodulation distortion too easily, and that is something we like to avoid as much as possible. A clean DAB signal at moderate power is better than a distorted one at 'high power', as much of that 'power' will be in signals that interfere with the signal you want to receive, and will only make the error correction less effective as it will have to correct errors introduced by unwanted signals from the transmitter itself rather than interference from the environment. So you waste a lot of power and will get a worse result. In developing the transmitter it is important to inspect the spectrum of the signal after every stage, to ensure you keep it 'clean'.<br />
<br />
The pre-amplifier is to pump the DAB RF signal up to a level suitable for the RF power amplifier. Typically this ranges from some hunderds of milliwatt to some watts, depending on the RF power stage used. Nowadays these RF power stages use advanced MOSFETs, which are capable of amplifying the signal by some 25 to 30 dB at high power. To keep them operating in the linear range one should set the quiescent current (the current flowing through the amplifier when no RF signal is applied) to a value that maximizes the distance between the top of the DAB signal and the 'shoulders'.<br />
<br />
[[Image:RaspDAB_spectrum_1.jpg|800px]]<br />
<br />
DAB spectrum with 30 dB shoulder distance<br />
<br />
To illustrate what is meant by this take a look at the spectrum shown above. You see the top of the DAB spectrum is flat, with steep sides going down about 30 dB, at which point the 'shoulders' start. This was an early inspection of the transmitter's output, before the quiescent current was optimized. The 'needles' reaching down are due to the synchronization 'null' signal of the DAB signal. After optimization of the 'shoulder distance' and using a spectrum analyzer with a sufficient dynamic range (which are not that easy to find...) the spectrum looked like this:<br />
<br />
[[Image:RaspDAB_spectrum_2.jpg|800px]]<br />
<br />
RaspDAB Transmitter spectrum<br />
<br />
You see the DAB signal flat top, with the noise at the bottom at about -75 dB relative to the top. The horizontal scale is 1 MHz/division. Let's compare this with the theoretical DAB spectrum from the DAB specification [1]:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/Theoretical%20DAB%20spectrum.PNG<br />
<br />
Theoretical DAB spectrum<br />
<br />
Compared to the 30 dB shoulder distance of the first photograph, the second one is with 40 dB shoulder distance actually pretty close to the theoretical spectrum ! So carefull optimization really is necessary, as this will improve the signal to noise ratio and improve reception.<br />
<br />
Before you can put the signal on air, still some filtering is necessary. First of all a Low Pass Filter to remove any harmonics that may be present at twice, three, four...etc. times the center frequency. Typically this is where the signal leaves the enclosure of what is referred to as the 'DAB transmitter'. But then there's the 'Spectrum Mask Filter'...<br />
<br />
In the DAB specification [1] the recommended spectrum mask is shown in section 15.4:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/DAB%20spectrum%20mask.PNG<br />
<br />
DAB Spectrum Mask<br />
<br />
You see 2 limits indicated: a critical and a non-critical one. According to the specification "The solid line mask shall apply to VHF transmitters in critical areas for adjacent channel interference. The dotted line mask shall apply to VHF transmitters in other circumstances." These masks mean that you should stay below the levels indicated for the frequencies shown. What is considered a critical vs. a non-critical situation is up to the radiocommunications regulator of your country...<br />
<br />
As the theoretical DAB spectrum shows, it is actually not possible to satisfy the mask requirements without a mask filter. So you need a filter with a wide (1.54 MHz) flat pass band and then very steep edges to filter out the components beyound +/- 0.97 MHz of the center frequency. Typically cavity filters are use for this, which are rather bulky specialist contraptions, and are therefore located outside of the 'DAB transmitter' enclosure. If the transmitter has been designed and optimized carefully it might be possible to reduce the spurious signal levels enough to be able to satisfy the non-critical mask requirements with a helical filter design.<br />
<br />
After the mask filter the signal can be fed to the antenna, which requires a description of it's own.<br />
<br />
Reference: [1] http://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf</div>Glokhoffhttps://wiki.opendigitalradio.org/File:RaspDAB_spectrum_1.jpgFile:RaspDAB spectrum 1.jpg2017-07-06T17:31:28Z<p>Glokhoff: DAB spectrum with 30 dB shoulders</p>
<hr />
<div>DAB spectrum with 30 dB shoulders</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_transmitterRaspDAB/The RaspDAB transmitter2017-07-06T17:26:24Z<p>Glokhoff: </p>
<hr />
<div>Once you know how to generate a DAB signal with the RaspDAB set up you'll be interested to know how to get it amplified so you can reach a wider audience. The block diagram of a basic DAB transmitter is shown below:<br />
<br />
[[Image:RaspDAB_transmitter.png|800px]]<br />
We'll discuss this from bottom to top, starting with the EasyDAB board which you will have come familiar with. Actually this set up is pretty general, so in stead of the EasyDAB board you could also use a HackRF or any other solution to generate the DAB RF signal. All of these "DAB Modulators" will receive the ETI stream from the ODR-DABmux software multiplexer, and construct the DAB signal based on information in the multiplex definition. Typically the RF signal is still at a pretty low level, some tens of milliwatts.<br />
<br />
Before actually amplifying the signal, we better make sure we don't amplify unwanted signals. These would just interfere, and due to the inherent unlinearity of the amplifiers lead to additional intermodulation distortion. Therefore a band pass filter is to be used between the DAB modulator and the RF pre-amplifier, letting just the DAB signal pass and filter out - to the extent possible - anything else. As you will see later, this is not as easy as it sounds...<br />
<br />
In the actual RaspDAB transmitter that was built as part of this project there is an additional 10 dB attentuator after the band pass filter, to enable a better granularity in amplitude setting of the EasyDAB board. The pre-amplifier stage used has a fixed amplification factor, and to keep operating in the linear amplification range we need to attentuate the signal. Otherwise we would introduce intermodulation distortion too easily, and that is something we like to avoid as much as possible. A clean DAB signal at moderate power is better than a distorted one at 'high power', as much of that 'power' will be in signals that interfere with the signal you want to receive, and will only make the error correction less effective as it will have to correct errors introduced by unwanted signals from the transmitter itself rather than interference from the environment. So you waste a lot of power and will get a worse result. In developing the transmitter it is important to inspect the spectrum of the signal after every stage, to ensure you keep it 'clean'.<br />
<br />
The pre-amplifier is to pump the DAB RF signal up to a level suitable for the RF power amplifier. Typically this ranges from some hunderds of milliwatt to some watts, depending on the RF power stage used. Nowadays these RF power stages use advanced MOSFETs, which are capable of amplifying the signal by some 25 to 30 dB at high power. To keep them operating in the linear range one should set the quiescent current (the current flowing through the amplifier when no RF signal is applied) to a value that maximizes the distance between the top of the DAB signal and the 'shoulders'.<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/20170521_121120.jpg<br />
<br />
DAB spectrum with 30 dB shoulder distance<br />
<br />
To illustrate what is meant by this take a look at the spectrum shown above. You see the top of the DAB spectrum is flat, with steep sides going down about 30 dB, at which point the 'shoulders' start. This was an early inspection of the transmitter's output, before the quiescent current was optimized. The 'needles' reaching down are due to the synchronization 'null' signal of the DAB signal. After optimization of the 'shoulder distance' and using a spectrum analyzer with a sufficient dynamic range (which are not that easy to find...) the spectrum looked like this:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/20170529_210510.jpg<br />
<br />
RaspDAB Transmitter spectrum<br />
<br />
You see the DAB signal flat top, with the noise at the bottom at about -75 dB relative to the top. The horizontal scale is 1 MHz/division. Let's compare this with the theoretical DAB spectrum from the DAB specification [1]:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/Theoretical%20DAB%20spectrum.PNG<br />
<br />
Theoretical DAB spectrum<br />
<br />
Compared to the 30 dB shoulder distance of the first photograph, the second one is with 40 dB shoulder distance actually pretty close to the theoretical spectrum ! So carefull optimization really is necessary, as this will improve the signal to noise ratio and improve reception.<br />
<br />
Before you can put the signal on air, still some filtering is necessary. First of all a Low Pass Filter to remove any harmonics that may be present at twice, three, four...etc. times the center frequency. Typically this is where the signal leaves the enclosure of what is referred to as the 'DAB transmitter'. But then there's the 'Spectrum Mask Filter'...<br />
<br />
In the DAB specification [1] the recommended spectrum mask is shown in section 15.4:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/DAB%20spectrum%20mask.PNG<br />
<br />
DAB Spectrum Mask<br />
<br />
You see 2 limits indicated: a critical and a non-critical one. According to the specification "The solid line mask shall apply to VHF transmitters in critical areas for adjacent channel interference. The dotted line mask shall apply to VHF transmitters in other circumstances." These masks mean that you should stay below the levels indicated for the frequencies shown. What is considered a critical vs. a non-critical situation is up to the radiocommunications regulator of your country...<br />
<br />
As the theoretical DAB spectrum shows, it is actually not possible to satisfy the mask requirements without a mask filter. So you need a filter with a wide (1.54 MHz) flat pass band and then very steep edges to filter out the components beyound +/- 0.97 MHz of the center frequency. Typically cavity filters are use for this, which are rather bulky specialist contraptions, and are therefore located outside of the 'DAB transmitter' enclosure. If the transmitter has been designed and optimized carefully it might be possible to reduce the spurious signal levels enough to be able to satisfy the non-critical mask requirements with a helical filter design.<br />
<br />
After the mask filter the signal can be fed to the antenna, which requires a description of it's own.<br />
<br />
Reference: [1] http://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf</div>Glokhoffhttps://wiki.opendigitalradio.org/File:DAB_spectrum_mask.PNGFile:DAB spectrum mask.PNG2017-07-06T17:21:00Z<p>Glokhoff: Spectrum mask from DAB specification</p>
<hr />
<div>Spectrum mask from DAB specification</div>Glokhoffhttps://wiki.opendigitalradio.org/File:Theoretical_DAB_spectrum.PNGFile:Theoretical DAB spectrum.PNG2017-07-06T17:20:34Z<p>Glokhoff: Theoretical DAB spectrum from DAB specification</p>
<hr />
<div>Theoretical DAB spectrum from DAB specification</div>Glokhoffhttps://wiki.opendigitalradio.org/File:RaspDAB_spectrum_2.jpgFile:RaspDAB spectrum 2.jpg2017-07-06T17:19:38Z<p>Glokhoff: A clean spectrum of a RaspDAB transmitter</p>
<hr />
<div>A clean spectrum of a RaspDAB transmitter</div>Glokhoffhttps://wiki.opendigitalradio.org/File:20170222_120621.jpgFile:20170222 120621.jpg2017-07-06T17:17:56Z<p>Glokhoff: The components of the RaspDAB set up</p>
<hr />
<div>The components of the RaspDAB set up</div>Glokhoffhttps://wiki.opendigitalradio.org/File:RaspDAB_transmitter.pngFile:RaspDAB transmitter.png2017-07-06T17:14:36Z<p>Glokhoff: Block Diagram of a RaspDAB based transmitter</p>
<hr />
<div>Block Diagram of a RaspDAB based transmitter</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2017-07-06T17:07:06Z<p>Glokhoff: </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.jpg|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 continuosly. 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 to invest 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>Glokhoffhttps://wiki.opendigitalradio.org/File:RaspDAB_contribution_chain.pngFile:RaspDAB contribution chain.png2017-07-06T17:04:25Z<p>Glokhoff: Picture of the RaspDAB contribution chain set up</p>
<hr />
<div>Picture of the RaspDAB contribution chain set up</div>Glokhoffhttps://wiki.opendigitalradio.org/Main_PageMain Page2017-07-02T18:55:26Z<p>Glokhoff: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
<div style="font-size:282%">Opendigitalradio.org</div><br />
<br />
<br />
<P><br />
<br />
<BIG><br />
Open techniques for Digital Radio Broadcasting<br />
</BIG><br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="width:100%; border:1px solid #ddcef2; background:#faf5ff; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#faf5ff; color:#000"<br />
! <h2 style="margin:0; background:#ddcef2; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Background</h2><br />
|-<br />
|style="color:#000;"|<br />
Open digital broadcasting techniques based on software defined radio. Digital radio transmission and development must also become democratized for experimenters and small broadcasters. Opendigitalradio.org wiki is about creating a community for documenting and exchanging experimentations and gather information about existing small-scale DAB projects. Please read [[Introduction]] for more information.<br />
'''[[Association Opendigitalradio|Opendigitalradio is a non-profit association based in Switzerland]]''' (page in french), offering also a broadcast infrastructure for temporary radio stations.<br />
<br />
This wiki is also the home of the '''ODR-mmbTools''', the continuation of the CRC-mmbTools from [http://mmbtools.crc.ca CRC]. Please see [[Introduction on DAB/DAB+]]<br />
<br />
Have a look at the [http://opendigitalradio.github.io/mmbtools-doc/mmbtools.pdf guide]<br />
<br />
<br />
[[News|Older news]]<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="border:1px solid #cef2e0; background:#f5fffa; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5fffa; color:#000"<br />
! <h2 style="margin:0; background:#cef2e0; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">DAB/DAB+ transmission</h2><br />
|-<br />
|style="color:#000;"|<br />
[[Image:Logo mmb.png|right]]<br />
*[[Introduction on DAB/DAB+]]<br />
*[[DAB/DAB+ encoding]]: MPEG Layer II or HE-AAC encoding, slideshow encoding<br />
*[[DAB multiplexing]]: putting together DAB/DAB+/DMB programs<br />
*[[DAB modulation]]: create the baseband COFDM modulation<br />
*[[DAB hardware]]: software radio peripheral, filtering, amplification<br />
|-<br />
|}<br />
<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5fffa; color:#000"<br />
! <h2 style="margin:0; background:#cef2e0; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Real cases, examples</h2><br />
|-<br />
|style="color:#000;"|<br />
<br />
The ODR-mmbTools are used in several real-world 24/7 broadcasts, as shown on http://www.opendigitalradio.org/software<br />
<br />
A recipe for a low cost DAB transmission chain for local broadcasts based on the ODR-mmbTools is the [[RaspDAB]] description.<br />
<br />
Older presentations:<br />
*[http://www.slideshare.net/radioradioradio/local-dab-broadcasting Presentation] and [[WorldDMB GA 2010 Open DAB demonstration|demonstration]] of the full open source DAB transmission solution at 2010 WorldDMB General Assembly in Belfast<br />
*[[First licensed open dab transmission]] for Label Suisse Festival 17-19 September 2010 Lausanne.<br />
*[[Demonstration of open source digital transmission chain at IBC]], Stand 10.D21 (EBU), 10-14 September 2010<br />
*[[DAB scripts examples]]<br />
*[[Installer scripts]] for '''Debian'''<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="border:1px solid #f2e0ce; background:#fffaf5; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#fffaf5; color:#000"<br />
! <h2 style="margin:0; background:#f2e0ce; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Other digital systems, transmission and reception</h2><br />
|-<br />
|style="color:#000;"|<br />
*[[DAB reception]] (Openmokast and others)<br />
*[[DAB measurement]] (measurement&monitoring tools, planning tools).<br />
*[[DRM/DRM+ Digital Radio Mondiale]], digital radio system for AM bands (LW, MW and SW) and all VHF bands (FM band and others). <br />
*[[FM RDS transmission]] (not really a digital system except RDS ;)<br />
*[[Crazy techniques using a VGA card as radio peripheral]]<br />
*[[Coverage planning]]<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="width:100%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; color:#000"<br />
! <h2 style="margin:0; background:#cedff2; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Contacts</h2><br />
|-<br />
|style="color:#000;"|<br />
Please use the crc-mmbtools mailing list to reach us. Subscribe by sending an email to '''crc-mmbtools+subscribe@googlegroups.com'''<br />
Follow us on '''Twitter''': http://twitter.com/opendigiradio to get informed, involved or for any questions. Find us [http://www.facebook.com/opendigitalradio also on '''Facebook''']<br />
<br />
Email: broadcast at opendigitalradio.org<br />
|-<br />
|}<br />
|}</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:59:04Z<p>Glokhoff: </p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the [[RaspDAB Requirements]] whether you have everything you need<br />
# [[Install Raspbian on the SD card]]<br />
# [[Some steps to increase security and create a new user]]<br />
# [[Install the OpenDigitalRadio software]]<br />
# [[Get ODR-AudioEnc to operate]]<br />
# [[Use ODR-DabMux to generate the multiplex]]<br />
# [[Go on air with the EasyDab board]]<br />
# [[Add Program Associated Data with ODR-PadEnc]]<br />
# [[Automate operation with Supervisor]]<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: [[the RaspDAB contribution chain]]<br />
* Xtra 2: [[the RaspDAB transmitter]]<br />
<br />
NOTE: this description is derived from https://github.com/glokhoff/RaspDAB , which will have the latest version. Please post comments or questions using the Github Issues reporting system - G. Lokhoff<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/20170222_120621.jpg</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_transmitterRaspDAB/The RaspDAB transmitter2017-07-02T16:55:50Z<p>Glokhoff: Created page with "Once you know how to generate a DAB signal with the RaspDAB set up you'll be interested to know how to get it amplified so you can reach a wider audience. The block diagram of..."</p>
<hr />
<div>Once you know how to generate a DAB signal with the RaspDAB set up you'll be interested to know how to get it amplified so you can reach a wider audience. The block diagram of a basic DAB transmitter is shown below:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/RaspDAB%20transmitter.png<br />
<br />
RaspDAB Transmitter Block Diagram <br />
<br />
We'll discuss this from bottom to top, starting with the EasyDAB board which you will have come familiar with. Actually this set up is pretty general, so in stead of the EasyDAB board you could also use a HackRF or any other solution to generate the DAB RF signal. All of these "DAB Modulators" will receive the ETI stream from the ODR-DABmux software multiplexer, and construct the DAB signal based on information in the multiplex definition. Typically the RF signal is still at a pretty low level, some tens of milliwatts.<br />
<br />
Before actually amplifying the signal, we better make sure we don't amplify unwanted signals. These would just interfere, and due to the inherent unlinearity of the amplifiers lead to additional intermodulation distortion. Therefore a band pass filter is to be used between the DAB modulator and the RF pre-amplifier, letting just the DAB signal pass and filter out - to the extent possible - anything else. As you will see later, this is not as easy as it sounds...<br />
<br />
In the actual RaspDAB transmitter that was built as part of this project there is an additional 10 dB attentuator after the band pass filter, to enable a better granularity in amplitude setting of the EasyDAB board. The pre-amplifier stage used has a fixed amplification factor, and to keep operating in the linear amplification range we need to attentuate the signal. Otherwise we would introduce intermodulation distortion too easily, and that is something we like to avoid as much as possible. A clean DAB signal at moderate power is better than a distorted one at 'high power', as much of that 'power' will be in signals that interfere with the signal you want to receive, and will only make the error correction less effective as it will have to correct errors introduced by unwanted signals from the transmitter itself rather than interference from the environment. So you waste a lot of power and will get a worse result. In developing the transmitter it is important to inspect the spectrum of the signal after every stage, to ensure you keep it 'clean'.<br />
<br />
The pre-amplifier is to pump the DAB RF signal up to a level suitable for the RF power amplifier. Typically this ranges from some hunderds of milliwatt to some watts, depending on the RF power stage used. Nowadays these RF power stages use advanced MOSFETs, which are capable of amplifying the signal by some 25 to 30 dB at high power. To keep them operating in the linear range one should set the quiescent current (the current flowing through the amplifier when no RF signal is applied) to a value that maximizes the distance between the top of the DAB signal and the 'shoulders'.<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/20170521_121120.jpg<br />
<br />
DAB spectrum with 30 dB shoulder distance<br />
<br />
To illustrate what is meant by this take a look at the spectrum shown above. You see the top of the DAB spectrum is flat, with steep sides going down about 30 dB, at which point the 'shoulders' start. This was an early inspection of the transmitter's output, before the quiescent current was optimized. The 'needles' reaching down are due to the synchronization 'null' signal of the DAB signal. After optimization of the 'shoulder distance' and using a spectrum analyzer with a sufficient dynamic range (which are not that easy to find...) the spectrum looked like this:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/20170529_210510.jpg<br />
<br />
RaspDAB Transmitter spectrum<br />
<br />
You see the DAB signal flat top, with the noise at the bottom at about -75 dB relative to the top. The horizontal scale is 1 MHz/division. Let's compare this with the theoretical DAB spectrum from the DAB specification [1]:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/Theoretical%20DAB%20spectrum.PNG<br />
<br />
Theoretical DAB spectrum<br />
<br />
Compared to the 30 dB shoulder distance of the first photograph, the second one is with 40 dB shoulder distance actually pretty close to the theoretical spectrum ! So carefull optimization really is necessary, as this will improve the signal to noise ratio and improve reception.<br />
<br />
Before you can put the signal on air, still some filtering is necessary. First of all a Low Pass Filter to remove any harmonics that may be present at twice, three, four...etc. times the center frequency. Typically this is where the signal leaves the enclosure of what is referred to as the 'DAB transmitter'. But then there's the 'Spectrum Mask Filter'...<br />
<br />
In the DAB specification [1] the recommended spectrum mask is shown in section 15.4:<br />
<br />
https://github.com/glokhoff/RaspDAB/raw/master/DAB%20spectrum%20mask.PNG<br />
<br />
DAB Spectrum Mask<br />
<br />
You see 2 limits indicated: a critical and a non-critical one. According to the specification "The solid line mask shall apply to VHF transmitters in critical areas for adjacent channel interference. The dotted line mask shall apply to VHF transmitters in other circumstances." These masks mean that you should stay below the levels indicated for the frequencies shown. What is considered a critical vs. a non-critical situation is up to the radiocommunications regulator of your country...<br />
<br />
As the theoretical DAB spectrum shows, it is actually not possible to satisfy the mask requirements without a mask filter. So you need a filter with a wide (1.54 MHz) flat pass band and then very steep edges to filter out the components beyound +/- 0.97 MHz of the center frequency. Typically cavity filters are use for this, which are rather bulky specialist contraptions, and are therefore located outside of the 'DAB transmitter' enclosure. If the transmitter has been designed and optimized carefully it might be possible to reduce the spurious signal levels enough to be able to satisfy the non-critical mask requirements with a helical filter design.<br />
<br />
After the mask filter the signal can be fed to the antenna, which requires a description of it's own.<br />
<br />
Reference: [1] http://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2017-07-02T16:51:09Z<p>Glokhoff: </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 />
https://github.com/glokhoff/RaspDAB/blob/master/RaspDAB%20contribution%20chain.png<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 continuosly. 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 to invest 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>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2017-07-02T16:42:03Z<p>Glokhoff: Created page with " == Creating a contribution chain for a local radio DAB multiplex == Now we have shown how to use a Raspberry Pi to provide a DAB Multiplex stream to an EasyDAB v2 we can cre..."</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 : Picture of RaspDAB contribution chain 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 continuosly. 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 to invest 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>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:40:50Z<p>Glokhoff: </p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the [[RaspDAB Requirements]] whether you have everything you need<br />
# [[Install Raspbian on the SD card]]<br />
# [[Some steps to increase security and create a new user]]<br />
# [[Install the OpenDigitalRadio software]]<br />
# [[Get ODR-AudioEnc to operate]]<br />
# [[Use ODR-DabMux to generate the multiplex]]<br />
# [[Go on air with the EasyDab board]]<br />
# [[Add Program Associated Data with ODR-PadEnc]]<br />
# [[Automate operation with Supervisor]]<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: [[the RaspDAB contribution chain]]<br />
* Xtra 2: [[the RaspDAB transmitter]]<br />
<br />
NOTE: this description is derived from https://github.com/glokhoff/RaspDAB , which will have the latest version. Please post comments or questions using the Github Issues reporting system - G. Lokhoff</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Automate_operation_with_SupervisorRaspDAB/Automate operation with Supervisor2017-07-02T16:39:58Z<p>Glokhoff: Created page with "== Installing Supervisor == It is time to make the operation automatic, such that when you power up the Raspberry Pi it will start the encoders and the multiplexer and delive..."</p>
<hr />
<div>== Installing Supervisor ==<br />
<br />
It is time to make the operation automatic, such that when you power up the Raspberry Pi it will start the encoders and the multiplexer and deliver a multiplexed stream to the EasyDAB board.<br />
<br />
To do so we use a software package called supervisor (extended information can be found at http://supervisord.org). We first need to install it with<br />
<br />
$ sudo apt-get install supervisor<br />
<br />
This will probably also install python-meld3 as it needs that package to function correctly.<br />
<br />
== Supervisor configuration files folder ==<br />
<br />
In this manual we will put the supervisor configuration files in a folder config in the user's home directory. If you want to put this elsewhere you need to make appropriate changes to the commands shown here. You can do this from a terminal window with<br />
<br />
$ mkdir config<br />
<br />
or from the graphical file manager. In this folder we make 2 subfolders, supervisor and mux:<br />
<br />
$ chdir config<br />
$ mkdir supervisor<br />
$ mkdir mux<br />
<br />
Again, you can also do this with the graphical filemanager.<br />
<br />
Now we can make the configuration file for program srv1 (the name is arbitrary, you can use your own names to make identification of the stations easy). Do this for all stations that you want include in the ensemble.<br />
<br />
== The contents of the configuration file ==<br />
<br />
Now let's have a look at the configuration file for the encoders. The following are examples:<br />
<br />
[program:enc-srv1]<br />
# DAB encoding using odr-audioenc<br />
command=/usr/local/bin/odr-audioenc -v [URL of audio stream] -C 200 -b 64 -r 48000 -c 2 -o tcp://localhost:59001 -D -L --audio-resampler=samplerate -L --src-converter-type=0 -p 58 -P /tmp/srv1-pad.fifo<br />
autostart=true<br />
autorestart=true<br />
priority=10<br />
stderr_logfile=/var/log/supervisor/enc-srv1.log<br />
stdout_logfile=/var/log/supervisor/enc-srv1.log<br />
<br />
[program:pad-srv1]<br />
# PAD encoding using odr-padenc<br />
command=/usr/local/bin/odr-padenc -o /tmp/srv1-pad.fifo -p 58 -t /home/[UserID]/PAD/srv1/DLS/DLS1.txt -d /home/[UserID]/PAD/srv1/MOT<br />
autostart=true<br />
autorestart=true<br />
priority=10<br />
stderr_logfile=/var/log/supervisor/pad-srv1.log<br />
stdout_logfile=/var/log/supervisor/pad-srv1.log<br />
<br />
So you define a name for the program that supervisor uses to identify the process it governs. In this case 2 programs, the audio encoder and PAD encoder for station srv1.<br />
<br />
You declare the command line as if you would invoke the program from a command line in a terminal window. Note that we don't use the more verbose reporting, as this would all be put in the log file, which is not necessary. The next 2 lines tell the supervisor program to start the program automatically, and also restart it when it stops. Then you can decalre the priority, which in our case should all be the same - perhaps with the exception of the multiplexer. And you provide the location of the log files, in this case just one file in which both error and normal log messages are collected.<br />
<br />
Make similar files for each station, and put these in the config/supervisor folder.<br />
<br />
The configuration file for the multiplexer is similar:<br />
<br />
[program:mux]<br />
command=/usr/local/bin/odr-dabmux -e /home/[UserID]/config/mux/dab.mux<br />
autostart=true<br />
autorestart=true<br />
priority=1<br />
stderr_logfile=/var/log/supervisor/mux.log<br />
stdout_logfile=/var/log/supervisor/mux.log<br />
<br />
Note we give this priority 1 as the multiplexer should always run.<br />
<br />
== Creating symbolic links ==<br />
<br />
For each radio program that will be part of the multiplex ensemble you need to create a symbolic link into the /etc/supervisor/conf.d/ folder. This is where supervisor will look for the configuration files. Providing symbolic links will point the program to the files we just created, so supervisor will know the parameters for the audio and PAD encoders and the multiplexer.<br />
<br />
Now we can make the symbolic links (assuming 'odr' is your username):<br />
<br />
$ sudo ln -s /home/odr/config/supervisor/srv1.conf /etc/supervisor/conf.d/srv1.conf<br />
<br />
for the configuration file for program srv1. You should do this for all stations you want to include in the multiplex and the multiplex program configuration file itself.<br />
<br />
== Getting Supervisor to work ==<br />
<br />
For every change you make to the configuration files you need to call supervisorctl to reread and update its configuration:<br />
<br />
$ sudo supervisorctl reread<br />
$ sudo supervisorctl update<br />
<br />
This will start supervisord and install it as a deamon, so it will automatically start from now on and start/restart the programs. All services are launched from supervisor, you don't need to start them manually anymore.<br />
<br />
To show status of all services :<br />
<br />
$ sudo supervisorctl status<br />
<br />
To [stop|start|restart] a service :<br />
<br />
$ sudo supervisorctl [stop|start|restart] service-name<br />
<br />
To apply change after change anything in /home/[UserID]/config/supervisor/ file you need to call supervisor to reread and update configuration.<br />
<br />
If you simply type<br />
<br />
sudo supervisorctl<br />
<br />
this will not revert to the command prompt, but you will be able to monitor the supervisor status and issue the commands directly.<br />
<br />
Supervisor redirects all logs from the tools to files in /var/log/supervisor/ You may need to ensure yourself that this directory exists. The logs will get rotated according to the policy defined by your distribution. More details in the child logging section of the documentation. Please refer to the official supervisor documentation for more details.<br />
<br />
If you have correctly installed all programs and configured them correctly you will now have a micro DAB transmitter, with the audio encoding, PAD encoding and multiplexer in a single Raspberry Pi and the modulator in the EasyDAB v2 board, that will automatically start to encode and multiplex and subsequently modulate and transmit the DAB ensemble as soon as you provide a supply voltage. It may take about a minute for the whole process to start, but once it does it will continue until you remove the supply voltage again.</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Add_Program_Associated_Data_with_ODR-PadEncRaspDAB/Add Program Associated Data with ODR-PadEnc2017-07-02T16:35:50Z<p>Glokhoff: Created page with "Program Associated Data is information that, as the name implies, is somehow linked with the audio program. And as such it is logical to carry the information in the audio bit..."</p>
<hr />
<div>Program Associated Data is information that, as the name implies, is somehow linked with the audio program. And as such it is logical to carry the information in the audio bitstream. ODR-PadEnc enables 2 types of program associated data: simple text ('Dynamic Label Segment') and a slideshow (using the Multimedia Object Transfer protocol). The text is read from a file and the slides from a directory. Both are encoded by ODR-PadEnc and placed in a FIFO (First In First Out) structure, one for every audio program, from where ODR-AudioEnc gets the information and includes it in the audio bitstream.<br />
<br />
== FIFO creation ==<br />
<br />
So we first need to create the FIFO. This is done with<br />
<br />
$ mkfifo /tmp/srv1_pad.fifo<br />
<br />
You can give any name for the fifo file, but here we stick to [service name]_pad.fifo for clarity. And it is placed in the /tmp folder as it is just a conduit to transfer information from one program to another.<br />
<br />
== DLS Text ==<br />
<br />
The DLS text information is normally shown as scrolling text on the display of the receiver. Each line of text can be at maximum 128 characters, though some receivers are known not to be able to display all 128. Also some receivers seem to show one character more than what is included in the text file, which seems to be from the previous DLS text. These are just annoying software bugs in the receivers, but you may want to prepare your texts for it by always sending the same length - less that 128 characters (actually, shorter is better as scolling will take less time) - and always having a 'space' character at the end to cover up any text still left in the memory.<br />
<br />
We'll first create a directory for the PAD and DLS:<br />
<br />
$ mkdir PAD<br />
$ chdir PAD<br />
$ mkdir srv1<br />
$ chdir srv1<br />
$ mkdir DLS<br />
<br />
In this directory you can place the text files to be carried as DLS. Here we call them DLS1.txt and DLS2.txt.<br />
<br />
== MOT slides ==<br />
<br />
In the directory PAD we also create the MOT directory:<br />
<br />
$ mkdir MOT<br />
<br />
In this directory you can place .jpg or .png files with a size of maximum 50 kbytes, and dimensions of 320 by 240 pixels. Typically just a single slide is put here, with the station logo, but you can add more if you want to. These will be carried in a caroussel, just like the DLS text. We call the slide logo.jpg. It's good practice to add a description file, called logo.jpg.sls_params . This is a simple text file with e.g. the following content:<br />
<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=Station Logo<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/logo.jpg<br />
<br />
This will enable more advanced receivers to keep a categorized selection of slides in memory, e.g. the logo, news pages etc.<br />
<br />
== Including PAD in the audio stream ==<br />
<br />
Once you have put the text files in the PAD directory and the slide(s) in the MOT directory you can invoke the PAD encoder with<br />
<br />
$ odr-padenc -o /tmp/srv1-pad.fifo -t /home/[UserID]/PAD/srv1/DLS/DLS1.txt -t /home/[UserID]/PAD/srv1/DLS/DLS2.txt -d /home/[UserID]/PAD/srv1/MOT -p 58<br />
<br />
This will read the text files and transcode them, and also ingress the slides in the MOT directory and put all information in the fifo, where the audio encoder can pick them up. The number of PAD bytes per audio frame is signalled here as 58 (the default). You may want to reduce this at lower audio bitrates, to slightly improve the audio quality.<br />
<br />
NOTE: I have no clue why the text files have to be mentioned each individually, and just the directory of the slides needs to be indicated... Seems the latter approach could be used for the text files as well.<br />
<br />
Now the audio encoder needs to be told where to pick up the PAD:<br />
<br />
$ odr-audioenc -v http://server-66.stream-server.nl:8852 -C 200 -b 64 -o tcp://localhost:59000 -D -L --audio-resampler=samplerate -L --src-converter-type=1 -l -V -p 58 -P /tmp/srv1_pad.fifo<br />
<br />
So you add the -p 58 to indicate the length (should be identical to the value in the odr-padenc invokation) and indicate with -P the location of the PAD fifo.<br />
<br />
That's it ! You should see PAD text now on your DAB receiver, and - if you have a receiver or software to decode it (like DAB Player) - should see the slide(s) starting to appear.<br />
<br />
For more information, also on DL-plus, see the examples in the ODR Wiki. And now all elements are up and running, let's ensure this is started automatically upon booting !</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Go_on_air_with_the_EasyDab_boardRaspDAB/Go on air with the EasyDab board2017-07-02T16:32:32Z<p>Glokhoff: Created page with "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 th..."</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 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 : typlically 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>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Use_ODR-DabMux_to_generate_the_multiplexRaspDAB/Use ODR-DabMux to generate the multiplex2017-07-02T16:29:25Z<p>Glokhoff: Created page with "We now open a new terminal console window and start to work on generating an actual DAB multiplex. The invocation of the ODR-DabMux program doesn't provide you with many optio..."</p>
<hr />
<div>We now open a new terminal console window and start to work on generating an actual DAB multiplex. The invocation of the ODR-DabMux program doesn't provide you with many options, If you issue<br />
<br />
$ odr-dabmux -h<br />
<br />
you simply get a message that you need to provide a configuration file and an short explanation how a DAB multiplex is constructed of services that are based on service components which together fit into subchannels in the Common Interleaved Frame.<br />
<br />
So you run the program with<br />
<br />
$ odr-dabmux PATH_TO/NAME_OF_CONFIGURATION.mux<br />
<br />
We need to provide all information the multiplexer needs in the multiplex definition file.<br />
<br />
== How to define your DAB multiplex ==<br />
<br />
To help you understand how to define a DAB multiplex file some examples are included in the dab/ODR-DabMux/doc folder. Let's have a look at the example.mux file:<br />
<br />
; This is an example configuration file that illustrates<br />
; the structure of the configuration.<br />
; It doesn't show all possible options. A more detailed example<br />
; is available in doc/advanced.mux<br />
;<br />
; It contains two services, one DAB and one DAB+, and also shows<br />
; both the file input useful for offline processing, and the<br />
; ZeroMQ input useful in a 24/7 scenario.<br />
<br />
; More information about the usage of the tools is available<br />
; in the guide, which can be found on the<br />
; www.opendigitalradio.org website.<br />
; <br />
<br />
It's always clever to read the documentation. I hope you take the time to do it !<br />
<br />
; As you can see, comments are defined by semicolons.<br />
;<br />
; It consists of six mandatory sections, whose relative order in this<br />
; file are of no importance.<br />
<br />
; The general section defines global multiplex parameters.<br />
general {<br />
; the DAB Transmission mode (values 1-4 accepted)<br />
dabmode 1<br />
<br />
Always use dabmode 1, it's the only one really used...<br />
<br />
; the number of ETI frames to generate (set to 0 to get an unlimited number)<br />
nbframes 10<br />
<br />
10 is fine for a first test, later on you will put this at 0 for continuous operation.<br />
<br />
; boolean fields can accept either false or true as values:<br />
<br />
; Set to true to enable logging to syslog<br />
syslog false<br />
<br />
; Enable timestamp definition necessary for SFN<br />
; This also enables time encoding using the MNSC.<br />
tist false<br />
<br />
Set this to true later on.<br />
<br />
; The management server is a simple TCP server that can present<br />
; statistics data (buffers, overruns, underruns, etc)<br />
; which can then be graphed a tool like Munin<br />
; The doc/stats_dabmux_multi.py tool is a suitable<br />
; plugin for that.<br />
; If the port is zero, or the line commented, the server<br />
; is not started.<br />
managementport 12720<br />
}<br />
<br />
To be discussed later on<br />
<br />
remotecontrol {<br />
; enable the telnet remote control server on the given port<br />
; This server allows you to read and define parameters that<br />
; some features export. It is only accessible from localhost.<br />
; Set the port to 0 to disable the server<br />
telnetport 12721<br />
<br />
To be discussed later on<br />
<br />
; The remote control is also accessible through a ZMQ REQ/REP socket,<br />
; and is useful for machine-triggered interactions. It supports the<br />
; same commands as the telnet RC.<br />
; The example code in doc/zmq_remote.py illustrates how to use this rc.<br />
; To disable the zeromq endpoint, remove the zmqendpoint line.<br />
; By specifying "lo" in the URL, we make the server only accessible<br />
; from localhost. You can write tcp://*:12722 to make it accessible<br />
; on all interfaces.<br />
zmqendpoint tcp://lo:12722<br />
<br />
To be discussed later on<br />
<br />
; the remote control server makes use of the unique identifiers<br />
; for the subchannels, services and components. Make sure you<br />
; chose them so that you can identify them.<br />
}<br />
<br />
Now it get's interesting...<br />
<br />
; Some ensemble parameters<br />
ensemble {<br />
id 0x8d4b ; you can also use decimal if you want<br />
<br />
Every Ensemble has its own hexadecimal identifier code, such that receivers can detect they are different. There doesn't seem to be a central entity that distributes these codes (at least not in the Netherlands), so please check what ID code might be appropriate by checking the Ensemble codes of other ensembles in your region, and select a different one. It does seem to be good practice to start all identity codes with the short country code as in http://www.etsi.org/deliver/etsi_ts/101700_101799/101756/02.01.01_60/ts_101756v020101p.pdf section 5.4 Country ID. For example: in the case of the Netherlands this is '8'.<br />
<br />
ecc 0xe3 ; Extended Country Code<br />
<br />
From the same table we see that the extended country code is 'E3'<br />
<br />
local-time-offset auto ; autmatically calculate from system local time<br />
; or<br />
;local-time-offset 1 ; in hours, supports half-hour offsets<br />
<br />
Keep this as is, but make sure the system clock of the Raspberry is synchronized with an NTP server. By the way, if the time display on the receivers is not correct, simply stop and restart the multiplexer. This may happen if the multiplexer started before the time was synchronized with the Raspberry Pi.<br />
<br />
; all labels are maximum 16 characters in length<br />
label "OpenDigitalRadio"<br />
; The short label is built from the label by erasing letters, and cannot<br />
; be longer than 8 characters. If omitted, it will be truncated from the<br />
; label<br />
shortlabel "ODR"<br />
}<br />
<br />
Think carefully about the name for your multiplex. Some DAB receivers will use the longer label, but some with just an RDS like display will use the shortlabel of maximum 8 characters. It is not clear why the shortlabel has to be derived from the label as explained above... With all the complexity of the DAB system, why this strange restriction ? (e.g. I could think of a label 'Radio Four', but with this restriction one cannot make the short label 'Radio 4'...)<br />
<br />
; Definition of DAB services<br />
services {<br />
; Each service has it's own unique identifier, that is<br />
; used throughout the configuration file and for the RC.<br />
srv-fu {<br />
id 0x8daa<br />
label "Funk"<br />
; you can define a shortlabel too.<br />
}<br />
srv-ri {<br />
id 0x8dab<br />
label "Rick"<br />
}<br />
}<br />
<br />
In this section you give every radio station ('service') a unique ID ( Just as the ensemble ID, start with the short country code followed by 3 hexadecimal characters you choose - check the labels of other stations first so you do not copy one by accident ! ) and label that will be visible on the display of the DAB receiver so the listener can select what to listen to. By the way: you can change the part after 'srv-' with something you derive from the label you give the service, as illustrated, and keep this consistent for the subchannels and component definitions below.<br />
<br />
subchannels {<br />
sub-fu {<br />
; This is our DAB programme, using a file input<br />
type audio<br />
inputfile "funk.mp2"<br />
bitrate 128<br />
id 10<br />
protection 3<br />
}<br />
<br />
Here subchannels are defined, which for this simple example are audio programs only. In this first example the input is an MPEG 1 Layer II encoded audio file, which is type 'audio' (as the audio encoding in the original DAB specification). See below for using a stream from ODR-AudioEnc. You have to supply the bitrate (which should match the one you have set in the ODR-AudioEnc command line). Also a unique ID (it is probably best to number them logically 1 to ...) and the error correction protection level.<br />
<br />
For 'old fashioned DAB' there are 5 error protection levels, UEP 1 to 5. UEP 1 provides the best protection, but at the cost of Capacity Units: it requires more error protection bits to be calculated and sent together with the bits that carry the audio information. This ratio is called the 'code rate'. For UEP 1 this is about 0.35, meaning that of all the bits sent for this station, almost 2/3rd are error correction bit and just about 1/3rd are bits carrying the audio information. According to https://www.ofcom.org.uk/__data/assets/pdf_file/0027/55494/annex-g.pdf the code rates for UEP 2 to 5 are approximately 0.42, 0.5, 0.6 and 0.75. UEP means 'Unequal Error Protection': some bits in the MPEG2 audio stream are better protected than others, as an error in them has an impact for a longer time than just one sample. In DAB+ this has changed, and modern Reed-Solomon encoding is used, protecting all audio bits the same way. There are 8 protection levels, in 2 categories A and B. EEP (Equal Error Protection) A1 to A4 have code rates from 1/4th, 3/8th, 1/2nd and 3/4th, and EEP B1 to B4 have code rates 4/9th, 4/7th, 4/6th and 4/5th . The EEP A protection can be used for bitrates in 8 kbits/sec increments, whereas the EEP B protection levels are limited to bitrates in 32 kbits/sec increments. (Please note, that currently the EasyDAB doesn't seem to be able to encode EEP B rates. This restricts the options available to compile the multiplex).<br />
<br />
sub-ri {<br />
; This is our DAB+ programme, using a ZeroMQ<br />
type dabplus<br />
; Accepts connections to port 9000 from any interface.<br />
; Use ODR-AudioEnc as encoder<br />
inputfile "tcp://*:9000"<br />
bitrate 96<br />
id 1<br />
protection 3<br />
<br />
This is similar as the previous subchannel, but this is a DAB+ AAC encoded station. As inputfile a stream from the ODR-AudioEnc is defined. To establish the link, the audio encoder needs to be supplied the exact URL it needs to send the stream to. The multiplexer listens for the stream on the port and interface defined as above.<br />
<br />
; ZMQ specific options, mandatory:<br />
<br />
; Maximum size of input buffer, in AAC frames (24ms)<br />
; when this buffer size is reached, some frames will be<br />
; discarded to get the size again below this value.<br />
; As the present implementation discards entire AAC superframes,<br />
; (5 frames = 120ms) the effect will clearly be audible.<br />
zmq-buffer 40<br />
<br />
; At startup or after an underrun, the buffer is filled to this<br />
; amount of AAC frames before streaming starts.<br />
zmq-prebuffering 20<br />
<br />
; In an ideal scenario, where the input rate exactly corresponds<br />
; to the rate at which the frames are consumed by dabmux, you<br />
; see the buffer level staying around the zmq-prebuffering value.<br />
; Network latency jitter can make it temporarily go lower or higher.<br />
; Encoder clock drift will make the buffer either slowly fill or<br />
; empty, which will create intermittent glitches.<br />
}<br />
}<br />
<br />
I guess from this explanation the need for a buffer when using a stream input is clear...<br />
<br />
; In our simple example, each component links one service to one subchannel<br />
components {<br />
; the component unique identifiers are used for the RC.<br />
comp-fu {<br />
; According to specification, you should not define component labels if<br />
; the service is only used in one component. The service label is sufficient<br />
; in that case.<br />
service srv-fu<br />
subchannel sub-fu<br />
}<br />
<br />
comp-ri {<br />
service srv-ri<br />
subchannel sub-ri<br />
}<br />
}<br />
<br />
If you are using slide show PAD later on, you need to insert an indication here. Check the OpenDigitalRadio Wiki for details.<br />
<br />
; A list of outputs<br />
outputs {<br />
; The unique-id can be used by the remote control or the statistics server<br />
; to identify the output<br />
<br />
; Output RAW ETI NI to standard output<br />
stdout "fifo:///dev/stdout?type=raw"<br />
<br />
Use this if you want to use RAW ETI. However, in our case we use ZeroMQ. So comment out (put ; before 'stdout') the above line and enable the ZeroMQ output by removing the ';' before 'zmq' below:<br />
<br />
; ZeroMQ output example <br />
; This output does not back-pressure the multiplexer.<br />
; Listen on all interfaces, on port 9100<br />
;zmq "zmq+tcp://*:9100"<br />
<br />
; Output ETI-over-TCP. This is like piping a RAW ETI NI data stream<br />
; into a TCP socket, except that the output can handle simultaneous<br />
; connections.<br />
; 0.0.0.0 means "listen on all interfaces"<br />
; This output does not back-pressure the multiplexer.<br />
;tcp "tcp://0.0.0.0:9200"<br />
<br />
Use this for modulators that can receive an ETI stream over TCP.<br />
<br />
; Throttle output to real-time (one ETI frame every 24ms)<br />
;throttle "simul://"<br />
<br />
For real-time operation (transmitting) you need to enable this output, so remove the ';' .<br />
<br />
; Important! For real-time operation, you need to have exactly one<br />
; output that applies back-pressure to ODR-DabMux, otherwise it will run<br />
; at the highest possible rate on your system!<br />
;<br />
; For an output to a pipe, the data consumer at the other end of the pipe<br />
; will dictate the multiplexing rate to ODR-DabMux.<br />
;<br />
; If you use the zmq+tcp:// or the tcp:// output,<br />
; you must also enable a simul:// output!<br />
}<br />
<br />
And that's the end of the multiplex configuration file.<br />
<br />
== Starting the multiplexer ==<br />
<br />
As mentioned above, once you have defined your multiplex configuration file, you can start the multiplexer with<br />
<br />
$ odr-dabmux PATH_TO/NAME_OF_CONFIGURATION.mux<br />
<br />
If your configuration file is OK, you will see an overview of the settings you provided, and some messages indicating the multiplexer has started.<br />
<br />
In the repository you can find a RaspDab.mux example that you can use to generate a multiplex with one or two audio programs. Create a new directory in the home directory with the name 'config' in which we will store all configuration files for the project. And in this directory make a subdirectory called 'mux' to store the multiplex configuration files. So let's store RaspDab.mux there.<br />
<br />
Assuming you invoke the program from the home directory, you can now issue the command<br />
<br />
$ odr-dabmux ./config/mux/RaspDab.mux<br />
<br />
Leave this also running, as it is time to get to the EasyDAB board...</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Get_ODR-AudioEnc_to_operateRaspDAB/Get ODR-AudioEnc to operate2017-07-02T16:27:07Z<p>Glokhoff: Created page with "If you have checked the installation of the OpenDigitalRadio software with the -h option for odr-audioenc you will have seen it is possible to issue a large number of options...."</p>
<hr />
<div>If you have checked the installation of the OpenDigitalRadio software with the -h option for odr-audioenc you will have seen it is possible to issue a large number of options. On this page we just focus on the most commonly used ones, necessary at first to encode audio that comes from an Internet stream into a signal that can be used in a DAB multiplex. It is assumed this is a situation that is very common: the radio station already has an internet stream running, so for the first test we can use that to insert the audio in the DAB stream. For now we assume you will run all necessary OpenDigitalRadio modules in the same Raspberry Pi. In another page we will discuss other situations.<br />
<br />
A typical invokation of odr-audioenc looks like:<br />
<br />
$ odr-audioenc -v http://server-66.stream-server.nl:8852 -C 200 -b 64 -o tcp://localhost:59000 -D -L --audio-resampler=samplerate -L --src-converter-type=1 -l -V<br />
<br />
(all typed on one line, don't press ENTER in between !) Let's look in more detail to each of the options:<br />
<br />
-v http://server-66.stream-server.nl:8852 is the source of the audio. In this case it is a stream from the Internet that will be handled by the VLC input. Audio-enc can include a library from the well-known VLC player, such that all its features are available !<br />
-C 200 this specifes the VLC cache lenght<br />
-b 64 tells the encoder to encode at a bitrate of 64 kilobits per seconds<br />
-o tcp://localhost:59000<br />
where the output signal should go. In this case it is made available on port 59000 of the 'localhost', which means this computer (Raspberry Pi) ODR_DabMux will reference this port and pick up the signal.<br />
D Drift compensation. There is always some difference between the clock signal of the audio encoder of e.g. the incoming stream and the output clock signal (crystals always have a small deviation, and with many stations sharing a single DAB multiplex some drift compensation is necessary). See also the explanation in the help information for odr-audioenc.<br />
-L --audio-resampler=samplerate -L --src-converter-type=1 these are options for the VLC library, informing it should use the 'samplerate' resampler and use the best quality available<br />
-l this will show a display of the input signal like a VU meter<br />
-V this will provide some detail about what the program is doing<br />
<br />
If you run the program with the command line as shown above you will see it provides some information on what it is doing and a display showing the volume of the audio signal.<br />
<br />
Leave this program running while we start for a look at the ODR-DabMux program.</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Install_the_OpenDigitalRadio_softwareRaspDAB/Install the OpenDigitalRadio software2017-07-02T16:23:53Z<p>Glokhoff: Created page with "After you have logged in as the new user (let's assume ' odr'), it is time to install the OpenDigitalRadio software. As the modulation of the DAB signal will be performed by ..."</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>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Some_steps_to_increase_security_and_create_a_new_userRaspDAB/Some steps to increase security and create a new user2017-07-02T16:21:38Z<p>Glokhoff: Created page with "Once you have installed Raspbian you should make some changes to the settings of the Raspberry Pi. So go to the applications main menu by clicking on the raspberry in the uppe..."</p>
<hr />
<div>Once you have installed Raspbian you should make some changes to the settings of the Raspberry Pi. So go to the applications main menu by clicking on the raspberry in the upper left, select 'Preferences' and go to the Raspberry Pi configuration program.<br />
<br />
In the 'System' tab you should increase the file system - if not already done -, so all available empty space on the SD card can be used for the file system. You should also change the password for the default user 'pi'. This is by default 'raspberry', which is well known, so at least you should change this as a first security measure (and be sure to remember it, so please note it somehow). You can set a hostname, which is easy to recognize the unit in a network. Normally one would start with the desktop, but de-select automatic login as user 'pi'. I selected 'wait for network' during start up, as I want to make sure the network is up and stable before the DAB software starts. Set the remaining items on the tab to your liking.<br />
<br />
On the 'Interfaces' tab I only enabled the VNC interface, such that it is possible to control the system remotely using a VNC viewer.<br />
<br />
Finally, set all items on the 'Localization' tab to their correct value. Especially the time setting will be used to copy the time to the DAB signal. You will have to reboot to activate these settings.<br />
<br />
If you want, you can add or remove certain programs from the main menu using the main menu editor in the preferences category. This will e.g. enable you to install a graphical software packet update program.<br />
<br />
== Some checks ==<br />
<br />
Now select the add/remove software program, and check that git and gcc (GNU C Compiler) are installed, by entering these names and wait until you see a checkmark to confirm.<br />
<br />
In most cases it is convenient to set the IP address of the interface you use (the Ethernet cable is preferred, for reason of stability - in that case disable the Wifi) to a fixed one, so EasyDAB can later find it easily. You can access the settings menu by right clicking on the 2 arrows or Wifi symbol in the upper right corner.<br />
<br />
UPDATE: Since apparently Raspbian has been updated, it seems you might get a message that the file /etc/dhcpcd.conf cannot be saved. You may want to check http://elinux.org/RPi_Setting_up_a_static_IP_in_Debian . Or https://www.modmypi.com/blog/how-to-give-your-raspberry-pi-a-static-ip-address-update<br />
<br />
You may want to disable WiFi and Bluetooth altogether for an installation that is to run reliably. This can be done by adding overlays to the /boot/config.txt file, such as<br />
<br />
dtoverlay=pi3-disable-bt<br />
dtoverlay=pi3-disable-wifi<br />
<br />
See https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README<br />
<br />
If you have a small display you may also prefer to remove the mathematica and wolfram startup icons in the taskbar. You can access the taskbar settings menu by right clicking on the taskbar.<br />
<br />
== Adding a new user ==<br />
<br />
Next we are going to add a new user so the DAB software doesn't run under the default user account. Open a terminal console window by double clicking on the black rectangular icon with the prompt symbol >_ in the upper left corner. You will see the user name and computer name (pi@raspberrypi), an indication of the current directory (~ , meaning the user's home directory) and the dollar sign. We will use the $ sign also in this guide to indicate command you have to type (so don't type the first $ sign itself, just what is shown after it).<br />
<br />
To add the new user type<br />
<br />
$ sudo adduser USERID<br />
<br />
Instead of USERID you just type any name for the new user you can think of. Make it something you can remember easily, but shouldn't be too obvious so it is difficult to guess. In the examples here we use 'odr' as it is also used in many scripts and other documentation, but for security you better use something else. You will have to provide a new password for the new user account. Don't make it the same as for the user 'pi' ! Some user details can be provided as well, but this is not mandatory.<br />
<br />
Next we need to ensure the new user can also run commands as superuser. This is done by editing the file /etc/sudoers using the visudo program:<br />
<br />
$ sudo visudo -f /etc/sudoers<br />
<br />
This opens a simple text editor that can be used to change the file. You will have to scroll down to the line under the line<br />
<br />
root All=(ALL:ALL) ALL<br />
<br />
Add a similar line but change 'root' into the USERID you have chosen. Save the change by pressing CTRL and O ("CTRL+O") simultaneously, confirm the filename by pressing ENTER and exit the editor using CTRL+X .<br />
<br />
Next it is time to reboot and log in as the new user, and install the OpendigitalRadio software.</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/Install_Raspbian_on_the_SD_cardRaspDAB/Install Raspbian on the SD card2017-07-02T16:18:21Z<p>Glokhoff: Created page with "The first thing to do is to format the SD card and install the Raspbian operating system for your Raspberry Pi. == Installation with NOOBS == Visit https://www.raspberrypi.o..."</p>
<hr />
<div>The first thing to do is to format the SD card and install the Raspbian operating system for your Raspberry Pi.<br />
<br />
== Installation with NOOBS ==<br />
<br />
Visit https://www.raspberrypi.org/downloads/noobs/ to learn how to install RaspBian using NOOBS. Be sure to read the software installation guide and video, as this will tell you how to prepare the SD card and get the NOOBS software on it. As I connected the Raspberry Pi to the Internet using an Ethernet cable, I decided to use NOOBS Lite, and download the Raspbian files during installation. If you want to prepare more than one SD card, you might want to save some time by downloading NOOBS with Raspbian included only once.<br />
<br />
== Installation using Raspbian light ==<br />
<br />
It may also be possible to get a system working based on Raspbian Light ( see https://www.raspberrypi.org/downloads/raspbian/ ) and only download the necessary software packages, but I didn't try that yet. Any information on this is appreciated !</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:16:12Z<p>Glokhoff: </p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the [[RaspDAB Requirements]] whether you have everything you need<br />
# [[Install Raspbian on the SD card]]<br />
# [[Some steps to increase security and create a new user]]<br />
# [[Install the OpenDigitalRadio software]]<br />
# [[Get ODR-AudioEnc to operate]]<br />
# [[Use ODR-DabMux to generate the multiplex]]<br />
# [[Go on air with the EasyDab board]]<br />
# [[Add Program Associated Data with ODR-PadEnc]]<br />
# [[Automate operation with Supervisor]]<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: the RaspDAB contribution chain<br />
* Xtra 2: the RaspDAB transmitter<br />
<br />
NOTE: this description is derived from https://github.com/glokhoff/RaspDAB , which will have the latest version. Please post comments or questions using the Github Issues reporting system - G. Lokhoff</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDAB/RequirementsRaspDAB/Requirements2017-07-02T16:15:16Z<p>Glokhoff: Created page with " Apart from some imagination, creativity and basic knowledge on how to use command line linux what is required for this project: * A Raspberry Pi 3 model B (might work on Ra..."</p>
<hr />
<div><br />
<br />
Apart from some imagination, creativity and basic knowledge on how to use command line linux what is required for this project:<br />
<br />
* A Raspberry Pi 3 model B (might work on Raspberry Pi 2 model B as well, but not yet tested)<br />
* An micro SD memory card to install the software for your Raspberry Pi on. 8 GB should just be enough.<br />
* An EasyDAB v2 board, preferably with the latest firmware (at least version 10.10.2016)<br />
* A router and some UTP cables (just to create a subnet on which to test the set up)<br />
* A small vertical antenna, of about 36 cm length (don't run the EasyDAB board without it !)<br />
* A USB keyboard and mouse, plus a monitor with HDMI input (perhaps your TV ?) to connect to the Raspberry Pi<br />
* An Internet connection, so you can get on line<br />
<br />
And some time and persistance, for when things don't work as you supposed they would ;o)</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:13:29Z<p>Glokhoff: </p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the [[RaspDAB Requirements]] whether you have everything you need<br />
# Install Raspbian on the SD card<br />
# Some steps to increase security and create a new user<br />
# Install the OpenDigitalRadio software<br />
# Get ODR-AudioEnc to operate<br />
# Use ODR-DabMux to generate the multiplex<br />
# Go on air with the EasyDab board<br />
# Add Program Associated Data with ODR-PadEnc<br />
# Automate operation with Supervisor<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: the RaspDAB contribution chain<br />
* Xtra 2: the RaspDAB transmitter<br />
<br />
NOTE: this description is derived from https://github.com/glokhoff/RaspDAB , which will have the latest version. Please post comments or questions using the Github Issues reporting system - G. Lokhoff</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:12:01Z<p>Glokhoff: Start page of the RaspDAB description</p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
As I'm not that experienced using Linux there were some unexpected hurdles that I needed to overcome. It might just help others to document how it was done, so it is easier for them.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the [[RaspDAB Requirements]] whether you have everything you need<br />
# Install Raspbian on the SD card<br />
# Some steps to increase security and create a new user<br />
# Install the OpenDigitalRadio software<br />
# Get ODR-AudioEnc to operate<br />
# Use ODR-DabMux to generate the multiplex<br />
# Go on air with the EasyDab board<br />
# Add Program Associated Data with ODR-PadEnc<br />
# Automate operation with Supervisor<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: the RaspDAB contribution chain<br />
* Xtra 2: the RaspDAB transmitter<br />
<br />
NOTE: this description is derived from https://github.com/glokhoff/RaspDAB , which willhave the latest version. Please post comments or questions using the Github Issues reporting system - G. Lokhoff</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:08:42Z<p>Glokhoff: </p>
<hr />
<div>A practical guide for an ODR-mmbtools automated DAB+ micro transmitter using Raspberry Pi and EasyDab v2. May also be useful for other Linux based installations.<br />
<br />
Nowadays to transmit a DAB+ ensemble requires little more than<br />
<br />
* the OpenDigitalRadio mmbtools software<br />
* a Raspberry Pi, and<br />
* an EasyDAB v2 board<br />
<br />
This project aims to provide documentation how to build such a 'micro transmitter' which could be used as the starting point for a low cost DAB+ transmitter for e.g. local radio. It is based on experience from building a system, starting from getting the Raspbian operating system installed, installing the OpenDigitalRadio programs required, configuring and using these, installing supervisor to enable automatic start up and configuring and using the EasyDAB v2 DAB modulator board.<br />
<br />
As I'm not that experienced using Linux there were some unexpected hurdles that I needed to overcome. It might just help others to document how it was done, so it is easier for them.<br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the Requirements whether you have everything you need<br />
# Install Raspbian on the SD card<br />
# Some steps to increase security and create a new user<br />
# Install the OpenDigitalRadio software<br />
# Get ODR-AudioEnc to operate<br />
# Use ODR-DabMux to generate the multiplex<br />
# Go on air with the EasyDab board<br />
# Add Program Associated Data with ODR-PadEnc<br />
# Automate operation with Supervisor<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: the RaspDAB contribution chain<br />
* Xtra 2: the RaspDAB transmitter</div>Glokhoffhttps://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-02T16:07:41Z<p>Glokhoff: Start page of the RaspDAB description</p>
<hr />
<div><br />
<br />
Here's the run down of the steps to take:<br />
<br />
# Check the Requirements whether you have everything you need<br />
# Install Raspbian on the SD card<br />
# Some steps to increase security and create a new user<br />
# Install the OpenDigitalRadio software<br />
# Get ODR-AudioEnc to operate<br />
# Use ODR-DabMux to generate the multiplex<br />
# Go on air with the EasyDab board<br />
# Add Program Associated Data with ODR-PadEnc<br />
# Automate operation with Supervisor<br />
<br />
And some extra's to help you set up an actual local DAB ensemble:<br />
<br />
* Xtra 1: the RaspDAB contribution chain<br />
* Xtra 2: the RaspDAB transmitter</div>Glokhoffhttps://wiki.opendigitalradio.org/Main_PageMain Page2017-07-02T15:54:45Z<p>Glokhoff: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
<div style="font-size:282%">Opendigitalradio.org</div><br />
<br />
<br />
<P><br />
<br />
<BIG><br />
Open techniques for Digital Radio Broadcasting<br />
</BIG><br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="width:100%; border:1px solid #ddcef2; background:#faf5ff; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#faf5ff; color:#000"<br />
! <h2 style="margin:0; background:#ddcef2; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Background</h2><br />
|-<br />
|style="color:#000;"|<br />
Open digital broadcasting techniques based on software defined radio. Digital radio transmission and development must also become democratized for experimenters and small broadcasters. Opendigitalradio.org wiki is about creating a community for documenting and exchanging experimentations and gather information about existing small-scale DAB projects. Please read [[Introduction]] for more information.<br />
'''[[Association Opendigitalradio|Opendigitalradio is a non-profit association based in Switzerland]]''' (page in french), offering also a broadcast infrastructure for temporary radio stations.<br />
<br />
This wiki is also the home of the '''ODR-mmbTools''', the continuation of the CRC-mmbTools from [http://mmbtools.crc.ca CRC]. Please see [[Introduction on DAB/DAB+]]<br />
<br />
Have a look at the [http://opendigitalradio.github.io/mmbtools-doc/mmbtools.pdf guide]<br />
<br />
<br />
[[News|Older news]]<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="border:1px solid #cef2e0; background:#f5fffa; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5fffa; color:#000"<br />
! <h2 style="margin:0; background:#cef2e0; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">DAB/DAB+ transmission</h2><br />
|-<br />
|style="color:#000;"|<br />
[[Image:Logo mmb.png|right]]<br />
*[[Introduction on DAB/DAB+]]<br />
*[[DAB/DAB+ encoding]]: MPEG Layer II or HE-AAC encoding, slideshow encoding<br />
*[[DAB multiplexing]]: putting together DAB/DAB+/DMB programs<br />
*[[DAB modulation]]: create the baseband COFDM modulation<br />
*[[DAB hardware]]: software radio peripheral, filtering, amplification<br />
|-<br />
|}<br />
<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5fffa; color:#000"<br />
! <h2 style="margin:0; background:#cef2e0; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Real cases, examples</h2><br />
|-<br />
|style="color:#000;"|<br />
<br />
The ODR-mmbTools are used in several real-world 24/7 broadcasts, as shown on http://www.opendigitalradio.org/software<br />
A recipe for a low cost DAB transmission chain for local broadcasts based on the ODR-mmbTools is the [[RaspDAB]] description.<br />
<br />
Older presentations:<br />
*[http://www.slideshare.net/radioradioradio/local-dab-broadcasting Presentation] and [[WorldDMB GA 2010 Open DAB demonstration|demonstration]] of the full open source DAB transmission solution at 2010 WorldDMB General Assembly in Belfast<br />
*[[First licensed open dab transmission]] for Label Suisse Festival 17-19 September 2010 Lausanne.<br />
*[[Demonstration of open source digital transmission chain at IBC]], Stand 10.D21 (EBU), 10-14 September 2010<br />
*[[DAB scripts examples]]<br />
*[[Installer scripts]] for '''Debian'''<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="border:1px solid #f2e0ce; background:#fffaf5; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#fffaf5; color:#000"<br />
! <h2 style="margin:0; background:#f2e0ce; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Other digital systems, transmission and reception</h2><br />
|-<br />
|style="color:#000;"|<br />
*[[DAB reception]] (Openmokast and others)<br />
*[[DAB measurement]] (measurement&monitoring tools, planning tools).<br />
*[[DRM/DRM+ Digital Radio Mondiale]], digital radio system for AM bands (LW, MW and SW) and all VHF bands (FM band and others). <br />
*[[FM RDS transmission]] (not really a digital system except RDS ;)<br />
*[[Crazy techniques using a VGA card as radio peripheral]]<br />
*[[Coverage planning]]<br />
|-<br />
|}<br />
|}<br />
<br />
{| style="width:100%; border-spacing:8px; margin:-8px -8px;"<br />
|class="MainPageBG" style="width:100%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; color:#000;"|<br />
{| cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; color:#000"<br />
! <h2 style="margin:0; background:#cedff2; font-size:120%; font-weight:bold; border:1px solid #afa3bf; text-align:left; color:#000; padding:0.2em 0.4em;">Contacts</h2><br />
|-<br />
|style="color:#000;"|<br />
Please use the crc-mmbtools mailing list to reach us. Subscribe by sending an email to '''crc-mmbtools+subscribe@googlegroups.com'''<br />
Follow us on '''Twitter''': http://twitter.com/opendigiradio to get informed, involved or for any questions. Find us [http://www.facebook.com/opendigitalradio also on '''Facebook''']<br />
<br />
Email: broadcast at opendigitalradio.org<br />
|-<br />
|}<br />
|}</div>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T18:50:53Z<p>Glokhoff: </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 developped 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>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T18:50:20Z<p>Glokhoff: </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 developped 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 all direction 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>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T17:08:03Z<p>Glokhoff: </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 developped 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 />
The limitation is that the antenna directivity diagram cannot be included, but for all direction transmissions this is quite handy. It appears to be based on the [http://www.ve2dbe.com/english1.html Radio Mobile website by Roger Coudé] .<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>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T17:07:45Z<p>Glokhoff: </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 developped 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 Radio Mobile website. The limitation is that the antenna directivity diagram cannot be included, but for all direction transmissions this is quite handy. It appears to be based on the [http://www.ve2dbe.com/english1.html Radio Mobile website by Roger Coudé] .<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>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T17:07:26Z<p>Glokhoff: </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 developped 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 Radio Mobile website. The limitation is that the antenna directivity diagram cannot be included, but for all direction transmissions this is quite handy. It appears to be based on the *[http://www.ve2dbe.com/english1.html Radio Mobile website by Roger Coudé] .<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>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T17:03:41Z<p>Glokhoff: Adding the source of the Nautel coverage planning</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 developped 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 Radio Mobile website. The limitation is that the antenna directivity diagram cannot be included, but for all direction transmissions this is quite handy.<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>Glokhoffhttps://wiki.opendigitalradio.org/Coverage_planningCoverage planning2017-05-26T16:20:25Z<p>Glokhoff: Addition of some useful coverage prediction websites</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 developped 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 />
The limitation is that the antenna directivity diagram cannot be included, but for all direction transmissions this is quite handy.<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>Glokhoffhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2017-05-19T05:13:29Z<p>Glokhoff: /* Known receiver issues */</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 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 these 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 to annotate 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 />
! Codec<br />
! Sample rate [kHz]<br />
! Frame length [ms]<br />
! Interval [ms]<br />
|-<br />
| MP2<br />
| 48<br />
| 24<br />
| 1200<br />
|-<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| 2400<br />
|-<br />
| AAC-LC<br />
| 48<br />
| 20<br />
| 1000<br />
|-<br />
| AAC-LC<br />
| 32<br />
| 30<br />
| 1500<br />
|-<br />
| HE-AAC<br />
| 48<br />
| 40<br />
| 2000<br />
|-<br />
| HE-AAC<br />
| 32<br />
| 60<br />
| 3000<br />
|}<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 />
== 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. As this does not allow flow control, the odr-padenc cannot take advantage of the complete available PAD bandwidth. There is an ongoing development to achieve [[bidirectional PAD communication protocol]] is established.<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 />
== 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 />
== 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>Glokhoffhttps://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2017-05-19T05:12:47Z<p>Glokhoff: /* Known receiver issues */</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 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 these 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 to annotate 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 />
! Codec<br />
! Sample rate [kHz]<br />
! Frame length [ms]<br />
! Interval [ms]<br />
|-<br />
| MP2<br />
| 48<br />
| 24<br />
| 1200<br />
|-<br />
| MP2 LSF<br />
| 24<br />
| 48<br />
| 2400<br />
|-<br />
| AAC-LC<br />
| 48<br />
| 20<br />
| 1000<br />
|-<br />
| AAC-LC<br />
| 32<br />
| 30<br />
| 1500<br />
|-<br />
| HE-AAC<br />
| 48<br />
| 40<br />
| 2000<br />
|-<br />
| HE-AAC<br />
| 32<br />
| 60<br />
| 3000<br />
|}<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 />
== 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. As this does not allow flow control, the odr-padenc cannot take advantage of the complete available PAD bandwidth. There is an ongoing development to achieve [[bidirectional PAD communication protocol]] is established.<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 />
== 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 />
== 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 />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Glokhoff