Digital audio broadcasting system - Specification of the DAB command set for receivers (DCSR)

This standard describes a command set which should be used to control DAB receivers. The coding of these commands is also described. This command set is intended to be used on different physical bus systems. The coding should be mapped transparently on different physical interfaces.
Selection conflict management, dynamic bandwidth problems and the device addressing are not within the scope of this document.

Digitales Tonrundfunksystem - Spezifikation des DAB-Befehlssatzes für Empfänger (DCSR)

Dieses Schriftstück beschreibt einen Befehlssatz, der für die Steuerung von DAB-Empfängern benutzt werden sollte und auch die Codierung der Befehle. Dieser Befehlssatz ist dazu bestimmt, in verschiedenen physikalischen Bussystemen benutzt zu werden. Die Codierung sollte an verschiedenen physikalischen Schnittstellen transparent konvertiert werden.
Auswahl-Konfliktmanagement, dynamische Bandbreitenprobleme und die Adressierung der Baueinheiten liegen nicht im Anwendungsbereiches dieser Norm.

Système de radiodiffusion sonore numérique - Spécifications du jeu de commande DAB pour le récepteur (DCSR)

Le présent document décrit un ensemble de commandes qu’il convient d’utiliser pour les récepteurs DAB. Il décrit également le codage de ces commandes. Cet ensemble de commandes est destiné à être utilisé avec différents systèmes de bus physiques. Il est recommandé que le codage soit appliqué de manière transparente sur différentes interfaces physiques.
Le présent document ne couvre pas les points suivants : gestion des conflits de sélection, problèmes de largeur de bande dynamique et adressage des appareils.

Digital audio broadcasting system - Specification of the DAB command set for receivers (DCSR)

General Information

Status
Published
Publication Date
31-Aug-2001
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
01-Sep-2001
Due Date
01-Sep-2001
Completion Date
01-Sep-2001

Overview

EN 50320:2000 - Specification of the DAB command set for receivers (DCSR) - is a CENELEC/CLC standard that defines a standardized command/response/notification protocol to control DAB (Digital Audio Broadcasting) receivers. The standard specifies the command set, binary coding and message structure so that DAB receivers can be controlled consistently across different physical bus systems. It focuses on the instruction set and message timing, while explicitly excluding selection conflict management, dynamic bandwidth problems and device addressing.

Key topics and technical requirements

  • Message types and sequencing: Defines three message classes - Command, Response and Notification - and requires that a new command is not sent until the final response of the previous command has been received.
  • Timing constraints: A quick response must be returned within 100 ms (t1); if the final response cannot be provided in that time an interim response must be sent.
  • Binary coding and mapping: Specifies a compact DCSR binary layout and a reference table of category and reference codes so the command set can be mapped transparently onto different physical interfaces (CAN, serial, USB, vehicle buses, etc.).
  • Standard command set: Includes commands such as get_receiver_capability, tune, get_tii, select_tii, get_pad, select_pad, get_figs, select_figs, get_channel, select_channel, search_for_ensemble, set_drc, get_audio_info, get_dab_status, and manufacturer-specific extensions.
  • Capability discovery: A detailed notify_receiver_capability notification reports receiver profile, supported features, manufacturer/model/serial (CRIN-based ID), frequency tables and interface descriptors.
  • Error and status handling: Standardized responses (accepted, rejected, busy, syntax_error, command_not_implemented) and notifications (including notify_error_message) for predictable error handling.
  • Extensibility: Support for manufacturer_specific_command and notifications and reserved fields for future definition (Rfu/Rfa/Rfd).

Applications and practical value

  • Enables interoperability between DAB controllers (e.g., car head units, infotainment systems, set-top boxes) and DAB receiver modules from different vendors.
  • Useful for automotive systems integration, consumer electronics, in-vehicle infotainment (IVI) design, test labs and firmware development for DAB receivers.
  • Facilitates standardized capability detection, remote tuning, service-following, audio information retrieval, FIG and PAD handling, and diagnostics across different bus technologies.
  • Helps manufacturers implement predictable error handling, timing behavior and binary mapping needed for robust DAB control interfaces.

Who should use this standard

  • DAB receiver OEMs and module vendors
  • Automotive IVI and audio system integrators
  • Embedded software developers implementing DAB control protocols
  • Test & certification labs validating DAB receiver interoperability
  • System architects designing DAB-enabled consumer electronics

Related standards

  • References CRIN (Car Radio Identification Number) usage for manufacturer/model identifiers (as noted in the standard). For physical bus mapping consider relevant bus/interface standards (automotive and industrial serial/CAN/USB specifications) when implementing DCSR.

Keywords: EN 50320, DAB, DCSR, digital audio broadcasting, DAB receiver, command set, DAB protocol, receiver control, notify_receiver_capability.

Standard
SIST EN 50320:2001
English language
84 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Frequently Asked Questions

SIST EN 50320:2001 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Digital audio broadcasting system - Specification of the DAB command set for receivers (DCSR)". This standard covers: This standard describes a command set which should be used to control DAB receivers. The coding of these commands is also described. This command set is intended to be used on different physical bus systems. The coding should be mapped transparently on different physical interfaces. Selection conflict management, dynamic bandwidth problems and the device addressing are not within the scope of this document.

