feasibility report on rds2 development issues fully ...feasibility report on rds2 development issues...

R15/006_5

RDS2

Feasibility report on RDS2 development issues

- Fully backwards compatible with RDS

Geneva November 2015

RDS2 development issues

page 2

This report has been prepared by the RDS 2.0 Specialist group which met at Budapest from 10 – 12 November 2014. The meeting was hosted by MTVA. The group had received from the RDS Forum in June 2014 the following mandate:

1. Identify existing unused functions within RDS 1.0; 2. Ensure complete compatibility with RDS 1.0; 3. Establish a consensus on a set of high level customer requirements, PS names with

up to 16 characters for example; 4. Define the technical and upgradable architecture based on agreed standards and

regulations; 5. Identify the work items and expertise needed.

The following RDS experts participated in the meeting: Frits de Jong – chaired the meeting, RDS Forum Office Consultant, Netherlands Josh Caskey, Silicon Labs, USA Peter Jako (invited to represent MTVA radio), Hungary Dietmar Kopitz, RDS Forum Office Consultant, Switzerland Attila Landanyi, T&C Holding, Germany Mark Saunders, Nokia Here, United Kingdom Hendrik van der Ploeg, Catena Radio Design, Netherlands The following RDS Forum members participated by correspondence in the elaboration of this report: Jeroen Langendam, ItoM, Netherlands Vincent Simonacci, Radio France, France Olivier Soulié, Worldcast Systems, France Invited for liaison with the US NRSC RBDS Subcommittee and feedback on RBDS issues: Mike Bergman, CEA, USA David Layer, NAB, USA

After the RDS Forum meeting in June 2015, Dietmar Kopitz has updated the report ,

together with Frits de Jong and Attila Ladanyi .Joop Beunders has helped to review this entire new version.


page 3

Executive summary

RDS was introduced almost 30 years ago. During the introductory phase in Europe, the car industry became very involved and that was the start of an extremely successful roll -out. Shortly afterwards RDS (RBDS) was launched in the USA.

In Europe, DAB is still trying to become firmly established and HD radio is growing in the USA. Despite various intentions promoting an analogue switch-off in a few European countries, in the meantime it has become obvious that FM radio with RDS will remain on the air and will continue to co-exist with Digital radio still for a long time. The major arguments are:

FM/RDS radio broadcasting is mature and FM/RDS radio receivers are cheap and universally available;

Traffic message announcements with TA/TP and TMC services are well established;

Due to the fact that DAB is a single frequency network, regional options are hardly possible

Due to sophisticated technologies, like multiple tuners, multiple antenna systems and RDS algorithms, this system is just about perfect and the perceived audio quality is very similar to that heard via Digital radio, which is true also for mobile reception;

It is ecologically crazy to throw away many millions of well-functioning FM/RDS radios.

The only disadvantage of RDS so far was the limited data capacity. A ground-breaking solution has been investigated by Magyar Radio already a couple of years ago. RDS Forum member Attila Ladanyi, from T&C Holding, presented in the RDS Forum for the first time the idea of how to increase the RDS data capacity. Basically, both sidebands around 57 kHz with RDS can be repeated a few times, up to four, centred on additional subcarriers higher up in the FM multiplex and compatible with the ITU Recommendations.

In November 2014, an RDS 2.0 workshop was held in Budapest with some RDS Forum members interested in this development.

The core elements of RDS2 are the additional subcarriers which will enable a significant increase of RDS data capacity to be achieved and then new additional open data applications (ODA) will be created. However, the scope of the specialist group was wider and included the following aspects:

A critical review of the existing RDS features and their future;

Derived from this, the elimination of unused features (called here “dead wood”) from the RDS standard;

Additional requirements, such as a long PS in UTF-8 and AF coding below 87.5 - 108 MHz, for China and Brazil.

In this respect RDS2 and Digital radio, like DAB+ and HD, are definitely not in direct competition and the adaptation of RDS to meet the future requirements for FM radio appeared to be unavoidable.

This report contains all the development work carried out by the RDS experts that met in Budapest. The results and recommendations, as described here, were approved by the RDS Forum meeting in June 2015.

Frits de Jong, Dietmar Kopitz Chairman of the Budapest RDS 2.0 workshop Principal editor of this report

NOTE 1: Dietmar Kopitz wishes to express his gratitude and appreciation to the other two member s of the editing team for this report, Frits de Jong and Attila Ladanyi. The editorial team held regular telephone conferences, almost once every week, to advance the editorial work for this report. What motivated the team most was the still increasing usage of FM radio worldwide. So, there is indeed a need to adapt RDS for the next 30 years to come. The project started as RDS 2.0. However, the Budapest workshop named the RDS version with more than one subcarrier “RDS2”. RDS 2.0 is now only used to designate the upcoming new RDS standard version.


page 4

CONTENTS

1 RDS 2.0 system issues .................................................................................................... 6

1.1 Objectives to be achieved ....................................................................................... 6

1.2 How do we identify within RDS 2.0 the current RDS (1)? ......................................... 6

1.3 Modulation and demodulation concept .................................................................... 6

1.4 Number of subcarriers to be used at maximum and ITU compatibility ...................... 7

1.5 What shall be the subcarrier frequencies precisely? ................................................ 7

1.6 What would be the recommended injection levels? ................................................. 7

1.7 Compacting (PI deletion / insertion) ........................................................................ 8

1.8 Data transmission net capacity of the additional streams ........................................ 8

2 Compatibility issues and new basic features .................................................................. 10

2.1 Can we really redefine bits in RDS and when is this necessary? (This is a "dead wood" issue) ............................................................................................... 10

2.2 Baseband coding of all Group types ...................................................................... 11

2.3 Station logo (new ODA-AID) .................................................................................. 12

2.4 PS (long) - 32 bytes with UTF-8 coding (new 15A) ................................................ 13

2.5 eRT - 128 bytes with UTF-8 coding (new AID) ...................................................... 13

2.6 AF coding for the FM frequency range 76-108 MHz for Brazil and 64 -108 MHz for China etc. (new ODA-AF plus for EON mapped frequencies 14A variant 10) ............................................................................................................ 14

3 Proof of concept ............................................................................................................. 18

3.1 Demonstrate the power of RDS2 for a number of typical use cases (ensure involvement of broadcasters and manufacturers) .................................................. 18

3.1.1 Encoder .................................................................................................... 18

3.1.2 RDS2 receiver ........................................................................................... 18

3.2 Field-test plan to validate RDS2 in a dynamic environment and various reception conditions .............................................................................................. 18

3.3 Test transmission on air ........................................................................................ 19

3.4 Define a demonstrator / Test vehicle ..................................................................... 19

4 Marketing issues and new Applications .......................................................................... 20

4.1 Why ODAs are so important for RDS 2.0 and why they are “application oriented” ............................................................................................................... 20

4.2 Positioning of RDS 2.0 in relation to DAB and HD radio ........................................ 21

4.3 Promotion of RDS 2.0 to stakeholders ................................................................... 21

4.4 Added value TMC services: Urban and inter-urban Traffic services and Weather information for travellers ......................................................................... 21

4.5 The World Broadcast Web: FM with a standardized user interface ........................ 22

5 UECP adaptation ........................................................................................................... 23

5.1 RDS2 encoder concept and model ........................................................................ 23

5.2 Hardware model .................................................................................................... 23

5.3 Software model ..................................................................................................... 23

5.4 Addressing method ............................................................................................... 23

5.5 Handling of ODA data ........................................................................................... 23

5.5.1 Concept .................................................................................................... 23

5.5.2 Required ODA commands. ........................................................................ 24

