What's That Weird Symbol On My Radio's Display?

Have you noticed a weird character on your radio display? Like a stubborn “ Ĺ ” character that won't go away?

Historically, FM RDS radios expected a fixed-length static 64-character (RadioText) display. They relied on broadcasters' encoders to manually pad the remaining text blocks with standard ASCII spaces (0x20) rather than terminating the string abruptly with 0x0D.

Even though, right from the start in 1990, the CENELEC EN 50067 standard for transmitting RDS explicitly stated: "Each [RadioTEXT] message should be ended by the code 0x0D (Hex) - carriage return - if the current message requires less than 16 segment addresses." 0xD was designed as an efficient end-of-message marker so stations didn't have to add empty padding spaces.

Then, along came 'Dynamic RadioTEXT' where 'Now Playing...' information became the norm. The use of 0x0D to signal the end of the text field became even more important, indicating to receivers that anything that followed was to be displayed on a fresh screen. Most software in RDS radios handles this correctly and does just that. A few badly engineered radios just print that command character (or their interpretation of it at least) to the screen, and do nothing more.

So why do some receivers mishandle it? The problem stems from how early RDS decoder chips (like the SAA6579) mapped incoming bytes directly to simple 8-bit character ROMs. Because 0xD is a non-printable control character rather than a letter or number, these older chips often displayed it as a generic unprintable glyph (like a blank block, a question mark, or a space) instead of treating it as a command to stop reading the string.

Some modern receivers still exhibit this kind of behaviour - like, for example, much of the Pure Elan series (due, it seems, to somewhat incomplete firmware implementation). Many modern consumer radios like Pure are rarely firmware coded from scratch. They are built using turnkey modules and SDKs, predominantly from Frontier Smart Technologies (formerly Frontier Silicon). One plausible explanation is that when Frontier wrote the RDS parsing software layer for their multi-standard (DAB/FM) modules, they may have routed raw RDS character streams straight through a unified string handling function designed to feed a graphic TFT display. It seems that a few developers who added their proprietary RDS decoding firmware simply failed to trap 0x0D as a control character delimiter, letting it pass directly into the display's text buffer as an active payload byte. As a result, “ Ĺ ” appears on the display at the end of the RadioTEXT message.

But why is it often the “ Ĺ ” character that appears? In some character sets used in embedded RTOS GUI frameworks (like UC/GUI or custom graphics libraries used by Frontier Silicon), characters from 0x0D to 0x1F are completely unpopulated. Instead of clipping or ignoring bytes less than 0x20, a bitwise error or mapping offset in the font decoder wraps or re-maps 0x0D to a higher page index. In the standard ISO-8859-2 (Latin-2) character set (frequently used as a fallback template in European consumer electronics), the character “ Ĺ ” sits at position 0xC5 or maps structurally to character indices sharing low-nibble matching with 0x0D. If the receiver’s firmware pushes that byte into a font renderer, that interprets raw bytes through an incorrect code page offset, 0x0D turns directly into an “ Ĺ ” character.

From a product design standpoint, radios like the Pure Elan series are primarily a digital radio (DAB/DAB+) which happen to implement the FM waveband provided by the Frontier Silicon module as a legacy feature. It’s likely that when QC teams test these units, they focus on DAB multiplex parsing, DAB slideshow artwork, and DAB AAC audio decoding. The FM RDS functionality is treated as a ‘check-the-box’ feature. Such engineers probably tested the newly developed radio sets against radio stations using an encoder that padded out to a full 64 characters, 'old-school' fashion, using 0x20 spaces, - thus completely missing the fact that a raw 0x0D is an important control character to be properly used in RadioTEXT display parsing. Broadcasters like the BBC still use padding in RadioTEXT message fields, so were probably assumed to be the 'best standard' for which RadioTEXT displays should be tested against, rather than ensuring perfect compliance with EN50067. Ironically, the BBC was involved in developing and writing that very standard.

In short, a very small number of FM receiver displays don't interpret the 0x0D message termination character as an indication that, when the next updated RadioTEXT message is received, they must clear their RadioTEXT display field and start a new message. Instead, 0x0D gets ignored and printed to the screen as a weird character. The majority of FM radio sets do, however, work correctly.