XCMD

Download as pdf or txt
Download as pdf or txt
You are on page 1of 11

XCMD=

<rds><item
X-Command
for RDS Encoders

<artist>
A guide how to broadcast tagged information
using a RDS encoder’s text command
based on markup language

<news> Revision 2017-05-24

</item></rds
Ing. Jan KoIar, PlRA DigitaI s.r.o. Pira.cz

>
Introduction
Benefit of the X-Command is well illustrated on following situations. A typical
broadcast automation system is taking internal text fields and loading the RDS
encoder by a text describing current program being broadcast.

1. Conventional RDS Encoder 


TEXT=James Arthur - Say You Won’t Let Go

Figure 1 – Final result – standard RDS encoder

2. RDS Encoder with X-Command Support 


XCMD=<rds><item><dest>3</dest><text><artist>James Arthur</artist> -
<title>Say You Won’t Let Go</title></text></item></rds>

Figure 2 – Final result – RDS encoder with X-Command support


Motivation for the X-Command Implementation
The X-Command for RDS encoders has been originally developed by Pira.cz to create
an extended interface for forwarding tagged text information provided by FM broadcast
automation systems.

RDS ENCODER

RT+
12V D C ETHERNET R S -232 OUTPUT IN P U T G P IO

X-COMMAND
LOOP S ID E

Figure 3 – The X-Command tagging application example

Radiotext Plus (RT+) is a technology based on Radio Data System (RDS) standard
that tags text messages so specific content type can be retrieved from them. The RT+
enhances possibilities of existing Radiotext service as it helps the receivers to
recognize and classify what kind of information is currently put in the Radiotext. The
purpose of RT+ is to enable analogue FM RDS radios to display metadata such as
Artist and Title details for songs, scrolling news headlines, information about the radio
station, etc. The investment in RT+ is future proof – RT+ equivalents exist in all digital
radio and mobile audio technologies: DMB/DAB/DAB+, DRM+, HD Radio, MP3 etc.

The RT+ specification has been published before more than 10 years. After this period
we can make following summarization:

 RT+ is supported by many RDS encoders. Although the level of support


significantly varies between products of different brands, radio stations can
select a suitable solution from the market offer.
 RT+ is well supported by current radio receivers, especially receivers integrated
in mobile equipment and in car radios, which nowadays represent typical
equipment for FM radio listening
 Almost all FM radio stations use some kind of broadcast automation software
which holds appropriate text information describing current program, incl.
separate artist and title fields, commercials, news, program guide etc.
 Despite all this, expansion of the RT+ is still unsatisfactory in 2017 (globally
estimated at less than 10 % of radio stations using RDS).

The reason is primarily not inside the products themselves but in the manner how the
products communicate between themselves. Loading the RDS encoders with RT+
metadata has not yet been covered by any suitable standard which could help mass
deployment of the RT+. Let's look at some methods which are currently in use:

 RTP= command or equivalent


This method provides the tagging data in two steps. First, the plain text is sent to
the RDS encoder. Next, it is necessary to specify positions in the text where to
find the tags:
TEXT=James Arthur - Say You Won’t Let Go
RTP=04,00,11,01,15,19
This solution is still well suitable for connection between control software and
RDS encoder of the same brand. The RTP= command was however
unsuccessful in general use. Support of the RTP= command across different
broadcast automation systems is insufficient. Providing the information in two
steps may disallow smooth visual transition between the tracks. Last but not
least, it makes only a small sense to annoy software developers with RDS and
RT+ coding as this should be entirely a job for the RDS encoder.
 UECP free format or ODA groups
This solution is sometimes used by regional or national stations for RT+, it is
however obsolete due to its complexity, requirement of access to low layers of
RDS processing, dependence on the RDS encoder’s setup and possible
conflicts with other RDS services. The UECP does not provide any widely
applicable method how to send metadata.

The X-Command brings a solution for all the disadvantages listed above. It
unambiguously tells the RDS encoder what do to, without solving how to do that. One
text, one line, metadata included.

“The X-Command potentially brings the same revolution to the RDS


like the RT+ service as it finally allows the RT+ to become widely used.”

Even through the broadcast automation system does not handle the RDS RT+ feature,
the X-Command allows forwarding the metadata to the RDS encoder without losing
any information. Just send the X-Command and forget. The RDS encoder does the
entire job – parsing of the command, loading the text, RT+ coding and optimization
and sending everything to your listeners.