5.6 Adaptations needed for stream 0 .......................................................................... 24

5.7 Further action required .......................................................................................... 24


page 5

6 IPR statement ................................................................................................................ 25

7 Standard development concept (RDS & RBDS) .............................................................. 26

7.1 Proposed new RDS standard structure .................................................................. 26

7.2 Further action required .......................................................................................... 28

8 Receiver profiles, marking and certification requirements of RDS devices and compliance testing ......................................................................................................... 29

8.1 Receiver profiles ................................................................................................... 29

8.2 Marking on receivers, packaging and documentation ............................................ 30

8.3 Compliance test .................................................................................................... 31

9 Frequently Asked Questions........................................................................................... 35

10 References .................................................................................................................... 35


page 6

1 RDS2 system issues

1.1 Objectives to be achieved

The main objective is to produce a new version of the RDS standard to include RDS2, fully adapted to the technology of today.

Over the past 30 years, a fascinating development took place. Most of the multimedia applications and standards have been created or redefined significantly. Hardware has become extremely powerful with dedicated software and middleware. 30 years ago Internet as well as its protocols did not exist yet. Navigation systems became affordable in the late nineties, and a full range of attractive smartphones only exists since a few years. The computer power of all these new products can be compared with that of the mainframe installations of 30 years ago.

The listener expectations have grown faster than the technology. Visual experience is very important like the Internet look and feel. Scrolling text or delivering just audio only is nowadays perceived as insufficient for FM radio, specifically by the younger generation using mostly smartphones. New types of radio receivers with added value features are therefore required. RDS has proven so far that it has been very successful. Now the time has come to solve the only disadvantage, the lack of sufficient data capacity. With RDS2 FM will remain state of the art for the next decades to come. FM radio with RDS is an analogue-digital hybrid system, which is still a very valid data transmission technology and only the applications need adaptation.

1.2 How do we identify within RDS the current RDS1?

RDS1 is called the so far existing updated RDS standard versions. RDS 2.0 stands for a new generation of the RDS standard. The current RDS standard will be embedded in the new RDS standard. Equipment built with RDS options being implemented using the basic carrier of 57 kHz only, will have to be identified as RDS1, or RDS2 using all possible carriers.

There is no particular need to identify an RDS2 transmission. RDS1 will use only the 57 kHz subcarrier (stream 0) and RDS2 will use in addition to stream 0 also the upper streams 1 to 3 on the additional subcarriers. Modulation and demodulation continue to be the same technology, apart from the frequency shifting used for the streams 1-3. All this is described in further detail here [3 and 4].

RDS2 is intended to be fully backwards compatible with the current RDS. Even receivers only capable to decode stream 0 can benefit from new features as defined in RDS 2.0, like the 32-byte UTF-8 PS-name signalled in new group type 15A. Full current RDS functionality is guaranteed when in addition to stream 0 also streams 1 to 3 are used. For both, RDS receivers and FM broadcasters, RDS 2.0 will offer a wide variety of new features still to be developed, each to be made available by an ODA. In stream 0 the largest part of the RDS data is mandatory and defined by the already existing RDS standard in order to secure reliable operation for all product categories and in particular the automotive ones.

Given the considerable success that FM radio still has worldwide, the lower parts in the FM band down to 64 MHz or 76 MHz may well become an option to be used by a number of countries and not just only in Brazil. An interesting feature can then be the self-configuration of an FM radio receiver. With geographical information in group type 1A and additional system information delivered by an ODA, the radio could set-up itself to the required band limits and the system parameters that apply in the region where the radio is used.

1.3 Modulation and demodulation concept

The modulation and demodulation characteristics as defined in the RDS standard since 1984 are also valid for the additional carriers. Both sidebands around 57 kHz with RDS are repeated up to a maximum of four in total. These are centred on additional carriers higher up in the FM multiplex.


page 7

The additional capacity is obtained by using the: “Single Modulation-type Multiple Subcarriers” technology (SMMS). This patented technology allows the stacking of identical ly generated subcarriers of 57 kHz in the range between 60 and 100 kHz.

The additional subcarriers are as the main (57 kHz) subcarrier also derived from and locked to the 19 kHz pilot-tone using a grid of 4.75 kHz (1/4 of 19 kHz pilot). This also meets the ITU requirements closely and offers the advantage that all frequencies can be derived from the pilot-tone. The first position after 57 kHz (61.75 kHz) is not used in order to avoid any interference to existing RDS car radios.

1.4 Number of subcarriers to be used at maximum and ITU compatibility

The ITU Recommendation about injection levels and frequency limitations implies that for the RDS kind of signal (injection level between 1.2 and 2.0 kHz) up to a maximum of four subcarriers can be used [1], the main-carrier on 57 kHz and up to three additional ones , all modulated in an identical way between 60 and 76 kHz .

1.5 What shall be the subcarrier frequencies precisely?

Stream 0: 57.0 kHz (Main data stream – 3 x Pilot-tone) Stream 1: 66.5 kHz Stream 2: 71.25 kHz Stream 3: 76.0 kHz (4 x Pilot-tone) The theoretically possible 61.75 kHz subcarrier shall not be used.

Figure 1 - RDS2 offers the ability to transmit up to three more subcarriers along with the legacy

RDS subcarrier, as shown in this image from Jump2Go The division numbers are always integers: 57000 Hz / 48 = 1187.5 (bits/second) 66500 Hz / 1187.5=56 71250 Hz / 1187.5=60 76000 Hz / 1187.5=64 See also Clause 4.6, Clock-frequency and data-rate, in the RDS standard [2].

1.6 What would be the recommended injection levels?

The ITU recommends up to 10% for the 19 kHz for the pilot-tone and 10% injection level for data. The 10% for the pilot-tone may be reduced down to 6 or 6.5 kHz and it can then be assumed that four times 2 to 2.2 kHz injection level for each of the four data subcarriers is permitted [1]. The10% limit of 7.5 kHz for RDS2 can then be met.

RDS2 is flexible; it can also run with only two or three sub-carriers with an individual higher deviation, if necessary. This may depend on regional and geographical conditions, mainly there where multipath propagation is a problem for reliable RDS data reception . General rules cannot be given yet and depend on more experience to be gained with larger field trials.


page 8

1.7 Compacting (PI deletion / insertion)

On the streams 1 to 3 only ODAs will be transmitted. The automatic tuning function can be achieved with data carried only on stream 0.

The PI code on the upper streams is then redundant information, permitting to use “compacting” as shown in Figure 2, below for type A and B groups. For type A groups the PI is in block A and for B type group in block A and C.

Figure 2 - “Compacting” is removing PIs for transmission on streams 1 to 3 and reinserting them after reception of the data, the value of PI being obtained from stream

0 decoding. This principle is explained in this diagram

1.8 Data transmission net capacity of the additional streams

As mentioned already, the freely available data capacity in RDS is relatively low. In an FM broadcaster network, up to 40% of the RDS capacity is mandatory programme information like PI, PS, PTY and AF lists, all in the 0A type groups. When in addition RadioText RT and EON information are transmitted, only about 25% of the data capacity can be used for services signalled in ODA, such as TMC [1].

Often choices have to be a trade-off and must be made between those applications that can be implemented in one RDS channel. For example, to choose between a rich RadioText (RT) service or a full TMC service, it is not possible to have both simultaneously in the same FM radio programme.

However, with RDS2 this issue can be solved completely.


page 9

The Table 1 below shows the increase of the RDS data capacity if up to three additional RDS streams are added. The example is given for group type A only, with 37 freely available bits to be used exclusively for ODA applications.

Table 1 – Possible increase of RDS data capacity for RDS2 devices