This standard describes a command set which should be used to control DAB receivers. The coding of these commands is also described. This command set is intended to be used on different physical bus systems. The coding should be mapped transparently on different physical interfaces. Selection conflict management, dynamic bandwidth problems and the device addressing are not within the scope of this document.

SIST EN 50320:2001 is classified under the following ICS (International Classification for Standards) categories: 33.160.20 - Radio receivers. The ICS classification helps identify the subject area and facilitates finding related standards.

You can purchase SIST EN 50320:2001 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of SIST standards.

Standards Content (Sample)


SLOVENSKI STANDARD
01-september-2001
Digital audio broadcasting system - Specification of the DAB command set for
receivers (DCSR)
Digital audio broadcasting system - Specification of the DAB command set for receivers
(DCSR)
Digitales Tonrundfunksystem - Spezifikation des DAB-Befehlssatzes für Empfänger
(DCSR)
Système de radiodiffusion sonore numérique - Spécifications du jeu de commande DAB
pour le récepteur (DCSR)
Ta slovenski standard je istoveten z: EN 50320:2000
ICS:
33.160.20 Radijski sprejemniki Radio receivers
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD  EN 50320
NORME EUROPÉENNE
EUROPÄISCHE NORM November 2000

ICS 33.160.20
English version
Digital audio broadcasting system
Specification of the DAB command set for receivers (DCSR)

Système de radiodiffusion sonore Digitales Tonrundfunksystem -
numérique - Spécifications du jeu de Spezifikation des DAB-Befehlssatzes
commande DAB pour le récepteur (DCSR) für Empfänger (DCSR)

This European Standard was approved by CENELEC on 2000-01-01. CENELEC members are bound to
comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and
notified to the Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Czech Republic,
Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway,
Portugal, Spain, Sweden, Switzerland and United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2000 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.

Ref. No. EN 50320:2000 E
Page 2
Foreword
This European Standard was prepared by the Technical Committee CENELEC TC 206,
Consumer equipment for entertainment and information and related sub-systems.
The text of the draft was submitted to the Unique Acceptance Procedure and was approved by
CENELEC as EN 50320 on 2000-01-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2001-05-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2003-01-01
__________
Page 3
Contents
1 General.5
1.1 Scope.5
1.2 Structure of DCSR.5
2 Reference table.7
3 Responses.8
3.1 accepted.8
3.2 rejected.8
3.3 interim.9
3.4 command_not_implemented.9
3.5 busy.10
3.6 syntax_error.10
4 Commands and notifications .11
4.1 get_receiver_capability.11
4.2 notify_receiver_capability.12
4.3 tune.24
4.4 get_tii.25
4.5 notify_tii.27
4.6 select_tii.30
4.7 get_pad.32
4.8 notify_pad.33
4.9 select_pad.34
4.10 get_figs.36
4.11 notify_fig.42
4.12 select_figs.43
4.13 get_channel.44
4.14 notify_channel.46
4.15 select_channel.48
4.16 get_selection_status.51
4.17 notify_selection_status.52

Page 4
4.18 search_for_ensemble.54
4.19 notify_search_for_ensemble.59
4.20 set_drc.60
4.21 get_audio_info.62
4.22 notify_audio_info.63
4.23 get_dab_status.64
4.24 notify_dab_status.64
4.25 set_dab_status_auto_notification.68
4.26 get_active_info.71
4.27 notify_active_info.72
4.28 notify_service_following.72
4.29 manufacturer_specific_command.73
4.30 manufacturer_specific_notification.74
4.31 notify_error_message.75
5 Example of DCSR coding.77
6 Guidelines for data fields, reserved for future use (Rfu’s) or addition (Rfa’s) and
table entries, reserved for future definition (Rfd’s).83
7 Glossary.84
8 References.84

Page 5
1 General
1.1 Scope
This standard describes a command set which should be used to control DAB receivers. The
coding of these commands is also described. This command set is intended to be used on
different physical bus systems. The coding should be mapped transparently on different
physical interfaces.
Selection conflict management, dynamic bandwidth problems and the device addressing are not
within the scope of this document.
1.2 Structure of DCSR
The DCSR paper describes the Instruction Set, which consists of three types of messages as
follows:
The “Command” is used by a controlling device in order to tell the DAB receiver to perform a
certain action, to deliver certain information or to move into a certain state.
The “Response” contains only a quick reaction (t1 < 100 ms, bus transfer time not included) to
the “Command”, e.g. accepted, rejected, busy. If the final response cannot be provided within
100 ms an interim response shall be sent within 100 ms. t1x shall be zero if no interim response
is sent. This response is mandatory and returned to the sender of the command.
The “Notification” contains the entire answer to the “Command”. The commands are considered
from the DAB receiver point of view. The notifications are sent to the controller or to the
specified output.
A new command shall not be sent before the final response of the previous command was
received (t2 ≥ 0)
Page 6
DAB
Controller
Receiver
t1
t1x
t3
t2
t4
time
Figure 1 - General command response structure

