Introduction to the telesoftware on radio project.
William Overington
Monday 29 August 2005
The telesoftware on radio project is, at the time of writing this document, a theoretical development. Hopefully the system will be developed into a practical, working, broadcasting system in the future.
The telesoftware on radio project uses the digital audio broadcasting system of the following standard as the basis for broadcasting signals.
Radio broadcasting systems; Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers
ETSI ETS 300 401 ed.2 (1997-05)
Reference: RE/JTC-00DAB-4
The copy which I am using is in a pdf document with ets_300401e02p.pdf as the file name.
I am not a broadcasting engineer and am only using the standard as a way to get the signal to a telesoftware_on_radio system within, or attached to, the radio receiver.
Here is how I obtained the document, in case some readers are interested in obtaining a copy.
First go to the following web page.
http://www.etsi.org/services_products/freestandard/home.htm
Click on DOWNLOAD NOW!
This leads to the following web page.
http://pda.etsi.org/pda/queryform.asp
Then enter into the "Search for" text box the following.
ETS 300 401
Then click on the Search button.
Two documents are offered and I chose the one lower down the page, entitled as follows, by clicking on the Download link.
ETSI ETS 300 401 ed.2 (1997-05)
This then lead through a registration procedure. Registration is free and straightforward.
I was then offered a choice of pdf and Word documents.
I chose the pdf version which is listed as being of 1108606 bytes.
I am thinking that the best way for the telesoftware on radio project to proceed is to use the PAD (Programme Associated Data) system of the ETSI ETS 300 401 ed.2 (1997-05) standard. Section 7.4, which starts on on page 84, and annex A, clause A.4, which starts on page 196, together have the relevant information.
My present thinking is to use only F-PAD (fixed Programme Associated Data) data for the telesoftware on radio system.
Page 86 of the standard has the following.
quote
F-PAD type: this 2-bit field shall indicate the content of the Byte L-1 data field. The values "01" and "11" are reserved for future use of the Byte L-1 data field.
end quote
My present thinking is that telesoftware on radio could use F-PAD type "11" with F-PAD type extension "10".
Thus the two bytes of the F-PAD would provide hexadecimal values from E000 to EFFF with the meaning that the two bytes are for the telesoftware on radio system and these could be used by the telesoftware on radio system independently of other information and any radio receiver not using the telesoftware on radio system could safely ignore them.
Once the hexadecimal values are received from the radio receiver, they would then be preprocessed so as to produce a stream of Unicode 16-bit characters. All planes of Unicode would be accessible as those 16-bit Unicode characters could contain Unicode surrogates in pairs.
The preprocessing from hexadecimal value to Unicode character is as follows.
There is a variable named highpart which is initially set to zero. There is a variable named lowpart which is initially set to zero.
In the following, 0x followed by hexadecimal digits indicates a hexadecimal value. U+ followed by hexadecimal digits indicates a Unicode character expressed in hexadecimal format.
If the incoming hexadecimal value is from 0xE800 to 0xE8FF, then highpart is set to the least eight bits of the incoming hexadecimal value. For example, 0xE81E sets highpart to 0x1E yet sends no character to the Unicode character stream.
If the incoming hexadecimal value is from 0xE900 to 0xE9FF, then lowpart is set to the least eight bits of the incoming hexadecimal value and a 16-bit character is sent to the Unicode character stream, consisting of the current contents of highpart and lowpart used to form the two bytes of the character; the value of highpart is then set to zero. For example, 0xE982 sets lowpart to 0x82 and sends a character to the Unicode character stream. That character has hexdecimal 82 as the lower byte but could be U+0082 or U+0182 or U+0282 or some other character of which the lower byte has the value hexadecimal 82, depending on the value of highpart when the 0xE982 value is received.
Thus, in order to signal some text which uses only Unicode characters within the range U+0000 to U+00FF, a sequence of 0xE9.. values are used as the F-PAD data values.
If, however, a character such as U+1E82 LATIN CAPITAL LETTER W WITH ACUTE is required, then the sequence 0xE81E 0xE982 can be used.
Please note that if two Unicode characters which have the same, non-zero, upper byte value are required in sequence, the 0xE8.. values must be sent for each of them, as the system always resets the value of highpart when a character is sent to the Unicode character stream.
If the incoming hexadecimal value is from 0xEA00 to 0xEFFF, then a Unicode character of exactly the same hexadecimal value is sent to the character stream. For example, 0xEA21 sends a U+EA21 character to the Unicode character stream. For example, 0xEBD2 sends a U+EBD2 character to the Unicode character stream.
The reason for this is that this makes the sending of those Unicode character codes, which are from the Unicode Private Use Area, as efficient as sending characters from the range U+0000 to U+00FF. The reason for having that efficiency for those Private Use Area characters is that U+EA00 to U+EAFF are used for delivering 1456 object code (in speech "fourteen fifty-six object code") software to the system, U+EB00 to U+EBFF are used for delivering eutocode graphics commands and multimedia control commands to the system and U+EC00 to U+EFFF can be used for delivering graphic coordinate data to the system, though that can also be done using decimal digit codes from the U+EBF0 to U+EBF9 range. Nevertheless, the use of U+EC00 to U+EFFF to indicate data values from 0 to 1023 directly does add efficiency to the system.
In the event that the available F-PAD coding space becomes highly limited then 0xE800 to 0xE9FF would be sufficient to use the system, as the Unicode characters from U+EA00 to U+EFFF could be produced by using them. However, if possible, the system as set out above would be best as that would mean that higher speed could be produced when loading 1456 object code programs and using eutocode graphics and the multimedia system.
I am researching the way to join the various parts of the system together, but readers might like the following links in order to consider for themselves the way to produce the system.
The 1456 object code system is introduced and indexed on the web at the following web page.
http://www.users.globalnet.co.uk/~ngo/14560000.htm
I have in mind that each character in the Unicode character stream of this telesoftware on radio project which is in the range U+EA00 to U+EA7F would be sent as input to a 1456 engine which would use any such character as if in the range U+0000 to U+00FF as those characters are used in the above linked collection of documents. However, the telesoftware on radio 1456 engine would keep the characters in the U+EA00 to U+EA7F range so that Unicode text strings could be handled mixed in with the software using some particular codes from within the U+EA00 to U+EAFF range to delimit the strings without ambiguity.
The 1456 object code would be interpreted by a Java program running in the system. Thus matters such as how to represent floating point numbers and so on are all covered by simply stating that each such matter is carried out as Java carries it out.
The telesoftware on radio hardware system would run a firmware Java program which would interpret the 1456 object code and eutocode graphics commands. The text and graphical display could be displayed on either a television screen or on a PC screen or on a display panel built-in to the radio receiver.
A key feature of the system is intended to be that mouse event support is a standard feature. Some applications could be load and go, using neither colour button pushes or mouse events. Some applications could use only colour buttons and some applications could use mouse events as well. Some applications could be synchronized to the sound being delivered by the radio and some applications could be entirely independent of the sound being delivered by the radio.
By using the Private Use Area of Unicode to express 1456 object code and eutocode graphics commands it will hopefully be possible to produce good results, even though the speed of delivery of F-PAD data is relatively slow.
The eutocode graphics system is introduced in the following documents.
http://www.users.globalnet.co.uk/~ngo/ast03000.htm
http://www.users.globalnet.co.uk/~ngo/ast03100.htm
However, those documents, though still valid, were written some time ago and there are now authoring-time glyphs for many of the Private Use Area characters used in that document available in the Quest text font. There are no authoring-time glyphs for U+EC00 to U+EFFF though there are authoring-time glyphs for the multimedia authoring digits U+EBF0 to U+EBF9. The use of U+EBF0 to U+EBF9 makes authoring of graphics more straightforward yet I want to keep the U+EC00 to U+EFFF system in use as well so that the 1456 object code system can output a stream of eutocode graphics control characters to go directly to the eutocode graphics engine of the telesoftware on radio system without needing to convert a number in the range 0 to 1023 into one, two, three or four multimedia authoring digits only for the eutocode graphics engine to need to convert them back into an integer.
The Quest text font, which is my own font, is a free download from the following web page.
http://www.users.globalnet.co.uk/~ngo/fonts.htm
End of document telesoftware_on_radio tor00100.htm.