Without compacting Groups/sec Total bit/sec Data increase

Stream 0 11.4 422 (11.4x37)

Stream 0 2 74

Stream 0 and 1 2 +11.4 496 6.7 times

Stream 0, 1 and 2 2 + 22.8 918 12.4 times

Stream 0, 1, 2 and 3 2 + 34.2 1339 18.1 times

With compacting Groups/sec Total bit/sec Data increase

Stream 0 11.4 422

Stream 0 2 74

Stream 0 and 1 2 + 15,2 636 8.6 times

Stream 0, 1 and 2 2 + 30.4 1198 16.2 times

Stream 0, 1, 2 and 3 2 + 45.6 1761 23.8 times

Currently in RDS only about two ODA groups as a maximum can be used. In practice it will often be less.

Table 1 shows the data capacity with RDS2, when the three additional subcarriers with the compacting technique are used, a significant increase of available data for new added value features becomes available. The increase is between 10 up to over 20 t imes as compared with the current RDS system.

Another way to look at the increased data capacity is that RDS ODA groups in the upper carriers could be using a specific data transfer protocol (byte-oriented, but not yet defined). This will have to be part of further development work to be done in the RDS Forum (see also Section 4.5).


page 10

2 Compatibility issues and new basic features

2.1 Can we really redefine bits in RDS and when is this necessary? (This is a "dead wood" issue)

In the Table 2 below those receiver features can be identified that are “dead wood”.

Table 2 – Marked RDS features identified as “dead wood”

RDS feature Group Usage Intense

Usage Seldom

Usage Never

Future Observations

AF 0A x x

AID (ODA) 3A x x

CI (PI) all x x

CT 4A x x

DI 0A&0B

DI-d0 0A&0B x Mono/stereo

DI-d1 0A&0B x Artificial head: yes/no

DI-d2 0A&0B x Compressed: yes/no

ECC 1A x x Needed for RadioDNS

EG (Linkage)

14A x

EON 14A x x

eRT ODA x x Future potential

EWS 9A x Can be replaced by ODA

EWS id 1A x Can be replaced by ODA

IH 6A&6B x Can be replaced by ODA

ILS (Linkage)

14A x

LA (Linkage) 1A&14A x

LSN (Linkage)

14A x

Language code

1A x

MS 0A&0B&15B x

ODA x x

PI all x x

PIN 1A x

PS 0A&0B x x

PTY all x x

PTYI DI-bit d3 x x Static/dynamic PTY id

PTYN 10A x x

RP 7A x Can be replaced by ODA

RP id 1A x Can be replaced by ODA

RT 2A&2B x x

RT+ ODA x x Future potential

TA 0A&0B&14A15B x x

TDC 5A&5B x Can be replaced by ODA

TMC ODA (8A) x x

TP all x x

NOTE 2: Everything that has no future could be deleted from the RDS standard: The yellow marked features are “dead wood” and those marked green can continue as ODAs.


page 11

2.2 Baseband coding of all Group types

NOTE 3: B groups should in the future exclusively be used for fast switching purposes like 15B and the 14B group for TA EON. Group type 2B for RT will then no longer be needed. The same is true for 0B,1B, 4B and 10B.

Group type 0A: DI-d0 Mono/Stereo; DI-d1 Artificial head; DI-d2 Compressed are to be

deleted

DI-d3 Static/Dynamic PTY remains and it is proposed to change this indicator to PTYI only.

The M/S flag is no longer needed and will be rfu (reserved for future use).

Figure 3 – Basic tuning and switching information – modified type 0A group

Group type OB is “dead wood” and will not be needed any longer.

Group type 1A remains to signal ECC. PIN code can be deleted; so Block D becomes free

and is available for any future Slow labelling code.

Figure 4 – Slow labelling codes – modified type 1A group

1B is “dead wood” and is no longer needed.

Group type 2A Radio Text RT remains unchanged.


page 12


Group type 3A AID ODA remains unchanged. ODA’s signalled in the upper carriers should

use a 3A group associated with them.

3B remains unchanged as well.

Group type 4A CT remains unchanged.


Group types 5A/B TDC will become free and available because TDC can become an ODA.

Group types 6A/B IH will become free and available because IH can become an ODA.

Group types 7A/B RP (Radio paging) can become freely available. RP can be continued as

an ODA.

Group types 8A/B Used as ODA and ODA-TMC (Traffic Message Channel) remains unchanged. TMC services coded on the upper subcarriers may offer more detailed regional information and thus can be added value to TMC services (subject for further development).

Group types 9A/B EWS (Emergency Warning System) can become freely available. EWS

can be continued as an ODA.

Group type 10A PTYN remains unchanged.


Group type 11A/B, 12A/B and 13A/B remain unchanged and are available for ODA.

Group type 14A EON remains unchanged. However, the unused variant (10) can be used for

mapped AF coding for the FM band extension below 87.5 MHz as shown in Figure 10 below.

Group type 15A can be re-assigned to be used for 32 byte long PS codes in UTF-8 as shown

in Figure 6 below.

Group 15B is to be retained, also for backwards compatibility, but has to be modified with

respect to DI, now PTYI only.

New RDS2 features are explained in the following, 2.3 to 2.6.

2.3 Station logo (new ODA-AID)

This requires the definition of a new ODA.

The work to be done is urgent, because this will be needed as a kind of background application for RDS2 to fill the gap when there are no other ODAs to be transmitted and also in between them to let a receiver get the logo after a reasonable amount of time when newly tuned to the programme, say after 5 minutes. Once the logo has been completely obtained, it can be stored in the receiver.

A Specialist Group has still to be created to specify this ODA (deadline for completion of the work to be done: end of 2015). The work can be undertaken by correspondence; the group may also use Skype. However, when the work is approaching the end, one meeting of the group in early 2016 may well be advantageous.


page 13

Some hints for this development are as follows: Basic would be station logos with pictures in the graphic formats gif, jpg or png format and not bigger than 4 Kbyte. Better would be , if the picture could be build up step by step and to the effect that it gets sharper on the receiver display during the transmission cycle. The technique to be used is called “Interlacing”. Some caution is needed with respect to IPR being attached to the finally chosen technique.

For more details see also here:

http://en.wikipedia.org/wiki/Interlacing_%28bitmaps%29 In this special case the “Adam7” algorithm may offer be the best solution, see here http://de.wikipedia.org/wiki/Adam7 or http://en.wikipedia.org/wiki/Adam7_algorithm A good detailed guide can also be found here http://www.vias.org/pngguide/chapter08_07.html

2.4 PS (long) - 32 bytes with UTF-8 coding (new 15A)

Group type 15A can be re-assigned to be used for 32 byte long PS codes in UTF-8 as shown in Figure 5:

Figure 5 – Long PS, UTF-8 coded – modified type 15A group

An obvious advantage is that the long PS will put an end to the use of toggled PS with the OA group.

2.5 eRT - 128 bytes with UTF-8 coding (new AID)

The old AID 6552 will have to be replaced by the new AID 6553. Instead of a text flag a text counter can be used, incremented at each text change and reset when the maximum 63 was reached. At each text change a burst of 3B groups shall be sent.

http://en.wikipedia.org/wiki/Interlacing_%28bitmaps%29

http://de.wikipedia.org/wiki/Adam7

http://en.wikipedia.org/wiki/Adam7_algorithm

http://www.vias.org/pngguide/chapter08_07.html


page 14

3A group:

Figure 6 – New eRT, UTF-8 coded – modified type 3A group

3B group:

Figure 7 – New eRT, UTF-8 coded, Text counter – modified type 3B group