NOTE  All parameter fields are always present unless otherwise stated.
The DCSR structure is coded as follows:
2 bits 6 bits bytes
α
b b b b b b
1 0 5 0 *8-1 0
α
category_code reference_code parameters

Page 7
2 Reference table
category code reference code
get_receiver_capability 0x1 0x01
tune 0x1 0x02
get_tii 0x1 0x03
select_tii 0x1 0x04
get_pad 0x1 0x05
select_pad 0x1 0x06
get_figs 0x1 0x07
select_figs 0x1 0x08
get_channel 0x1 0x09
select_channel 0x1 0x0A
get_selection_status 0x1 0x0B
search_for_ensemble 0x1 0x0C
set_drc 0x1 0x0D
get_audio_info 0x1 0x0E
get_dab_status 0x1 0x0F
set_dab_status_auto_notification 0x1 0x10
get_active_info 0x1 0x11
manufacturer_specific_command 0x1 0x20

accepted 0x2 0x01
rejected 0x2 0x02
interim 0x2 0x03
command_not_implemented 0x2 0x04
busy 0x2 0x05
syntax_error 0x2 0x06
notify_receiver_capability 0x3 0x01
notify_tii 0x3 0x03
notify_pad 0x3 0x05
notify_fig 0x3 0x07
notify_channel 0x3 0x09
notify_selection_status 0x3 0x0B
notify_search_for_ensemble 0x3 0x0C
notify_audio_info 0x3 0x0E
notify_dab_status 0x3 0x0F
notify_active_info 0x3 0x11
notify_service_following 0x3 0x12
manufacturer_specific_notification 0x3 0x20
notify_error_message 0x3 0x30
Category code 0x1: Command
0x2: Response
0x3: Notification
Page 8
3 Responses
3.1 accepted
Category:
Response (mandatory)
Purpose:
The receiver indicates to the controller that it is able to start the execution of the
command. No notify_error_message is allowed to follow, but other notifications may
follow.
Syntax:
accepted ()
Parameter:
none
3.2 rejected
Category:
Response (mandatory)
Purpose:
The receiver indicates to the controller that it can not process the command (e.g.
parameter out of range).
A notify_error_message will follow or in case of a manufacturer_specific_command a
manufacturer_specific_notification (containing the error message) will follow.
Syntax:
rejected ()
Parameter:
none
Page 9
3.3 interim
Category:
Response (mandatory)
Purpose:
The receiver indicates to the controller that it can not start executing the command within
100 ms. Subsequent to an initial response of INTERIM, the receiver shall not send any
additional INTERIM responses for this command. The receiver shall send a final
response when the command execution is started. No further command is allowed
before the final response is received.
Syntax:
interim ()
Parameter:
none
3.4 command_not_implemented
Category:
Response (mandatory)
Purpose:
The receiver indicates to the controller that it can not process the command, because
this command is not implemented in the receiver.
No notification will follow.
Syntax:
command_not_implemented ()
Parameter:
none
Page 10
3.5 busy
Category:
Response (mandatory)
Purpose:
The receiver indicates to the controller that it can not process the command at this time,
because the receiver is busy. The controller should send this command again later.
No notification will follow.
Syntax:
busy ()
Parameter:
none
3.6 syntax_error
Category:
Response (mandatory)
Purpose:
The receiver indicates to the controller that he can not process the command, because
there is a syntactical error in the received command (e.g. wrong number of parameters).
No notification will follow.
Syntax:
syntax_error ()
Parameter:
none
Page 11
4 Commands and notifications
All meaningless command parameters are to be ignored (handled as ‘don’t care’) by the
receiver.
4.1 get_receiver_capability
Category:
Command (mandatory)
Purpose:
The controller asks the DAB receiver for its capabilities.
Syntax:
get_receiver_capability ()
Parameter:
none
Reaction:
response(accepted)
notify_receiver_capability(.)
The receiver provides the receiver capabilities.
response(rejected)
notify_error_message(…)
response(interim)
response(busy)
response(syntax_error)
Page 12
4.2 notify_receiver_capability
Category:
Notification (mandatory)
Purpose:
The DAB receiver provides its capabilities to the controller.
Syntax:
notify_receiver_capability (dcsr_id, dcsr_profile, manufacturer_id, model_number,
model_year, serial_number, freq_range, transmission_mode, max_net_bitrate,
max_cu_num, num_subch, tii, sf, drc, acs, pad, aic, audio_info, aud_dec,
vid_dec, fig_filtering, Rfa, service_following, interface_descriptor)

