0x0D issue in Magic RDS

[mrandrew01]

Hello! I have noticed a very small "fault" if you could say with the carriage return character 0x0D, that being the addition of spaces before the 0x0D character. Implementation from other known brands include 0x0D as the first character in the 2A group, and afterwards how many spaces are needed to fill the group.
EXAMPLE : Benassi_Bros._Feat._Dhany_-_Hit_My_Heart___<0D> could be : Benassi_Bros._Feat._Dhany_-_Hit_My_Heart<0D>___

[Jan]

You have a great observation. This is not a fault, it is an implementation from a time when it was more convenient to do it this way for compatibility with some old receivers. Receiver support for shortened text has not always been very good in the past. You are right that today there is probably no reason to place the CR character always at the end of a segment.

Given that today the most widely used RDS encoders are probably from our production, we are reluctant to change any detail that has been set in some way for 20 years, so as not to unintentionally influence something. However, if a different opinion prevails, a change is of course possible.

[mrandrew01]

Perhaps, it can be a separate option on how the end user wants the CR character to function, 0x0D then spaces, or spaces then 0x0D bit , also... there are many users who probably don't have the latest firmware (example offline broadcast sites, etc.)

Also, unrelated to car tuners, but on the fm-dx webserver platform, when 0x0D is detected, the radiotext field gets centered, adding spaces "ruins" that spacing.

Now, related to car tuners, many have their own "way" of implementing the RDS spec, some maunfacturers don't account if the RT field even properly ends with 64 characters, or 0x0D,they will show the text that was decoded  (skoda,vw), or DPS not being accounted sometimes for safety... etc. There are many examples of DOs and DON'Ts, but if we had to account for all old tuners, with outdated specs, or careless implementation... we would have been removing 99% of features

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

Perhaps, it can be a separate option on how the end user wants the CR character to function, 0x0D then spaces, or spaces then 0x0D bit , also... there are many users who probably don't have the latest firmware (example offline broadcast sites, etc.)

Also, unrelated to car tuners, but on the fm-dx webserver platform, when 0x0D is detected, the radiotext field gets centered, adding spaces "ruins" that spacing.

Now, related to car tuners, many have their own "way" of implementing the RDS spec, some maunfacturers don't account if the RT field even properly ends with 64 characters, or 0x0D,they will show the text that was decoded  (skoda,vw), or DPS not being accounted sometimes for safety... etc. There are many examples of DOs and DON'Ts, but if we had to account for all old tuners, with outdated specs, or careless implementation... we would have been removing 99% of features

I second this. 💯

[Jan]

I completely understand your point of view and we will take your comment into consideration at the earliest opportunity. But there are other points of view as well.

With all due respect, these systems are designed for other use than hobby DX reception. By the way, it's a nice hobby that I also pursued. Various incompatibilities and proprietary solutions of commercial FM receivers are a long-term problem which is an obstacle to development of new RDS services. Some "features", such as the completely unexpected truncation of Radiotext on some new car radios, prove that the developers have probably gone completely crazy.

We introduced the RT+ service, Long PS or broadcasting of diacritical marks (ěščřžý etc.) here in the Czech republic. Although majority of stations here can use these options today, only a small portion of them actually do it. They could simply turn it on with a few clicks, but they won't. I say this just to illustrate who is actually stuck in a time decades ago. Many stations incl. the public service radio still rely on deprecated dynamic PS. They are still convinced that they have reasons for this. Change is usually met with great displeasure. I don't blame anyone, it's just a fact.

[mrandrew01]

Definetly. Change is one of the hardest things to do, even outside of radio. New car multimedia systems are a huge (and buggy) mess, software developers don't care about these technical details regarding radio (such asa proper RDS implementation, proper AF, etc.) as much as they did maybe 15 or 20 years ago, when radio was the most popular way to find new music. Many people now who will listen to music in their new cars would choose streaming platforms via Android Auto and Apple Carplay, the shift has moved to making sure those have full compatibilty and can seamlessly work.

I have my fair share of experiences with stations, last year I have mailed the technical department of a national broadcast chain to add dynamic info in their stations' RT via UECP, I was only met with the fact that "they are marketing their RT" (by showing static KISS FM in RT, and dynamic PS cycling station name and frequency), and that such info is useless. Many technicians here in Romania care only if the station has audio. Using your RDS to the maximum, or even properly setting up PI codes is sadly optional :'(

Looking forward for the change regarding 0x0D, hopefully including both the old and new ways as a toggle like "Reverse CR character 0x0D assignment order", for whoever likes having one way or the other. 
Thank you for your fast answers!