The eRT application group remains unchanged. The character table E.3 in the current RDS standard IEC 62106 ed.3 will no longer be needed, because of UTF-8 coding.

2.6 AF coding for the FM frequency range 76-108 MHz for Brazil and 64 -108 MHz for China etc. (new ODA-AF plus for EON mapped frequencies 14A variant 10)

The new ODA-AF:

The 3A group with the new AID 0x6365

Figure 8 – New ODA-AF– type 3A group


page 15

The new application group for the transmission of AF codes

Figure 9 – New ODA-AF application group – type A group

As we want to cover a much wider range, we shall use with this method 9-bit AF codes. The 8-AF codes in Band II 87.5 – 108.0 MHz are compatible with the AF codes used so far and the same is true for the “special meanings code table”.

Table 3 - 9-bit AF code table for VHF Band II (87.5 – 108 MHz)

Number Binary code Carrier frequency

1 0 0000 0001 87,6 MHz

2 0 0000 0010 87,7 MHz

: : :

: : :

204 0 1100 1100 107,9 MHz

Table 4 - 9-bit special meanings code table

Number Binary code Special meaning

0 0 0000 0000 Not to be used

205 0 1100 1101 Filler code

206 0 1100 1110 Not assigned

207 0 1100 1111 Not assigned

: : :

223 0 1101 1111 Not assigned

224 0 1110 0000 No AF exists

225 0 1110 0001 1 AF follows

: : :

249 0 1111 1001 25 AFs follow

250 0 1111 1010 An L

F/MF frequency follows

251 0 1111 1011 Not assigned

: : :

255 0 1111 1111 Not assigned


page 16

Table 5 - 9-bit AF code table for VHF Band I (64.0 – 88.0 MHz)

Number Binary code Carrier frequency

256 1 0000 0000 Not assigned

257 1 0000 0001 64,1 MHz

258 1 0000 0010 64,2 MHz

: : :

495 1 1110 1111 87,9 MHz

496 1 1111 0000 88,0 MHz

497 Not assigned

: : :

512 Not assigned

Group type 14A EON remains unchanged. However, the unused variant (10) is now used for

mapped AF coding for the other FM Band.

NOTE 4: The mapped frequency codes are 8-bit codes. For Band II these are obtained by deleting the m.s.b. and for Band I deduce 256 from the channel number, e.g. for 64.2 MHz use 258-256=2, thus the 8-bit channel number code being 0000 0010.

Figure 10 – EON group – variant 10 modified type 14A group

NOTE 5: Here is an example to show how the AF coding will work with the Band extension –The AF code table has 512 entries in all. Values 0…255 are identical to current AF coding (Table 2 and 3).

Values 257 …496 contain the frequencies 64.1 to 88.0 MHz in a continuous list starting at code 257 through to code 496, in steps of 100 kHz.


page 17

Part of the list is shown below:

Code Freq Code Freq

117 99.2

373 75.7

118 99.3

374 75.8

119 99.4

375 75.9

120 99.5

376 76.0

121 99.6

377 76.1

122 99.7

378 76.2

123 99.8

379 76.3

124 99.9

380 76.4

125 100.0

381 76.5

126 100.1

382 76.6

EON Variants 5, 6, 7, 8 are used when the Tuned Frequency and the Mapped frequency are both in the SAME ‘range’ (Code range 0-255 OR 256-511). But EON Variant 10 is used exclusively when the Tuned Frequency and the Mapped frequency are both in the OPPOSITE ‘range’, i.e. the OTHER FM Band (which is likely to be rarer).

So, Tuned frequency is 99.5, Mapped frequency is 100.0. Variant 5 used with codes 120 and 125.

Tuned frequency is 75.8, Mapped frequency is 76.6 . Variant 5 used with codes 118 (374-256) and 126 (382-256).

Tuned frequency is 99.6, Mapped frequency is 76.4 . Variant 10 used with codes 121 and 124 (380-256).

Tuned frequency is 76.4, Mapped frequency is 99.6. Variant 10 used with codes 124 (380-256) and 121.

The receiver knows what the tuned frequency is (i.e. if in the higher or lower Band) so depending upon if variant 5 (6, 7, 8) or variant 10 is used, knows in which ‘range’ the mapped frequency falls (variant 5,6,7,8 = SAME range; variant 10 = OTHER range).

(Variant 4 can also be used (method A list) when all frequencies are in the same range) .


page 18

3 Proof of concept

3.1 Demonstrate the power of RDS2 for a number of typical use cases (ensure involvement of broadcasters and manufacturers)

In order to create a wide level of acceptance for RDS2, it will be essential to have a demonstrator available in an early stage of the development process. The main objective is to proof on the table the additional capacity of RDS2 in relation to with the current RDS 1.0.

3.1.1 Encoder

A few prototype RDS2 encoders using a frequency shift box, employing Direct Digital Synthesis technology (DDS), are available from TC Holding (Attila Ladanyi).

3.1.2 RDS2 receiver

Currently a few scenarios are going to be worked out by CATENA for a receiver capable to decode the additional streams. As a first approach three extra RDS decoders, tuned on the additional centre frequencies of 66.5, 71.25 and 76.0 kHz will be used. This development will include application software to communicate the additional information transmitted on streams 1 - 3 to the user.

3.2 Field-test plan to validate RDS2 in a dynamic environment and various reception conditions

As soon as a test transmission is on air, it is important to validate RDS2 in the real world.

From the first implementation phase of RDS, about 25 years ago, a huge knowledge has been built about the reliability of RDS reception under various reception conditions. Field strength is an important parameter, but distortion caused by “Multipath” is the most critical factor for RDS. A valuable amount of statistical data is still available. It is also known that subcarriers higher up in the FM multiplex may show inferior data reception reliability than the current RDS carrier of 57 kHz, see Figure 11 [4].

Figure 11 - Bit error rate for the RDS subcarriers

RDS2 will offer its added value most probably in automotive applications. For this reason it will be extremely important to prove the concept of RDS2 under the various reception conditions which are relevant for proper RDS mobile reception.


page 19

3.3 Test transmission on air

Ideally, a test transmission should be available on a strong FM transmitter and a number of transponders using alternative frequencies, also used as small gap fillers, in a mountainous area.

The RDS reception can be validated at a variety of different reception conditions

1) strong signal

2) weak signal

3) multipath and

4) adjacent channel situations

all randomly occurring in a dynamic reception environment.

3.4 Define a demonstrator / Test vehicle

The most obvious choice for a test vehicle implementation would be using the brand new RX014 from MacBe, designed by RDS Form member Joop Beunders, capable of evaluating all 4 streams

A consideration could be to add more redundancy by repeating the relevant content more often in order to compensate for possible lower RDS performance on the additional subcarriers.


page 20

4 Marketing issues and new Applications

4.1 Why ODAs are so important for RDS2 and why they are “application oriented”

The RDS system of 1984 mainly met the requirements of the public broadcasters with large radio programme networks and to achieve auto-tuning for car radios being driven in these networks.

The 16 groups (0 to F hex, each with variants “A” or “B”) were intended to carry “features” and therefore occupy the available groups already to a large extent. The sixteen variant “B” groups are only partially used, because half of the payload bytes are reserved for the second PI. Half of the “A” groups are used for RDS features and most of them will need to be continued for compatibility reasons. The remainder is not sufficient to program all possible applications of the world. For this reason we need to make RDS more flexible and future -proof. Fortunately, the right tool to achieve this objective existed already and it is called ODA.

For each station are now eight parallel data services with the free groups for ODA possible and for more we do not have at the moment enough capacity on air (2 kbit, net).