Page 13
1 byte 4 bytes 2 bytes 2 bytes 1 byte
b b b b b b b b b b
7 0 31 0 15 0 15 0 7 0
dcsr_id dcsr_profile manufacturer_id model_number model_year .
1 byte 1 byte
b b b b
15 8 7 0
asc_1 asc_2
3 bytes 1 byte 1 byte 10 bits
b b b b b b b b
23 0 7 0 7 0 9 0
serial_number freq_range transmission_mode max_net_bitrate max_cu_num .
16 bytes 2 bytes
b b b b
127 0 15 0
freq_table freq_band freq_band_flex
1 byte 19 bits 19 bits 19 bits 19 bits bits
α
b b b b b b b b b b b b
7 0 18 0 18 0 18 0 18 0 -1 0
α
num_freq_flex start_freq 1 end_freq 1 . start_freq n end_freq n padding
6 bits 1 byte 4 bits 4 bits 1 byte 4 bits 1 bit 3 bit 1 bit 1 bit
b b b b b b b b b b b b b b b b b
5 0 7 0 3 0 3 0 7 0 3 0 0 2 0 0 0
num_subch tii sf drc acs pad aic audio_info aud_dec vid_dec .
2 bits 4 bits 2 byte
b b b b b b
1 3 0 15 0
fig_filtering Rfa service_following interface_descriptor
1 byte
b b
7 0
num_i/o interface 1 . interface n
1 bit 7 bit 4 bit 4 bit 1 byte 1 byte
b b b b b b b b b b b
0 6 0 3 0 3 0 7 0 7 0
in/out I/O_Id Rfa num_protocols protocol 1 . protocol m

Page 14
Parameter:
dcsr_id
This 8-bit field, coded as unsigned binary number, shall specify the DCSR Identifier
(1.254). The DCSR Identifier determines the supported DCSR version. Since the DCSR
versions are backward compatible, a certain dcsr_id means, all lesser dcsr_id’s are also
supported.
b .b
7 0
0000 0000 signals no information
0000 0001 DCSR version 1
0000 0010 DCSR version 2
... ...
1111 1110 DCSR version 254
1111 1111 Rfd (escape option)
dcsr_profile
This 32 -bit field indicates which optional commands and notifications are implemented
in the receiver.
Bit flag
b0 get_tii
b1 get_pad
b2 select_tii
b3 select_pad
b4 select_figs
b5 set_drc
b6 get_audio_info
b7 get_channel
b8 notify_channel
b9 manufacturer specific command
b10.b31 Rfa
The flags shall be coded as follows bi (i=0.31).
0 : optional command not implemented
1 : optional command implemented

Page 15
manufacturer_id
This 16-bit field, coded as 2 ASCII characters, shall specify the manufacturer Identifier
based on CRIN (Car Radio Identification Number, see ref.[5]).
ASC_1: This 8-bit field, coded as ASCII character shall specify the first character
of manufacturer identifier (A-Z) according to ref.[5].
ASC_2: This 8-bit field, coded as ASCII character shall specify the second
character of manufacturer identifier (A-Z) according ref.[5].
model_number
This 16-bit field, coded as an unsigned binary number, shall specify the model number
based on CRIN ( ref. [5]). This 16-bit binary field represents the 4 digits (decimal) model
number of CRIN.
b .b decimal model_number
15 0
0000 0000 0000 0000. 0000
0000 0000 0000 0001 0001
... ...
0010 0111 0000 1111 9999
0010 0111 0001 0000 not to be used
... ...
1111 1111 1111 1110 not to be used
1111 1111 1111 1111 not to be used

model_year
This 8-bit field, coded as ASCII character, shall specify the model year based on CRIN
(ref. [5]).
serial_number
This 24-bit field, coded as an unsigned binary number, shall specify the serial number
based on CRIN (ref. [5]). This 24-bit field is the binary representation of the 7 digits
(decimal) serial number of CRIN.
b .b decimal serial_number
23 0
0000 0000 0000 0000 0000 0000 000 0000
... ...
1001 1000 1001 0110 0111 1111 999 9999
1001 1000 1001 0110 1000 0000 not to be used
... ...
1111 1111 1111 1111 1111 1111 not to be used

