Posted by: Jan
« on: March 01, 2014, 08:10:33 pm »A summarization of this issue is finally available at http://pira.cz/rds/rdschars.pdf
News:
Thank you for using this forum as the technical support base for your device.
● You can format the text and attach screenshots, photos and RDS Spy records
● Faster reply: 50 % of questions are answered within 30 minutes
● You don't need to register (but registration is possible)
● The members represent a wide range of experts
● The resolution will be helpful to other users
● You'll be notified by email about new post
Posted by: Hoggins!
« on: July 24, 2011, 09:20:29 pm »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.
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.
Posted by: Jan
« on: June 29, 2011, 11:58:56 am »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).
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).
Posted by: Attila
« on: June 29, 2011, 10:35:47 am »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)
use the RDS character set.
See Annex E (normative) Table E.1 - including czech characters.
(RDS technical specs 2008 / RDS forum)
Posted by: Jan
« on: June 28, 2011, 02:43:36 pm »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.
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.
Posted by: Hoggins!
« on: June 28, 2011, 12:16:58 pm »Yes, that was a quick and imprecise shortcut, of course.
Then I believe I should remove all accented characters from the transmitted RadioText...
Thanks !
Then I believe I should remove all accented characters from the transmitted RadioText...
Thanks !
Posted by: Jan
« on: June 28, 2011, 07:34:15 am »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.
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.
Posted by: Hoggins!
« on: June 27, 2011, 01:13:14 pm »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!
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!