Why would we need adaptable applications instead of a group-fixed flow of information?

The history shows us how fast “applications” are becoming outdated and new ones arrive.

In principle, radios and especially car radios become thus after a few years outdated and as in the majority of cases they are an integral part of the dashboard, they are not exchangeable with more modern devices.

The car manufacturers’ answer is the expectation for more computer driven applications as is possible with the "connected car" concept and using smartphone mirroring or binding (not physical integration) so that in the car radio is already often a smartphone connection (physical or wireless) with the Android (or iOS) operating system.

We have to make this new RDS 2.0 standard for the next decades. It would absolutely be an illusion to write this still for the hardware platforms of the past in mind and only using one- or two-line displays.

The vision to be taken should be radio receivers that can accept add-on applications like those used in computers. This concept will also be applicable to DAB as well as for the Internet radio functionality.

In the “good old days” when we still considered real radios, the price of the display was important. Today the display is often an integral part of a multimedia navigation system, although car radios with basic RDS functionality still remain in use for low-end car models.

During the last years touchscreens have been used in many electronic devices, with resolutions ranging between QVGA and HDTV.

Today the installed applications are getting updates almost weekly and even faster new applications are becoming available on the market. Old applications disappear almost exactly as quickly as new ones become available. Anyway these deve lopments are now dynamic and no longer static.

In other words, nowadays “tests” are being carried out in the market with real end -users and not anymore exclusively in the developer’s laboratory. The majority of the end -users accepts this and also expects this way of progressive development that better responds to user needs. Fresh development ideas will thus have priority over perfection. This will become then the ultimate aim to be progressively achieved.

For the radio station’s programming crew the current RDS is nearly useless at the moment. There is not enough flexibility nor usability and also no standardized HMI.

The new RDS 2.0 standard must exactly respond here.


page 21

4.2 Positioning of RDS2 in relation to DAB and HD radio

One can ask the question ‘Do we need a significant increase of data capacity for RDS when Digital radio DAB and to a lesser extend HD radio can offer a larger data capacity than FM RDS?’

The answer is certainly yes. It is expected that RDS will still remain on the air for long time and will mostly co-exist alongside Digital radio implementations for the next couple of decades.

An analogue switch-off is for most countries in the world no option anymore. For a significant number of European countries like Austria, Finland, France, Italy, Spain and the former eastern part of Europe, a full roll-out of Digital radio is far behind the horizon.

In this respect RDS2 is not in competition with ongoing Digital radio implementations.

RDS will always remain the digital part of the analogue FM broadcasting system.

With its new flexibility it will open up new possibilities again where DAB and HD radio can continue to follow on.

RDS2 is also HD radio compatible, because it is still within the 100 kHz ITU-R’s regulation and can also co-exist with other SCA solutions in parallel.

4.3 Promotion of RDS2 to stakeholders

The following promotional activities are considered and will be an issue of discussion with all RDS Forum members

1. A brochure on RDS2 and what it is all about, in early 2016.

2. In addition RDS2 will continue to be promoted on the RDS Forum web site with interesting presentations from the RDS Forum members as well as this feasibility report.

3. On the RDS Forum web site there is already promotion for RDS2 available, see here http://www.rds.org.uk/2010/Future.htm

4. The RDS Forum workshop in 2015 will deal exclusively with RDS2.

5. A special RDS2 workshop will be organised in autumn 2015: This workshop is mainly for non-members of the RDS Forum and for the participation fee to be paid shall be used to finance it. The automobile industry should be invited to attend.

6. An article written by RDS Forum members should be published in the international issue of the Radio World later in 2015.

7. The ITU-R Study Group 6 shall be informed via the IEC TC 100 about the upcoming new RDS 2.0 standard version. This should be arranged for autumn 2015 with the help of the IEC Central Office in Geneva.

The RDS Forum should also arrange that RDS2 is presented at national and internat ional conferences dealing with the future of FM radio, such as the SET Expo in Brazil in August 2015, the “Salon de la Radio” in Paris in early 2016 and CES Las Vegas in January 2016 as well as the IFA Berlin in September 2016.

4.4 Added value TMC services: Urban and inter-urban Traffic services and Weather information for travellers

A good example where RDS2 can prove its added value is Traffic Information provided by RDS-TMC.TMC is nowadays very much a motorway oriented service. However, now location tables with a much higher level of detail can be used to support messages for more road classes and specifically for large urban areas like Paris, London, Munich and Berlin.

http://www.rds.org.uk/2010/Future.htm


page 22

Currently the limited data capacity in RDS simply prevents the transmission of all this information on FM radio.

RDS2 will offer new opportunities for a better and richer TMC service.

We observe that infrastructures in large urban areas for signalling traffic information already use a fully automated data collection process, which has been improved significantly over recent years. However, up to now the constraints within RDS have clearly imposed those limitations caused by the available data capacity for the RDS-TMC services.

4.5 The World Broadcast Web: FM with a standardized user interface

Until now, all services were addressed to a special hardware. A service was inevi tably defined for the whole world regardless of the usability. In reality, this concept works only for special cases. This approach has also unfortunately prevented that broadcasters can define and operate their own data services, involving editors and programme makers. The programming team in the radio station was so far not creatively involved working with RDS.

As one can see on the Internet, only services are really provided, not at all fixed on a bit pattern that the receiving device has to implement as unalterable. In the Internet a browser is used for receiving different applications on the same screen like Firefox or Explorer. We need urgently something like this to be installed inside the FM radio receiver.

If the programming crew of the broadcast studio wanted to create applications, this would introduce an ongoing process. To use this potential, we shall no longer transfer only data that are related to the internal RDS structure but need now to define in addition a universal data transfer protocol. As such the protocol would be of a general nature and be applicable to all ODAs and it should also be application-agnostic. Similar to other transfer protocols , the RDS Forum could then call this technique “RPEG” (derived from RDS Protocol Expert Group).

With RPEG one could implement a database to be used for database transfer, without the need to deal with different aspects of the RDS protocol , just in a similar way as the WYSIWYG (“What You See Is What You Get“) development of services for the Internet.


page 23

5 UECP adaptation

5.1 RDS2 encoder concept and model

An RDS2 encoder is composed of an RDS1 main stream encoder for the basic subcarrier and three RDS encoders for the three upper streams 1 to 3. For the upper streams frequency shifting is used subsequent to data encoding being done for a 57 kHz subcarrier . Streams 1 to 3 can all be enabled or disabled as required by the transmission operator. To achieve this functionality, a new control and set-up command is required in the UECP [5].

All RDS features are transmitted on the basic stream 0. The only exceptions are ODAs which can be transmitted on the main stream for compatibility reasons or on the upper streams , if no backwards compatibility constraints apply.

5.2 Hardware model

For RDS2 no change of the hardware model appears to be required.

It shall be possible in the future to offer a choice between two options, the RDS1 encoder alone and the RDS2 encoder, which is composed of four RDS encoders, one for the main stream and three for the upper streams.

Both encoder unit types will require to be adequately marked as RDS1 and RDS2.

Both units are always only within one single encoder box that the UECP can easily address in the same way, as already is done now.

5.3 Software model

For RDS1 the software model requires to be updated to take account of dead wood issues, modified RDS features, like the PTYI, and new RDS features and groups, like the long PS with the new group 15A. Apart from these adaptations the current software model remains valid.

For RDS2 and only for the upper subcarriers the Software model will be different. As it will be used only for ODA transmission, it does not require separate Data sets. So, the RDS2 software model will be much simpler for subcarriers 1 to 3. However, one has to ensure that the same PI code is used for all streams. This is the PI code of the active Data set in the main RDS stream 0. Also, for the basic stream the same RDS1 software model applies.