Page 16
freq_range (freq_table, freq_band, freq_band_flex)
The structure freq_range provides information about which tune/search strategies are
provided by the receiver and which frequencies/frequency bands are supported.
freq_table
This 128 -bit field indicates the predefined frequency tables used for the command
search_for_ensemble.
If the frequency band a frequency table is dedicated to, is not supported completely by
the receiver, then only those frequency table entries are used that are inside the
supported band (the complete ensemble must be inside the supported band).
Bit flag
b0 16 kHz steps
b1
CEPT frequency table for Band III, ref.[7]
b2
CEPT frequency table for L-Band, ref.[7]
b3 Canada frequency table for L-Band
b4-b127 Rfa
The flags shall be coded as follows bi (i=0.127).
0 : Frequency table not supported
1 : Frequency table supported
freq_band
This 16-bit field indicates the supported predefined DAB frequency bands.
Bit flag Frequency band (freq_band)
b0 Band III (174,000 MHz.240,000 MHz)
b1 L-Band (1452,000 MHz.1492,000 MHz)
b2-b15 Rfa
The flags shall be coded as follows bi (i=0.15).
0 : Frequency band not supported
1 : Frequency band supported
freq_band_flex (num_freq_flex, start_freq x, end_freq x, padding)
The structure freq_band_flex provides the possibility for the receiver, to signal
additionally provided DAB frequency bands, which can not be indicated by the
parameter freq_table (see above). If no additional frequency bands are provided,
num_freq_flex shall be set to zero. Freq_band_flex consists of the following fields:
num_freq_flex: This 8-bit field, coded as an unsigned binary number, shall
specify the number of additional bands defined by a list of start and stop
frequencies (maximum 255). The value ‘0’ means that there is no additional
frequency band supported. The start_freq x and the end_freq x fields are not
present in this case.
Page 17
start_freq x: This 19-bit field, coded as an unsigned binary number, shall specify
the start frequency (in multiples of 16 kHz) of an additional receiver defined
band x, see ref.[1].
end_freq x: This 19-bit field, coded as an unsigned binary number, shall specify
the end frequency (in multiples of 16 kHz) of an additional receiver defined
band x, see ref.[1].
padding: This variable field of padding bits (set to zero) is used to guarantee a
byte aligned coding. The length of this field is calculated as follows:
number of padding bits = q*8bits - num_freq_flex*2*19bits
0 ≤ number of padding bits < 8
q is an integer value
transmission_mode
This 8-bit field indicates the supported modes. It is possible that not every receiver will
support each transmission mode in each frequency band.
Bit flag
b0 transmission Mode I
b1 transmission Mode II
b2 transmission Mode III
b3 transmission Mode IV
b4-b6 Rfa
b7 automatic mode detection
The flags shall be coded as follows bi (i=0.7).
0 : Mode not supported
1 : Mode supported
max_net_bitrate
This 8-bit field, coded as an unsigned binary number, shall specify the maximum bit rate
(excluding FIC) at the output of the Viterbi decoder in multiples of 8 kbit/s.
max_cu_num
This 10-bit field, coded as unsigned binary number, shall specify the maximum number
of CUs per CIF which can be handled by the receiver.
num_subch
This 6-bit field, coded as an unsigned binary number, shall specify the maximum number
of MSC sub-channels which can be decoded simultaneously.
tii
This 8-bit field indicates the TII support.

Page 18
Bit flag
b0 main_id and sub_id
b1 field strength information
b2 carrier information
b3 delay information derived from the TII signal
b4 rough position defined by region Id derived from
TII signal and the FIC information
b5 receiver position defined by longitude and
latitude derived from TII signal and the FIC
information
b6 Rfa
b7 Rfa
The flags shall be coded as follows bi (i=0.5).
0 : TII processing not supported
1 : TII processing supported
sf
This 4-bit field indicates the support of particular sampling frequencies for audio. The
support of 48 kHz sampling frequency is mandatory, if an audio decoder is present.
Bit flag
b0 24 kHz (LSF)
b1 Rfa
b2 Rfa
b3 Rfa
The flags shall be coded as follows bi (i=0,1).
0 : Sampling frequency not supported
1 : Sampling frequency supported

Page 19
drc
This 4-bit field indicates the support of dynamic range control.
Bit flag
b0 DRC (using F-PAD, see ref.[1])
b1 DRC (receiver generated)
b2 Rfa
b3 Rfa
The flags shall be coded as follows bi (i=0.3).
0 : not supported
1 : supported
acs
This 8-bit field indicates the supported Access Control Systems (ACS).
Bit flag
b0 NR-MSK [3]
b1 Eurocrypt EN 50094 [4]
b2 Rfa
b3 Rfa
b4 Rfa
b5 Rfa
b6 Rfa
b7 Rfa
The flags shall be coded as follows bi (i=0.7).
0 : Access Control System not supported
1 : Access Control System supported

Page 20
pad
This 4-bit field indicates the support of PAD output.
Bit flag
B0 PAD output of the selected audio sub-channel which is sent
to the on board audio decoder
B1 PAD output of any selected audio sub-channel
B2 PAD output of a not selected audio sub-channel
B3 PAD output streams of more than one audio sub-channel in
parallel
The flags shall be coded as follows bi (i=0.3).
0 : not supported
1 : supported
aic
This flag indicates the support of the AIC.
b0 = 0 : receiver is not able to provide the FIGs from the AIC
b0 = 1 : receiver is able to provide the FIGs from the AIC as long as selected
sub-channels do not fully occupy available decoding capacity
audio_info
This 3-bit field indicates the support of audio_info.
Bit flag
B0 audio_info of the selected audio sub-channel which is sent to
the on board audio decoder
B1 audio_info of any selected audio sub-channel
B2 audio_info of a not selected audio sub-channel
The flags shall be coded as follows bi (i=0.2).
0 : not supported
1 : supported
aud_dec
This flag indicates the presence of an audio source decoder.
b0=0 : no audio source decoder present
b0=1 : at least one audio source decoder present

