http://wiki.opendigitalradio.org/api.php?action=feedcontributions&user=Hb9egm&feedformat=atomOpendigitalradio - User contributions [en]2024-03-29T15:56:48ZUser contributionsMediaWiki 1.19.20+dfsg-0+deb7u3http://wiki.opendigitalradio.org/Installer_scriptsInstaller scripts2022-10-18T13:23:05Z<p>Hb9egm: Replace my old script by dab-scripts</p>
<hr />
<div>==Install scripts for Debian ==<br />
<br />
The repository [https://github.com/opendigitalradio/dab-scripts dab-scripts] makes it easy to install, configure and operate the ODR-mmbTools on a debian system.<br />
<br />
Comments/suggestions are welcome ([https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools google group] -or- [https://github.com/opendigitalradio/dab-scripts/issues GitHub issues])</div>Hb9egmhttp://wiki.opendigitalradio.org/SNMPSNMP2022-01-21T10:38:35Z<p>Hb9egm: Mention SNMP has stalled</p>
<hr />
<div>Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436'''<br />
<br />
OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)<br />
<br />
The '''goal of the Project SNMP''' is to make the monitoring statistics available through SNMP.<br />
<br />
Update January 2022: It is such a pleasure to work with SNMP that this effort has stalled.<br />
<br />
==Steps==<br />
<br />
; Understand how to represent our monitoring values in a MIB<br />
: List what by whan to monitor and define keyword<br />
<br />
; Define a MIB structure and write a MIB<br />
: The best pratice seem to have 1 MIB by product/software and reserve one sub-level for each<br />
: 51436.1 for ODR-DabMux<br />
: 51436.2 for ODR-DabMod<br />
: 51436.3 for ODR-AudioEnc<br />
: 51436.4 for ODR-PadEnc<br />
<br />
; As every tool can be run more than once on a machine, all of them need to start with a table.<br />
<br />
; Understand how to interface with snmpd and write scripts to connect the mmbTools with snmpd<br />
<br />
==Things to monitor==<br />
<br />
Things to monitor for the ODR-mmbTools:<br />
<br />
* ODR-PadEnc<br />
** Nothing<br />
* ODR-AudioEnc<br />
** Nothing. Audio levels are available through ODR-DabMux<br />
* ODR-DabMux<br />
** Seconds until expiry of TAI bulletin<br />
** For each ZMQ input:<br />
*** state (0 Unknown, 1 NoData, 2 Unstable, 3 Silent, 4 Streaming)<br />
*** min buffer<br />
*** max buffer<br />
*** number of ZMQ underruns (overflows at 2^32 - 1)<br />
*** number of ZMQ overruns (overflows at 2^32 - 1)<br />
*** audio level peak, left channel<br />
*** audio level peak, right channel<br />
** We could add the number of frames encoded, to detect a stuck multiplexer (To be discussed)<br />
* ODR-DabMod<br />
** one set of values for CFR<br />
*** Percentage of samples clipped<br />
*** Percentage of errors clipped<br />
*** MER after CFR<br />
*** PAPR before CFR<br />
*** PAPR after CFR<br />
** The configured TIST offset<br />
** The current TIST value<br />
** To be added: The TIST value of the frame FCT=0<br />
** one set of values for SDR device<br />
*** Number of underruns<br />
*** Number of late packets<br />
*** Number of frames transmitted</div>Hb9egmhttp://wiki.opendigitalradio.org/FDK-AAC-DABplusFDK-AAC-DABplus2022-01-21T10:37:25Z<p>Hb9egm: </p>
<hr />
<div>'''FDK-AAC-DABplus''' contains a DAB and a DAB+ encoder, which has been '''deprecated''' in favour of [[ODR-AudioEnc]], which now integrates the codec in the same repository.<br />
<br />
In september 2016, FDK-AAC-DABplus was split in three: ODR-AudioEnc, fdk-aac and ODR-PadEnc, for ease of maintainability and packaging, to clarify the licence situation a bit, and in the hope that the DAB+ modification to fdk-aac could be given upstream. This is unlikely to happen, and since ODR-AudioEnc is the only tool requiring the DAB+-capable fdk-aac, the codec was moved back into ODR-AudioEnc to simplify compilation and installation.<br />
<br />
<br />
----<br />
<br />
<br />
The DAB encoder is derived from libtoolame-dab. toolame-02l has been converted to a shared library libtoolame-dab.<br />
<br />
The DAB+ encoder is derived from the Fraunhofer FDK AAC code from Android, patched for 960-transform and proper header and firecode.<br />
<br />
The main tool is '''dabplus-enc''', which can encode from a file or pipe source, all inputs supported by libVLC or an ALSA soundcard, and encode to a ZeroMQ output compatible with [[ODR-DabMux]], to a file or to standard output. The VLC ALSA input supports experimental '''sound card clock drift compensation''', that can compensate for imprecise sound card clocks.<br />
<br />
To encode DLS and Slideshow data, '''[[ODR-PadEnc]]''' reads images from a folder and DLS text from a file, and generates the PAD data for the encoder.<br />
<br />
For detailed usage, see the usage screen of the different tools.<br />
<br />
<br />
Its development is public : http://github.com/Opendigitalradio/fdk-aac-dabplus<br />
<br />
== Installation ==<br />
===Prerequisites===<br />
<br />
The FDK-AAC-DABplus package depends on libfec, boost-thread, boost-system, alsa and ZeroMQ.<br />
For instructions on how to install these, please see [[ODR-DabMux#Prerequisites]]<br />
<br />
The [[mot-encoder]] optionally needs ImageMagick's magick_wand to be able to resize pictures.<br />
<br />
===Building===<br />
<br />
See https://github.com/Opendigitalradio/fdk-aac-dabplus#how-to-build<br />
<br />
==Usage==<br />
<br />
Several usage scenarios are shown in<br />
https://github.com/Opendigitalradio/fdk-aac-dabplus#how-to-use<br />
<br />
===Problem solving===<br />
<br />
In the case you are using '''ZeroMQ between the encoder and odr-dabmux''', and you see errors that the size of the data is wrong, then the configured bitrate in the mux probably doesn't correspond to the bitrate given to the encoder. Make sure they are identical.<br />
<br />
If you are using a '''pipe between the encoder and odr-dabmux''', and you see a lot of errors like this:<br />
<2> ERROR: Incomplete DAB+ frame! 136 != 360<br />
<5> reach end of file -> rewinding<br />
<2> ERROR: Can't rewind file<br />
<6> ETI frame number: 228<br />
<br />
Then the stream has to be buffered before giving it to muxer, this additional buffer installed between encoder and fifo. To calculate proper block size for mbuffer ("-s" parameter), the table below may be used:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
!DAB+ Stream bitrate, kbps<br />
!Block size, bytes<br />
|-<br />
|16<br />
|240<br />
|-<br />
|24<br />
|360<br />
|-<br />
|32<br />
|480<br />
|-<br />
|48<br />
|720<br />
|-<br />
|56<br />
|840<br />
|-<br />
|64<br />
|960<br />
|-<br />
|72<br />
|1080<br />
|-<br />
|128<br />
|1920<br />
|-<br />
|160<br />
|2400 <br />
|}<br />
<br />
In example above, for stream with bitrate 24 kbps, mbuffer size set to 360 bytes. This trick helping to solve problem.<br />
<br />
==Historical notes==<br />
<br />
The encoders were renamed at version 0.2.0. The aac-enc testing program disappeared, but its code is still in src/.<br />
The aac-enc-dabplus and aac-enc-dabplus-zmq were renamed to dabplus-enc-file and dabplus-enc-file-zmq. dabplus-enc-alsa-zmq appeared in v0.2.0.<br />
<br />
In v0.2.2, dabplus-enc-file-zmq received support for output to file and pipe, making dabplus-enc-file obsolete, which has therefore been removed.<br />
<br />
In v0.4.0, lots of code redundancy between different encoder variants has been merged into '''dabplus-enc'''. The old tools '''dabplus-enc-file-zmq''', '''dabplus-enc-alsa-zmq''' and all this have been replaced by a single encoder.<br />
<br />
Some of the ''encode-'' scripts available in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux repository] might still make use of the old names.</div>Hb9egmhttp://wiki.opendigitalradio.org/DAB_scripts_examplesDAB scripts examples2022-01-21T10:35:24Z<p>Hb9egm: mention zmq is old</p>
<hr />
<div>==Scripts with ZeroMQ based communication between encoders and mux==<br />
<br />
This was the preferred interface until EDI was implemented in ODR-AudioEnc and ODR-DabMux. Many examples used this, for instance the example site configuration in the [[dab-scripts]] repository.<br />
<br />
More examples of scripts and configuration files are in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux repository] on github.<br />
<br />
==Scripts for fifo based communication==<br />
<br />
Before the custom ZeroMQ-based protocol, the tools were connected using fifos.<br />
<br />
*'''[[First_licensed_open_dab_transmission#Scripts|8 channel DAB transmission using Jack]]'''<br />
*[[WorldDMB_GA_2010_Open_DAB_demonstration#Scripts|4 channels DAB transmission]] with 3 internet stations and laptop microphone.<br />
<br />
Old scripts<br />
*[[Example of live re-transmission on DAB of an Internet Radio radio station]]<br />
*'''[[Example of live re-broadcasting on DAB of many Internet radio stations]]'''<br />
*[[Example of the creation of a multiplex stream of 2 DAB stations]]<br />
*[[Example of the creation of a DAB+ transmission]]<br />
<br />
===CRC Live CD===<br />
<br />
*[[How to install latest version of gnuradio with CRC MMBtools live CD]]</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-AudioEncODR-AudioEnc2020-09-23T08:23:22Z<p>Hb9egm: </p>
<hr />
<div>'''ODR-AudioEnc''' is a DAB and a DAB+ encoder, replacing [[Toolame-DAB]] and [[FDK-AAC-DABplus]] respectively.<br />
<br />
The DAB encoder is derived from libtoolame-dab. toolame-02l has been converted to a shared library libtoolame-dab.<br />
<br />
The DAB+ encoder is using the fdk-aac library the Fraunhofer FDK AAC code from Android, patched for 960-transform and proper header and firecode.<br />
<br />
The main tool is '''odr-audioenc''', which can encode from a file or pipe source, all inputs supported by libVLC or an ALSA soundcard, and encode to a ZeroMQ output compatible with [[ODR-DabMux]], to a file or to standard output. The VLC ALSA input supports experimental '''sound card clock drift compensation''', that can compensate for imprecise sound card clocks.<br />
<br />
'''DAB MOT Slideshow and DLS''' support is possible thanks to [[ODR-PadEnc]]. <br />
<br />
ODR-AudioEnc v2 and earlier are compatible with ODR-PadEnc v2. ODR-AudioEnc v3 is compatible with ODR-PadEnc v3.<br />
<br />
For detailed usage, see the usage screen of the different tools.<br />
<br />
<br />
Its development is public : http://github.com/Opendigitalradio/ODR-AudioEnc and releases are available as git tags. The git master branch always points to the latest release, the next branch is where development happens. <br />
<br />
== Installation ==<br />
===Prerequisites===<br />
<br />
The ODR-AudioEnc package depends on libfec, boost-thread, boost-system, alsa and ZeroMQ.<br />
For instructions on how to install these, please see [[ODR-DabMux#Prerequisites]]<br />
<br />
The [[mot-encoder]] optionally needs ImageMagick's magick_wand to be able to resize pictures.<br />
<br />
===Building===<br />
<br />
See https://github.com/Opendigitalradio/ODR-AudioEnc#how-to-build<br />
<br />
==Usage==<br />
<br />
Several usage scenarios are shown in<br />
https://github.com/Opendigitalradio/ODR-AudioEnc#how-to-use<br />
<br />
===Problem solving===<br />
<br />
In the case you are using '''ZeroMQ between the encoder and odr-dabmux''', and you see errors that the size of the data is wrong, then the configured bitrate in the mux probably doesn't correspond to the bitrate given to the encoder. Make sure they are identical.<br />
<br />
If you are using a '''pipe between the encoder and odr-dabmux''', and you see a lot of errors like this:<br />
<2> ERROR: Incomplete DAB+ frame! 136 != 360<br />
<5> reach end of file -> rewinding<br />
<2> ERROR: Can't rewind file<br />
<6> ETI frame number: 228<br />
<br />
Then the stream has to be buffered before giving it to muxer, this additional buffer installed between encoder and fifo. To calculate proper block size for mbuffer ("-s" parameter), the table below may be used:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
!DAB+ Stream bitrate, kbps<br />
!Block size, bytes<br />
|-<br />
|16<br />
|240<br />
|-<br />
|24<br />
|360<br />
|-<br />
|32<br />
|480<br />
|-<br />
|48<br />
|720<br />
|-<br />
|56<br />
|840<br />
|-<br />
|64<br />
|960<br />
|-<br />
|72<br />
|1080<br />
|-<br />
|128<br />
|1920<br />
|-<br />
|160<br />
|2400 <br />
|}<br />
<br />
In example above, for stream with bitrate 24 kbps, mbuffer size set to 360 bytes. This trick helping to solve problem.<br />
<br />
==Historical notes==<br />
<br />
v3.0.0 is a breaking change because the communication with ODR-PadEnc was replaced by a socket.<br />
<br />
The encoders were renamed at version 0.2.0. The aac-enc testing program disappeared, but its code is still in src/.<br />
The aac-enc-dabplus and aac-enc-dabplus-zmq were renamed to dabplus-enc-file and dabplus-enc-file-zmq. dabplus-enc-alsa-zmq appeared in v0.2.0.<br />
<br />
In v0.2.2, dabplus-enc-file-zmq received support for output to file and pipe, making dabplus-enc-file obsolete, which has therefore been removed.<br />
<br />
In v0.4.0, lots of code redundancy between different encoder variants has been merged into '''dabplus-enc'''. The old tools '''dabplus-enc-file-zmq''', '''dabplus-enc-alsa-zmq''' and all this has been replaced by a single encoder.<br />
<br />
Some of the ''encode-'' scripts available in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux repository] might still make use of the old names.<br />
<br />
In September 2016, FDK-AAC-DABplus was split in three: ODR-AudioEnc, fdk-aac and ODR-PadEnc, for ease of maintainability and packaging, to clarify the licence situation a bit, and in the hope that the DAB+ modification to fdk-aac could be given upstream.</div>Hb9egmhttp://wiki.opendigitalradio.org/Bidirectional_PAD_communication_protocolBidirectional PAD communication protocol2020-09-23T08:21:22Z<p>Hb9egm: </p>
<hr />
<div>The communication between [[ODR-PadEnc]] and [[ODR-AudioEnc]] was done using a nonblocking FIFO until ODR-PadEnc v3, and was subsequently replaced by a unix domain datagram socket.<br />
<br />
The implementations are in https://github.com/Opendigitalradio/ODR-PadEnc/blob/master/src/pad_interface.cpp and https://github.com/Opendigitalradio/ODR-AudioEnc/blob/master/src/PadInterface.cpp</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-09-23T08:19:11Z<p>Hb9egm: /* Communication with audio encoder */</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 />
==== 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>Hb9egmhttp://wiki.opendigitalradio.org/ODR-PadEncODR-PadEnc2020-09-23T08:15:12Z<p>Hb9egm: Explain version 3</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 />
==== 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 with audio encoder ==<br />
The communication of the odr-padenc with the audio encoder is currently done via a FIFO and therefore unidirectional. It has been considered to use a [[bidirectional PAD communication protocol]] to make use of flow control, to take advantage of the complete available PAD bandwidth, but later, the uniform mode has been introduced instead, for backwards compatibility reasons.<br />
<br />
=== Protocol ===<br />
The current protocol is in use since commits 5c6b9fb (fdk-aac-dabplus) and 182d08c (toolame-dab).<br />
On odr-padenc's side, each write to the FIFO consists of (padlen + 1) bytes, divided into the following components (all widths in bytes):<br />
+--------------+---------+-------+--------------+<br />
| zero padding | X-PAD | F-PAD | used PAD len |<br />
+--------------+---------+-------+--------------+<br />
| padlen | 1 |<br />
| <used PAD len> |<br />
X-PAD and F-PAD must already be in the reversed transmission byte order. The unused part at the beginning must be filled up with zeros and is ignored by the audio encoder. The unused PAD bytes within the audio frame result in additional bytes available to audio data.<br />
<br />
== Usage of DL Plus ==<br />
To enable the transmission of DL Plus, the DLS text file has to contain a parameter block at its very beginning - the plain DL text must follow after it. Thus all parameters are surrounded by a pair of opening/closing tags. Within the parameter block, comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
##### parameters { #####<br />
<br />
# nothing happens in here; this is just a comment line<br />
<br />
##### parameters } #####<br />
Just a label<br />
As in the above example, the parameters block does not contain any parameters, it has the same effect as if the DLS text file contained just the plain label.<br />
<br />
To enable DL Plus in the first place, the setting <code>DL_PLUS=1</code> is used. If this line is not present, DL Plus is disabled and all further DL Plus related parameters do not affect the odr-padenc behaviour. As no tag is specified here, one DUMMY tag is used (DL Plus transmissions must consist of at least one tag).<br />
##### parameters { #####<br />
DL_PLUS=1<br />
##### parameters } #####<br />
Just a label<br />
<br />
To add DL Plus tags, one parameter line per tag has to be used, which contains content type, start marker and length marker - one-after-another and separated by a single space. Please note that the value of the start/length markers is specified in terms of characters - not bytes! '''Also note that the length marker is the length minus one, as it is defined by the spec as "the number of characters following the first character".'''<br />
##### parameters { #####<br />
DL_PLUS=1<br />
# this tags "Michael Jackson" as ITEM.ARTIST<br />
DL_PLUS_TAG=4 5 14<br />
# this tags "Thriller" as ITEM.TITLE<br />
DL_PLUS_TAG=1 23 7<br />
##### parameters } #####<br />
Now: Michael Jackson - Thriller<br />
<br />
Furthermore, the values of the <code>Item Toggle</code> and <code>Item Running</code> fields can be set. If there is no value for any of these two fields set, it remains 0. According to the spec, both fields being 0 means that they are not maintained at all.<br />
<br />
The following example makes use of all available DL Plus parameters:<br />
##### parameters { #####<br />
DL_PLUS=1<br />
DL_PLUS_ITEM_TOGGLE=0<br />
DL_PLUS_ITEM_RUNNING=1<br />
DL_PLUS_TAG=4 5 27<br />
DL_PLUS_TAG=1 36 31<br />
##### parameters } #####<br />
Now: Global Deejays Feat. Rozalla - Everbody's Free (2009 Radio Mix)<br />
<br />
Note: The DLS text file must use Unix line breaks (<code>\n</code>), not Windows line breaks (<code>\r\n</code>)! To convert the latter to the former, you can use the <code>tr</code> command:<br />
tr -d '\r' < input.txt > output.txt<br />
<br />
<br />
=== Item Toggle/Running bits from separate file ===<br />
Usually the Item Toggle bit and the Item Running bit of DL Plus are provided together in the same DLS text file as the actual label text itself. However, a user might want to use the feature of ODR-PadEnc to use more than one DLS text file. This means that the state of the two bits had also to be maintained correctly in all that DLS text files, in order to keep them constant (until they change). As some files may contain static content (e.g. the broadcaster's web site URL), this would require to still keep also these actually static files always up-to-date.<br />
<br />
To prevent this, since commit c5d5653 a separate file can be specified that will be used to derive the state of the two mentioned bits. An example for a minimum file that contains the two bits, is the following:<br />
##### parameters { #####<br />
DL_PLUS_ITEM_TOGGLE=1<br />
DL_PLUS_ITEM_RUNNING=0<br />
##### parameters } #####<br />
<br />
== Transmitting further Slideshow parameters via parameters file ==<br />
See above for the filename of a file which contains additional Slideshow parameters. Comment lines begin with an "#" and are ignored. Empty lines are skipped as well.<br />
# nothing happens in here; this is just a comment line<br />
This file has the same effect as if the file would not exist.<br />
<br />
A separate line for each parameter has to be used. The following example just adds data for the Categorized Slideshow (catSLS):<br />
# this slide is in category #1 and slide #1 within this category<br />
CategoryID/SlideID=1 1<br />
# the used category #1 gets named<br />
CategoryTitle=Test category<br />
<br />
The following example makes use of all currently by odr-padenc processed Slideshow parameters:<br />
# this slide is in category #3 and slide #2 within this category<br />
CategoryID/SlideID=3 2<br />
# the used category #3 gets named<br />
CategoryTitle=Test category 3<br />
<br />
# a URL is provided where further information can be found<br />
ClickThroughURL=http://wiki.opendigitalradio.org/ODR-PadEnc<br />
# provide an alternative location for this slide<br />
AlternativeLocationURL=http://wiki.opendigitalradio.org/Tux2.png<br />
<br />
== Request slides dir re-read ==<br />
ODR-PadEnc transmits all slides in the slides dir before that directory is scanned for slides again. However, in some cases (e.g. on a new song) it may be desired to manually request a slides dir re-read.<br />
<br />
From version 2.3.0 on this can be done by placing a file called <code>REQUEST_SLIDES_DIR_REREAD</code> into the slides dir (e.g. by executing <code>touch REQUEST_SLIDES_DIR_REREAD</code>). When this file is present, the slides dir is re-read and this file is deleted.<br />
<br />
== Request DLS text file re-read ==<br />
Similar to the slides, it may be desired to manually refresh the current DL text as e.g. the next song is played. Therefore, since commit <code>d91981c</code> it is possible to request the re-read of a DLS text file.<br />
<br />
This can be achived by creating a file with the same filename as the DLS text file, suffixed by <code>.REQUEST_DLS_REREAD</code>. When this file is present, the following happens:<br />
* the related DLS text file is re-read<br />
* the related DLS text file is made the current DLS text file (only applies if multiple DLS text files are used)<br />
* the DL text is immediately inserted into the PAD transmission<br />
* the re-read request file is deleted<br />
<br />
Example: Two DLS text files are used (first file for artist/title and second file for website address/phone number). A new song starts and currently the second file is the current file. Using the described mechanism, the encoder can be forced to change to the first file (which has been updated to the new artist/title) and to immediately transmit the updated DLS text.<br />
<br />
== Known receiver issues ==<br />
<br />
Many older receivers only support the '''EBU Complete Latin based repertoire''' (charset 0).<br />
This is the motivation for the character set conversion from UTF-8, a modern and universal encoding, towards this widely supported<br />
character set.<br />
<br />
In case other conversions are needed, please get in touch with the developers on the mailing list.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Brand !! Model !! Firmware version !! Description<br />
|-<br />
| SANGEAN || DPR-17 || DPR17-vp02D-EU5V || DL: texts having exactly 128 bytes are not displayed<br />
|-<br />
| SANGEAN || DPR-36 || DPR36-VP01EU || DL: one character from previous DLS beyond current DLS remains visible<br />
|}</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2020-04-07T06:38:10Z<p>Hb9egm: </p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by Opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available as git tags. The git master branch always points to the latest release, the next branch is where development happens.<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface]] (ETI) stream as input and outputs a complex baseband stream of interlaced I/Q samples with a default sampling frequency of 2.048MHz. It can also directly drive SDR devices through Ettus' UHD driver, [https://github.com/pothosware/SoapySDR/wiki SoapySDR] and LimeSuite.<br />
<br />
Some devices require resampling to another sampling rate, which increases CPU requirements and can be done internally by ODR-DabMod.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.54. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd and/or soapy (including drivers for your SDR device), don't forget to also install the -dev package from your distribution.<br />
<br />
You need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository. Also don't forget the -dev package.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
<br />
Build and install according to the instructions in the README.<br />
<br />
<br />
<br />
to update to latest upstream:<br />
git pull<br />
<br />
and do the bootstrap configure make again.<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: with a configuration file, and a smaller set of features is available through command line arguments. Use the -h option to see all options:<br />
<br />
odr-dabmod -h<br />
<br />
For the configuration file, start with the example configuration inside the doc folder: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini doc/example.ini]<br />
<br />
This example file describes and explains all supported settings.<br />
<br />
Several settings can be modified while the modulator is running by enabling the '''remotecontrol''', see [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/README-RC.md doc/README-RC.md] for more details.<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
<br />
odr-dabmod modulator.ini<br />
<br />
See also [[DAB hardware]]<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for the old USRP1 device only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Hb9egmhttp://wiki.opendigitalradio.org/Installer_scriptsInstaller scripts2019-09-30T10:03:43Z<p>Hb9egm: </p>
<hr />
<div>==Install scripts for Debian ==<br />
<br />
There is an installer script for '''Debian''' jessie, stretch and buster. It installs<br />
* uhd (from debian packages)<br />
* tons of dependencies and build tools (debian packages)<br />
* [[ODR-DabMux]] (from github source)<br />
* [[ODR-DabMod]] (from github source)<br />
* [[Fdk-aac-dabplus]] (from github source)<br />
* [[ODR-AudioEnc]] (from github source)<br />
* [[ODR-PadEnc]] (from github source)<br />
* the scripts and examples from [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux]<br />
<br />
It requires sudo to be installed, and must be executed as a regular user (not root).<br />
<br />
The script is maintained in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux] repository, and is here: https://github.com/mpbraendli/mmbtools-aux/blob/master/installer/debian.sh<br />
Download is easily possible using<br />
<br />
wget https://raw.githubusercontent.com/mpbraendli/mmbtools-aux/master/installer/debian.sh<br />
<br />
'''Please make sure you understand what this script is doing before executing it!'''<br />
<br />
Comments/suggestions are welcome ([https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools google group] -or- [https://github.com/mpbraendli/mmbtools-aux/issues GitHub issues])<br />
<br />
==Install script for the GNURadio Live System==<br />
There is also a script that can be used on the GNURadio Live System. Please see https://github.com/mpbraendli/mmbtools-aux/tree/master/installer</div>Hb9egmhttp://wiki.opendigitalradio.org/Installer_scriptsInstaller scripts2019-09-30T10:01:47Z<p>Hb9egm: </p>
<hr />
<div>==Install scripts for Debian 8 (Jessie) ==<br />
<br />
There is an installer script for '''Debian''' jessie and buster. It installs<br />
* uhd (from debian packages)<br />
* tons of dependencies and build tools (debian packages)<br />
* [[ODR-DabMux]] (from github source)<br />
* [[ODR-DabMod]] (from github source)<br />
* [[Fdk-aac-dabplus]] (from github source)<br />
* [[ODR-AudioEnc]] (from github source)<br />
* the scripts and examples from [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux]<br />
<br />
It requires sudo to be installed, and must be executed as a regular user (not root).<br />
<br />
The script is maintained in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux] repository, and is here: https://github.com/mpbraendli/mmbtools-aux/blob/master/installer/debian.sh<br />
Download is easily possible using<br />
<br />
wget https://raw.githubusercontent.com/mpbraendli/mmbtools-aux/master/installer/debian.sh<br />
<br />
'''Please make sure you understand what this script is doing before executing it!'''<br />
<br />
Comments/suggestions are welcome ([https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools google group] -or- [https://github.com/mpbraendli/mmbtools-aux/issues GitHub issues])<br />
<br />
==Install script for the GNURadio Live System==<br />
There is also a script that can be used on the GNURadio Live System. Please see https://github.com/mpbraendli/mmbtools-aux/tree/master/installer</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-AudioEncODR-AudioEnc2019-04-23T08:28:05Z<p>Hb9egm: </p>
<hr />
<div>'''ODR-AudioEnc''' is a DAB and a DAB+ encoder, replacing [[Toolame-DAB]] and [[FDK-AAC-DABplus]] respectively.<br />
<br />
The DAB encoder is derived from libtoolame-dab. toolame-02l has been converted to a shared library libtoolame-dab.<br />
<br />
The DAB+ encoder is using the fdk-aac library the Fraunhofer FDK AAC code from Android, patched for 960-transform and proper header and firecode.<br />
<br />
The main tool is '''odr-audioenc''', which can encode from a file or pipe source, all inputs supported by libVLC or an ALSA soundcard, and encode to a ZeroMQ output compatible with [[ODR-DabMux]], to a file or to standard output. The VLC ALSA input supports experimental '''sound card clock drift compensation''', that can compensate for imprecise sound card clocks.<br />
<br />
'''DAB MOT Slideshow and DLS''' support is possible thanks to [[ODR-PadEnc]]<br />
<br />
For detailed usage, see the usage screen of the different tools.<br />
<br />
<br />
Its development is public : http://github.com/Opendigitalradio/ODR-AudioEnc and releases are available as git tags. The git master branch always points to the latest release, the next branch is where development happens. <br />
<br />
== Installation ==<br />
===Prerequisites===<br />
<br />
The ODR-AudioEnc package depends on libfec, boost-thread, boost-system, alsa and ZeroMQ.<br />
For instructions on how to install these, please see [[ODR-DabMux#Prerequisites]]<br />
<br />
The [[mot-encoder]] optionally needs ImageMagick's magick_wand to be able to resize pictures.<br />
<br />
===Building===<br />
<br />
See https://github.com/Opendigitalradio/ODR-AudioEnc#how-to-build<br />
<br />
==Usage==<br />
<br />
Several usage scenarios are shown in<br />
https://github.com/Opendigitalradio/ODR-AudioEnc#how-to-use<br />
<br />
===Problem solving===<br />
<br />
In the case you are using '''ZeroMQ between the encoder and odr-dabmux''', and you see errors that the size of the data is wrong, then the configured bitrate in the mux probably doesn't correspond to the bitrate given to the encoder. Make sure they are identical.<br />
<br />
If you are using a '''pipe between the encoder and odr-dabmux''', and you see a lot of errors like this:<br />
<2> ERROR: Incomplete DAB+ frame! 136 != 360<br />
<5> reach end of file -> rewinding<br />
<2> ERROR: Can't rewind file<br />
<6> ETI frame number: 228<br />
<br />
Then the stream has to be buffered before giving it to muxer, this additional buffer installed between encoder and fifo. To calculate proper block size for mbuffer ("-s" parameter), the table below may be used:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
!DAB+ Stream bitrate, kbps<br />
!Block size, bytes<br />
|-<br />
|16<br />
|240<br />
|-<br />
|24<br />
|360<br />
|-<br />
|32<br />
|480<br />
|-<br />
|48<br />
|720<br />
|-<br />
|56<br />
|840<br />
|-<br />
|64<br />
|960<br />
|-<br />
|72<br />
|1080<br />
|-<br />
|128<br />
|1920<br />
|-<br />
|160<br />
|2400 <br />
|}<br />
<br />
In example above, for stream with bitrate 24 kbps, mbuffer size set to 360 bytes. This trick helping to solve problem.<br />
<br />
==Historical notes==<br />
<br />
The encoders were renamed at version 0.2.0. The aac-enc testing program disappeared, but its code is still in src/.<br />
The aac-enc-dabplus and aac-enc-dabplus-zmq were renamed to dabplus-enc-file and dabplus-enc-file-zmq. dabplus-enc-alsa-zmq appeared in v0.2.0.<br />
<br />
In v0.2.2, dabplus-enc-file-zmq received support for output to file and pipe, making dabplus-enc-file obsolete, which has therefore been removed.<br />
<br />
In v0.4.0, lots of code redundancy between different encoder variants has been merged into '''dabplus-enc'''. The old tools '''dabplus-enc-file-zmq''', '''dabplus-enc-alsa-zmq''' and all this have been replaced by a single encoder.<br />
<br />
Some of the ''encode-'' scripts available in the [https://github.com/mpbraendli/mmbtools-aux mmbtools-aux repository] might still make use of the old names.<br />
<br />
In september 2016, FDK-AAC-DABplus was split in three: ODR-AudioEnc, fdk-aac and ODR-PadEnc, for ease of maintainability and packaging, to clarify the licence situation a bit, and in the hope that the DAB+ modification to fdk-aac could be given upstream.</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-DabMuxODR-DabMux2019-04-23T08:27:13Z<p>Hb9egm: </p>
<hr />
<div>ODR-DabMux is a free open source [[DAB multiplexing|DAB Multiplexer]] initially developed by Communication Research Center (CRC) from Canada, and subsequently<br />
forked by Opendigitalradio. It is a command line tool.<br />
<br />
The development is done publicly on [http://github.com/Opendigitalradio GitHub] with releases available as git tags. The git master branch always points to the latest release, the next branch is where development happens.<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
<br />
<br />
<br />
==Build information for ODR-DabMux==<br />
<br />
Install the required dependencies according to the information in [https://github.com/Opendigitalradio/ODR-DabMux/blob/master/INSTALL.md INSTALL.md] file.<br />
<br />
Each time you update from the git repository (either git checkout or git pull) you should do<br />
./bootstrap.sh<br />
to re-generate the autotools scripts and generate the ./configure script<br />
<br />
<br />
==Usage==<br />
<br />
Please follow the steps in the [http://opendigitalradio.github.io/mmbtools-doc/mmbtools.pdf guide] to get up and running.<br />
<br />
<br />
===Configuration file===<br />
The full configuration can also be specified in a configuration file.<br />
<br />
The example configuration file that is included in doc ([https://github.com/Opendigitalradio/ODR-DabMux/blob/master/doc/example.mux example.mux]) contains an example with a multiplex consisting of two services. The example file is commented, and is a good example to build your own. The [https://github.com/Opendigitalradio/ODR-DabMux/blob/master/doc/advanced.mux advanced.mux] presents more options.<br />
<br />
To run odr-dabmux with a configuration file, run<br />
odr-dabmux my_config.mux<br />
<br />
==Information from the ODR Archives==<br />
<br />
Documentation and descriptions on CRC-DabMux can be found on http://mmbtools.crc.ca/content/view/39/65/<br />
<br />
The last version published by CRC is [http://mmbtools.crc.ca/component/option,com_docman/task,doc_download/gid,33/ version 0.3.0.4], on which the latest developments are based.<br />
<br />
<br />
===Patch to increase page size===<br />
Some glitches have been noticed on some machines. They are due to underruns in the FIFO. This patch increases the buffer sizes in the mux. wrning, this patch will also increase the delay. To apply it use, the patch command. (for CRC-DabMux <= 0.3.0.4)<br />
<br />
--- src/dabInputFifo.cpp.org 2011-09-27 10:08:35.202323204 -0400<br />
+++ src/dabInputFifo.cpp 2011-09-27 10:13:57.638315966 -0400<br />
@@ -169,11 +169,12 @@<br />
if (data->buffer != NULL) {<br />
delete data->buffer;<br />
}<br />
- if (size == 0) {<br />
- size = 1024;<br />
- }<br />
- data->buffer = new unsigned char[size * 16];<br />
data->maxSize = size * 16;<br />
+ int minSize = 2*getpagesize();<br />
+ while (data->maxSize < minSize) {<br />
+ data->maxSize += size;<br />
+ }<br />
+ data->buffer = new unsigned char[data->maxSize];<br />
#ifdef _WIN32<br />
ReleaseSemaphore(data->semBuffer, 1, NULL);<br />
#else<br />
<br />
<br />
See the manpage for more info:<br />
*[[CRC-DabMux man page]]</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2019-04-23T08:26:24Z<p>Hb9egm: </p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by Opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available as git tags. The git master branch always points to the latest release, the next branch is where development happens.<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface]] (ETI) stream as input and outputs a complex baseband stream of interlaced I/Q samples with a default sampling frequency of 2.048MHz. It can also directly drive SDR devices through Ettus' UHD driver and [https://github.com/pothosware/SoapySDR/wiki SoapySDR].<br />
<br />
Some devices require resampling to another sampling rate, which increases CPU requirements and can be done internally by ODR-DabMod.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.54. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd and/or soapy (including drivers for your SDR device), don't forget to also install the -dev package from your distribution.<br />
<br />
You need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository. Also don't forget the -dev package.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
<br />
Build and install according to the instructions in the README.<br />
<br />
test with:<br />
odr-dabmod -h<br />
<br />
to update to latest upstream:<br />
git pull<br />
<br />
and do the bootstrap configure make again.<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: through command line arguments or with a configuration file:<br />
<br />
===Command line arguments===<br />
<br />
Example with command-line interface:<br />
odr-dabmod ./racor.eti -l -g1 -r3200000<br />
<br />
This modulates the racor.eti file, performs OFDM modulation on baseband at a sampling frequency of 3.2Msamples/sec. Output is sent to the standard output. It can be redirected into a file, or piped into a baseband player ([[CRC-Dwap.py]]).<br />
<br />
When using a USRP, the integrated UHD output can be used. This requires the definition and usage of a configuration file.<br />
<br />
===Configuration file===<br />
<br />
Take the example configuration from GitHub: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini example.ini]<br />
<br />
The '''input''' section defines if you want to read a file or ETI over ZeroMQ. The ZeroMQ must point to a odr-dabmux ZeroMQ output.<br />
The '''modulator''' section sets parameters for the modulator which are described below.<br />
<br />
'''firfilter''' enables the filter that was previously done in the baseband player. It reduces out of band energy, and will increase signal quality, and reduce energy waste in the mask filter. The filter taps can be generated with the helper script in doc/fir-filter<br />
<br />
For each possible output, there is a section: '''outputuhd''' and '''outputfile'''. '''outputfile''' only defines the filename. '''outputuhd''' is more interesting: it defines the device flags, the TX frequency, the PGA gain, and what clocking source you want to use. In case of refclk loss, it is possible to make the modulator crash so as to avoid transmitting a corrupt signal, maybe even on the wrong frequency.<br />
<br />
The parameter<br />
device=master_clock_rate=32768000,type=b100<br />
is valid for USRP B100, and the master_clock_rate allows us to avoid resampling the 2048000sps signal. It is used as UHD device parameter without modification. There are other USRPs supported: See [[DAB hardware]]<br />
<br />
The txgain can be modified while the modulator runs by enabling the '''remotecontrol'''<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
odr-dabmod -C modulator.ini<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for regular USRP1 only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Hb9egmhttp://wiki.opendigitalradio.org/SNMPSNMP2018-03-07T10:24:12Z<p>Hb9egm: </p>
<hr />
<div>Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436'''<br />
<br />
OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)<br />
<br />
The '''goal of the Project SNMP''' is to make the monitoring statistics available through SNMP.<br />
<br />
==Steps==<br />
<br />
; Understand how to represent our monitoring values in a MIB<br />
: List what by whan to monitor and define keyword<br />
<br />
; Define a MIB structure and write a MIB<br />
: The best pratice seem to have 1 MIB by product/software and reserve one sub-level for each<br />
: 51436.1 for ODR-DabMux<br />
: 51436.2 for ODR-DabMod<br />
: 51436.3 for ODR-AudioEnc<br />
: 51436.4 for ODR-PadEnc<br />
<br />
; As every tool can be run more than once on a machine, all of them need to start with a table.<br />
<br />
; Understand how to interface with snmpd and write scripts to connect the mmbTools with snmpd<br />
<br />
==Things to monitor==<br />
<br />
Things to monitor for the ODR-mmbTools:<br />
<br />
* ODR-PadEnc<br />
** Nothing<br />
* ODR-AudioEnc<br />
** Nothing. Audio levels are available through ODR-DabMux<br />
* ODR-DabMux<br />
** Seconds until expiry of TAI bulletin<br />
** For each ZMQ input:<br />
*** state (0 Unknown, 1 NoData, 2 Unstable, 3 Silent, 4 Streaming)<br />
*** min buffer<br />
*** max buffer<br />
*** number of ZMQ underruns (overflows at 2^32 - 1)<br />
*** number of ZMQ overruns (overflows at 2^32 - 1)<br />
*** audio level peak, left channel<br />
*** audio level peak, right channel<br />
** We could add the number of frames encoded, to detect a stuck multiplexer (To be discussed)<br />
* ODR-DabMod<br />
** one set of values for CFR<br />
*** Percentage of samples clipped<br />
*** Percentage of errors clipped<br />
*** MER after CFR<br />
*** PAPR before CFR<br />
*** PAPR after CFR<br />
** The configured TIST offset<br />
** The current TIST value<br />
** To be added: The TIST value of the frame FCT=0<br />
** one set of values for SDR device<br />
*** Number of underruns<br />
*** Number of late packets<br />
*** Number of frames transmitted</div>Hb9egmhttp://wiki.opendigitalradio.org/SNMPSNMP2018-03-07T10:03:03Z<p>Hb9egm: </p>
<hr />
<div>Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436'''<br />
<br />
OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)<br />
<br />
The '''goal of the Project SNMP''' is to make the monitoring statistics available through SNMP.<br />
<br />
==Steps==<br />
<br />
; Understand how to represent our monitoring values in a MIB<br />
: List what by whan to monitor and define keyword<br />
<br />
; Define a MIB structure and write a MIB<br />
: The best pratice seem to have 1 MIB by product/software and reserve one sub-level for each<br />
: 51436.1 for ODR-DabMux<br />
: 51436.2 for ODR-DabMod<br />
: 51436.3 for ODR-AudioEnc<br />
: 51436.4 for ODR-PadEnc<br />
<br />
; Understand how to interface with snmpd and write scripts to connect the mmbTools with snmpd<br />
<br />
==Things to monitor==<br />
<br />
Things to monitor for the ODR-mmbTools:<br />
<br />
* ODR-PadEnc<br />
** Nothing<br />
* ODR-AudioEnc<br />
** Nothing. Audio levels are available through ODR-DabMux<br />
* ODR-DabMux<br />
** Seconds until expiry of TAI bulletin<br />
** For each ZMQ input:<br />
*** state (0 Unknown, 1 NoData, 2 Unstable, 3 Silent, 4 Streaming)<br />
*** min buffer<br />
*** max buffer<br />
*** number of ZMQ underruns (overflows at 2^32 - 1)<br />
*** number of ZMQ overruns (overflows at 2^32 - 1)<br />
*** audio level peak, left channel<br />
*** audio level peak, right channel<br />
** We could add the number of frames encoded, to detect a stuck multiplexer (To be discussed)<br />
* ODR-DabMod<br />
** one set of values for CFR<br />
*** Percentage of samples clipped<br />
*** Percentage of errors clipped<br />
*** MER after CFR<br />
*** PAPR before CFR<br />
*** PAPR after CFR<br />
** The configured TIST offset<br />
** The current TIST value<br />
** To be added: The TIST value of the frame FCT=0<br />
** one set of values for SDR device<br />
*** Number of underruns<br />
*** Number of late packets<br />
*** Number of frames transmitted</div>Hb9egmhttp://wiki.opendigitalradio.org/SNMPSNMP2018-02-15T16:22:38Z<p>Hb9egm: </p>
<hr />
<div>Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436'''<br />
<br />
OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)<br />
<br />
The '''goal of the Project SNMP''' is to make the monitoring statistics available through SNMP.<br />
<br />
==Steps==<br />
<br />
# Understand how to represent our monitoring values in a MIB<br />
# Define a MIB structure and write a MIB<br />
# Understand how to interface with snmpd and write scripts to connect the mmbTools with snmpd<br />
<br />
==Things to monitor==<br />
<br />
Things to monitor for the ODR-mmbTools:<br />
<br />
* ODR-PadEnc<br />
** Nothing<br />
* ODR-AudioEnc<br />
** Nothing. Audio levels are available through ODR-DabMux<br />
* ODR-DabMux<br />
** Seconds until expiry of TAI bulletin<br />
** For each ZMQ input:<br />
*** state (0 Unknown, 1 NoData, 2 Unstable, 3 Silent, 4 Streaming)<br />
*** min buffer<br />
*** max buffer<br />
*** number of ZMQ underruns (overflows at 2^32 - 1)<br />
*** number of ZMQ overruns (overflows at 2^32 - 1)<br />
*** audio level peak, left channel<br />
*** audio level peak, right channel<br />
** We could add the number of frames encoded, to detect a stuck multiplexer (To be discussed)<br />
* ODR-DabMod<br />
** one set of values for CFR<br />
*** Percentage of samples clipped<br />
*** Percentage of errors clipped<br />
*** MER after CFR<br />
*** PAPR before CFR<br />
*** PAPR after CFR<br />
** The configured TIST offset<br />
** The current TIST value<br />
** To be added: The TIST value of the frame FCT=0<br />
** one set of values for SDR device<br />
*** Number of underruns<br />
*** Number of late packets<br />
*** Number of frames transmitted</div>Hb9egmhttp://wiki.opendigitalradio.org/SNMPSNMP2018-02-15T09:53:40Z<p>Hb9egm: </p>
<hr />
<div>Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436'''<br />
<br />
OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)<br />
<br />
The '''goal of the Project SNMP''' is to make the monitoring statistics available through SNMP.<br />
<br />
==Steps==<br />
<br />
# Understand how to represent our monitoring values in a MIB<br />
# Define a MIB structure and write a MIB<br />
# Understand how to interface with snmpd and write scripts to connect the mmbTools with snmpd<br />
<br />
==Things to monitor==<br />
<br />
Things to monitor for the ODR-mmbTools:<br />
<br />
* ODR-PadEnc<br />
** Nothing<br />
* ODR-AudioEnc<br />
** Nothing. Audio levels are available through ODR-DabMux<br />
* ODR-DabMux<br />
** Seconds until expiry of TAI bulletin<br />
** For each ZMQ input:<br />
*** state (0 Unknown, 1 NoData, 2 Unstable, 3 Silent, 4 Streaming)<br />
*** min buffer<br />
*** max buffer<br />
*** number of ZMQ underruns<br />
*** number of ZMQ overruns<br />
*** audio level peak, left channel<br />
*** audio level peak, right channel<br />
** We could add the number of frames encoded, to detect a stuck multiplexer (To be discussed)<br />
* ODR-DabMod<br />
** one set of values for CFR<br />
*** Percentage of samples clipped<br />
*** Percentage of errors clipped<br />
*** MER after CFR<br />
*** PAPR before CFR<br />
*** PAPR after CFR<br />
** The configured TIST offset<br />
** The current TIST value<br />
** To be added: The TIST value of the frame FCT=0<br />
** one set of values for SDR device<br />
*** Number of underruns<br />
*** Number of late packets<br />
*** Number of frames transmitted</div>Hb9egmhttp://wiki.opendigitalradio.org/SNMPSNMP2018-02-14T09:57:35Z<p>Hb9egm: Created page with "Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436''' OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)..."</p>
<hr />
<div>Opendigitalradio has reserved a Private Entreprise Number for SNMP: '''51436'''<br />
<br />
OID: <code>iso.org.dod.internet.private.enterprise.opendigitalradio</code> (1.3.6.1.4.1.51436)<br />
<br />
The '''goal of the Project SNMP''' is to make the monitoring statistics available through SNMP.<br />
<br />
==Steps==<br />
<br />
# Understand how to represent our monitoring values in a MIB<br />
# Define a MIB structure and write a MIB<br />
# Understand how to interface with snmpd and write scripts to connect the mmbTools with snmpd</div>Hb9egmhttp://wiki.opendigitalradio.org/DRM/DRM%2B_Digital_Radio_MondialeDRM/DRM+ Digital Radio Mondiale2018-02-14T09:49:31Z<p>Hb9egm: </p>
<hr />
<div>[[Image:drm4.jpg |thumbnail | right | RX DRM ]]<br />
<br />
There are some good options in order to receive and transmit DRM30 and DRM+ currently available.<br />
<br />
*[https://github.com/Opendigitalradio/qt-drmplus qt-drmplus] QT-based SDR DRM+ receiver with librtlsdr as frontend.<br />
<br />
*[https://sourceforge.net/projects/drm/ Dream] The great free software DRM30 receiver and transmitter.<br />
<br />
*[https://github.com/kit-cel/gr-drm GNURadio DRM blocks] All the power of GNURadio and DRM together! This recent Felix Wunsch work implements a DRM transmitter in this stage, and in a next stage will also implement a DRM receiver. Comes with gnuradio-companion examples supporting both file and USRP outputs.<br />
<br />
*[http://www.drm-sender.de/ Spark] free (but not free software) DRM30/DRM+ (also FM/RDS and AM/AMSS) transmitter that supports direct RF output (possible hardware options include the USRP and Diragen). Also supports the use of the royalties-free codec CELT.<br />
<br />
<br />
*[http://www.dsp4swls.de/sodira/sodiraeng.html Sodira] free (but not free software) DRM30/DRM+ receiver. Native support for the RTL2832 is comming soon in order to properly allow DRM+ reception.<br />
<br />
*[http://nt.eit.uni-kl.de/static/diorama/index.html Diorama], Matlab implementation of a DRM receiver.<br />
<br />
*[http://www.drm-sender.de/ Wavesink] Michael Feilen's DRM+, DAB and FM software receiver which uses the a RTL2832 dongle to receive the signal.<br />
<br />
[http://www.drmrx.org/receiver_mods.html Receivers modification to get the DRM signal on a soundcard]<br />
<br />
See also [[DRM_trial_II_in_Sottens]] reporting a test transmission made with Spark, USRP and an amateur radio amplifier on the decommissioned MW transmitter mast of Sottens</div>Hb9egmhttp://wiki.opendigitalradio.org/DRM/DRM%2B_Digital_Radio_MondialeDRM/DRM+ Digital Radio Mondiale2018-02-14T09:49:07Z<p>Hb9egm: </p>
<hr />
<div>[[Image:drm4.jpg |thumbnail | right | RX DRM ]]<br />
<br />
There are some good options in order to receive and transmit DRM30 and DRM+ currently available.<br />
<br />
*[https://github.com/Opendigitalradio/qt-drmplus] QT-based SDR DRM+ receiver with librtlsdr as frontend.<br />
<br />
*[https://sourceforge.net/projects/drm/ Dream] The great free software DRM30 receiver and transmitter.<br />
<br />
*[https://github.com/kit-cel/gr-drm GNURadio DRM blocks] All the power of GNURadio and DRM together! This recent Felix Wunsch work implements a DRM transmitter in this stage, and in a next stage will also implement a DRM receiver. Comes with gnuradio-companion examples supporting both file and USRP outputs.<br />
<br />
*[http://www.drm-sender.de/ Spark] free (but not free software) DRM30/DRM+ (also FM/RDS and AM/AMSS) transmitter that supports direct RF output (possible hardware options include the USRP and Diragen). Also supports the use of the royalties-free codec CELT.<br />
<br />
<br />
*[http://www.dsp4swls.de/sodira/sodiraeng.html Sodira] free (but not free software) DRM30/DRM+ receiver. Native support for the RTL2832 is comming soon in order to properly allow DRM+ reception.<br />
<br />
*[http://nt.eit.uni-kl.de/static/diorama/index.html Diorama], Matlab implementation of a DRM receiver.<br />
<br />
*[http://www.drm-sender.de/ Wavesink] Michael Feilen's DRM+, DAB and FM software receiver which uses the a RTL2832 dongle to receive the signal.<br />
<br />
[http://www.drmrx.org/receiver_mods.html Receivers modification to get the DRM signal on a soundcard]<br />
<br />
See also [[DRM_trial_II_in_Sottens]] reporting a test transmission made with Spark, USRP and an amateur radio amplifier on the decommissioned MW transmitter mast of Sottens</div>Hb9egmhttp://wiki.opendigitalradio.org/SHA_2017_OrganisationSHA 2017 Organisation2017-07-11T12:20:38Z<p>Hb9egm: Created page with "==Orga page for SHA2017== SHA2017 is an international non-profit outdoor hacker camp/conference taking place in The Netherlands in 2017 on August 4th to 8th. [https://wiki.sha..."</p>
<hr />
<div>==Orga page for SHA2017==<br />
SHA2017 is an international non-profit outdoor hacker camp/conference taking place in The Netherlands in 2017 on August 4th to 8th. [https://wiki.sha2017.org/w/Main_Page The Camp] (for those who don't know what it is) <br />
<br />
Our village: [https://wiki.sha2017.org/w/Village:Opendigitalradio] <br />
<br />
Going: Matthias, Mathias, Rashid, Andreas<br />
<br />
Subjects we want to look into, do tests, trials, experiments, whatever:<br />
<br />
==Projects==<br />
* Digital Predistortion<br />
* Calculate MER<br />
<br />
==Equipment==<br />
<br />
Everybody takes power distribution cables!<br />
<br />
===Mathias===<br />
*Spectrum analyser?<br />
*?<br />
<br />
===Rash===<br />
*?<br />
*NUC ?<br />
*USRP B200<br />
*3.2W PEP Amplifier incl Power Supply<br />
<br />
===mpb===<br />
*USRP B200<br />
*LimeSDR<br />
*Directional coupler and attenuators<br />
*RTLSDR<br />
*Some amateur radio stuff<br />
*coloured LED stripes + arduino for decoration<br />
*long ethernet cable<br />
<br />
If requested<br />
*USRP B100<br />
*GPSDO modules<br />
*Ethernet router/switch<br />
<br />
We have ordered a village tent with tables and chairs, we need some lighting</div>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2017-07-04T07:02:03Z<p>Hb9egm: /* 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 />
https://github.com/glokhoff/RaspDAB/raw/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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-04T07:00:58Z<p>Hb9egm: </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 />
https://github.com/glokhoff/RaspDAB/raw/master/20170222_120621.jpg</div>Hb9egmhttp://wiki.opendigitalradio.org/RaspDABRaspDAB2017-07-04T07:00:19Z<p>Hb9egm: </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 />
https://github.com/glokhoff/RaspDAB/raw/master/20170222_120621.jpg</div>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_transmitterRaspDAB/The RaspDAB transmitter2017-07-04T06:57:20Z<p>Hb9egm: Hb9egm moved page The RaspDAB transmitter to RaspDAB/The RaspDAB transmitter without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/The_RaspDAB_contribution_chainRaspDAB/The RaspDAB contribution chain2017-07-04T06:57:12Z<p>Hb9egm: Hb9egm moved page The RaspDAB contribution chain to RaspDAB/The RaspDAB contribution chain without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Automate_operation_with_SupervisorRaspDAB/Automate operation with Supervisor2017-07-04T06:57:03Z<p>Hb9egm: Hb9egm moved page Automate operation with Supervisor to RaspDAB/Automate operation with Supervisor without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Add_Program_Associated_Data_with_ODR-PadEncRaspDAB/Add Program Associated Data with ODR-PadEnc2017-07-04T06:56:57Z<p>Hb9egm: Hb9egm moved page Add Program Associated Data with ODR-PadEnc to RaspDAB/Add Program Associated Data with ODR-PadEnc without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Go_on_air_with_the_EasyDab_boardRaspDAB/Go on air with the EasyDab board2017-07-04T06:56:49Z<p>Hb9egm: Hb9egm moved page Go on air with the EasyDab board to RaspDAB/Go on air with the EasyDab board without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Use_ODR-DabMux_to_generate_the_multiplexRaspDAB/Use ODR-DabMux to generate the multiplex2017-07-04T06:56:42Z<p>Hb9egm: Hb9egm moved page Use ODR-DabMux to generate the multiplex to RaspDAB/Use ODR-DabMux to generate the multiplex without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Get_ODR-AudioEnc_to_operateRaspDAB/Get ODR-AudioEnc to operate2017-07-04T06:56:34Z<p>Hb9egm: Hb9egm moved page Get ODR-AudioEnc to operate to RaspDAB/Get ODR-AudioEnc to operate without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Install_the_OpenDigitalRadio_softwareRaspDAB/Install the OpenDigitalRadio software2017-07-04T06:56:23Z<p>Hb9egm: Hb9egm moved page Install the OpenDigitalRadio software to RaspDAB/Install the OpenDigitalRadio software without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/Some_steps_to_increase_security_and_create_a_new_userSome steps to increase security and create a new user2017-07-04T06:56:07Z<p>Hb9egm: Hb9egm moved page Some steps to increase security and create a new user to RaspDAB/Some steps to increase security and create a new user</p>
<hr />
<div>#REDIRECT [[RaspDAB/Some steps to increase security and create a new user]]</div>Hb9egmhttp://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-04T06:56:07Z<p>Hb9egm: Hb9egm moved page Some steps to increase security and create a new user to RaspDAB/Some steps to increase security and create a new user</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/Install_Raspbian_on_the_SD_cardRaspDAB/Install Raspbian on the SD card2017-07-04T06:55:57Z<p>Hb9egm: Hb9egm moved page Install Raspbian on the SD card to RaspDAB/Install Raspbian on the SD card without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/RaspDAB/RequirementsRaspDAB/Requirements2017-07-04T06:55:41Z<p>Hb9egm: Hb9egm moved page RaspDAB Requirements to RaspDAB/Requirements without leaving a redirect</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>Hb9egmhttp://wiki.opendigitalradio.org/Farsync_cardFarsync card2017-05-28T19:12:17Z<p>Hb9egm: Prefer TE1e</p>
<hr />
<div>==Use with ODR-DabMux==<br />
<br />
To use the Farsync card with the ODR-DabMux multiplexer, the raw output has to be used:<br />
raw://<device name><br />
<br />
<device name> is the name of the device under linux.<br />
<br />
Usually, it is <br />
raw://sync0<br />
<br />
See below for more information on the farsync card on Linux.<br />
<br />
==Some information about the FarSite FarSync TE1 card==<br />
<br />
http://www.farsite.com/synchronous_X.21_RS422_V.35_RS530_PCI_PCIe_cards/farsync_e1_G.703_G.704_pci_card_linux_windows.shtml<br />
<br />
The TE1e model is preferred because the external clock input will allow you to connect a reference to avoid clock drift between audio encoders, multiplexer and modulators.<br />
<br />
About clock sources: [[Media:TE1eExtSyncClockConfigForSFN-V2.pdf]]<br />
<br />
<br />
On 05. Nov 2013, Kevin Curtis (FarSite) has communicated the following to the mmbTools mailing list:<br />
<br />
===Driver versions.===<br />
We try our best to keep up with the new Kernel releases, but this is sometimes an impossible task, so we now just try and keep up with the Ubuntu releases instead. However, if you do not find a release of the drivers that is compatible with the Kernel version that you need to work with, then please email support@farsite.com and will will do our best to resolve your issue.<br />
<br />
===Driver version compatibility===<br />
Each new release of the FarSync driver usually adds new functionality, and this normally means that the fstioc_info structure, which is used to pass configuration/ststus information between the farsync driver and an application, is changed also. We add new configuration/status fields to the end of the structure. In order to save you having to rebuild your application, say for example the CRC-DabMux tool, each time we make a release we have made it possible to tell the driver to be compatible with a specific previous version of the fstioc_info structure. This can be done in various ways. For example:<br />
<br />
* specify the base fstioc_info structure version at module load time. This is then the default value for all API sessions. If there is not a value set at module load time, then the structure version is assumed to be the latest version.<br />
* use the farutil <device> set_iocver <version> command. This will set the base version for a give FarSync port, e.g. sync0.<br />
* the application can use the ioctl(FSTCMD) with the command value of FSTCMD_SET_VERSION<br />
<br />
In the case of the MMB Tools I suspect you would use the first option and select the structure version at module load time.<br />
<br />
We have been using version numbers since 1.09.xx and for the FarSync base 2.1.x release the version numbers and their meanings are as follows:<br />
<br />
* 0 - compatible with versions 1.07.xx to 1.09.02<br />
* 1 - compatible with version 1.09.03 and 1.09.04<br />
* 2 - compatible with version 1.09.05<br />
* 3 - compatable with version 2.0.x<br />
* 4 - compatible with version 2.1.x<br />
<br />
===Setting the version with the module runtime parameter===<br />
<br />
The farsync and fsflex drivers can be passed a module load time parameter called fst_iocinfo_version. Depending on how the module is loaded the value can specified in one of two ways:<br />
<br />
when using modprobe to load the kernel modules, add the following lines to the /etc/modprobe.conf file<br />
options farsync fst_iocinfo_version=<value><br />
options fsflex fst_iocinfo_version=<value><br />
<br />
when using insmod to load the kernel module, append the parameter to the insmod command, for example<br />
insmod farsync.ko fst_iocinfo_version=2<br />
insmod fsflex.ko fst_iocinfo_version=2<br />
<br />
===Setting the version using the farutil command===<br />
<br />
When using the farutil command to set the compatibility version number please make sure that it is used before the FarSync port has been opened for use. When you have set the value you can check it has been set correctly. Here is an example:<br />
<br />
farutil sync0 set_iocver 3<br />
farutil sync0 get_iocver <br />
<br />
<br />
===Setting the version using the ioctl(FSTCMD)===<br />
If you want to be sure that your application will always work with a given version of the structure you can add the following to the initialisation section of your code:<br />
<br />
static void<br />
do_set_iocver (int version)<br />
{<br />
static struct fstioc_cmd my_cmd;<br />
unsigned char iocinfo_version;<br />
<br />
iocinfo_version = version;<br />
printf("Requesting IOC Info structure version to be %d\n",<br />
iocinfo_version);<br />
my_cmd.command = FSTCMD_SET_VERSION;<br />
my_cmd.version = 1;<br />
my_cmd.input_data_len=1;<br />
my_cmd.status = 0x55555555;<br />
my_cmd.data_ptr = &iocinfo_version;<br />
req.ifr_data = (char *)&my_cmd;<br />
if (ioctl(sock, FSTCMD, &req))<br />
{<br />
perror("Error in setting IOC Info version number\n");<br />
exit(0);<br />
}<br />
if (my_cmd.status == 0xaaaaaaaa)<br />
{<br />
printf("IOC Info version set to %d\n", iocinfo_version);<br />
}<br />
else<br />
{<br />
printf("Error processing IOC Info version. Status is %x\n", my_cmd.status);<br />
}<br />
}<br />
<br />
<br />
How do I know what my device names are called?<br />
You can use the command "cat /proc/farsync"<br />
<br />
# more /proc/farsync <br />
FarSync OEM Driver version 2.0.8 - Patch Level 00 - Build -b191<br />
2 Cards found<br />
sync0-sync1:(K4739218) FarSync T2U IRQ193, 2 ports, State: Running <br />
sync2-sync2:(K5329089) FarSync TE1 IRQ185, 1 ports, State: Running <br />
Total number of ports = 3<br />
<br />
Note also that the State should be Running, and if it not this value there may have been a problem loading the card with it firmware. Consult the Trouble Shooting Guide on the product CD for more help in this case.<br />
<br />
===Versions of FarSync TE1 cards.===<br />
We now have three versions of the FarSync TE1 card as follows:<br />
<br />
* TE1: A single port PCI card with an RJ48 and BNC tx and rx connector.<br />
* TE1R: A single port PCI card with a RJ48 connector only<br />
* TE1e: A single port PCI Express with an RJ48 and BNC tx and rx connector with an external clock input of up to 10mhz through a SMA connector is supported to allow synchronisation of the output data clock, to, for example, a GPS source.<br />
<br />
<br />
===Compilation Errors on install===<br />
If you are installing the FarSync drivers and encounter compilation errors when building the driver, then check to see if there is a later version of the driver for download on our website. If there is a later version then please use this one.<br />
<br />
If there are still compilation errors, check to see if there are any patches for this version of the driver on our website. If there are please install them.<br />
<br />
If there are still compilation errors then contact support@farsite.com<br />
<br />
The farsync drivers and latest patches can be found at http://farsite.com/custsupp/Download_FarSync_software.htm<br />
<br />
===Application Stability Issues===<br />
If your application crashes as soon as it is started, then it may have been compiled for an earlier version of the FarSync driver. Loading the farsync module specifying the correct fstioc_info version will probably resolve the issue.</div>Hb9egmhttp://wiki.opendigitalradio.org/MediaWiki:WelcomecreationMediaWiki:Welcomecreation2017-04-30T09:17:32Z<p>Hb9egm: mention email address verification</p>
<hr />
<div>== Welcome, $1! ==<br />
<br />
Your account has been created. '''You must confirm your email address before you can edit'''.<br />
<br />
In case of troubles, please ask [[User:hb9egm]] by email!<br />
<br />
You can change your {{SITENAME}} [[Special:Preferences|preferences]] if you wish.</div>Hb9egmhttp://wiki.opendigitalradio.org/MediaWiki:WelcomecreationMediaWiki:Welcomecreation2017-04-22T23:50:32Z<p>Hb9egm: /* Welcome, $1! */</p>
<hr />
<div>== Welcome, $1! ==<br />
<br />
Your account has been created. '''Before you can edit''', please ask [[User:hb9egm]] by email to add you to the correct group!<br />
<br />
You can change your {{SITENAME}} [[Special:Preferences|preferences]] if you wish.</div>Hb9egmhttp://wiki.opendigitalradio.org/MediaWiki:WelcomecreationMediaWiki:Welcomecreation2017-04-22T23:50:18Z<p>Hb9egm: Created page with "== Welcome, $1! == Your account has been created. Before you can edit, please ask User:hb9egm by email to add you to the correct group! You can change your {{SITENAME}} ..."</p>
<hr />
<div>== Welcome, $1! ==<br />
<br />
Your account has been created. Before you can edit, please ask [[User:hb9egm]] by email to add you to the correct group!<br />
<br />
You can change your {{SITENAME}} [[Special:Preferences|preferences]] if you wish.</div>Hb9egmhttp://wiki.opendigitalradio.org/User:Hb9egmUser:Hb9egm2017-04-22T23:49:50Z<p>Hb9egm: /* Matthias P. Braendli */</p>
<hr />
<div>==Matthias P. Braendli==<br />
Website: http://mpb.li<br />
<br />
Email: <first name>@mpb.li<br />
<br />
HB9EGM is the callsign of a swiss amateur radio operator.<br />
<br />
He maintains the ODR-mmbTools: [[ODR-DabMux]], [[ODR-DabMod]], [[ODR-AudioEnc]] and contributes to [[ODR-PadEnc]].</div>Hb9egmhttp://wiki.opendigitalradio.org/User:Hb9egmUser:Hb9egm2017-04-22T23:49:39Z<p>Hb9egm: /* Matthias P. Braendli */</p>
<hr />
<div>==Matthias P. Braendli==<br />
Website: http://mpb.li<br />
Email: <first name>@mpb.li<br />
<br />
HB9EGM is the callsign of a swiss amateur radio operator.<br />
<br />
He maintains the ODR-mmbTools: [[ODR-DabMux]], [[ODR-DabMod]], [[ODR-AudioEnc]] and contributes to [[ODR-PadEnc]].</div>Hb9egmhttp://wiki.opendigitalradio.org/MediaWiki:SidebarMediaWiki:Sidebar2017-02-23T10:34:50Z<p>Hb9egm: Add guide</p>
<hr />
<div>* Navigation<br />
** mainpage|mainpage<br />
**http://www.opendigitalradio.org|Opendigitalradio.org<br />
** recentchanges-url|recentchanges<br />
** randompage-url|randompage<br />
** helppage|help<br />
<br />
*ODR-mmbTools<br />
** ODR-DabMux|ODR-DabMux<br />
** ODR-DabMod|ODR-DabMod<br />
** ODR-AudioEnc|ODR-AudioEnc<br />
** ODR-PadEnc|ODR-PadEnc<br />
<br />
*External links<br />
**http://github.com/Opendigitalradio|GitHub<br />
**http://opendigitalradio.github.io/mmbtools-doc/mmbtools.pdf|Guide<br />
**https://sourceforge.net/projects/drm/|Dream<br />
**http://www.drm-sender.de/|Spark<br />
**https://github.com/andrmuel/gr-dab|gr-dab</div>Hb9egmhttp://wiki.opendigitalradio.org/Main_PageMain Page2017-02-23T10:32:54Z<p>Hb9egm: </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 />
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>Hb9egmhttp://wiki.opendigitalradio.org/ODR-DabMuxODR-DabMux2017-02-23T10:31:44Z<p>Hb9egm: Update the page</p>
<hr />
<div>ODR-DabMux is a free open source [[DAB multiplexing|DAB Multiplexer]] initially developed by Communication Research Center (CRC) from Canada, and subsequently<br />
forked by opendigitalradio. It is a command line tool.<br />
<br />
The development is done publicly on [http://github.com/Opendigitalradio GitHub] with releases available on www.opendigitalradio.org<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
<br />
<br />
<br />
==Build information for ODR-DabMux==<br />
<br />
Install the required dependencies according to the information in [https://github.com/Opendigitalradio/ODR-DabMux/blob/master/INSTALL.md INSTALL.md] file.<br />
<br />
Each time you update from the git repository (either git checkout or git pull) you should do<br />
./bootstrap.sh<br />
to re-generate the autotools scripts and generate the ./configure script<br />
<br />
<br />
==Usage==<br />
<br />
Please follow the steps in the [http://opendigitalradio.github.io/mmbtools-doc/mmbtools.pdf guide] to get up and running.<br />
<br />
<br />
===Configuration file===<br />
The full configuration can also be specified in a configuration file.<br />
<br />
The example configuration file that is included in doc ([https://github.com/Opendigitalradio/ODR-DabMux/blob/master/doc/example.mux example.mux]) contains an example with a multiplex consisting of two services. The example file is commented, and is a good example to build your own. The [https://github.com/Opendigitalradio/ODR-DabMux/blob/master/doc/advanced.mux advanced.mux] presents more options.<br />
<br />
To run odr-dabmux with a configuration file, run<br />
odr-dabmux my_config.mux<br />
<br />
==Information from the ODR Archives==<br />
<br />
Documentation and descriptions on CRC-DabMux can be found on http://mmbtools.crc.ca/content/view/39/65/<br />
<br />
The last version published by CRC is [http://mmbtools.crc.ca/component/option,com_docman/task,doc_download/gid,33/ version 0.3.0.4], on which the latest developments are based.<br />
<br />
<br />
===Patch to increase page size===<br />
Some glitches have been noticed on some machines. They are due to underruns in the FIFO. This patch increases the buffer sizes in the mux. wrning, this patch will also increase the delay. To apply it use, the patch command. (for CRC-DabMux <= 0.3.0.4)<br />
<br />
--- src/dabInputFifo.cpp.org 2011-09-27 10:08:35.202323204 -0400<br />
+++ src/dabInputFifo.cpp 2011-09-27 10:13:57.638315966 -0400<br />
@@ -169,11 +169,12 @@<br />
if (data->buffer != NULL) {<br />
delete data->buffer;<br />
}<br />
- if (size == 0) {<br />
- size = 1024;<br />
- }<br />
- data->buffer = new unsigned char[size * 16];<br />
data->maxSize = size * 16;<br />
+ int minSize = 2*getpagesize();<br />
+ while (data->maxSize < minSize) {<br />
+ data->maxSize += size;<br />
+ }<br />
+ data->buffer = new unsigned char[data->maxSize];<br />
#ifdef _WIN32<br />
ReleaseSemaphore(data->semBuffer, 1, NULL);<br />
#else<br />
<br />
<br />
See the manpage for more info:<br />
*[[CRC-DabMux man page]]</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2017-02-07T09:14:06Z<p>Hb9egm: /* Building odr-dabmod */</p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available ad interim on http://mpb.li<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [[http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface ETI]] stream as input and outputs a complex baseband stream of interlaced 16 bits I/Q samples with a default sampling frequency of 2.048MHz. It can also directly communicate to the Ettus USRPs using the UHD driver.<br />
<br />
The USRP1 will require resampling to 3.2Msps, which will requires high CPU usage but cannot be avoided. Newer USRPs have a more flexible clocking system.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.42. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd, don't forget to also install the -dev package from your distribution.<br />
<br />
If you want to use the zeromq inputs or outputs, you need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
<br />
Build and install according to the instructions in the README.<br />
<br />
test with:<br />
odr-dabmod -h<br />
<br />
to update to latest upstream:<br />
git pull<br />
<br />
and do the bootstrap configure make again.<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: through command line arguments or with a configuration file:<br />
<br />
===Command line arguments===<br />
<br />
Example with command-line interface:<br />
ord-dabmod ./racor.eti -l -g1 -r3200000<br />
<br />
This modulates the racor.eti file, performs OFDM modulation on baseband at a sampling frequency of 3.2Msamples/sec. Output is sent to the standard output. It can be redirected into a file, or piped into a baseband player ([[CRC-Dwap.py]]).<br />
<br />
When using a USRP, the integrated UHD output can be used. This requires the definition and usage of a configuration file.<br />
<br />
===Configuration file===<br />
<br />
Take the example configuration from GitHub: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini example.ini]<br />
<br />
The '''input''' section defines if you want to read a file or ETI over ZeroMQ. The ZeroMQ must point to a odr-dabmux ZeroMQ output.<br />
The '''modulator''' section sets parameters for the modulator which are described below.<br />
<br />
'''firfilter''' enables the filter that was previously done in the baseband player. It reduces out of band energy, and will increase signal quality, and reduce energy waste in the mask filter. The filter taps can be generated with the helper script in doc/fir-filter<br />
<br />
For each possible output, there is a section: '''outputuhd''' and '''outputfile'''. '''outputfile''' only defines the filename. '''outputuhd''' is more interesting: it defines the device flags, the TX frequency, the PGA gain, and what clocking source you want to use. In case of refclk loss, it is possible to make the modulator crash so as to avoid transmitting a corrupt signal, maybe even on the wrong frequency.<br />
<br />
The parameter<br />
device=master_clock_rate=32768000,type=b100<br />
is valid for USRP B100, and the master_clock_rate allows us to avoid resampling the 2048000sps signal. It is used as UHD device parameter without modification. There are other USRPs supported: See [[DAB hardware]]<br />
<br />
The txgain can be modified while the modulator runs by enabling the '''remotecontrol'''<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
odr-dabmod -C modulator.ini<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for regular USRP1 only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Hb9egmhttp://wiki.opendigitalradio.org/ODR-DabModODR-DabMod2017-02-07T09:12:54Z<p>Hb9egm: </p>
<hr />
<div>==About ODR-DabMod==<br />
ODR-DabMod is the DAB OFDM modulator initially developed by Communication Research Center (CRC) from Canada, and subsequently forked<br />
by opendigitalradio.<br />
<br />
CRC have stopped releasing new versions.<br />
The development is now pursued by opendigitalradio on [http://github.com/Opendigitalradio GitHub] with releases available ad interim on http://mpb.li<br />
<br />
The main communication channel is the [https://groups.google.com/forum/#!forum/crc-mmbtools CRC-mmbTools Google Group mailing list]<br />
<br />
Original CRC version [[http://web.archive.org/web/20131031110313/http://mmbtools.crc.ca/content/view/44/71/ CRC-DabMod description and source code] archived on the MMBTools website<br />
<br />
==Description==<br />
<br />
ODR-DabMod takes an [[Ensemble Transport Interface ETI]] stream as input and outputs a complex baseband stream of interlaced 16 bits I/Q samples with a default sampling frequency of 2.048MHz. It can also directly communicate to the Ettus USRPs using the UHD driver.<br />
<br />
The USRP1 will require resampling to 3.2Msps, which will requires high CPU usage but cannot be avoided. Newer USRPs have a more flexible clocking system.<br />
<br />
==Build information==<br />
<br />
If you run debian, have a look at the [[Installer scripts]]<br />
<br />
===Prerequisites===<br />
<br />
You will need boost at least version 1.42. The one from your distribution is probably fine, and if you have installed GNURadio or UHD, you will already have it.<br />
<br />
You need uhd, don't forget to also install the -dev package from your distribution.<br />
<br />
If you want to use the zeromq inputs or outputs, you need a recent (4.0.4 or later) version of [http://zeromq.org/ ZeroMQ], preferably installed from your distribution's repository.<br />
<br />
===Building odr-dabmod===<br />
<br />
First get it via the package or git repository:<br />
git clone https://github.com/Opendigitalradio/ODR-DabMod<br />
cd ODR-DabMod<br />
./bootstrap.sh<br />
<br />
<br />
When building from the source code, be careful to disable debugging, otherwise there will be lot of wasted CPU usage:<br />
./configure --with-debug-malloc=no --disable-debug --enable-fft-simd --enable-input-zeromq<br />
<br />
If you don't have zeromq, remove the --enable-input-zeromq flag.<br />
<br />
make<br />
sudo make install<br />
<br />
to test:<br />
odr-dabmod -h<br />
<br />
to update to latest upstream:<br />
git pull<br />
./bootstrap.sh<br />
<br />
==Usage==<br />
There are two ways of using ODR-DabMod: through command line arguments or with a configuration file:<br />
<br />
===Command line arguments===<br />
<br />
Example with command-line interface:<br />
ord-dabmod ./racor.eti -l -g1 -r3200000<br />
<br />
This modulates the racor.eti file, performs OFDM modulation on baseband at a sampling frequency of 3.2Msamples/sec. Output is sent to the standard output. It can be redirected into a file, or piped into a baseband player ([[CRC-Dwap.py]]).<br />
<br />
When using a USRP, the integrated UHD output can be used. This requires the definition and usage of a configuration file.<br />
<br />
===Configuration file===<br />
<br />
Take the example configuration from GitHub: [https://github.com/Opendigitalradio/ODR-DabMod/blob/master/doc/example.ini example.ini]<br />
<br />
The '''input''' section defines if you want to read a file or ETI over ZeroMQ. The ZeroMQ must point to a odr-dabmux ZeroMQ output.<br />
The '''modulator''' section sets parameters for the modulator which are described below.<br />
<br />
'''firfilter''' enables the filter that was previously done in the baseband player. It reduces out of band energy, and will increase signal quality, and reduce energy waste in the mask filter. The filter taps can be generated with the helper script in doc/fir-filter<br />
<br />
For each possible output, there is a section: '''outputuhd''' and '''outputfile'''. '''outputfile''' only defines the filename. '''outputuhd''' is more interesting: it defines the device flags, the TX frequency, the PGA gain, and what clocking source you want to use. In case of refclk loss, it is possible to make the modulator crash so as to avoid transmitting a corrupt signal, maybe even on the wrong frequency.<br />
<br />
The parameter<br />
device=master_clock_rate=32768000,type=b100<br />
is valid for USRP B100, and the master_clock_rate allows us to avoid resampling the 2048000sps signal. It is used as UHD device parameter without modification. There are other USRPs supported: See [[DAB hardware]]<br />
<br />
The txgain can be modified while the modulator runs by enabling the '''remotecontrol'''<br />
<br />
Once you have defined a configuration file (let's call it modulator.ini), you can call:<br />
odr-dabmod -C modulator.ini<br />
<br />
==Additional information concerning the options==<br />
<br />
-c, or '''dac_clk_rate''': Pre-correction for the CIC filter in the USRP:<br />
<br />
This filter is used on the FPGA for up-sampling to 128MHz.<br />
This pre-correction filter is only enabled when the -c option is used.<br />
You should use -c128000000 for regular USRP1 only.<br />
<br />
-g, or '''gainmode''': Gain computation mode<br />
<br />
The gainmode option controls how ODR-Dabmod computes the OFDM symbol gain.<br />
<br />
mode 0 (FIX) uses a fixed factor and is really not recommended. It is more<br />
useful on an academic perspective for people trying to understand the<br />
DAB modulation. <br />
<br />
mode 1 (MAX) is the normalization of every OFDM symbol. <br />
No overshoot, no truncating, but varying output power (around<br />
3dB) which might not be the best for some power amplifier. <br />
<br />
mode 2 (VAR) uses the method specified in ETSI 300 798. This<br />
method normalizes to 4 times the standard deviation for an approximation<br />
of the RMS power. So around 6/100000 samples will be truncated and will<br />
introduce some really minor distortion. But this mode also maximizes the<br />
output power. This is the gain mode recommended for real world operation<br />
as it is based on a DAB standard; the only difference is that ODR-Dabmod<br />
uses a better resolution with 16 bits in place of 8 bits. <br />
<br />
(Additional info taken from [http://groups.google.com/group/crc-mmbtools/browse_thread/thread/5b92f11422cd9c6e?pli=1 google groups discussion],<br />
originally written by Pascal Charest, CRC)<br />
<br />
*[[CRC-DabMod usage]]</div>Hb9egmhttp://wiki.opendigitalradio.org/MediaWiki:SidebarMediaWiki:Sidebar2017-02-07T09:09:55Z<p>Hb9egm: </p>
<hr />
<div>* Navigation<br />
** mainpage|mainpage<br />
**http://www.opendigitalradio.org|Opendigitalradio.org<br />
** recentchanges-url|recentchanges<br />
** randompage-url|randompage<br />
** helppage|help<br />
<br />
*ODR-mmbTools<br />
** ODR-DabMux|ODR-DabMux<br />
** ODR-DabMod|ODR-DabMod<br />
** ODR-AudioEnc|ODR-AudioEnc<br />
** ODR-PadEnc|ODR-PadEnc<br />
<br />
*External links<br />
**http://github.com/Opendigitalradio|GitHub<br />
**https://sourceforge.net/projects/drm/|Dream<br />
**http://www.drm-sender.de/|Spark<br />
**https://github.com/andrmuel/gr-dab|gr-dab</div>Hb9egmhttp://wiki.opendigitalradio.org/MediaWiki:SidebarMediaWiki:Sidebar2017-02-07T09:09:08Z<p>Hb9egm: </p>
<hr />
<div>* Navigation<br />
** mainpage|mainpage<br />
**http://www.opendigitalradio.org|Opendigitalradio.org<br />
** recentchanges-url|recentchanges<br />
** randompage-url|randompage<br />
** helppage|help<br />
<br />
*ODR-mmbTools<br />
** ODR-DabMux|ODR-DabMux<br />
** ODR-DabMod|ODR-DabMod<br />
** ODR-AudioEnc|ODR-AudioEnc<br />
** ODR-PadEnc|ODR-PadEnc<br />
<br />
*External links<br />
**http://github.com/Opendigitalradio|Github<br />
**https://sourceforge.net/projects/drm/|Dream<br />
**http://www.drm-sender.de/|Spark<br />
**https://github.com/andrmuel/gr-dab|gr-dab</div>Hb9egmhttp://wiki.opendigitalradio.org/Bidirectional_PAD_communication_protocolBidirectional PAD communication protocol2017-02-06T12:59:34Z<p>Hb9egm: Replace version by type</p>
<hr />
<div>The current [[ODR-PadEnc]] to [[ODR-AudioEnc]] communication is done through a nonblocking FIFO.<br />
<br />
The proposal is to replace it by a UDP-based request/reply protocol.<br />
<br />
For every audio frame, the ODR-AudioEnc checks if a block of PAD data is available by doing a nonblocking recv() on the UDP socket. If yes, it inserts it into the audio frame; if not, the audio frame will not contain PAD. In any case, it sends a request to ODR-PadEnc for new data:<br />
<br />
UDP PAD Request - message format<br />
| type (1 byte) |<br />
| 0x1 (request) |<br />
<br />
ODR-PadEnc prepares the PAD block and answers with a UDP reply message:<br />
<br />
UDP PAD Reply - message format<br />
| type (1 byte) | PAD data (N bytes) |<br />
| 0x2 (reply) | <PAD> |<br />
<br />
Future versions of the messages as well as new types of messages shall use different values for the type field.<br />
<br />
<br />
Multi-byte values (none yet) use network endianness (i.e. big-endian).<br />
<br />
TODO:<br />
<br />
* Define the order of bytes for the PAD data</div>Hb9egm