5.4 Addressing method

For reasons of backwards compatibility the current addressing method shall not be changed. Thus RDS2 encoders can only be addressed as one encoder box and not for the four RDS encoder modules individually.

To address the individual RDS2 encoder modules for the upper streams, new command messages must be defined.

5.5 Handling of ODA data

5.5.1 Concept

For RDS1 everything will remain as it is now.

For RDS2 the ODAs can either use RDS1 distribution on the main stream 0, also for reasons of backwards compatibility or instead exclusive distribution on the upper streams, either on all streams or only a single specific one. The data to be distributed must then also be adequately buffered. Thus, if the transmission is done via all streams, a common buffer must be used for the streams 1-3and if a specific stream is used, then it will have to use its associated buffer.

3A groups defining the ODA and the corresponding application groups belong together and must be distributed together on the same stream, either a specific one or all upper streams together. This can be achieved via the two kinds of upper stream buffers, the common or the stream specific one.


page 24

5.5.2 Required ODA commands.

ODA configuration and Short Message Command (MEC 40) will be valid for RDS1 only and a corresponding new command for the ODA configuration on the upper streams will be needed.

ODA Identification Group usage sequence (MEC 41) is specific to RDS1. For RDS2 an equivalent command will not be needed as a specific group sequence is not required. RDS2 can use instead FIFO.

ODA Free Format Group (MEC 42) and ODA Relative Priority Group Sequence (MEC 43) are outdated and no longer needed for RDS1, which will have to use MEC 46 instead. MEC 42 is also not needed for RDS2.

ODA “Burst Mode” control (MEC 44) and ODA “Spinning Wheel” timing control are for RDS1, but no longer used; these commands should be retained nevertheless, as they can be useful.

ODA data command (MEC 46) will be valid for RDS1 only and a corresponding new command for the ODA distribution on the upper streams will be needed.

ODA Data Command access right (MEC 47) appears to be suitable already for both, RDS1 and RDS2.

5.6 Adaptations needed for stream 0

Everything described above in Sections 2.2, 2.4 and 2.6 will require new (or instead adapted) UECP message commands to be created.

5.7 Further action required

A Specialist Group has been created during the 2015 Forum’s meeting to undertake the adaptation of the UECP specification (deadline for completion of the work to be done: end of 2015). The work will be undertaken by correspondence; the group may also use Skype. However, when the work is approaching the end, one meeting of the group in early 2016 may well be advantageous.

The new UECP version shall be backwards compatible and thus shall be usable also on old encoders.


page 25

6 Intellectual Property Rights Statement

RDS2.0 technology is based on the principle of multiple modified RDS subcarriers between 60 and 100 kHz in the FM multiplex. This patented technology has been developed by T&C Holding in cooperation with Hungarian technical universities and tested with the Hungarian radio. Investments have been done since 2009 to prove the feasibility and robustness of the concept. Demonstration boards have been built and used to present the concept to the RDS Forum. Mr Attila Ladanyi from T&C Holding holds IPR with patent DE 10 2010 022 011, and several other patents are pending. It is seen as reasonable and fair to charge the RDS2 decoding devices with a small fee, in order to earn back a part of the investments done by T&C Holding and other stakeholder. It is not the intention to charge Encoder manufacturers for the use of RDS2 technology. This will also be the case for Service providers and in this context, are also both Public and Commercial Broadcasters included. At the moment various scenarios are going to be worked out and discussions are ongoing with an industry partner and active RDS Forum member for a leading role to licence the RDS2 technology. Attention is drawn to the fact , that development work in the RDS Forum for both, the new IEC 62106 standard as well as new features and applications running under an ODA are subject of the open publication policy from the RDS Forum. When a submission is made, the person/company making the submission must sign an IPR statement to declare that the technology, if protected by patents, will be available on free an equal terms. At the upcoming RDS Forum meeting in June the issue will be presented and dealt with in detail.


page 26

7 Standard development concept (RDS & RBDS)

7.1 Proposed new RDS standard structure

Figures 12 and 13, below, show a basic concept for arriving at a new structure for the RDS 2.0 standard version, IEC 62106 (unchanged reference number). New is that the RDS 2.0 standard will consist of five parts that wil l be separately maintained. This will have also the advantage of a simpler maintenance, hopefully also increasing the speed for finalisation and increased transparency for all involved.

As the RBDS standard only shows the differences with respect to the RDS standard, there is an opportunity to integrate it fully as Part 6. Alternatively, there will be at least the need to correctly cross-reference to the planned new IEC RDS 2.0 standard version. The RDS Forum has created in June 2015 a liaison and is committed to collaborate with the NAB and the CEA, to achieve this adaptation and also liaise with the RBDS Subcommittee.

Figure 12 – As “Applications” dominate the pyramid there is a need to re -structure the RDS standard and to adapt it to software development requirements


page 27

Figure 13 – Proposed new RDS 2.0 standard structure

Part 4 groups together all Tables with their national and regional variants, like the PTYs, and also the PI-CC / ECC country Tables that require regular updating, because of changing country designations and consequently new country and ECC codes. Also, the receiver profiles in section 8.1 of this report appear to be country or world -region specific (e.g. different for the European Broadcasting Area and for RBDS in North Americ a - USA, Canada and Mexico).

Table 6 details the proposed new structure of the future RDS 2.0 IEC standard 62106. Here it is shown how the current structure of the RDS standard can be arranged for usage within the newly proposed RDS 2.0 standard structure.

In conclusion, IEC 62106:2000 (first edition), IEC 62106:2009 (second edition) and IEC 62106:2015 (third edition) have the same main text and annex structure. However, this fourth edition will be differently structured and will consist of five or six parts.

Part 1: RDS system overview: Modulation characteristics and baseband coding

Part 2: RDS message format: Coding and definition of RDS features

Part 3: Coding of Open Data Applications

Part 4: Coding of tables

Part 5: Marking of RDS1 and RDS2 devices

Part 6: RBDS (proposed as an option to the RBDS Subcommittee)


page 28

Table 6 - Proposed new structure of the future RDS 2.0 IEC standard 62106

Current IEC 62106 structure / Proposed new structure

Part 1

Part 2

Part 3

Part 4

Part 5

Delete a

Introduction X X X X X

1 Scope X

2 Normative references X

3 Abbreviations X

4 Modulation characteristics of the data channel (physical layer)

X

5 Baseband coding (data-link layer) X

6 Message format (session and presentation layers) X

7 Description of features X

8 Marking X

Annex A (normative) Offset words to be used for group and block synchronisation

X

Annex B (informative) Implementation of the modified shortened cyclic code

X

Annex C (informative) Implementation of group and block synchronisation

X

Annex D (normative) Programme identification codes and extended country codes

X X

Annex E (normative) Basic and extended RDS character sets

X

Annex F (normative) Programme type codes X

Annex G (informative) Conversion between time and date conventions

X

Annex H (informative) ARI (Autofahrer-Rundfunk-Information) system

X

Annex J (normative) Language identification X

Annex K (informative) RDS logo X

Annex L (informative) Open data registration X

Annex M (normative) Coding of Radio Paging (RP) X

Annex N (normative) Country codes and extended country codes

X

Annex P (normative) Coding of RadioText Plus information (RT+)

X

Annex Q (normative) Coding of enhanced RadioText (eRT)

X

Annex R (informative) RBDS in the USA X

Annex S (normative) List of RDS specific abbreviations X

Bibliography X

New:

Station logo (max 4Kbyte) X

Long PS name (UTF-8 coded 32 bytes) X

new AF coding with new FM Band limits X