Page 21
vid_dec
This flag indicates the presence of an video source decoder.
b0=0 : no video source decoder present
b0=1 : at least one video source decoder present
fig_filtering
This 2 bit field indicates the level of FIG filtering support.
b b
1 0
receiver is not able to perform FIG filtering at all
receiver is able to perform basic FIG filtering by
type/extension
10 receiver is able to perform basic FIG filtering by
type/extension and FIG data field header bits
(C/N, OE, P/D, D1, D2, TCId)
receiver is able to perform advanced FIG
filtering by type/extension, FIG data field
header bits (C/N, OE, P/D, D1, D2, TCId) and
by evaluation of the Service Information
Version (SIV, see in ref.[1])
service_following
This 16-bit field indicates the service following to different broadcast systems. If the
receiver supports the service following to FM or AM then another command set is
needed to control the FM or AM part of the receiver.
Bit flag
b0 DAB ensemble, no local windows
b1 DAB ensemble, with local windows
b2 Rfa
b3 Rfa
b4 FM with RDS
b5 FM without RDS
b6 AM (MW in 9 kHz steps & LW)
b7 AM (MW in 5 kHz steps & SW)
b8.b15 Rfa
The flags shall be coded as follows bi (i=0.15)
0 : service following not supported
1 : service following supported
interface_descriptor (num_i/o, interface x)

Page 22
The interface_descriptor list provides information about which interfaces are provided by
the DAB receiver and which protocols are supported on this interface.
num_i/o: This 8-bit field indicates the total number of interfaces (n) which are
supported by the receiver (bi-directional interfaces shall be treated as two
separate interfaces). The value zero is not allowed.
interface x (in/out, I/O_Id, num_protocols, protocol x)
The interface x field provides information about one particular interface.
in/out: This 1-bit flag indicates the direction of the interface. For bi-directional
interfaces the type (I/O_Id) shall be indicated twice for in and for out.
0: output of the receiver
1: input to the receiver
I/O_Id: This 7-bit field, coded as an unsigned binary number, shall specify the
type of interface (I/O Identifier), as described by the following table.
b .b Physical Interface
6 0
000 0000 not specified (default)
000 0001 Audio speaker
000 0010 Headphone
000 0011 Audio line fixed level
000 0100 Audio line variable level
000 0101 Audio digital (optical)
000 0110 Audio digital (electrical)
000 0111 IEEE1394
000 1000 RF-input
000 1001 Video RGB
000 1010 Video FBAS
000 1011 S-Video
000 1100 RS 232
000 1101 D2B
000 1110 IEEE 1284
000 1111 IEC958
001 0000 SPI
001 0001 2
I C
001 0010 USB
001 0011 IrDA
001 0100 Rfd
... ...
Page 23
b .b Physical Interface
6 0
111 1110 Rfd
111 1111 Rfd (escape option)
The position n of the appropriate interface in the interface_descriptor list is used
for further referencing. For the first interface in this list n shall be 1, for the last
th
interface n shall be num_i/o. To address the x interface within the command to
be used as the input or output interface, x is used as the
input_interface_reference or output_interface_reference respectively.
num_protocols: This 4-bit field indicates the total number of protocols (m) which
are supported by the receiver on the particular interface. If this value is set to
zero, then no protocol is signalled. A default protocol should be used.
protocol x: This 8-bit field, coded as an unsigned binary number, indicates a
protocol which is supported by the receiver on the particular interface.
b .b protocol
7 0
0000 0000 not specified (default); this code should be used if
the physical interface implies the protocol
0000 0001 RDI low capacity mode
0000 0010 RDI high capacity mode (normal frame)
0000 0011 RDI high capacity mode (extended frame)
0000 0100 SPDIF
0000 0101 AES-EBU
0000 0110 I S
0000 0111
DCSR universal protocol for byte–oriented
interfaces
0000 1000 Rfd
... ...
1111 1110 Rfd
1111 1111 Rfd (escape option)
Page 24
4.3 tune
Category:
Command (mandatory)
Purpose:
The controller asks the DAB receiver to use a certain input interface, to tune directly to a
particular DAB frequency with the given transmission mode.
Syntax:
tune (input_interface_reference, Rfa, keep_decoding, transmission_mode, tune_freq)
1 byte 1 bit 1 bit 3 bits 19 bits
b b b b b b b b
7 0 0 0 2 0 18 0
input_interface_reference Rfa keep_decoding transmission_mode tune_freq

Parameter:
input_interface_reference
This 8-bit field, derived from the interface descriptor of the receiver capability notification
shall address the input interface (RF-input) for the selection. If the
input_interface_reference is set to zero the input interface does not change. If no input
interface was specified before, the default input is used.
keep_decoding
This flag indicates whether the receiver should try to continue decoding without
interruption while performing this command or not.
b0 = 0 : do not try to continue decoding
b0 = 1 : try to continue decoding
transmission_mode
This 3-bit field specifies the DAB transmission mode.
b .b
2 0
000 keep the current transmission mode
001 transmission mode I
010 transmission mode II
011 transmission mode III
100 transmission mode IV
101 Rfd
110 Rfd
111 detect the appropriate transmission mode automatically