The X-Command Characteristics


 Based on simplified markup language
 XML and RT+ compatible
 Already supported by many broadcast automation systems
 Performs better than RTP= command used by conventional RDS encoders
 The use is completely free of charges and restrictions
 No need to know anything about RDS RT+ coding
 Low consumption of system resources
 Reduced protocol overhead (less than 50 % of total capacity)
 Simply readable and writable by human
 Open to future extensions
The X-Command Support
The X-Command is currently supported by following RDS encoders and devices from
Pira.cz:

P132 RDS Encoder


P232 RDS Encoder
P332 RDS Encoder
P232 Microcontroller

(A firmware update is available for existing units.)

The X-Command is naturally supported by all broadcast automation systems which


enable the user to define output data template. See the section 'Recommended Steps
for Broadcasters' for more details.

Frequently Asked Questions


Is the X-Command compatible with CENELEC RDS standards?
The X-Command only extends standard set of commands accepted by the RDS
encoder on its communication port. Therefore, no compatibility issue can occur from
the perspective of RDS standards. For tagged text, the X-Command leads to
standard RT+ service (see the figure 3).
The X-Command Specification
The X-Command Coding Rules
Communication platforms
The list of communication platforms suitable for the X-Command is including but not
limited to: serial RS-232 channel, TCP connection, reading file via HTTP protocol etc.

The X-Command header


The X-Command entry normally starts with XCMD= prefix placed before the content.
The prefix may be omitted if misinterpretation cannot occur. This case must be
explicitly specified in the RDS encoder's documentation.

Total length limit


The X-Command content length including all necessary elements and tags must not
exceed 255 bytes. Since the Radiotext length is limited to 64 characters by the RDS
standard (128 characters in possible future enhancement), the overall length limit is
still bountiful but allows seamless implementation also on the smallest platforms.

Root element
The X-Command content is delimited by element <rds>...</rds>. Anything outside
this root element is ignored by the X-Command parser (but it’s still counted in the total
length limit). If the root element is not found or incomplete, no operation is performed.

Escape sequences and character replacing


The tags (incl. angle brackets) accepted by the X-Command do not occur in the text
under consideration. Moreover, escaped text is potentially not available from the
source. Thus, no escaping is required in general. The X-Command parser in the RDS
encoder shall ignore an occurrence of single angle bracket in the text. If angle
brackets form a fake (unknown) tag, that tag will completely disappear from the
resulting text. The X-Command processor shall replace &lt; and &gt; entities with
correct characters < and >.
The X-Command processor replaces characters with ASCII code 31 or lower with a
space character and a sequence of space characters with a single space.

Character encoding
The X-Command always expects UTF-8 encoding. Conversion to EBU Latin CP is
made inside the RDS encoder. Systems using 8-bit ANSI encoding must perform
either conversion to UTF-8 or removal of all characters with ASCII code 128 or higher.

Compatibility with XML


The X-Command content can be generated using the same tools and rules valid for
the XML (Extended Markup Language). The X-Command prohibits use of attributes
inside the tags. The XML declaration (prolog) is accepted but ignored.
Case sensitivity
The X-Command is case insensitive when parsing the elements.
For example, tags <title>, <TITLE> or <Title> have the same functionality.

Terminating character
The X-Command entry must be terminated by CR character (0x0D) in case of serial or
TCP connection. The terminating character is not required for file input type.

The Item element


The "item" typically represents information related to current program being broadcast.
Only one item is accepted inside the root element.

The Item element format


The item element format is as follows:
<rds><item><dest>destination_code</dest><text>tagged_text</text></item></rds>

List of destination codes


The destination code effectively determines how the text information will appear on the
receiver.