new eRT (UTF-8 coded 128 bytes) X

a Delete: “Dead wood” from IEC 62106ed3 (2015)

7.2 Further action required

A Specialist Group has been created during the Forum’s 2015 meeting to undertake the creation of the new RDS 2.0 standard (deadline for completion of the work to be done: end of 2015). The work will be done by correspondence. However, when the work is approaching the end, one meeting of the group in early 2016 is necessary.

The same group could also elaborate, in collaboration with the RBDS Subcommittee, a proposal for adapting the RBDS standard to RDS 2.0 and deliver it back to the US NRSC RBDS Subcommittee for further action.


page 29

8 Receiver profiles, marking and certification requirements of RDS2 devices and compliance testing

8.1 Receiver profiles

Table 6, below recommends the usage of RDS features applicable to various types of FM/RDS receiver, described by the following generic descriptions:

Hi-Fi – Typically a mains powered non-portable device used within a home (living room etc.).

Portable – Typically a battery/mains option device for use in kitchen/bathroom etc. which may on occasion be taken outside or (for example) on holiday.

Smart/Tablet – Smartphone or Tablet device with integrated FM tuner.

Car Radio – A single or multiple-tuner receiver mounted within the vehicle dashboard, used

for audio reception (i.e. excludes any integrated TMC function).

TMC – A separate hand-held PND TMC receiver or the TMC part incorporated with in a car radio/navigation system.

Table 6 – Usage of RDS features in various receiver types

M: Mandatory R: Required D: Desirable O: Optional - Not considered as a principle feature, however can be added to justify a

price point in the market in comparison with competition

Feature Hi-Fi Port-able

Smart/ Tablet

Car Radio

TMC

AF Da R O M R

b

CT D D Oc M M

d

ECC e D D R D D

PI-Extended Generic O O O D R

PS (short) EON-PS (short)

M O

R O

M O

M D

Regionalisation g D D D M

PS (long) D D R R

PI is mandatory to implement for all RDS products f.

a AF is useful even for a fixed location device (in a simplified form) as it will ensure the device is using optimum

frequency if same station is available from more than one.

b Used in addition to Tuning Information with TMC Group (TI).

c Connected devices that are synchronized to the mobile carrier's network will always be at least few seconds off.

The time tolerance in the NITZ standard for mobile networks is in the order of minutes, not seconds or milliseconds. Many mobile devices can be manually re-configured to synchronize time via another source (such as

NTP or SNTP server), but some devices cannot be re-configured, or the end-user does not care to change it.

d In order to sync with traffic message expiry times etc

e Required for RadioDNS;ECC and PI-CC uniquely identify country world-wide.

f PI-CC, the PI country code, is used to uniquely identify country together with ECC.

g Capability to identify Regional networks and programs. Product reacts up to customer expectation . The radio shall

identify the generic PI structure and use the regional AF information.

http://en.wikipedia.org/wiki/NITZ

http://en.wikipedia.org/wiki/Network_Time_Protocol


page 30

Table 6 continued - Usage of RDS features in various receiver types

Feature Hi-Fi Port-able

Smart/ Tablet

Car Radio

TMC

Programme logo h D D D D

PTYI i

PTY SELECTION j

PTY STAND-BY/EON

D O

D O

D O

D O

PTY-31 k

(ALARM) EON

M R R M Dl

PTYN m

O O O O

Regionalisation D

Service Following FM & DAB

n

M

RT o

RT+ o

eRT p

R O O

R O O

R D

r

O

Rq

D O

TP EON-TP TA EON-TA

Ds

O D

s

O

Ds

O D

s

O

O O O O

M M M M

TMC TMC-SPN TMC-TI

R D R

t

h RDS2 receivers only.

i PTYI has some limited application if PTY Standby feature is implemented.

j PTY descriptions available in multi-languages, preferably selectable by user.

k Receiver should ‘awake’ from standby mode and break with alarm announcement into audio with pre -set

increased volume.

l In a TMC device, although audio will not be presented, a display indication that there is an ‘Alarm’ will prompt the user to be alert.

m Display functionality only.

n Only for multi-standard receivers; the relevant info is carried in DAB.

o Radiotext and RT+ in widespread use.

p For RDS2 only: eRT not yet widely implemented, but needed for specific markets .

q For in-car use, the ability to disable the RT display should be provided.

r For RT+ exist a wide range of classes, but among them, apart from item ‘title’ and ‘artist’ is one that will be v ery attractive, i.e. the web address for the radio programme’s home page.

s Even in ‘home’ devices, the ability to identify and receive Traffic information is useful.

t All Tuning Information variants 6,7,8,9 & 10 should be supported plus AF in 0A groups ( when AFI bit set).

Comprehensive TMC implementation guidelines are separately available.

8.2 Marking on receivers, packaging and documentation

The following marking shall be used on receivers, packaging and documentation:

RDS1 if upper streams cannot be demodulated RDS2 if upper streams 1-3 can be demodulated NOTE 6: The old RDS logo from previous versions of the RDS standard shall no longer be used.


page 31

Receivers are in conformity with the marking “RDS1” if they implement the RDS group decoding listed in Table 7, below by using decoding only on stream 0.

Table 7 - Groups to be decoded by receivers marked “RDS1”

Group Hi-Fi Port-able

Smart/ Tablet

Car Radio

TMC Comments

0A – basic tuning 1A - slow labelling 2A - RadioText 3A - ODA 4A - CT 8A - TMC 10A - PTYN 14A/B - EON 15A/B – PS (long)

M M M O* D

O R O

M M M O* D

O R O

M M M O* D

O R M

M M M M* D

O M M

M M

M

M

To uniquely identify country together with ECC *Required for RT+ and the new AF lists format (see Section 2.6)

Receivers are in conformity with the marking “RDS2” if they implement the RDS group decoding listed in Table 8, below by using decoding on all four streams.

Table 8 - Groups to be decoded by receivers marked “RDS2”

Group Hi-Fi Port-able

Smart/ Tablet

Car Radio

TMC Comments

0A - basic-tuning 1A - slow labelling 2A - RadioText 3A - ODA 4A - CT 8A - TMC 10A - PTYN 14A/B - EON 15A/B – PS (long)

M M M M* M

R M M

M M M M* M

R M M

M M M M* M

R M M

M M M M* M

R M M

M M

M

M

To uniquely identify country together with ECC *Required for all public ODA-AID groups including those on streams 1-3

NOTE 7: RDS1 is an open technology that can be freely used. RDS2 is a licensed technology from T & C Holding, Germany, see Section 6.

A physical or online data interface (e.g. USB) is desirable to permit listeners to update or install in RDS2 radio receivers new application software to be used for decoding new ODAs. Certification requirements Normally, self-certification is recommended. A compliance test is optional.

8.3 Compliance test

For the receiver manufacturer a proposed option is that a qualified RDS Forum member makes a compliance test, also on the basis of the IEC standard 62634, for a fee to be mutually agreed. Particularly for car radios and TMC receivers a drive test in a defined area may be part of the evaluation.

An important issue is also the capability to select correctly the proper AF with the best audio quality. If applicable, identification of Regional programmes and corresponding switching within the relevant radio programme networks can be tested.

Contact the RDS Forum Office in Geneva, Switzerland, for help in arranging these kinds of tests.

NOTE 8: The certificate issued can only be used for the specific receiver model tested.


page 32

9 Frequently Asked Questions

Q 01 – Why discrete carriers are used instead some spread spectrum like modulation technique? All carriers are derived from the 19 kHz pilot tone, which allows block and bit synchronisation

between the RDS carriers. The existing modulation technology is very robust. RDS2 suppor ts all

