Character set

[Hoggins!]

Hello,

What is the correct character set for the RS-232 communications with the PIRA32 RDS encoder ? Does it support accented characters as of ISO-8859-1 ?

Thanks in advance,

Hoggins!

[Jan]

The PIRA32 uses standard 8-bit ASCII communication. Character set for extended ASCII range (usualy 128-255) is not defined as RDS encoder does not interpret or modify these characters, i.e. it's like to ask what character set uses the RS-232 cable
How the extended characters will be interpreted depends on the receiver only. Due to the fact that most receivers can't show there characters at all and moreover they have problems when sending code page mark, it's highly recommended not to use the extended part of ASCII as this may cause more problems than benefits.

[Hoggins!]

Yes, that was a quick and imprecise shortcut, of course.

Then I believe I should remove all accented characters from the transmitted RadioText...

Thanks !

[Jan]

That's the best you can do because you have two choices:
1) Leave the national characters in the text => a few listeners will enjoy the nice text but this will be unreadable for most of others
2) Use the basic characters only, the text will not look perfectly but anybody on any receiver will be able to read it without problems.
The problem has more extensive background but the result is above. That's my present opinion.

[Attila]

third and best choice:
use the RDS character set.
See Annex E (normative) Table E.1 - including czech characters.
(RDS technical specs 2008 / RDS forum)

[Jan]

This is equivalent to choice 1. How can this LCD show the extended characters?



It shows blank spaces instead.

Another problem is the code page switching using the control characters. If you try the example from the RDS standard:

For example, the name of the second Greek program service could be transmitted in type 0 groups as follows:
Characters: ΔE YT EP O (Text segment address: 0 1 2 3)

Text segment address - Character codes - Characters Effect
0 - 0/14, 0/14 - SO, SO Selection of code-table E.2 (control characters)
0 - 15/14, 4/5 - Δ, E First two letters
1 - 5/9, 5/4 - Y, T Second two letters
2 - 4/5, 5/0 - E, P Third two letters
3 - 4/15, 2/0 - O, Last letter and space

this will result in blinking the first PS segment on many receivers because they interpret the control characters as any other characters. So they show in sequence two blank spaces and then space and E as the first PS segment.

There's a big mistake in the RDS standard. It should be strictly claimed that receivers with simple LCD or no code page switching implemented must ignore all characters in ASCII range 0 to 31. It's a pity that there is only one PS and one RT possible at one time. Better option would be to transmit primary PS and RT that can be showed on any LCD and secondary PS and RT with extended characters that can be showed on clever receivers. Unfortunately this is only an imagination, today it's probably too late to think about it. As a result, the extended character sets are generally useless for PS and RT (but are not excluded for use with some special services, of course).

[Hoggins!]

Thanks Jan !

That is because I've used car radios that have dot matrix LCD screens, and are able to display lower case characters, so accents could be displayed for RT+ data. I don't recall if there were accents on the stations I checked, though.

So my present solution is to convert all accented characters to their nearest non-accented character. For french language, it is easy, as it does not change the meaning of the world, though not gramatically correct.

[Jan]

A summarization of this issue is finally available at http://pira.cz/rds/rdschars.pdf