Page 25
If the transmission mode is not supported for the given frequency, the command will be
rejected.
The transmission_mode is set to “000” for example if the controller asks the receiver to
change just the antenna input or change to another frequency in the same MFN.
tune_freq
This 19-bit field, coded as an unsigned binary number, shall specify the DAB centre
frequency, see ref.[1].
tune_freq = 0 means keep the currently tuned frequency.
Reaction:
response(accepted)
notify_dab_status()
The receiver provides the DAB status.
response(rejected)
notify_error_message(…)
response(interim)
response(busy)
response(syntax_error)
4.4 get_tii
Category:
Command (optional)
Purpose:
The controller asks the DAB receiver for output of the transmitter identification
information (TII) .
This command, with its associated notification (notify_tii), allows the controller to monitor
the number and identification of the transmitters contributing to the received DAB signal.
This data can be represented in many ways, the receiver signals which representations
it supports in its receiver capabilities and any of these can be selected in the tii_select
parameter. Use of these representations:
• The main_id and sub_id can be used to identify the region in which the DAB
signal is currently received.
• Carrier information will allow the controller to estimate delays from the
transmitters or perform proprietary TII processing.
• Delay information is an indicator of the distance to each transmitter and can
be used to perform triangulation.

Page 26
• The rough position indicated by region identifier has application in MMI or data
terminals
• The position is the result of a triangulation on a number of transmitters and
has application in traffic management systems.
Syntax:
get_tii (tii_select, Rfa, continuous_tii)
1 byte 7 bits 1 bit
b b b b b
7 0 6 0 0
tii_select Rfa continuous_tii
Parameter:
tii_select
This 8-bit field indicates the kind of TII data. If all flags are set to zero the output will be
stopped. Any subsequent use of this command with the same
output_interface_reference will cause the tii_select parameter to be superseded by the
new value. If tii_select has a bit set that is not defined in the receiver capabilities then
the command shall be rejected with a “parameter value not supported” error notification
given.
Bit flag
b0 main_id and sub_id
b1 carrier information
b2 delay information derived from the TII signal
b3 rough position defined by region Ids derived from
TII signal and the FIC information
b4 receiver position defined by longitude and
latitude derived from TII signal and the FIC
information
b5 Rfa
b6 Rfa
b7 Rfa
continuous_tii
This flag indicates if the controller asks the DAB receiver for continuous output of the
transmitter identification information (TII) .
b0 = 0 : only one notify_tii will follow
b0 = 1 : the receiver will provide notify_tii as often as possible

Page 27
Reaction:
response(accepted)
notify_tii(.)
The receiver provides the TII data.
response(rejected)
notify_error_message(…)
response(interim)
response(busy)
response(not implemented)
response(syntax_error)
4.5 notify_tii
Category:
Notification (optional)
Purpose:
The DAB receiver provides the TII data. This data can be split up into several
notifications in case of a large amount of data. If no transmitters are identified then no
notification shall be generated.
Syntax:
notify_tii (tii_select, tii_data_list, receiver_position)

Page 28
1 byte bytes bytes
α β
b b b b b b
7 0 *8-1 0 *8-1 0
α β
tii_select tii_data_list receiver_position
3 bits 5 bits byte byte
χ δ
b b b b b b b b
2 0 4 0 *8-1 0 *8-1 0
χ δ
only if b0 or b1 or b2 or
Rfa nrt transmitter 1 . transmitter n
b3 (tii_select) = 1
1 bit 7 bits 3 bits 5 bits
b b b b b b b
0 6 0 2 0 4 0
only if b0 (tii_select) = 1
Rfa main_id Rfa sub_id .
5 bits 3 bits 8 bytes 8 bytes
b b b b b b b b
4 0 2 0 31 0 31 0
only if b1 (tii_select) = 1
Rfa ncp carrier_pair 1 . carrier_pair n .
16 bits 16 bits 16 bits 16 bits
b b b b b b b b
15 0 15 0 15 0 15 0
I-Signal Q-Signal I-Signal Q-Signal
transmitter n, transmitter n, transmitter n, transmitter n,
carrier pair m, carrier pair m, carrier pair m, carrier pair m,
carrier 1 carrier 1 carrier 2 carrier 2
5 bits 11 bits
b b b b
4 0 10 0
only if b2 (tii_select) = 1
Rfa delay
4 bits 11 bits 11 bits bits
ε
b b b b b b b b
3 0 10 0 10 0 -1 0
ε
only if b3 (tii_select) = 1
num_of_regions region_id 1 . region_id n padding .
20 bits 20 bits
b b b b
19 0 19 0
only if b4 (tii_select) = 1
latitude longitude
Parameter:
tii_select
see get_tii
tii_data_list
nrt
This 5-bit field indicates the number of received transmitters. This unsigned
binary number, coded in the range 1 . 24, shall specify the number of
Transmitters for which information (main_id, sub_id, field strength information,
carrier information, delay information) is provided. The other codes are reserved.
This field is present if b0 or b1 or b2 of tii_select is set.