current applications and existing RDS devices. Anyone who wants to upgrade just need to replace a

chip, the entire product design and basic software remains as is.

Q 02 –The RDS “1” is also locked to the pilot in phase; so what about RDS2 – can phase locking there be applied as well and if yes, how? An important requirement for proper RDS2 decoding is phase and bit synchronisation with the groups

and blocks in the mainstream. This is achievable with DSP technology. At the encoder all carriers are

derived from the 19 kHz pilot tone. RDS2 modulation is using next to 57 kHz three additional

subcarriers. They are achieved using frequency shifting.

Q 03 –What are the differences between RDS1 and RDS2?

RDS2 offers three additional RDS streams. As a number of mandatory elements from the main stream

such as AFs, PS and PTY.do not need to be present in the upper streams, RDS2 can achieve about 15

times more net data capacity compared with RDS1.

Q 04 – How can RDS2 increase the RDS-TMC capacity? By using ODA on the upper carriers with high quality detailed traffic information for urban and

specific regional areas.

Q 05 –How can we achieve that TMC device manufacturers use the RDS-TMC on the additional subcarriers in EXACTLY the same way as on the main subcarrier? By means of a special TMC ODA. Existing PNDs devices with a new RDS2 external receiver can then

receive a translated ODA data stream, e.g. from 9A to 8A. The original PND software may remain

unchanged. However, the number of 8A groups then increases from 3 to up to 45 per second.

Q 06 –On RDS is no IPR. If there is IPR on RDS2 –what will be the consequences for broadcasters, encoder manufacturers, chip makers and manufacturers of receiving devices? There will be no charges for broadcasters and encoder manufacturers. Only the RDS2 chip or key

component will be charged with a moderate fee on fair and equal terms for receiver and device

manufacturers.

Q 07 –What advantages and innovation could RDS2 offer to the car radio industry? First of all RDS2 can offer a much better TMC service with more detailed urban traffic information.

Second, there can be attractive display information like station logos. Third, there can be local or

regional information for special events or emergency warnings. Graphical features can also be used

for more attractive commercials. RDS2 can also be used to update the car radio with new features and

apps over its live time. Soon, we shall have connected cars. Thus, "remote update" functionality is

important, not only for car radios, but also for the FM/RDS radio in smart phones.

Q 08 –Can TPEG be used on RDS2? No. However, with the RDS-TMC ODAs automatically translated TPEG TEC (Traffic Event Compact)

messages can of course be carried also over RDS2, compared to RDS1 with a much increased speed

and total message transmission capacity. This may well need some form of adaptation of the existing

ODAs for TMC, an issue still to be studied.


page 33

Q 09 –Why would chipset makers be interested in the RDS2 implementation? It will create significant added value, and quantities may rise extremely fast since RDS2 is basically

an extension of RDS1, which itself is mature and well established. Through new products new service

opportunities are created. Broadcast real time data services are s ignificantly better for a lot of

applications. This can boost the entertainment and advertising, and allows also for new radio show

formats.

Q 10 –Could RDS2 be used as a means to achieve Service Following with the Internet included? Yes, it can give direct information via a new ODA and how to find back your favourite station on the

Internet. RDS2 will include the treatment of the Internet connection as an alternative frequency.

Q 11 – What are the recommended injection levels for RDS2? Between 1.5 to 3.5 kHz, for each carrier.

Q 12 – Would RDS2 work for FM radio received on smart phones? In principle, yes. However, the RDS propagation for the upper carriers must be tested thoroughly for

smart phones with their commonly used (and sometimes built -in) FM antennas. RDS2 has been

designed also for smart phones a as receiving device. Some work without a headset and with separate

speakers. However, today most smart phones use the head phone cord as an antenna. As smart phones

developed into universal communication devices, more broadcast data will be a logical extension.

Q 13 – In the USA, HD-Radio and occasionally SCA are used; is RDS2 compatible with them? Since RDS2 developments are only very recent, no real tests on air have been made so far. Thus, the

answer is based on assumptions only. With 92 kHz SCA, probably yes, and with 67 kHz SCA no.

However, with RDS2 individual subcarriers can be also be switched off. Thus RDS2 maybe be usable

with 67 kHz SCA at least with one additional subcarrier on 76 kHz. HD-Radio is also a target for

some new functions. Some simple tests will be required soon to show that there are really no major

problems. The RDS Forum will keep the RBDS Subcommittee informed on all observations made

during over the air tests.

Q 14 – In RDS2 there will be enhanced Radiotext and in RDS we have also RT. Why twice Radiotext? Enhanced Radio text goes far beyond the character set which is available for RDS1. With UTF -8

coding almost all languages (Arabic, Chinese Russian, etc.) can be cover ed. UTF-8 needs more data

capacity which RDS2 can cope with. The eRT can also be used for longer ASCII text, up to 128 bytes.

Q 15 –Will RT+ work with enhanced Radiotext on RDS2? Yes, with some restrictions, however. However it may be preferable to crea te a version supporting all

possible 128 characters and also using more than two tags. The possibilities to achieve this have not

yet been studied.

Q 16 – What about the RDS propagation for the upper carriers at dynamic reception conditions? Theoretically this will be a bit less reliable. Extensive field trials will provide more clarity about this

in practice. In case the reliability of RDS reception needs to be improved, additional redundancy, by

repeating data more frequently, may be added.

Q 17 – Who will validate the performance of RDS2 on the road? A team from the RDS Forum with involvement of IC development and production companies and the

manufacturers of car radios in association with the car industry.


page 34

Q 18 – How will this performance be communicated in objective and measurable terms? By publishing measuring data and results from field trials. The performance will most probably be

expressed using comparison with the RDS performance on the main carrier.

Q 19 – How is RDS2 positioned in marketing terms next to DAB+? RDS2 is an FM radio extension, available on frequencies from 64 to 108 MHz worldwide (and on the

Internet. As a worldwide available radio application RDS2 offers much added value when compared

with RDS1. RDS2 is not meant to be a competitor for DAB+. Both can co-exist.

Q 20 – Is RDS2 possible as a running change on an existing platform? Time needed to market RDS2 can be short for a number of reasons and this is an asset for RDS2. In

certain cases no hardware changes are needed, only software. Probably a software update over the air

would be possible in some particular cases.

Q 21 – Would an existing RDS receiver be completely unaffected by an RDS2 transmission? Yes. All existing RDS features remain available. New features and se rvices will exclusively use ODA

Backward compatibility with RDS1was a major pre-requisite for the RDS Forum.

Q 22 – Would a broadcaster need permission from their regulator to switch from RDS to RDS2? Yes – but RDS2 complies with existing ITU regulations as far as the injection levels of audio, pilot

tone and additional RDS data is concerned. Therefore, permission to use RDS2 on air for

experimentation and/or a regular service may be obtained.


page 35

10 References

[1] Recommendation ITU-R BS.450-3: Transmission standards for FM sound broadcasting at VHF (2001)

[2] RDS standard IEC 62106 ed.3 (2015) [3] xRDS, Radio Data System with increased data rate / by Peter Jako and Attila Ladanyi –

doc. SR2/009_1 [4] xRDS calculations / by Dr. Istvan Standeisky and Dipl. Ing. László Gyimesi – doc.

SR2/010_1 [5] UECP - SPB 490 v. 7.05, RDS Universal Encoder Communication Protocol – RDS Forum

Specification, (February 2010) [6] US NRSC-4-B, National Radio Systems Committee – NRSC-4-A: United States RBDS

standard, (April 2011)

feasibility report on rds2 development issues fully ...feasibility report on rds2 development issues...

Documents