Enhanced RT ODA support?

[Rían Mac Guinneál (fmdx.ie)]

Will RDS Spy ever support the Enhanced RadioText (eRT) and Enhanced RadioText plus (eRT+) in the future?

I understand it is not implemented commercially, but I did implement it in my prototype encoder which works in other decoding softwares such as RDS Surveyor.

ODA : Radiotext+ for eRT [4BD8]
ODA : eRT (Enhanced RadioText) [6552]

Would it be possible to implement this? 

[andrew01]

It would also be really nice if the RDS Encoders would also have these options available, not only RDS Spy. 

[Rían Mac Guinneál (fmdx.ie)]

Here is a sample of eRT and eRT+. The recording is long enough to observe 3 messages with 2 different tags.

[Jan]

The eRT is an ODA application, so it can be broadcast using existing encoders via the UECP protocol, just like some stations broadcast RT+.
I am ready to give it the highest priority and directly implement these features to all products within a few weeks. However, it seems that the RDS2 technology (incl. logo and eRT) has been rejected by car radio manufacturers. Until their approach changes, it is unlikely that we will continue to implement software features that will not be useful in practice. Of course, we value our users. We try to accommodate them and we are constantly working on improving features that have daily benefits. Integral part of this activity is the ability to put things aside that may well represent a dead end.
By the way, we gave the RDS Spy a simple API interface. A skilled programmer can write an eRT plugin in a few days if there is real interest.
I understand that you probably expected a better answer, but I hope you will at least appreciate my honesty

[Rían Mac Guinneál (fmdx.ie)]

I am ready to give it the highest priority and fully implement these features to all products within a few weeks. However, it seems that the RDS2 technology (incl. logo and eRT) has been rejected by car radio manufacturers. Until their approach changes, it is unlikely that we will continue to implement software features that will not be useful in practice. Of course, we value our users. We try to accommodate them and we are constantly working on improving features that have daily benefits. Integral part of this activity is the ability to put things aside that may well represent a dead end.
By the way, we gave the RDS Spy a simple API interface. A skilled programmer can write an eRT plugin in a few days if there is real interest.
I understand that you probably expected a better answer, but I hope you will at least appreciate my honesty

Thanks for the honesty. At least from my experiments it works in Skoda and VW cars.

[Jan]

Yes, the eRT is "only" an ODA application which has existed for a long time. However, for practical operation of this function, you encounter the limit of the transmission capacity of the original RDS. For this reason, the latest edition of the RDS standard does not even consider the option of transmitting eRT within stream 0. This is logical, because the transmission capacity is just right even with classic RT and since eRT is not backward compatible, both must be transmitted.
Without full support for RDS2 on the receiver side and without explicit acceptance of this system by the authorities carrying out technical supervision, we will probably not be able to move forward. Although radio stations were expected to be the driving force behind this development, the opposite is true. To this day, most stations are unable and unwilling to broadcast even RT+, which is a 20-year-old feature... There is almost zero interest in the eRT from the stations. The fact that eRT can sometimes transmit slightly longer text is probably irrelevant. The radio industry is more focused on keeping messages as short as possible, while providing more information via hybrid radio services. The eRT+ is still limited to 64 characters - no progress here. I see the real benefit of the eRT in Unicode support, which is unfortunately proving to be a marginal topic for the part of the world where FM broadcasting is widespread. There could be some benefit in countries where an alphabet other than the Latin is used.

[andrew01]

It would be nice to have the eRT/eRT+ function available on the RDS encoders, maybe not everyone will use it, but if some receivers (2 car brands are a big thing/chunk of tuners, honestly) can support it, why not include it? Besides, 128 UTF-8 bytes are a big thing compared to normal RT's 64 characters.

Through RDS1, eRT/eRT+ seem to work fine (no issues with decoding on a external decoder application), with the only disadvantage being that it "eats" % of other groups.

[Jan]

As a manufacturer, we will not go against the currently valid standard. It would not even be technically possible if we want to maintain the quality level of the current functions. The encoders support the UECP ODA protocol, so developers have the opportunity to try it out.

IEC 62106-6

Coding of enhanced RadioText (eRT)

Broadcasting conventions

"The transmission capacity of RDS is not sufficient to use normally RT and eRT at the same time on stream 0, i.e. it shall be either one or the other RadioText mode. If RDS2 is used, eRT can be on the upper streams and RT can be at the same time on stream 0."


I understand your effort. This however needs to be directed at car radio manufacturers so that they finally implement RDS2.

[andrew01]

RDS2 might never be of interest within car manufacturers because of very few users of RDS2 in general (at least that is how I see it, in my country we have only 3 STATIONS using RT+, and 2 using Long PS, which are part of RDS1). Many regulators do not agree with going over 75khz for extra RDS carriers. It is true that radio is not of interest for car manufacturers (the interest moved to streaming apps), for example new tuners from various brands, have a database based on the PI Code so they don't have to show the current RDS-PS (this way they can fit the full name and not be constrained to RDS-PS's 8 character capability), only if they don't have it in their database, then RDS-PS will be shown.

Still, coming back to eRT/eRT+, if it can be added to the existent RDS2-capable encoders, I don't see why it shouldn't be included, the few users who use RDS2 are users who would love having every single function available to be sent

[Jan]

We have been trying for years to convince radio stations to stop using dynamic or scrolling PS. One reason is that car radios cannot correctly display the PS name in the list when scanning the band. Car radio manufacturers solved it in their own way and no longer display PS at all 

Another crazy thing is the abuse of station names in DAB, where stations insert various characters to appear at the beginning of the list. The resulting list sometimes looks terrible. It wouldn't surprise me if after some software update they end up at the bottom of the list or aren't shown at all.

[andrew01]

The same abuse logic on DAB+... works on FM, I have seen here radios insert characters such as <,>,!,* and they are all shown on top of radio lists. Dynamic/Scrolling PS use is a problem everywhere , except in places where the use of such practices is banned by regulators (like France, Slovakia, and a few). Some tuners like the one I have, also memorise parts of dynamic PS's (like a frequency or a fragment of artist - title info), without it being updated unless the text is static for a period of time, it creates a huge mess when trying to find a station because of this.

Coming back on topic, is eRT/eRT+ confirmed to be implemented in the RDS2 capable encoders and RDS Spy?