Code Destination
If the destination is not specified or its code is set to 0, a default
0 destination will apply. In the Pira.cz products the default destination is
Radiotext (RT1) without RT+.
1 Radiotext
3 Radiotext incl. RT+
4 Dynamic PS
5 Radiotext and Dynamic PS
7 Radiotext incl. RT+ and Dynamic PS
32 to 255 (The RDS encoder's manufacturer may define proprietary codes)

Other codes are reserved and should not be used.

Length limits
The Radiotext lenght is limited by RDS standard to 64 characters maximum. The same
limit applies to RT+ (sum of all tags). The Dynamic PS text length is usually limited to
128 characters maximum. Overflowing characters are truncated by the RDS encoder.
List of tags supported in the text
The tags in the text are optional. Following table summarizes the tags supported and
their RT+ equivalent:

Priority Tag RT+ equivalent


1 artist Item.Artist
2 title Item.Title
3 album Item.Album
4 comment Item.Comment
5 genre Item.Genre
6 news Info.News
7 sport Info.Sport
8 time Info.Date_Time
9 weather Info.Weather
10 traffic Info.Traffic
11 ad Info.Advertisement
12 url Info.Url
13 info Info.Other
14 short Stationname.Short
15 long Stationname.Long
16 now Programme.Now
17 next Programme.Next
18 host Programme.Host
19 page Programme.Homepage
20 phone Phone.Studio
21 sms SMS.Studio
22 email Email.Studio
23 subchn Programme.Subchannel

All tags must be written in the format <tag>...</tag>.

Limit for number of tags inside the text


The RT+ specification does not explicitly state a limit for total number of tags inside the
text. The RT+ coding rules however do not allow to mark more than two tags at one
time. Numerous experiments have shown that sending more than two tags
sequentially for the same Radiotext gives unpredictable results on various receivers.
Additionally, due to the limit of 64 characters in total, the information frequently got
truncated.
The X-Command accepts unlimited number of tags in the text. However only two tags
at maximum are put into the RT+ service, the decision is made on the basis of the tag
priority given above.
The X-Command Examples

XCMD=<rds><item><text>This is a minimum format for the X-Command


item</text></item></rds>

Radiotext This is a minimum format for the X-Command item


RT+ cleared
Dynamic PS not affected

XCMD=<rds><item><dest>3</dest><text>Now Playing: <artist>Julia


Michaels</artist> - <title>Issues</title></text></item></rds>

Radiotext Now Playing: Julia Michaels - Issues


 Julia Michaels
RT+
 Issues
Dynamic PS not affected

XCMD=<rds><item><dest>7</dest><text>Now Playing:
<artist>Prodigy</artist> - <title>Full Throttle</title> (<album>Music
for the Jilted Generation</album>)</text></item></rds>

Radiotext Now Playing: Prodigy - Full Throttle (Music for the Jilted Gener
 Prodigy
RT+
 Full Throttle
Dynamic PS Now Playing: Prodigy - Full Throttle (Music for the Jilted Generation)

XCMD=<rds><item><dest>3</dest><text><long>Radio National</long> - call


us: <phone>236-689-1122</phone></text></item></rds>

Radiotext Radio National - call us: 236-689-1122


 Radio National
RT+
 236-689-1122
Dynamic PS not affected

XCMD=<rds><item><dest>7</dest><text>Visit the website:


<url>http://myradio.com/</url></text></item></rds>

Radiotext Visit the website: http://myradio.com/


RT+  http://myradio.com/
Dynamic PS Visit the website: http://myradio.com/
Conclusion
Recommended Steps for Broadcasters
 Contact your software vendor with questions related to the X-Command support
in your broadcast automation system.
 If your RDS encoder supports X-Command and your broadcast automation
software meets the requirements stated below, you may put the RT+ on-air
immediately.
 Consider suppressing or entirely leaving dynamic PS usage. The dynamic PS
has never been supported by RDS standard, therefore its behavior on different
receivers is unpredictable and it’s often confusing for the listener. The RT+
service is a good substitute which works well on many receivers currently
available on the market.

Recommended Steps for Broadcast Software Developers


 The broadcast automation software should be able to establish a connection to
the RDS encoder by either a serial COM port or via TCP/IP (the RDS encoder
acts as a server).
 The software shall allow the serial port baudrate to be set at least in range of
1200 to 38400 bps (no parity, 8 data bits). The software shall implement a
reconnection algorithm for the TCP/IP – check the connection status and
reconnect if necessary before sending the data.
 Implement direct support for the X-Command at least for the <artist> and <title>
text elements, in the format defined in this document, incl. user selectable
destination.
- or -
Allow the user to define output template for the data, like on this example:

 Keep the text actual by sending it once when the playing song changes or on
similar event.
 Include the information in your promotional documents and user guide for quick
access.
X-Command History
Date Event

25th of April 2017 Introduction of the X-Command, experimental


implementation in the P232 RDS Encoder (fw version 2.1c)

24th of May 2017 Implementation of the X-Command in entire P132 RDS


encoders family (P132, P232, P332, fw version 2.1d)

Support & Newsgroup


Pira.cz Technical Forum: http://pira.cz/forum/index.php?board=8.0

© 2017 PlRA DigitaI s.r.o.

You might also like