Page 29
main_id
This 7-bit field indicates the main_id of a received transmitter.
This field is present if b0 of tii_select is set.
sub_id
This 5-bit field indicates the sub_id of a received transmitter.
This field is present if b0 of tii_select is set.
ncp (number of carrier pairs)
This 3-bit field, coded as an unsigned binary number, shall specify the number of
carrier pairs for which information is provided for this transmitter.
This field is present if b1 of tii_select is set.
I-Signal Transmitter n, Carrier Pair m, Carrier k,
Q-Signal Transmitter n, Carrier Pair m, Carrier k
These 16-bit fields, coded as two's complement numbers, shall contain the real
th
or imaginary part of the FFT result on the samples of the null symbol for the k
th th
carrier of the m carrier pair of the n transmitter.
These fields are present if b1 of tii_select is set.
delay
This 11-bit field, coded as an unsigned binary number (in the range 0 to 2047),
shall specify the relative time delay estimation from the received transmitter with
respect to the transmitter for which zero delay is signalled (delay=0) in
microseconds.
This field is present if b2 of tii_select is set.
receiver_position
num_of_regions
This 4-bit field, coded as unsigned binary number, shall specify the number of
regions, which are related to the current position.
This field is present if b3 of tii_select is set.
region_id
This 11-bit field, organised as a 5-bit upper part and a 6-bit lower part, shall
identify the region (see ref. [1])
This field is present if b3 of tii_select is set and if num_of_regions is unequal to
zero.
Page 30
padding: This variable field of padding bits (set to zero) is used to guarantee a
byte aligned coding. The length of this field is calculated like following:
number of padding bits = q*8 - (num_of_regions*11bit + 4bits)
0 <= number of padding bits < 8
q is an integer value
latitude
This 20-bit field, coded as two’s complement number, shall specify the coarse
latitude. (see ref. [1])
This field is present if b4 of tii_select is set.
longitude
This 20-bit field, coded as two’s complement number, shall specify the coarse
longitude. (see ref. [1])
This field is present if b4 of tii_select is set.
4.6 select_tii
Category:
Command (optional)
Purpose:
The controller asks the DAB receiver for continuous output of the transmitter
identification information (TII). This command allows the controller to send the TII data to
any output interface. No notify_tii will be sent to the controller.
see: get_tii
Syntax:
select_tii (output_interface_reference, protocol, tii_select)
1 byte 1 byte 1 byte
b b b b b b
7 0 7 0 7 0
output_interface_reference protocol tii_select

Parameter:
output_interface_reference
This 8-bit field, derived from the interface descriptor of the receiver capability notification
shall specify the interface to which the selection shall be directed. If the
output_interface_reference is not defined or is an input, the command shall be rejected
with a “parameter value invalid” error notification given.
protocol
Page 31
This 8-bit field, derived from the interface descriptor of the receiver capability notification,
shall specify the protocol which has to be used on the output interface.
tii_select
This 8-bit field indicates the kind of TII data. If all flags are set to zero the continuous
output will be stopped. Any subsequent use of this command with the same
output_interface_reference will cause the tii_select parameter to be superseded by the
new value. If tii_select has a bit set that is not defined in the receiver capabilities then
the command shall be rejected with a “parameter value not supported” error notification
given.
Bit flag
b0 main_id and sub_id
b1 carrier information
b2 delay information derived from the TII signal
b3 rough position defined by region Ids derived from
TII signal and the FIC information
b4 receiver position defined by longitude and
latitude derived from TII signal and the FIC
information
b5 Rfa
b6 Rfa
b7 Rfa
Reaction:
response(accepted)
The receiver provides the TII data on the specified output interface.
response(rejected)
notify_error_message(…)
response(interim)
response(busy)
response(not implemented)
response(syntax_error)
Page 32
4.7 get_pad
Category:
Command (optional)
Purpose:
The controller asks the DAB receiver for continuous output of the Programme
Associated Data (PAD).
This command, in association with the notify_pad notification, allows the controller to
view PAD (see [1] subclause 7.4) from an audio sub-channel. The receiver capabilities
signals whether this sub-channel is restricted to the currently selected audio sub-channel
or not and whether one or more sub-channels can be processed for PAD.
Syntax:
get_pad (pad_select, sub_ch_id)
2 bits 6 bits
b b b b
1 0 5 0
pad_select sub_ch_id
Parameter:
pad_select
This 2-bit field indicates the kind of PAD. The continuous output can be stopped by using
the command with the pad_select parameter as “nothing selected”. Any subsequent use
of this command with the same output_interface_reference and sub_ch_id will cause the
pad_select parameter to be superseded by the new value.
b b
1 0
0  0 nothing selected
0  1 F-PAD
1  0 F-PAD + X-PAD
1  1 Rfd
sub_ch_id
(Sub-channel Identifier): this 6-bit field shall identify the sub-channel that the PAD
carrying audio service component occupies (see ref.[1]). If the sub-channel specified is
not a valid audio sub-channel, the command shall be rejected with a “parameter value
not available” error notification given. If the command attempts to exceed the maximum
number of sub-channels that can be processed, the command shall be rejected with an
“insufficient processing/decoding power” error notification given.

Page 33
Reaction:
response(accepted)
notify_pad(.)
The receiver provides the PAD.
response(rejected)
notify_error_message(…)
response(interim)
response(busy)
response(not implemented)
response(syntax_error)
4.8 notify_pad
Category:
Notification (optional)
Purpose:
The DAB receiver provides the requested PAD of a particular audio sub-channel.
One notification carries the PAD information of one MPEG-frame. The PAD in a MPEG
frame is transmitted in a byte reve
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...