MOD-14-1723 Short Data Applications Design Guide - Issue 1

Sepura TETRA Terminal
Short Data Applications Design Guide

Software Release: Version 10.14
MOD-14-1723
Issue 1
COMMERCIAL IN CONFIDENCE
© SEPURA PLC 2014

MOD-14-1723 Short Data Applications
NOTICE
All rights reserved. This document may not be reproduced in any form either in part or in
whole without the prior written consent of Sepura plc, nor may it be edited, duplicated or
distributed using electronic systems.
This document and the product it describes are considered protected by copyright according
to the applicable laws.
The information in this document is subject to change without notice. This document is
intended for Sepura plc‟s customers and/or other parties only for the purposes of the
agreement or arrangement under which this document is submitted.
The document has been prepared to be used by professional and properly trained personnel
and the customer and/or other party assumes full responsibility when using it. Sepura Plc
welcomes customer and/or other party comments as part of the process of continuous
development and improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or
performance of the mentioned hardware or software products cannot be considered binding
but shall be defined in the agreement or arrangement made between Sepura plc and the
customer and/or other party.
However, Sepura plc has made all reasonable efforts to ensure that the instructions contained
in the document are adequate and free of material errors and omissions. Sepura plc will, if
necessary, explain issues which may not be covered by this document.
Sepura plc‟s liability for any errors in this document is limited to the documentary correction of
errors. Sepura plc WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS
DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL, (INCLUDING
MONETARY LOSSES), that might arise from the use of this document or the information in it.
Other product names mentioned in this document may be trademarks of their respective
companies, and they are mentioned for identification purposes only.
Copyright © Sepura plc 2014. All rights reserved.
Contact Details
Sepura plc
Radio House
St Andrew‟s Road
Cambridge CB4 1GR
United Kingdom
Web : www.sepura.com
Tel: +44 (0)1223 876000
Fax: +44 (0)1223 879000
Issued by Sepura Marketing Commercial-in-Confidence

©Sepura plc 2014 Issue 1 Page 2 of 89
ISSUE HISTORY
Version Date Change
Issue 1 18 July 2014 Initial Version
REFERENCES
Reference Title
{1} ETSI specification ETS 300 392-2 Edn 2 (v2.3.2) - http://www.etsi.org/
{2} Data Interface User Guide
{3} Terminal User Guide
{4} Radio Manager - Templates
{5} Radio Manager - Import and Export
{6} Radio Manager - Programming Radios

CONVENTIONS
Convention Description
Note icon, emphasizes related, reinforcing, or important information.
Tip icon, suggests alternative methods for accomplishing tasks or procedures.
Caution icon. Indicates actions or processes that require caution from the user
The use of square brackets will denote a customisable parameter. Where

[…] explanation or details are not contained in this document further details may
be obtained via the Radio Manager
All numbers, unless explicitly stated otherwise will be in decimal notation (i.e.
23
Base 10).
0x23 All numbers with „0x‟ preceding them will be in Hexadecimal (i.e. Base 16)

Table of Contents
1 INTRODUCTION ....................................................................................... 7
1.1 What are Short Data Applications? .............................................................................. 8
1.2 Basic Transmit Scenario................................................................................................ 9
1.3 Basic Receive Scenario ................................................................................................. 9
2 THE DEFINITION TABLES ..................................................................... 11

2.1 Introduction ................................................................................................................... 11
2.2 The ACTION table ......................................................................................................... 13

2.2.1 Delete Message () ....................................................................................................................................... 14
2.2.2 Display Form (Form ID) ............................................................................................................................... 15
2.2.3 Display Immediate () .................................................................................................................................... 15
2.2.4 Format String (Destination ID, Format ID [,Source ID [, Source ID . . . ] ][Persistence]) ................................ 15
2.2.5 Generate Alert (Alert ID) .............................................................................................................................. 16
2.2.6 No Action () ................................................................................................................................................. 17
2.2.7 Reset Parameter (ID)................................................................................................................................... 17
2.2.8 Reset Property (Property ID) ....................................................................................................................... 18
2.2.9 Save To Permanent Cache ( [Save Option] ) ............................................................................................... 18
2.2.10 Send SDS Message ( [Message ID [, Address ID]]) ................................................................................... 18
2.2.11 Send Status Message (Status Value, Address ID) ..................................................................................... 19
2.2.12 Set Parameter (ID, Value).......................................................................................................................... 19
2.2.13 Set Property (Property ID, Value[, Option] ................................................................................................. 19
2.2.14 Soft Key Function (Soft Key ID) ................................................................................................................. 22
2.3 The ADDRESS table ..................................................................................................... 25
2.4 The CHECK VALUE table ............................................................................................. 26
2.5 The EVENT CHECK table ............................................................................................. 28
2.6 The FIELD table ............................................................................................................ 30
2.7 The FORM table ............................................................................................................ 33
2.8 The FORM FIELD table ................................................................................................. 35
2.9 The LIST table ............................................................................................................... 39
2.10 The MESSAGE table ................................................................................................... 41
2.11 The MESSAGE CHECK table ..................................................................................... 43
2.12 The MESSAGE DEFN table ........................................................................................ 45
2.13 The PROTOCOL (Family) Table ................................................................................ 51
2.14 The STRING LIST table .............................................................................................. 52
2.15 The VR LIST Table ...................................................................................................... 54
2.16 Data Types - Use of MESSAGE DEFN Char Size and STRING LIST Type ............ 57
2.16.1 STRING LIST Types - Used by UI, Check Values and Delimiters .............................................................. 57
2.16.2 Encoding STRING LIST Or UI Values Into A Message .............................................................................. 58

2.16.3 Decoding Message Fields To Be Displayed On The UI .............................................................................. 59
2.17 Definition Tables and Links ....................................................................................... 62
3 LICENSING ............................................................................................. 65
4 WORKED EXAMPLE .............................................................................. 66

4.1 Introduction: ................................................................................................................. 66
4.2 Example scenario and detail information .................................................................. 67
4.3 Stage 1: Model the outgoing message structure ...................................................... 68
4.4 Stage 2: Design outgoing forms and selection of them ........................................... 70
4.5 Stage 3: Model incoming message structures, for checking and for displaying .. 74
4.6 Stage 4: Model the matching process ........................................................................ 77
4.7 Stage 5: Design the incoming message display forms ............................................ 80
4.8 Conclusion .................................................................................................................... 85
5 TERMINAL CONSIDERATIONS ............................................................. 87
6 GLOSSARY ............................................................................................. 88
7 APPENDIX A - 7 BIT TEXT CONVERSION RULES ............................... 89
INTENDED AUDIENCE
This User Guide is aimed at Application Developers and for use as a training support tool.

1 INTRODUCTION
Short Data Applications have been introduced to support the growth of SDS based protocols
interfacing with back end data systems (usually located in or beyond the SwMI). The
protocols carry data in an efficient format which although suited for low speed links (namely
the air interface) are not conducive to being readily readable and / or writable by a human
user. Short Data Applications provide a presentation layer on top of the SDS messages which
will allow users to read and write SDS messages in a clear and concise manner.
An example use of Short Data Applications would be to access a police vehicle database.
Screens would be accessed to logon and then enter details for the vehicle of interest. The
returned information would be displayed in a user readable form.
Before Short Data Applications the contents of messages were defined by what could be
entered using the terminal's UI, restricting it to visible characters (plus the space). With the
growth of SDS based protocols the use of non-printable characters within the message
protocol, for use as identifiers, binary data and field delimiters (depending upon each
message protocol definition), means that the organisation will want to use human un-readable
messages. In addition to this, messages are being designed to be space efficient, addressing
the need to use on a low bandwidth connection.
The purpose of Short Data Applications is two fold:
1. It allows the user to enter data and allow the terminal to translate the data into the
final SDS message. A Definition (in the form of tables) maps the data entered into
the fields to the raw SDS message. Some data will not be entered by the user and
will be transparent to them. By linking the Definition to the raw SDS message
structure, the presentation of the data to the user can be independent of the order
and format of the data in the final SDS message.
2. It allows the structured presentation of incoming SDS messages. An incoming
message will be identified as belonging to a given Form and this form will be used to
present all or some of the data contained in the SDS Message. The form will also be
able to re-order and label the information it presents making the readability of
incoming messages much simpler.
The fundamental point of Short Data Applications is to make the sending and receipt of
complex SDS message an effortless and user friendly task.
In addition Short Data Applications may be configured to be triggered by terminal functionality
and process a sequence of actions.
This Design Guide will:
introduce required concepts and features;
introduce the various Definition parts (Definition Tables);
o including how they define displayed forms;
o and how they check incoming messages.
explain how a message may be analysed and broken down (when received) or built
up (for sending);
show a worked example of a simple Short Data Application.

1.1 What are Short Data Applications?

From a user's point of view they:
are a means of selecting a specific Form from a Family / Protocol;
display a Form which can be navigated, fields filled in and sent;
display a Form as a result of a received SDS message being matched / recognised;
associate an action (an alert for example) to an event (recognition of an SDS
message or internal event for example).
Selecting a Family and Form The selected Form display
They are controlled by:

a Definition, consisting of a number of Tables (similar to a database definition);
with each Table containing data relating to its function and/or links to entries in
another (potentially shared) Table.
For example, one table (itself referenced by the Form definition tables) holds the
information for all the displayed Fields (length, attributes, type) but gets any required text
by referencing an entry in a (single) table of Strings.
FORM FIELD
CHECK VALUE
FIELD STRING LIST
MESSAGE DEFN
LIST
Similarly the Family / Protocol information table (containing the family / protocol name)
references the Form table (Form information, its name for example) and the 'Fields on the
Form' table (Form Field information, positioning for example). Both of the referenced
tables will themselves reference other tables for further information. In fact the Form table
will get the Name information by referencing the table of strings.
In this way data is not duplicated, can be accessed by any other table and is logically
grouped. There is only one table for each type of data, shared by all Families.
There are fourteen Tables making up the Definition, dealing with:

Families / Protocols;

Forms and their contents;

Messages and their composition / decomposition;
Message checking and matching;
Local validation;
Terminal event matching;
and associated Actions.
See the end of Chapter 2 (in section Definition Tables and Links) for figures showing
tables, their data and their linkage.
1.2 Basic Transmit Scenario
Short Data Applications allow a non technical user to enter text via the terminal‟s UI using
form based Text Input and then allow the terminal to translate that text into a (potentially)
more compact form for transfer over the air.
The sequence of operations and Definition requirements are as follows:
Allow selection, from a Radio Settings card, of a configured Family (Protocol) and
then selection of the required Form;
Navigate the form and fill in the required information in the designated fields. The
Definition contains all information relating to field types, placement and size,
navigation order, etc. including whether fields are mandatory and/or have associated
validation rules;
By selecting Send (customised fields or the green telephone key), using the
associated message definition, construct an SDS Message from fixed and Form
information and send it to the configured (or user selected) address;
In addition, the message contents may be cached and used to fill in fields when this
form is next selected and may have other actions associated with it.
See the Terminal User Guide for guidance on terminal operation.
1.3 Basic Receive Scenario
When a terminal receives an incoming SDS message it will check the message to determine
whether it needs to be presented to the user by means of a form. In addition, the receipt of a
recognised message may generate other actions, an alert for example.
If an incoming SDS Message fails the message check process and the message type (PID) is
recognised by the terminal Inbox, it is put in the Inbox, an icon is displayed and an alert raised
if so configured. From there it can be read, deleted and stored in the Message Store. These
messages are saved over a power off / power on cycle.
If an incoming SDS Message passes the message check process it is put in the Inbox
together with its associated Form ID, an icon is displayed and an alert raised if so configured.
From there it can be read and deleted. It is configurable, within the Definition (Form -
Attribute) whether these messages are saved over a power off / power on cycle. If so
configured by the Definition, a sequence of actions is initiated.

The sequence of operations and Definition requirements are as follows:

Match the message and so associate it with a form, a message structure and actions.
In order to classify the message the terminal must be configured to have the
following:
o A list of one or more checks to apply to incoming messages;
o Associate a message structure with each of the check lists;
o Optionally associate an action (or list of actions) with each of the check lists;
o Optionally associate a form with each of the check lists.
A check consists of one or more comparisons to predefined field values and their
corresponding values in the received SDS message. A successful classification
occurs when all the comparisons are successful.
If so configured, display the form (by automatically navigating to the message in the
Inbox) and populate the fields from the incoming message. The form may then be
navigated (and potentially fields altered or filled in and the whole form Sent - as
described above);
If so configured, process each of the associated actions, invoking each in turn;
The message, and its associated Form ID, is stored in the Inbox. If the message is
subsequently viewed in the Inbox it will be displayed using the associated Form
definition.
See Terminal User Guide for guidance on terminal operation.
The basic process is therefore:

For each Family / Protocol:
Design the Definition, (Forms, Messages, etc.) - see Chapter 4
Enter the design into Radio Manager and configure a terminal
Test the Short Data Applications
And iterate until correct.

MOD-14-1723 Short Data Applications - The Definition Tables
2 THE DEFINITION TABLES
2.1 Introduction
This chapter will introduce each of the Definition Tables in turn. For each it will detail the table
elements and how they might be used. It will detail which elements link to (use) other tables
and which are linked from (used by) other tables.
The chapter concludes with a diagram showing how all the tables are linked to each other.
This chapter is very factual and will be further explained by a worked example in a later
chapter.
Tables and table links

The Definition consists of a group of tables, each containing data and/or links to further
tables.
Each table consists of the defined information repeated the required number of times. For
example the STRING LIST table, which details the strings to be used, is organised as follows,
in this case showing four parameter sets, each set consisting of a type and a value:
Type Value
1 8 Bit Text User ID:
2 8 Bit Text Password:
STRING LIST
3 8 Bit Text Current Pwd
4 8 Bit Text New Pwd
Table information is accessed, from other tables, either by position or by ID, as defined by
each individual table.
By position: A reference to this type of table, for example STRING LIST as above,
would be of the form STRING LIST 2, indicating a link to the second parameter set, in
this case '8 Bit Text' and 'Password:'. A single parameter set is involved.
By ID: A reference to this type of table, typically having an ID as the first column, would
be of the form CHECK VALUE 3, indicating a link to ALL the parameter sets that have an
ID of 3. In the example below this would link to the third, fourth and fifth rows. The
indicated parameter sets are then usually processed in turn, in the order they appear in
the table. Multiple or single parameter sets are involved.
ID Field ID Value
1 1 5 17
2 1 6 18
3 3 7 17
CHECK VALUE 4 3 11 18
5 3 10 21
6 7 8 17
7 7 9 18
In this table a reference is being made to the FIELD table (by position) using the
indicated Field ID.

The Definition Tables are:

ACTION Action lists
ADDRESS Send Addresses
CHECK VALUE List of fields to check incoming SDS Message
EVENT CHECK Internal events that trigger actions
FIELD Field definition, for presentation or for message
construction / deconstruction
FORM List of forms
FORM FIELD Lists of contents of each form
LIST Lists of information to be accessed by other tables
MESSAGE Top level message properties
MESSAGE CHECK List of message, form, action and CHECK VALUE
associations
MESSAGE DEFN Low level message definition
PROTOCOL List of Families (named groups of Forms)
STRING LIST List of strings, for display, comparison, etc.
VR LIST List of validation rules for FORM FIELDs
Each table is presented in turn with associated information.
An overview of the tables, their content and their links, are shown at the end of this chapter.
Definitions for the following tables:

Values are normally of type byte and in the range 0-255 except where indicated.
ID: All valid ID references are byte values in the range 1 to 255. 0 represents that the ID is not
referenced.
x coordinates, y coordinates: from top left of screen, positive is down and right.

2.2 The ACTION table

Description
This table defines sequences of actions, grouped by ID, and their associated parameters
(using LIST).
Name Description
ID Lookup reference. All parameter sets with the same ID value will
belong to the action sequence definition, in the order in which they
appear in the table.
Function ID The function to be performed:
Delete Message
Display Form
Display Immediate
Format String
Generate Alert
No Action
Reset Parameter
Reset Property
Save To Permanent Cache
Send SDS Message
Send Status Message
Set Parameter
Set Property
Soft Key Function
See below for further information.
Parameter List ID This is a reference to the LIST table that holds a list of parameters
(entries in LIST where the ID matches this value) that will be used to
pass and receive data to/from the function referenced by the Function
ID parameter.
Name A reference to a specific (by position) value in the STRING LIST table
which will be displayed on the left context key when the action is
available for use.
The default value is '0' indicating no context key to be displayed.
On products that do not support context keys this parameter is
ignored.
See below for further explanations and parameter notes.
Links to and from other tables
FORM
LIST
FORM FIELD
ACTION
MESSAGE CHECK
STRING LIST
EVENT CHECK

Example
An example ACTION table:
ID Function ID Parameter List ID Name
1 2 Send SDS Message 2 0
ACTION
3 4 Generate Alert 4 0
4 4 Display Immediate 0 0
And the LIST table it references:

ID Entry Type Entry
1 1 Form ID 1
2 1 Form ID 2
3 2 Message ID 1
LIST 4 2 Address ID 1
5 3 Message ID 2
6 3 Address ID 1
7 4 Unsigned Integer 10
The first two columns only exist to aid readability and are not needed in the table within the
Terminal and Radio Manager.
The first ACTION table entry defines a 'Send SDS Message' function. It gets its parameters
from the ID = 2 entries in the LIST table. The first is a Message ID and references the first
MESSAGE parameter set. The address is obtained from the first parameter set in the
ADDRESS table.
The second ACTION table entry defines a similar function apart from using the second
MESSAGE parameter set.
The third action entry defines a pair of functions (referenced by the same ID):
to generate an alert, in fact the tenth Alert (as indicated in the LIST table);
and to display the message immediately. No parameters are required and LIST table is
not involved.
No context keys have been configured.
Further information on Name:
Name is only supported in terminals that support context keys;
Only one Name will be supported for each Action ID and this must be associated with
the first action of an 'Action ID block' (Actions with the same Action ID);
If a Name is not configured then the context key will not be labelled and there will be no
action if it is pressed.
2.2.1 Delete Message ()

This function will delete the current SDS message, typically the SDS message that
caused a form to be displayed;
Only valid as a FORM, FORM FIELD or MESSAGE CHECK function;
When invoking this function, any form displaying data from this message will be closed
as if it had been closed by the user;
The deletion of the SDS message includes the removal of the message from the
message inbox if the message is stored there.

This function must only be invoked once for any given Action ID and must also be the
last function in the list of functions for any given Action ID
2.2.2 Display Form (Form ID)

This function will display another form. This form will be able to use the current SDS
message, if one is associated with the form the function is invoked from, to populate its
fields;
Note: The population of the form‟s fields will be possible even when the action invoking
the Display Form function also includes the Delete Message function.
Valid as a FORM, FORM FIELD, MESSAGE CHECK or EVENT CHECK function;
Any existing form will be closed as if the user manually closed the form and navigated
away.
The new form is displayed full screen.
Note: If the form is not defined to be accessible by navigating via the SDA subject card
the user will not be able to return to the card once it has been closed.
All Auto-save cached data will be cleared when invoking this function. This will also
cancel the automatic display of the previously edited form that was to hold that data
which would have otherwise been displayed upon manual navigation to the cards located
below the SDA subject card;
The Form ID may be explicitly obtained from LIST. (Alternatively LIST may refer to a
Field ID which contains the Form ID). If the data associated with the field at the time of
invoking the function does not reference a valid form then the terminal will treat this
function as if it were the No Action function.
2.2.3 Display Immediate ()

Causes the presentation of the SDS Message that has passed the check procedure
(using the indicated form), by automatically navigating to the Inbox and displaying that
message using its associated Form;
Only valid as a MESSAGE CHECK function;
Requires no parameters.
Using Display Immediate ensures that the form will be displayed until navigated away
from by the user. Manually navigating away will also mark it as read. Receipt of another
Display Immediate message will replace the original Display Immediate message which,
since it was not manually navigated away from, will be marked as unread. Non Display
Immediate messages will not cause the unread Display Immediate message to be
navigated away from.
This function will have no effect if the Delete Message function is also associated with
the same Action ID.
2.2.4 Format String (Destination ID, Format ID [,Source ID [, Source ID . . . ]

][Persistence])
Use of this function in an SDA requires a Sepura Premium Application Pack
license in the radio, see section 3
This function replaces the contents of a destination field (defined by Destination ID) with
a string constructed from the contents of a formatting string (defined by Format ID) and
optionally the string contents of one or more fields (defined by Source ID);
Persistence defines the persistence of the string written to the Field identified by
DestinationID;
The resultant contents of the destination field may be used as a field for any
subsequently executed Action function within the same List of action functions. The

resultant contents of the destination field is not accessible by other lists of Action
functions;
The Format String function only updates the destination field and does not update the
display. The destination field contents are only displayed if saved using a subsequent
Save To Permanent Cache function and then the Form containing the destination Field
ID is (re)loaded. This behaviour is true only if the Save To Permanent Cache function is
called within the same Action function List as the Format String function;
The Destination ID may be obtained from a Field ID referenced via LIST. The
referenced field must be defined as Unicode 16 bit. The maximum field length is 255
characters;
The Format ID may be obtained from a Field ID referenced via LIST. The referenced
field must be defined as Unicode 16 bit. The referenced field supports fixed strings and
the formatting characters '%s' which reference, in turn, Source IDs;
For example 'Attending Scene: %s' would concatenate the text 'Attending Scene: ' with
the contents of the first referenced Source ID.
The Source ID may optionally be obtained from a Field ID referenced via LIST. It / they
(there can be a maximum of thirteen Source IDs referenced) are used as the source
string data for its respective '%s'. The format of the Source ID string data may be 7 bit, 8
bit or 16 bit Unicode) text.
Persistence may be obtained from a Field ID referenced via LIST. The following values
are supported with the specified functionality. Any non-supported values are treated as
value „0‟.
„0‟ – The string written to DestinationID persists for the duration of the action function
sequence currently being executed.
„1‟ - The string written to DestinationID persists for the duration the radio remains
powered. i.e. Saves the result to permanent cache.
„2‟ - The string written to DestinationID persists until overwritten, even over a power
cycle. i.e. Saves the result to permanent cache and restores it to permanent cache
following a power cycle.
The following example demonstrates the effect of the Format String function. Using the
following Field ID contents:
Field ID Content Notes
3 ID: %s%s - %s The formatting string
4 001 Numeric data
5 ABC Text data
6 Failed Status
After the Format String (2, 3, 5, 4, 6) function has been processed leaves the following
in Field ID 2 (replacing the original contents):
Field ID Content Notes
2 ID: ABC001 - Failed The formatted string
2.2.5 Generate Alert (Alert ID)

This function generates the alert defined by the Alert ID;
New Message Alert, associated with a received SDS, is not generated;
Alerts can be cancelled by any key press;
Only valid as a MESSAGE CHECK or EVENT CHECK function;
Requires an Alert ID parameter (from or via LIST), of a value between 1 and 24, which
may be obtained directly as an integer or via a Field ID to obtain the number from the
SDS Message.
Alerts are available with the following characteristics:

Alert ID Type Sounds Like

1 Single Shot Battery Flat Alert
2 Repetitive Battery Low Alert
3 Single Shot Beep Alert
4 Single Shot Call Cleared Alert
5 Repetitive Clear Speech Pip Tones
6 Single Shot Covert Mode Disable Alert
7 Single Shot Covert Mode Enable Alert
8 Repetitive Emergency Call Alert
9 Single Shot Emergency Direct Call Alert
10 Repetitive Half Duplex Call Alert
11 Single Shot Invalid Function Alert
12 Single Shot Key Click Alert
13 Single Shot Lone Worker Prompt Alert
14 Single Shot New Call Alert
15 Single Shot New Emergency Message
Alert
16 Repetitive New Message Alert
17 Single Shot No Selected Group Alert
18 Single Shot No Service Alert
19 Single Shot RCU Rotary Knob Out Of Step
Alert
20 Single Shot Start Listening Alert
21 Single Shot Stop Listening Alert
22 Single Shot Transmit Granted Alert
23 Single Shot Transmit Not Granted Alert
24 Repetitive Wait For Tx Alert
The application developer should be careful in the choice of alerts in order not
to cause confusion with alerts already in use in the terminal.
2.2.6 No Action ()
This function performs no action;
Its main use is preventing the operation of any Actions associated with the parent form,
when the field is in focus.
2.2.7 Reset Parameter (ID)

This function will cancel the over-ride of the specified parameter and the terminal will
revert to use of its configured value;
Only valid as a FORM, FORM FIELD or MESSAGE CHECK function;
Currently only Radio_Stat_Ready [4400] and Radio_Stat_Direct parameters may be
reset;
The ID may be explicitly obtained from LIST. (Alternatively LIST may refer to a Field
which contains the ID). If the data associated with the field at the time of invoking the

function does not reference a valid value, i.e '4400' or „4430‟, then the terminal will treat
this function as if it were the No Action function;
It is recommended that the Reset Property function with Property ID 18
(Radio_Stat_Direct) or 19 (Radio _Stat_Ready) is used in place of this function.
2.2.8 Reset Property (Property ID)

This function cancels the Set Property function and returns the indicated property
(parameter), or properties, to its customised value.
See the Set Property function for information on supported Property IDs and the
associated syntax.
2.2.9 Save To Permanent Cache ( [Save Option] )

This function will save all editable data on the current form into the Permanent Data
Cache (for subsequent use on new forms that allow use of this data to populate fields);
Only valid as a FORM or FORM FIELD function;
The optional Save Option may be obtained from LIST. The LIST returns a single number
(Unsigned Integer) or resolves to a formatted string (using a Field ID) representing the
Save Option value. In either case the value must be either zero or one otherwise the
radio treats the function as if it were the No Action function.
The following Save Options are supported:
Save Option Value Meaning
0 Do not preserve the changed parameter
across a power cycle
1 Preserve the changed parameter across a
power cycle
If the Save Option is not specified it is assumed to be '0' / Do not preserve across power
cycle.
Note that fields tagged as 'Secure' are never saved across a power cycle.
2.2.10 Send SDS Message ( [Message ID [, Address ID]])

This function will cause the message referenced by Message ID to be sent as an SDS
message to the destination referenced by Address ID;
The Message ID may be explicitly obtained from LIST. (Alternatively LIST may refer to a
Field ID which contains the Message ID).
The Address ID may be explicitly obtained from LIST or it may be the pre-defined Field
ID 253 ('SOURCE ISSI'). (Alternatively LIST may refer to a Field ID which contains the
Address ID).
When invoked directly from a FORM or FORM FIELD table, in the absence of a specified
Message ID and Address ID, those of the message associated with the current form are
used. If there is no associated message the function is treated as a No Action function;
When invoked directly from a MESSAGE CHECK or EVENT CHECK table, both
Message ID and Address ID must be supplied otherwise the function is treated as a No
Action function.

2.2.11 Send Status Message (Status Value, Address ID)

This function will cause a status message with the value specified by Status Value to be
sent to the address referenced by Address ID;
The Status Value may be explicitly obtained from LIST. (Alternatively LIST may refer to
a Field ID which contains the Status Value).
The Address ID may be explicitly obtained from LIST or it may be the pre-defined Field
ID 253 ('SOURCE ISSI'). (Alternatively LIST may refer to a Field ID which contains the
Address ID).
2.2.12 Set Parameter (ID, Value)

This function will temporarily over-ride a configuration value (until a Reset Parameter
function is invoked or the terminal is power cycled).
Valid as a FORM, FORM FIELD or MESSAGE CHECK function;
Currently only the Radio_Stat_Ready [4400] and Radio_Stat_Direct [4430]parameters
may be set (the top of screen 'ready' status text) and may be replaced by fixed text or
text contained within the SDS message;
The ID may be explicitly obtained from LIST. (Alternatively LIST may refer to a Field
which contains the ID). If the data associated with the field at the time of invoking the
function does not reference a valid value, i.e '4400' or „4430‟, then the terminal will treat
this function as if it were the No Action function;
The Value may be explicitly obtained from LIST. (LIST will refer to a Field ID). The data
to be used will either be in that field of the message or if that field does not exist its
default data (from String List) will be used;
It is recommended that the Set Property function with Property ID 18
(Radio_Stat_Direct) or 19 (Radio _Stat_Ready) is used in place of this function.
2.2.13 Set Property (Property ID, Value[, Option]

This function sets the specified radio parameter (Property) to the specified value, with the
following functional extensions:
o The new Value may, or may not, be preserved over a power cycle, using Option;
o The Property ID may be a list of Properties;
o More than one radio parameter may be set (all to the same value) using one action
if the Property IDs all support the same Property Type;
Function silently fails i.e. acts as if it were a No Action function if any of the following are
true:
o The Property ID is incorrectly structured;
o The Property ID references multiple Properties that do not share the same
Property Type;
o The structure of the Value data is incorrect;
o The Property referenced by the Property ID is one that is not supported;
The Property ID may be obtained from LIST. The LIST returns a single Property number
parameters to be set (a string of comma separated Property IDs).
The following Property IDs are supported:
Property ID Property Name Property Type
1 GPS Primary Address Address


2 GPS Secondary Address Address
3.i Special Call First Status Message Address
3.1 = Alarm Call in TMO
3.2 = Alarm Call in DMO
3.3 = Quick Call in TMO
3.4 = Quick Call in DMO
3.* = All four above
4.i Special Call Second Status Message Address Address
4.* = Both of above
5.i Special Call TMO Call Address Address
5.3 = Quick Call in TMO
5.* = Both of above
6.i Special Call DMO Via Gateway Destination Binary
6.* = Both of above
Where:
Value 0 = Configured TMO Identity
1 = Currently selected DMO Talk Group
7.i Special Call DMO to DMO Call Address Address
7.* = Both of above
8.i Special Call DMO to TMO Call Address Address
8.* = Both of above
9.i Quick Status Soft Key Address Address
9.1 = Quick Status 1
...
9.* = All twelve above
10 Status Message Default Address Address
11.i SDA Address Table and Attributes Address+Attribute
11.i = where i can be 1 to 50
11.* = All 50 values
12 Radio Status Line Group Call Text String
13 Radio Status Line Talk Text String
14 Radio Status Line Voice Call Text String
15 Radio Status Line Repeater In Call Text String
16 Radio Status Line Repeater Talk Text String
17 Radio Status Line Repeater Idle Text String


18 Radio Status Line DMO Direct Text String
19 Radio Status Line TMO Ready Text String
20 Radio Status Line Duplex Call Text String
Property IDs Syntax
A single number, a comma separated list of numbers, a single index number
(including the special 'all numbers' index '*') or a list of index numbers, as in these
examples:
'1' to set the GPS Primary Address
'1,2' to set both GPS Primary and Secondary Addresses (same Property Type)
'7.4' to set Quick Call In DMO address
'3.1,3.3,4.1,5.1,5.3' to set all TMO Special Call addresses (same Property Type)
'9.*' to set all Quick Status Soft Key Addresss (to the same Value)
The Value may be obtained from LIST. The List entry resolves to a formatted string
(using a Field ID) representing the value to be applied to the parameter(s).
The following Values are supported depending on the Property Type:
Address Property Type:
<dial string>:<dial mode> encoded as an 8 bit ASCII string, for example '1234:1'
Note that if shortened dialling is used as the definition of an address the ISSI used is
completed using the ISSI of this terminal. To be sure of the required destination the
full ISSI should be used in the address definition.
Binary Property Type:
<the value> encoded as 8 bit ASCII representation of the number, for example for
Property ID = 6, '1' indicating 'Currently selected DMO Talk Group'.
Address+Attribute Property Type:
<dial string>:<dial mode>:<attribute> encoded as an 8 bit ASCII string, for example
'1234:1:1'
Where allowed attributes (see also the ADDRESS Table section) are:
1 = Fixed Individual Address
2 = Editable Individual Address
3 = Fixed Group Address
Note that if shortened dialling is used as the definition of an address the ISSI used is
completed using the ISSI of this terminal. To be sure of the required destination the
full ISSI should be used in the address definition.
String Property Type:
<the text> encoded as Unicode (16 bit) string values for each character
The optional Option may be obtained from LIST. The LIST returns a single number
Option value. In either case the value must be either zero or one otherwise the radio
treats the function as if it were the No Action function.
The following Options are supported:
Option Value Meaning
0 Do not preserve the changed parameter
across a power cycle
1 Preserve the changed parameter across a
power cycle
If the Option is not specified it is assumed to be '0' / Do not preserve across power
cycle.
Note that if the referenced field is tagged as 'Secure' the changed parameter is not
preserved across a power cycle.

2.2.14 Soft Key Function (Soft Key ID)

This function initiates the Soft Key Function defined by the Soft Key ID;
If the terminal does not support the indicated Soft Key Function, no error is reported;
Requires a Soft Key ID parameter (from or via LIST), of a value in the table below, which
may be obtained directly as an integer or via a Field ID.
The following Soft Key Functions are supported:
Soft Key ID Soft Key Function name
0 None
1 Last Call re-dial
4 Keypad lock select/de-select
5 Clear All (Return to Top Level Screen)
7 Volume Up
8 Volume Down
10 Alarm
11 Increment talk group
12 Decrement talk group
13 Trunked Mode/Direct Mode Toggle
Dialling Mode Selection – Cycle Through Programmed Dialling
14
Modes
15 Toggle Fast Access Mode
16 Pulse External Alert DO1
17 External Alert On / Off
18 Alert Enable
20 Navigate to card #1
24 Home Group Select
25 Invert Display Toggle
26 Reject or Exit From Call
27 Quick Status Message 1
30 Toggle Scanning Mode
31 Toggle Display Mode (Large/Normal)
32 Hands Free


52 Accessory Public State Toggle
55 Activate External Alert DO1
58 Deactivate External Alert DO1
61 Report Position to PEI1
Enable/Disable Continuous Position Reports to PEI1 - only if in
62
Car Kit
63 Set default Service definition for PEI1
65 Quick Group 1 Select
70 Last Requested Group Toggle
71 Switch Stack to DMO
72 Switch Stack to TMO
73 Switch Stack to Repeater
74 Switch Stack to Gateway
76 Tone Signalling
77 Zeroise
78 Transmit Inhibit Toggle
82 Loudspeaker On/Off
84 Preemptive PTT
88 Sequence 1
89 Sequence 2
90 Sequence 3
91 Sequence 4
92 Activate Transmit Inhibit
93 Deactivate Transmit Inhibit
96 Save All Data
97 Generate Paging Alert
98 Discreet quick status 1 (status value for AL call request)
Discreet quick status 2 (status value for AL emergency call
99
request)
100 Normal Operation User Profile
101 User Profile 2
102 User Profile 3
103 User Profile 4
104 User Profile 5
105 User Profile 6
106 User Profile 7
107 User Profile 8
108 User Profile 9
109 User Profile 10


110 Do Not Disturb
111 Goto WAP Homepage
112 Goto WAP Bookmarks
113 Goto WAP Browser Menu
114 Goto WAP Help
115 Goto WAP Browse
117 Bluetooth On / Off
118 Bluetooth Headset Connect / Disconnect
119 Display Missed Event Information box
120 Start Key Agreement
121 Toggle E2EE State
122 Enable Line Out
123 Disable Line Out
124 Toggle Line Out Enable State
125 Line In 1 PTT On
126 Line In 1 PTT Off
127 Line In 2 PTT On
128 Line In 2 PTT Off
133 Man Down Alert and Man Down Alarm Clear
134 Man Down Toggle soft key
136 „Send‟ (green) key TLS Quick Status
137 „Clear‟ (red) key TLS Quick Status
138 Day / Night Mode Toggle
139 Local LS Mute Toggle
140 Toggle Accessory Audio State
141 Menu option
142 Talkgroup folder option
143 Help Call
144 Stop Key Agreement
145 TMO Cryptomode Normal
146 TMO Cryptomode 3 Master/Auto
147 TMO Cryptomode 3 Master/Man
148 TMO Cryptomode 3 Slave
149 DMO Cryptomode 1
150 DMO Cryptomode 2
151 DMO Cryptomode 3 Master/Auto
152 DMO Cryptomode 3 Master/Man
153 DMO Cryptomode 3 Slave
194 Press PTT
195 Release PTT
196 Mute Internal Loudspeaker and Internal Earpiece
197 Unmute Internal Loudspeaker and Internal Earpiece
198 Enable portable line output
199 Disable portable line output
200 Key Press Vibration Alert Toggle
To guarantee correct SDA operation each SDA Action List must contain no
more than one Soft Key Function.

2.3 The ADDRESS table

Description
This table defines where to send messages to, and from which addresses messages are
expected.
Name Description
Dial String This is the dial string and mode combination parameter used to
Dial Mode address an outgoing message.
The Dial Mode may take the values:
Mode #1
Mode #2
Mode #3
Mode #4
Mode #5
Attribute This defines the destination address properties:
whether it is sent to a fixed address or whether the address may be
edited by the user before the message is sent;
whether the message is an individual or group message.
The Attribute may take the following values:
Fixed Individual Address
Editable Individual Address
Fixed Group Address
(Editable Group Addresses are not supported)
MESSAGE ADDRESS
LIST
Example
An example ADDRESS table:
Value Attribute
Dial String Dial Mode
ADDRESS 1 209906 Mode #1 Fixed Individual Address
A single address is defined for this Definition. It is a Fixed Individual Address.
Notes
Setting a Fixed Group Address Attribute with no Dial String will send the message to the
currently selected group.
This table may also be referenced from STRING LIST.

2.4 The CHECK VALUE table

Description
This table defines the list of fields and check values that will be used to match an incoming
SDS message. A single match is made against each entry and if all entries for a given ID
match successfully then the SDS match will be successful. Any single failure to match and
the whole match will fail.
Name Description
belong to the check value sequence definition, in the order in which
they appear in the table.
Field ID A reference to a specific (by position) parameter set in the FIELD table,
defining further parameters related to the field to be checked.
The following values may also be used (no definition in the FIELD table
required):
Message Completeness: To test the long SDS flag;
PID (previously 254): To test the PID;
Source ISSI (previously 253): To test the Source ISSI.
Value A reference to a specific (by position) value in the STRING LIST table,
used to compare the incoming SDS Message Field against. The actual
field value matched depends on the STRING LIST Type.
FIELD
MESSAGE CHECK CHECK VALUE
STRING LIST
Example
An example CHECK VALUE table:
ID Field ID Value
1 1 PID 17
2 1 Source ISSI 18
3 1 10 19
4 2 PID 17
5 2 Source ISSI 18
6 2 10 20
CHECK VALUE 7 3 PID 17
8 3 Source ISSI 18
9 3 10 21
10 7 PID 17
11 7 Source ISSI 18
12 7 11 22
13 7 10 23

The table shows four similar check sequences.

The fourth sequence, the parameter set where ID = 7, consists of four checks as follows:
The message PID must be equal to the value of the seventeenth STRING LIST value;
The message Source ISSI must be equal to the value of the eighteenth STRING LIST
value;
The value in the eleventh field, as defined by the Message ID in the calling MESSAGE
CHECK parameter set, must be equal to the value in the twenty-second STRING LIST
value;
The value in the tenth field, as defined by the Message ID in the calling MESSAGE
CHECK parameter set, must be equal to the value in the twenty-third STRING LIST
value;
If any check fails, the match sequence fails, and a match is not obtained. The next
MESSAGE CHECK table entry is then tested.
Notes
The Message Completeness Field ID is set as the SDS message is received, as follows:
If all parts of a Long SDS message (or a single SDS message) have been received it will
have a value of '1' representing 'Complete'.
If one or more parts of a Long SDS message have not been received it will have a value
of '0' representing 'Incomplete'.
In order to support more complex message checking the following are allowed as STRING
LIST values:
ANY - The comparison will always be successful if the field in question is present in the
message, regardless of the content of the field;
NON-ZERO - The comparison is applied to Binary and Numerical fields and will succeed
providing the field is present in the message and it has a value whose content does not
comprise of all zero bits;
Ranges of values - The comparison is applied to numerical field types and allows the
comparison to check against a list of values or range of non negative integer values,
including zero.
For example, it could have the following value string: 0, 4, 6, 91-110, 0x35.
There is a restriction on the use of Range values when referencing

ADDRESS, i.e. when the Field ID refers to the pre-defined SOURCE ISSI
value. In this case, where multiple ADDRESS entries are being referenced
each individual entry must be stated, for example, the STRING LIST entry
must contain “1,2,3,6,7,8” rather than “1-3,6-8”.

2.5 The EVENT CHECK table
Use of this table in an SDA requires a Sepura Premium Application Pack

Description
This table defines which internal events will trigger an SDA action.
Name Description
Event Defines the internal triggers that will be processed.
The Event may take the following values:
Power On - TMO
Power On - DMO
Registration - ITSI Attach
Trigger Control Defines under what circumstances the event is allowed to trigger.
The Trigger Control may take the following values:
Always Trigger
Trigger Once Every Power Cycle
Action ID This value is used to obtain a list of action(s) by finding all entries in
ACTION that match this value. These are processed in turn.
EVENT CHECK ACTION
Example
An example EVENT CHECK table:
Trigger Action
Event
Control ID
1 Power On - TMO Trigger Once 33
EVENT
Registration - ITSI Always 34
CHECK 2
Attach Trigger
And the ACTION table it references:

ACTION 2 33 Generate Alert 3 0
The first EVENT CHECK table entry defines that whenever the terminal powers on in TMO
actions with ID 33 will be triggered once.
The second EVENT CHECK table entry defines that actions with ID 34 will be triggered
whenever (Always Trigger) the terminal successfully completes a Registration with ITSI
Attach.
The ACTION table shows that for the first event (Action ID = 33) an SDS Message is sent and
an Alert raised. For the second event (Action ID = 34) an Alert is raised.

Notes
An Event must only appear once in the EVENT CHECK table. Further occurrences are not
searched for if a first occurrence fails to trigger an action.
Event triggered SDAs are executed in the order they are triggered. They are queued until the
radio is able to process them. Reasons for queuing include waiting for the start up procedure
to complete and a form still being displayed from a previous SDA. If the queue, which has a
size of three, is full, any new events are discarded.
Event triggered SDAs have pre-emptive Form display priority over SDS triggered SDAs i.e.
the SDS triggered Form is closed as if the user had navigated away.

2.6 The FIELD table

Description
This table defines field detail, either for presentation purposes, or for construction /
deconstruction of SDS Message purposes.
Name Description
NM Default String Normal Mode Default String. A reference to the required string in
STRING LIST (by position), displayed as the default in normal mode.
A value of 0 indicates there is no string associated with this field.
LM Default String Large Mode Default String. A reference to the required string in
STRING LIST (by position), displayed as the default in large mode.
A value of 0 indicates there is no string associated with this field.
Max Length 1-140 - If this field is defined as being for ‘Data Input’ (see parameter
below) then this value represents the maximum number of characters
that can be entered into the field when used in a form.
Otherwise the value should be set to any non zero value.
Attributes This value defines how a field will be displayed.
The following Attributes combinations can be set:
Data Input
Data Input, Numerical
Data Input, Secure
Data Input, Secure, Numerical
Fixed Text
Fixed Text, Reverse Video
Fixed Text, Underline
Fixed Text, Secure
Fixed Text, Secure, Reverse Video
Fixed Text, Secure, Underline
(Other combinations are not supported)
FORM FIELD
CHECK VALUE
FIELD STRING LIST
MESSAGE DEFN
LIST

Example
An example FIELD table:
NM LM
Max
Default Default Attributes
Length
String String
1 1 1 1 Fixed Text
2 0 0 140 Data Input, Secure
3 0 0 1 Fixed Text
4 0 0 140 Data Input
5 Fixed Text,
6 7 1
Underline
6 8 8 1 Fixed Text
7 9 9 1 Fixed Text
FIELD 8 10 10 1 Fixed Text
9 Fixed Text,
11 12 1
Underline
10 Fixed Text, Reverse
13 13 1
Video
11 Fixed Text, Reverse
14 14 1
Video
12 Fixed Text,
15 16 1
Underline
The first definition indicates a field with default text, the same in normal and large modes, set
by the first and second entries in STRING LIST. Its length is set to an arbitrary value (in this
case '1') as it is not a 'Data Input' field.
The next three definitions do not have default text. The first and last are allowed to be 140
characters in length as they are 'Data Input' fields. The first of the three, when displayed will
be a 'Secure' field.
The fifth field definition uses different default strings, a situation that can arise to cope with the
restricted number of characters that can be displayed in large mode.
Notes
A default string may be set to populate an editable field as a starting point.
Attributes:
Fixed Text, indicates that the field cannot be edited (used as a caption for example)
Data Input, indicates that the field can be edited when displayed on a form;
Reverse Video, allowing some information, when displayed, to stand out from other
information;
Secure, indicates that when the field is displayed, its contents are represented as a '*'
replacing each actual character;
Underline, as an alternative to Reverse Video, allowing some information, when
displayed, to stand out from other information;
Numerical, restricts input to the numbers 0 to 9 only. The field will be left aligned. This
attribute only restricts character entry; the field itself may be populated with any
characters as a result of a default or from data in a referenced SDS message.
When secure data is cached it has an associated lifetime. This defines the time, from when
the form containing the secure data is closed, that expires the data has to be re-entered. The

timeout is controlled by the terminal parameter [Secure Field Timeout] and ranges form zero
(do not cache) to 30 minutes.
There are special FIELDs which require no definition. They are referenced by name, being:
Message Completeness (of long SDS message);
OPTA;
Message Source ISSI (previously numbered 253);
Message PID (previously numbered 254).
Attributes are overridden if the field has an associated action (in FORM FIELD). The field will
be displayed as a 'button' (two line outline).

2.7 The FORM table

Description
This table forms part of the definition of how the SDS Message will be displayed on the UI. It
handles the top level functions such as the form's name, which message to use, any actions
to be performed when it is sent and any form attributes. The exact contents of the form are
defined in the FORM FIELD table.
Name Description
Name A reference to the required string in STRING LIST (by position),
displayed when selecting the Form from the SDA Card
Message ID A reference to a specific (by position) parameter set in the MESSAGE
table, defining the message structure to be used when displaying a
message or constructing a message
Action ID 0 - When a form is displayed from the SDA card, pressing the green
telephone key performs the default actions of 'Send SDS Message'
and 'Save To Permanent Cache'
When a form is displayed from the Inbox, the green telephone key
is disabled from sending this form.
1-255 - This value is used to obtain a list of action(s) by finding all
entries in ACTION that match this value. These are processed in
turn when the green telephone send key is pressed.
Attribute This value defines attributes of the form:
whether the message displayed by this form, in the Message Inbox,
is saved at switch off;
whether when a new Form is displayed, fields are allowed to get
data from the cache (of previous field values for each field).
The following Attributes can be set:
Saving & Caching Disabled
Saving Enabled & Caching Disabled
Saving Disabled & Caching Enabled
Saving & Caching Enabled
A single parameter set is referenced, by position in the table.
PROTOCOL STRING LIST
MESSAGE CHECK FORM MESSAGE
LIST ACTION

Example
An example FORM table:
Message Action
Name Attributes
ID ID
1 29 1 2 Saving Disabled, Caching Enabled
FORM
This FORM definition indicates that there will be four forms, two of which have no name
(name not required here as the form is only displayed as a result of an incoming message).
The second form will:
th
have a name taken from the 30 STRING LIST parameter set;
nd
use the information in the SDS Message as directed by the 2 parameter set in the
MESSAGE table;
when sent process the actions in the ACTION table that have an ID of '3';
and the form will not be saved if in the Inbox (when powered down) and may be
populated from cached data.
Notes
It is recommended that all forms do reference a name. It is essential for a form to have a
name if it is the basis of an outgoing message.
A form action will not be triggered if the currently selected field itself has an associated action.
If Action ID is set to '0', it will be necessary to attach the required action to a displayed and
selectable field.
The Cache: The cache is updated, when a message is sent when no actions are associated
with a form (or a field on a form) or by use of the 'Save To Permanent Cache' function. It
saves all fields on a Form. If 'Caching Enabled' is set the cache is used as a potential source
of data for this form. Data is sourced in the following order (if they exist / are enabled): from
the SDS Message, from the permanent cache, from defaults.
Note that cached secure data has an associated lifetime after which it is deleted and has to
be re-entered.

2.8 The FORM FIELD table

Description
This table defines the UI layout of the Forms including fields and their parameters (placement,
size, attributes, etc.), field actions and the navigation order. The definition is for both Normal
and Large display modes, catering for alternative layouts but for common navigation order
and actions. Also included are whether the field is mandatory and if it has any validation rules
applied.
Name Description
ID A reference to the Form on which this field will be displayed. See below
for further information.
Field ID A reference to a specific (by position) parameter set in the FIELD table,
defining further parameters related to the field to be displayed
Action ID 0 - The action(s) are defined by the form (FORM - Action ID) and not
by this field, when the green telephone key is pressed
1-255 - This value is used to obtain a list of action(s) by finding all
entries in ACTION that match this value. These are processed in
turn when the green send key is pressed
XN 1-128
This is the „x‟ co-ordinate of the top left corner of this field, defined
in pixels, when in Normal mode
YN 1-65535 - This is the „y‟ co-ordinate of the top left corner of this field,
defined in pixels, when in Normal mode
WN 1-128
This is the width of this field, defined in pixels, when in Normal
mode
HN 1-6 for 3000 Series & 8200 Series, 1-7 for 8000/8100 Series
This is the height of this field, defined in terms of „lines of text‟,
when in Normal mode
XL 1-128
This is the „x‟ co-ordinate of the top left corner of this field, defined
in pixels, when in Large mode
YL 1-65535 - This is the „y‟ co-ordinate of the top left corner of this field,
defined in pixels, when in Large mode
WL 1-128
This is the width of this field, defined in pixels, when in Large mode
HL 1-4 - This is the height of this field, defined in terms of „lines of text‟,
when in Large mode
Navigation Order 0 - The field is not navigable
1-255 - This field is navigable. The order of the field 'tabbing' will be
numerical with the lowest number being selected first.
Completion Defines whether it is mandatory for this field to be filled in.
Mandatory The Completion Mandatory may take the following values:
Completion Optional
Completion Mandatory
Local Validation 0 - Local validation of this field not required
Rules ID 1-255 - This value is used to obtain a list of validation rule(s) by finding
all entries in VR LIST that match this value. These are processed in
turn when the user navigates away from the field or when the green
send key is pressed

Local Validation 0 - Local validation help message not required

Help Message ID 1-255 - A reference to the required string in STRING LIST (by position)
that contains a validation help message for this field. The user may
select to display this message.
Multiple parameter sets are referenced, by ID. The required parameter sets have the same ID
as the Form's position in the Form table, i.e. the fifth form will display all the fields defined in
the FORM FIELD table that have an ID of '5'.
FIELD
ACTION
FORM FORM FIELD
VR LIST
STRING LIST
Example
An example FORM FIELD table:
Action
Field
Order
Nav.
ID XN YN WN HN XL YL WL HL
ID
ID
6 2 13 0 5 5 116 1 5 5 116 1 0
7 2 15 0 5 20 55 1 5 25 116 1 0
8 2 7 0 65 20 55 1 5 43 116 1 1
9 2 16 0 5 35 55 1 5 61 116 1 0
10 2 8 0 65 35 55 1 5 79 116 1 2
FORM FIELD 11 3 17 0 5 5 116 1 5 5 116 1 0
12 3 18 0 5 20 116 1 5 25 116 1 0
13 3 10 0 5 35 116 1 5 45 116 1 1
14 4 17 0 5 5 116 1 5 5 116 1 0
15 4 10 0 5 20 116 1 5 25 116 1 1
16 4 11 0 5 35 116 1 5 45 116 1 2
. . . more columns:

Completion
Validation
Validation
Message ID
Mandatory
Rules ID
Local
Local
Help
ID
6 2 Completion Optional 0 0
FORM FIELD 11 3 Completion Optional 0 0
13 3 Completion Mandatory 21 50
The table above shows the definitions for three forms (as indicated by IDs 2, 3 and 4). Form 3
has three fields (Field IDs 10, 17 and 18), two of which are 'not navigable' (as they are a label
and a prompt text).
In addition Field ID 10 is
defined as mandatory (must be filled in)
when filled in validation rules from VR LIST which match the Local Validation Rules
ID (21) apply
th
local validation is supported by help text from the 50 entry in STRING LIST
No actions are defined and the form will be sent, assuming mandatory and validation tests
pass, when on any navigable field, by pressing the green telephone key.
When the form is displayed, the first field with focus will be the one with the lowest (non zero)
number, for example Field ID 7 for Form 2.

Notes
The UI layout uses a virtual screen which is then scaled to the physical pixels of the product
screen.
The width of the virtual screen is 128 pixels and form designs should ensure that the 'x'
coordinates and widths are set accordingly.
Similarly the height of the virtual screen is 64 pixels and form designs should ensure that the
'y' coordinates and heights are set accordingly.
If the whole of the width of a field cannot be displayed, it is not shown at all.
'y' coordinates are zero at the top of screen, and increase down the screen.
See Chapter 3 for further layout information.
For each Form Field - ID number, the Navigation Order value must either be zero or have a
unique non-zero number.
The maximum number of fields on any form is 20.
Mandatory completion fields are indicated by an icon (which is still displayed when the field is
filled in).
A field that has failed local validation rules is indicated by an icon. The icon is cleared when
the contents pass validation. Only fields where the user has entered data are validated.

2.9 The LIST table

Description
This table holds information that can be referenced by other tables and returns the parameter
set(s) where a lookup ID matches the LIST - ID. The LIST - ID value may be repeated and the
lookup will return all parameter sets that match.
Name Description
ID Lookup reference
Entry Type Indicates the type of data in Entry below.
Unsigned Integer
Address ID
Field ID
Form ID
Message ID
Entry Either a 32 bit unsigned integer value (Entry Type = Unsigned Integer)
or a byte reference ID to act as a lookup value to a table
Multiple parameter sets are referenced, by ID.
ADDRESS
PROTOCOL
FIELD
ACTION LIST
FORM
MESSAGE
Example
An example LIST table:
ID Entry Type Entry
1 1 Message ID 1
2 1 Address ID 1
3 2 Form ID 11
LIST
4 2 Form ID 22
5 3 Message ID 2
6 3 Address ID 1
This table could be used by a PROTOCOL table lookup to find which forms to offer on the
display. As an example, the PROTOCOL - FORM LIST ID could be '2' which would match
with the third and fourth entries. This would return these two parameter sets indicating that
the related forms are Form 11 and Form 22 (FORM information is indexed by position in the
table).
Similarly a request with ID equal to 3 (from an ACTION table) would in this case return
information relating to a message and its address. In the example table above a reference to

the second message definition (in the MESSAGE table) and the first address definition (in the
ADDRESS table) would be returned.

2.10 The MESSAGE table

Description
This table forms part of the (high level) definition of how the SDS Message will be constructed
(for transmission) or deconstructed (for display). It handles the top level functions such as the
outgoing PID, character set and addressing (by reference to the ADDRESS table). The exact
contents of the message are defined in the MESSAGE DEFN table.
Name Description
PID This is the PID that will be used in the outgoing SDS message
constructed using this structure
The following PIDs should not be used:
193 (RUA)
195 (Callout)
Character Set This is the Character Set that will be used in the outgoing SDS
message constructed using this structure.
The character set indicator will precede the SDS payload unless set to
'Not used'.
The following Character Sets may be selected:
Not used
Latin ISO 8859-1 (8 bit)
Latin ISO 8859-5 (8 bit)
Unicode (16 bit)
GSM 7-bit
Customised Encoding Scheme (8 bit)
Address ID A reference to a specific (by position) parameter set in the ADDRESS
table, defining further parameters related to the address to which the
message will be sent
Message Defn ID This value is used to obtain a list of SDS Message element (low level)
definitions by finding all entries in MESSAGE DEFN that match this
value. These are processed in turn when the message is constructed
or deconstructed.
A single parameter set is referenced, by position in the table.
FORM
ADDRESS
MESSAGE CHECK MESSAGE
MESSAGE DEFN
LIST

Example
An example MESSAGE table:
Address Message
PID Character Set
ID Defn ID
1 130 Latin ISO 8859-1 (8 bit) 1 4
2 130 Latin ISO 8859-1 (8 bit) 1 2
MESSAGE
3 130 Latin ISO 8859-1 (8 bit) 1 3
4 130 Latin ISO 8859-1 (8 bit) 1 1
There are four messages being dealt with in this Definition.
If the messages were sent, they would be sent:
Using a PID 130 (text message) header;
With a character set identifier before the payload;
With a payload as defined by the Message Defn ID (i.e. for the first message, using
the parameter sets in MESSAGE DEFN that have an ID of '4');
To an address defined in the ADDRESS table, in this case all messages being sent to
the first address definition in the ADDRESS table.
Notes
When Character Set is set to 'Customised Encoding Scheme' the 8 bit character set to use is
defined by terminal parameter [Text Coding Scheme 1].
For incoming messages with a PID of 2, 9, 132, 137, or 138, i.e text messages, the SDA
expects a coding scheme byte in the message. Other incoming messages should not contain
a coding scheme byte.

2.11 The MESSAGE CHECK table

Description
This table defines the rules by which incoming SDS Messages are checked to find an
associated Form and Message Definition.
If the Check Value entries all equal the values defined in the incoming SDS message when
using the MESSAGE DEFN table to extract the relevant fields, then a valid match is made.
The associated FORM table is used to display the information in the SDS Message when
such a successful match is made.
Name Description
Message ID This is a reference to the MESSAGE table (by position) that is used to
extract the field of the incoming SDS for potential matching
Form ID This is a reference to the FORM table (by position) that will be used to
display the incoming SDS Message if a successful match is made
Check Value ID This is a reference to the CHECK VALUE table that contains the field
references and associated values that will be used to compare against
the incoming SDS message
Action ID This is a reference to the ACTION table that configures what happens
when a match is achieved
MESSAGE
FORM
MESSAGE CHECK
CHECK VALUE
ACTION
Example
An example MESSAGE CHECK table:
Message ID Form ID Check Value ID Action ID
1 3 3 1 0
2 4 4 2 0
MESSAGE CHECK
3 4 3 3 0
4 4 4 4 0
The check takes each row above in turn. So, firstly the incoming SDS Message is
deconstructed using the information in the third parameter set of the MESSAGE table. The
CHECK VALUE table parameter sets that have an ID of '1' are then compared to the
indicated parts of the message (see CHECK VALUE section for more information).
If any check fails the procedure moves on to the next line of this table (until the end of the
table), deconstructing the messages according to the Message ID and checking for a match
using the Check Value ID referenced information.
If a match is found (all checks in CHECK VALUE pass) then

the message is associated with the indicated FORM table (for subsequent display
purposes for example)
it is placed in the Message Inbox with its associated Form ID
and the actions indicated by the Action ID (referencing the ACTION table) are initiated.
In this example there are no actions to be initiated.
Notes
Either a Form ID and / or an Action ID must be specified.
The incoming SDS Message is checked using each parameter set, in turn, until a match is
made. If no match is achieved the message is placed in the Message Inbox with no
associated Form.

2.12 The MESSAGE DEFN table

Description
This table defines the message elements that make up the SDS Message payload(s).
Name Description
belong to the message definition
Field ID This is a reference to the FIELD table so that the information can be
transferred between the message and a form using the relevant field
It is a reference to a specific (by position) parameter set in the FIELD
table also referenced by FORM FIELD
The following values may also be used in the definition of outgoing
messages (no definition in the FIELD table required):
Message Completeness flag
OPTA
Type This defines the type of the field in the message (see below and 2.14
Data Types for further information):
Type 1: Fixed Length
Type 1: Variable Length
Type 2
Delimited
Character This value defines the alignment properties of the field:
Alignment whether the field starts on a bit or byte boundary, relative to the
start of the payload (for the SDS Message defined by this
MESSAGE DEFN (entries using the same ID as used by this
entry);
whether the data in the field is aligned to the left or right side of
the field.
The following Character Alignments may be selected:
Right Bit Aligned
Right Byte Aligned
Left Bit Aligned
Left Byte Aligned
Character Size Defines how the field contents are encoded in the message:
Binary
ISO 8859-1
ISO 8859-5
Numeric
Unicode
GSM 7-bit
Customised Encoding Scheme
See 2.16 for further information.
Length This is only used when the Type is set to „Fixed Len: Type 1‟ or „Type
2‟
This is the length of the field in units of those defined in the Length
Multiplier value

Length Multiplier This defines the number of bits in each value defined in the Length
value:
Bits
Nibble (4 bits)
7-Bit (7 bits)
Byte (8 bits)
Word (16 bits)
Depends Upon This field references a Field ID defined in a previous entry in this
message definition table.
A value of zero means that this field is Not Conditional.
If it is non zero, it may be used for:
If the Type is set to 'Type 1: Variable Length' the indicated field
returns the Length (which is then multiplied by the Length
Multiplier value);
If the Type is set to 'Delimited' the delimiter will be the first 8 bits
of the indicated field (or first 7 bits for a 7 bit Character Size);
Otherwise, the indicated field is tested against the Depend Value
value to determine if this field 'exists' in the SDS Message.
Depend Value This is a reference to the STRING LIST table (by position) where the
string value used when handling conditional fields in this MESSAGE
DEFN entry.
If the „Depend Value‟ is set to a value of zero this means there is no
string value associated with this MESSAGE DEFN entry.
Delimiter Value This is only valid when the Type is set to „Delimited'.
It is a reference to a STRING LIST entry (by position) used to hold
the delimiting value for this field. The actual field value matched
depends on the STRING LIST Type - see 2.14 Data Types
FIELD
MESSAGE MESSAGE DEFN
STRING LIST

Example
An example MESSAGE DEFN table:
ID
Character
ID Type
Field
Alignment
1 10 10 Delimited Right Bit Aligned

2 10 8 Type 1: Fixed Length Right Byte Aligned
4 10 5 Delimited Right Byte Aligned
MESSAGE DEFN

8 11 5 Delimited Right Byte Aligned
11 12 29
Type 1: Variable
Left Byte Aligned
Length
. . . more columns:
Multiplier
Character
Delimiter
Depends
Length
Depend
Value
Value
Size
Upon
ID Length
1 10 ISO 8859-1 0 Bits 0 0 11

2 10 ISO 8859-1 256 Bits 0 0 0
3 10 ISO 8859-1 96 Bits 0 0 0
MESSAGE DEFN
4 10 ISO 8859-1 0 Bits 0 0 24

5 11 ISO 8859-1 0 Bits 0 0 12
6 11 ISO 8859-1 256 Bits 0 0 0
7 11 ISO 8859-1 96 Bits 0 0 0
8 11 Binary 0 Bits 0 0 25
9 12 ISO 8859-1 0 Bits 0 0 13
10 12 ISO 8859-1 8 Bits 0 0 0
11 12 ISO 8859-1 0 Bits 28 0 0
12 12 ISO 8859-1 1 Word 0 0 0
The first message definition, the parameter set where ID = 10, shows the message
consisting of four fields as follows:
1. A Delimited field, bit and right aligned, ISO 8859-1 encoded, with the delimiter defined
th
in the 11 parameter set of STRING LIST;

2. A Type 1: Fixed Length field, byte and right aligned, ISO 8859-1 encoded, with a
length of 256 bits;
3. As 2. but with a length of 96 bits;
th
4. As 1. but with the delimiter defined in the 24 parameter set.
Representing:
Field: 1 2 3 4
Description: A string and 32 characters 12 A string and
a delimiter characters a delimiter
Example: Start# abc . . . xyz ' test' End*
Note: Quotes only shown to indicate embedded spaces, they are not part of the string.
Note: The rest of the message is ignored and not used.
The second message definition, the parameter set where ID = 11, is similar to the first apart
from using different delimiter sources and the fourth field being Binary data.
The third message definition, the parameter set where ID =12, defines the following
message structure:
Field: 1 2 3 4
Description: A string # Length of A string Number
(delimiter) next string (16 bits)
(8 bits)
Example: Immediate # 10 'Location: ' 0x1234
Note: Quotes only shown to indicate spaces, they are not part of the string.
Consisting of 4 fields as follows:
1. A Delimited field, bit and right aligned, ISO 8859-1 encoded, with the delimiter defined
th
in the 13 parameter set of STRING LIST (in this case a '#');
2. A Type 1: Fixed Length field, byte and right aligned, with a length of 8 bits;
3. A Type 1: Variable Length field, byte and left aligned, with a length which is obtained
from Field 28 (includes a final space character in the example);
4. A Type 1: Fixed Length field, byte and right aligned, with a length of 16 bits (1 word).
Notes
The order of parameter sets in the table defines the order in the SDS Message. That is the
first entry represents the MSB in the message and the last the LSB in the message.
The link between the field on a form and the field in a message is achieved by them sharing
the same ID referencing the FIELD table.

Field ID:
When set to 'OPTA':
If an OPTA is not supported by the product the field generates a zero length string.
The Length and Length Multiplier should be set to that required by the OPTA,
otherwise the OPTA will be truncated or padded.
An OPTA is padded by the terminal parameter [Unused OPTA Character 7-bit
Mapping] if its Character Size is set to 'GSM 7-Bit', otherwise it is padded with 0xFF
('8-bit') or 0x00FF ('16bit'). 'Binary' and 'Numerical' Character Sizes are not supported
for OPTA.
Character Size cannot be set to 'Binary' or 'Numerical'
Systems that support OPTA typically require the first field of every message to be an
OPTA.
When set to 'Message Completeness':
A value '1' indicating 'Complete' is used for a new message.
If the message being sent is based on a received message the value will reflect the
received state of that message, a value of '1' if it was a single message or if all its
parts were received, a value of '0' if one or more of its parts were not received.
The field will be padded by zero bits if Character Size is Binary or Numerical and by
the equivalent value that represents the character for zero for all other Character
Sizes.
Types:
Type 1: Fixed Length, the length is specified in the definition;
Type 1: Variable Length, the length is defined in the SDS Message and is accessed
using the Depends Upon parameter;
Type 2, fields are preceded by a presence bit, and if present are of fixed length;
Delimited, the field continues until the designated (Delimiter Value) value. If the
Delimiter Value is zero then the field continues to the end of the message.
Character Alignment:
Type 2 data will be right aligned, Type 1 data may be right or left aligned;
If required the data will be padded with zeros (Null characters), or truncated.
Padding will be added at the start of the string if the field is right aligned or at the end of
the string if it is left aligned.
Fields that are to be GSM 7-bit encoded will be padded with a <CR> (00011012) first,
before padding with <SP>s (01000002). The first padding character will be a <CR>.
Other padding characters will be <SP> characters. For example 'Hello' when padded to 9
characters, left aligned, becomes 'Hello<CR><SP><SP><SP>'.
Fields will be truncated from the left if the field is right aligned and from the right if it is left
aligned.
The Character Size parameter defines how the field value is encoded into the message (and
vice versa). See Appendix B for information on how 7 Bit Text is packed into whole octets.
Note that if consecutive fields or fields and delimiters both use 7-bit encoding and are not
byte aligned, they are packed as if they are joined together into a single field. Otherwise
the fields are packed individually according to their encoding type. The fields are aligned
(as above) before they are joined.
The 'Customised Encoding Scheme' setting allows the mapping of the 8 bit data in the
message to 16 bit values for presentation on the terminal UI and in reverse for translating
data entered via the UI for encoding into the field. The mapping is defined in terminal
parameter [Transcoding Table 1]. Where a mapping is not possible the space character will
be used.

The length of a message element is obtained from the product of the Length value and the
Length Multiplier value. For example if Length is '10' and Length Multiplier is 'Byte'
(indicating 8 bits) then the actual length in the SDS Message is 80 bits.
For GSM 7-bit encoded data this 'Length x Length Multiplier' is the length of the original
text data i.e. it is in multiples of seven. It will be rounded down to a multiple of 7 if set
incorrectly. The original text data (after packing if required) are encoded into a string of
bytes as described in Appendix B.
Depends Upon may be used:

to obtain the length of a variable length field from within the message
to obtain the delimiter to be used from within the message
or may be used to make the field's existence dependant on the value(s) or existence of
another (preceeding) field.
The Delimiter Value value is ignored if this field is conditional (i.e. Depends Upon is non
zero).

2.13 The PROTOCOL (Family) Table

Description
This table holds information relating to the Protocols (Families) and their Forms, displayed by
the SDA card.
Name Description
Name A reference to the required string in STRING LIST (by position),
displayed in the tabs of the SDA card
0 - Indicates end of table entries
1-255 - Use the nth string in STRING LIST
Form List ID 0 - Indicates that this Family will not be displayed or be accessible
1-255 - This value is used to obtain a list of FORM numbers by finding
all entries in LIST that match this value. These are used to display
the list of available Forms for each Family.
FORM (via LIST)

PROTOCOL
STRING LIST
Example
An example PROTOCOL table:
Name Form List ID
1 74 21
PROTOCOL
2 108 1
th
This example indicates that there will be two Families. Their names are given by the 74 and
th
108 entries in STRING LIST.
The Form List ID will reference the LIST table, which will have one or more entries with this
value. It will return a form number for each of these matches. This returned form number will
be used to access the FORM table which contains (by referencing STRING LIST) the form
names for each family.
Notes
Families will be displayed in this order on the tabs of the SDA card.
Each tab, when selected, will display a list of selectable forms.

2.14 The STRING LIST table

Description
This table defines the type and value of the strings referenced by other tables.
Name Description
Type The type of value being defined:
8 Bit Text
16 Bit Text (Unicode)
Numerical (as a string)
Binary (as a hexadecimal string)
7 Bit Text (GSM)
See 2.14 Data Types for further information.
Value The data
FORM FIELD
CHECK VALUE
FIELD
MESSAGE DEFN
STRING LIST
FORM
PROTOCOL
ACTION
VR LIST

Example
An example STRING LIST table:
Type Value
1 8 Bit Text User ID:
3 8 Bit Text Current Pwd
4 8 Bit Text New Pwd
5 8 Bit Text PIN:
6 8 Bit Text Current PIN:
7 8 Bit Text New PIN:
8 8 Bit Text FAILURE
9 8 Bit Text SUCCESS
STRING LIST 10 Numerical 130
11 Numerical 1,2,5
12 8 Bit Text #
13 Binary 0x0800
14 Binary 0x02
15 Binary 0x2300
16 Binary 0x0a
17 8 Bit Text Login
18 8 Bit Text PIN Change
19 8 Bit Text ANY
Items to note are:
For the Type = '8 Bit Text' rows - Any characters may be used;
In row 11 - The use of a range (for use by CHECK VALUE), indicating 1 or 2 or 5;
In row 12 - This item probably represents a delimiter string;
In row 14 - This may be an indication to use the second parameter set in the ADDRESS
table
In row 16 - The hexadecimal format must be used but will accept upper and lower case;
In row 19 - The pre-defined check value (see CHECK VALUE Notes).
Notes
Do not put addresses in this table, just the 'reference' to the ADDRESS table (by position).

2.15 The VR LIST Table
Use of this table in an SDA requires a Sepura Premium Application Pack

Description
This table defines the validation rules applied to fields on SDA forms. Forms must pass all
validation checks before a form can be submitted. The user is alerted to validation failures.
Name Description
Entry ID Lookup reference. All parameter sets with the same Entry ID value
will belong to the validation rules set applied to the FORM FIELD
Rule ID This defines the rule that is applied to the field.
The following Rule IDs may be selected:
Date ddmmyy - checks for valid Gregorian calendar date in format
ddmmyy or ddmmyyyy, leap years taken into
account
Date mmddyy - checks for valid Gregorian calendar date in format
mmddyy or mmddyyyy, leap years taken into
account
Date yymmdd - checks for valid Gregorian calendar date in format
yymmdd or yyyymmdd, leap years taken into
account
Time 24hr - checks for a valid 24 hour time in the format hhmm
Alpha Only - checks that the entered string only contains text (no
numbers or symbols). The space character is
allowed. See below for definition of 'text'.
Alphanumeric - checks that the entered string only contains text
and/or numbers (no symbols). The space
character is allowed. See below for definition of
'text' and 'numbers'.
Check Length - checks that a string is within an allowed length
range. The range string (min,max) is referenced
by Rule Parameters ID
Check Range - checks that an integer number is within an allowed
range. The range string (min,max) is referenced
by Rule Parameters ID
Rule Parameters ID This is a reference to the STRING LIST table (by position) where the
string value defines the data needed by some Rule IDs
FORM FIELD VR LIST STRING LIST

Example
An example VR LIST table:
Entry ID Rule ID Rule Parameters ID
1 1 Date ddmmyy 0
VR LIST 2 2 Check Length 29
3 2 Alpha Only 0
And the STRING LIST table it references:

Type Value
..
STRING LIST 29 8 Bit Text 3,8
..
The VR LIST table above shows the definitions for two validation rules (as indicated by Entry
ID 1 and 2), each applied to a different FORM FIELD.
The first validation rule checks for a correctly entered date format.
The second validation rule checks that the entered data is both alpha text only and has a
length between 3 and 8 characters.
Notes
The Alpha Only validation rule considers the following Unicode characters to be valid:
0x0020 (Space)
0x0041 to 0x005A (Standard upper case)
0x0061 to 0x007A (Standard lower case)
0x00C0 to 0x00D6 (European characters)
0x00D8 to 0x00F6 (European characters)
0x00F8 to 0x00FF (European characters)
0x011E to 0x011F (Turkish characters)
0x0130 to 0x0131 (Turkish characters)
0x0150 to 0x0151 (Hungarian characters)
0x015E to 0x015F (Turkish characters)
0x0170 to 0x0171 (Hungarian characters)
0x0370 to 0x03FF (Greek characters)
0x0400 to 0x04FF (Cyrillic characters)
0x0600 to 06FF (Arabic characters)
0x20AC (Euro character)
0xFE70 to 0xFEFF (Arabic characters)
The Alphanumeric validation rule adds the following to the Alpha Only list:
0x0030 to 0x0039 (Numbers)
The following applies when more than one validation rule is applied to a field (i.e. multiple
Entry IDs have the same value):
The rule order is not important
The results of all rules of the same type are OR'd together to form true or false
results (allowing validations such as the field is between 10 and 20 OR between 50
and 60)

The results of all same type rules are AND'd together with the results of individual
rules
The resulting true or false is used to report validity

2.16 Data Types - Use of MESSAGE DEFN Char Size and STRING LIST
Type
Information presented on the UI may come directly from the STRING LIST table or may be
part of a message defined by a MESSAGE DEFN table. As explained below, how that data is
actually displayed depends on the source definition - Char Size for MESSAGE DEFN data,
Type for STRING LIST data.
Information encoded into a message, either from a STRING LIST or from the UI, will be
encoded using the Char Size parameter within the MESSAGE DEFN table.
2.16.1 STRING LIST Types - Used by UI, Check Values and Delimiters
The Types of Values in the STRING LIST tables may be 16 bit text, 8 bit text, 7 bit text,
Numeric or Binary.
16 bit text values are stored as Unicode strings and the others as 8 bit ASCII strings, with
Numeric being a base-10 value and Binary a hex value.
The following apply depending on where the STRING LIST value is being used:
On the UI
When displayed on the UI they will be displayed as defined.
As a Check Value
The actual value matched depends on the Type value in the STRING LIST table for that
entry. For example if the value is set to "130", depending on the Type set in STRING LIST,
this will match with the following values in the message:
Type Matches With
16 Bit Text 0x003100330030
8 Bit Text 0x313330
Numeric 0x82
Binary 0x130
0xB1190C
7 Bit Text (see Appendix B for conversion
rules)
As a Delimiter
The use of the delimiter referenced by the MESSAGE DEFN table also uses the STRING
LIST Type to define the value of the delimiter, as Check Value example above.

2.16.2 Encoding STRING LIST Or UI Values Into A Message

The MESSAGE DEFN Char Size setting controls how data, whether from a STRING LIST
value or entered on the UI, will be encoded into the Message.
The available Char Size options are:
Unicode
The data will be treated as if it represents a series of Unicode strings, as follows:
Field Data Message Data (Hex)
“0x1234” 0x003000780031003200330034
“1234” 0x0031003200330034
“12abc” 0x00310032006100620063
“Fred” 0x0046007200650064
“剥浯” 0x52656D6F
“회신대상:각디가 ” 0xD68CC2E0B300C0C1003AAC01B514AC00
Note that each 'character' has its Unicode value.
ISO 8859-1, ISO 8859-5 (8 bit Non Unicode)

The data will be treated as if it represents a series of 8 bit ASCII strings, as follows:
“0x1234” 0x307831323334
“1234” 0x31323334
“12abc” 0x3132616263
“4321456789” 0x34333231343536373839
“Fred” 0x46726564
“Remo” 0x52656D6F
“회신대상:각디가 ” 0x8CE000C13A011400
Note that if the data is actually a 16 bit character it will have its most significant byte
stripped off and may become meaningless.
Numeric
The data will be treated as if it represents a numerical value in base 10, as follows:
“0x1234” 0x0
“1234” 0x4d2
“12abc” 0x0
“1382378863” 0x52656D6F
“4123456789” 0xF5C6F515
“4321456789” 0x0
“-45” 0x0
“Fred” 0x0
Note that the data will be treated as if it were zero if:
no value has been entered;
it contains invalid values;
32
it is out of range (0 to 2 - 1 incl.).
Binary
The data will be treated as if it represents a series of bytes represented in hex format, as
follows:


“0x1234” 0x1234
“1234” 0x1234
“12abc” 0x12abc
“4321456789” 0x4321456789
“52656D6F” 0x52656D6F
“Fred” 0x0
“회신대상:각디가 ” 0x0
Note that the data will be treated as if it were zero if:
no value has been entered;
it contains invalid values.
7 Bit Text
The data will be treated as if it represents a series of 7 bit ASCII strings, as follows:
“0x1234” 0x307C4C36A301
“1234” 0x31D98C06
“12abc” 0x3159583C06
“RJ5äù” 0x52656D6F00
“seventy” 0xF3B2BDECA6E71B
see Appendix B for conversion rules
Note that if the data is actually a 16 or 8 bit character it will have its most significant bits
stripped off and may become meaningless.
2.16.3 Decoding Message Fields To Be Displayed On The UI

The MESSAGE DEFN Char Size setting controls how data will be displayed on the UI.
The available Char Size options are:
Unicode
The value of the field will be presented as a series of 16 bit Unicode characters, as follows:
Message Data (Hex) Field Data
0x46726564 “”
0x0031003200330034 “1234”
0x003000780031003200330034 “0x1234”
0x0046007200650064 “Fred”
0x52656D6F “剥浯”
0xD68CC2E0B300C0C1003AAC01B514AC00 “회신대상:각디가 ”

ISO 8859-1, ISO 8859-5 (8 bit Non Unicode)

The value of the field will be presented as a series of 8 bit ASCII characters, as follows:
0x46726564 “Fred”
0x31323334 “1234”
“”
0x003000780031003200330034 (as first 'character' is
00/Null)
0x52656D6F “Remo”
Numeric
The value of the field is considered to be a base 10 number and will be presented as such,
as follows:
0x4d2 “1234”
0x12abc “76476”
0x101943295 “26489493”
0xF5C6F515 “4123456789”
0x52656D6F “1382378863”
0x0 “0”
Note that only the least significant 32 bits will be taken into account and where no value is
present it will be treated as the value zero.
Binary
The value of the field will be presented as a right aligned hex string, as follows:
0x0 “0x0”
0x1234 “0x1234”
0x1234 “0x1234”
0x12abc “0x12abc”
0x52656D6F “0x52656D6F”
0xD68CC2E0B300C0C1003A “0xD68CC2E0B300C0C1003A
AC01B514AC00 AC01B514AC00”
7 Bit Text
The value of the field will be presented as a series of 7 bit ASCII characters, as follows:
0x31D98C06 “1234”
0x52656D6F00 “RJ5äù”
0xF3B2BDECA6E71B “seventy”
see Appendix B for conversion rules
Note that the above examples assume that the Message Data fits exactly into the field (or in
the case of 7 bit data is padded to the octet boundary by zeros).
The Character Alignment parameter, with larger fields, will have the effect of padding the
indicated end of the data with zeros (or in the case of 7 bit data, a <CR> and then zeros).


2.17 Definition Tables and Links
PROTOCOL
Name STRING LIST
Form List ID
MESSAGE CHECK
LIST FORM
Name
Message ID MESSAGE
FORM_FIELD Action ID
Attribute
ID
Field ID FIELD
Action ID
XN, YN, WN, HN
XL, YL, WL, HL VR LIST
Navigation Order
Local Validation Rules ID
ACTION
Local Validation Help Message ID
EVENT CHECK ID
Event Function ID
Trigger Control Parameter List ID LIST
Action ID Name
MESSAGE CHECK
STRING LIST

MESSAGE CHECK MESSAGE

Message ID
Form ID FORM
Action ID
Check Value ID ACTION
CHECK VALUE
ID
Field ID FIELD
Value
STRING LIST
Type
FORM FIELD VR LIST FIELD
Value
Entry ID (ID) MESSAGE DEFN
Rule ID (Rule) FORM
Rule Parameters ID
PROTOCOL
ACTION
PROTOCOL FORM FIELD
ACTION LIST
ID ADDRESS
Entry Type
FIELD
Entry
FORM
Or MESSAGE

MESSAGE CHECK LIST

FORM
LIST ADDRESS
Value
FORM FIELD
MESSAGE Attribute
CHECK VALUE
PID
Character Set LIST
Address ID
Message Defn ID MESSAGE DEFN
ID
Field ID FIELD
Type Normal Default String ID STRING LIST
Character Alignment Large Default String ID
Character Size Max Length
Length Attributes
Length Multiplier
Depends Upon
Depend Value STRING LIST
Delimiter Value

MOD-14-1723 Short Data Applications - Licensing
3 LICENSING
The following functionality is only available when the radio is licensed by a Sepura Premium
Application Pack license:
Set Property action, see 2.2.13
Reset Property action, see 2.2.8
Soft Key Function action, see 2.2.13
Format String action, see 2.2.4
Event Triggers using the Event Check table, see 2.5
Completion Mandatory, see 2.8
Local validation, see 2.8 & 2.15
If a radio is not licensed and the customised SDA contains any of the above licensable
functionality the radio behaves as follows (as if no SDA is customised):
Incoming SDS messages are not matched and no forms, actions, etc. are triggered;
Event Triggers are ignored;
The SDA Template Card is blank;

MOD-14-1723 Short Data Applications - Worked Example
4 WORKED EXAMPLE
4.1 Introduction:
In order to define a Short Data Application, the tables described in Chapter 2 need to be filled
in. Not all tables will be required in all designs, for example there may be no incoming checks
required.
The essential requirements are an understanding of the SDS Message structure and likely
contents coupled with an understanding of the operational requirements.
We will now work through an example in stages:
Introducing the scenario, followed by;
Stage 1: the definition of the outgoing SDS Messages;
Stage 2: selecting a form and the definition of the form contents;
Stage 3: the definition of the incoming SDS Messages;
Stage 4: the definition of the matching process to associate an incoming SDS Message to
a form;
Stage 5: the definition of that forms layout and content.
Note that this example does not use any local validation.

4.2 Example scenario and detail information
A system is in use in an airport. The SDS protocol allows the users to enter a flight number
which is sent to a fixed address. The status of that flight is then returned to the user from that
address. Further updates may be sent as the status changes.
All text is in 8 bit ASCII encoding.
All messages use PID 232.
The address is 123789
The following SDS Message can be sent from the terminal:

Message 1
Name: Flight Request
Structure: #REQ#<user name>#<password>#<flight number>#
Notes: The three fields are alphanumeric.
The # characters act as separators.
The <password> field should not be visible to casual viewers.
The following messages can be received by the terminal:

Message 2
Name: Error
Structure: #ERROR#<error code>#<error text>#
Notes: The possible <error codes>, a binary byte, are:
1 = 'Unknown Username/password'
2 = 'Unknown flight number'
The <error text> field is alphanumeric printable ASCII free form text.
Message 3
Name: Response
Structure: #RESP#<flight number>#<status code>#<details>#
Notes: The possible <status code> values, a binary byte, are:
1 = 'On Time'
2 = 'Delayed'
3 = 'Boarding'
4 = 'Cancelled'
5 = 'Landed'
When the flight is 'Boarding' the message must be given special attributes to
highlight the urgency of this status.
The <flight number> and <details> fields are alphanumeric printable ASCII
free form text.

4.3 Stage 1: Model the outgoing message structure
Using MESSAGE, MESSAGE DEFN, FIELD, ADDRESS and STRING LIST tables
The outgoing message is made up of:

Some fixed text
Followed by three user entered fields, separated by '#'
The MESSAGE table could therefore be:
PID Character Set Address ID Message Defn ID
MESSAGE 1 232 Not Used 1 1
The Character Set is set to 'Not used' as this PID definition does not need it.
The IDs refer to the first entry in the ADDRESS table and the ID=1 entries in the MESSAGE
DEFN table.
An ADDRESS table can be constructed:

Value Attribute
Dial String Dial Mode
ADDRESS 1 00123789 Mode #1 Fixed Individual Address
The Dial String and Mode combination is set to a predefined address and the Attribute 'Fixed
Individual Address' ensures it is not visible to the sender.
The following values are likely to be required and are declared in the STRING LIST table:
Type Value
1 8 Bit Text #REQ#
STRING LIST
2 8 Bit Text #
Where the Type is 8 bit ASCII strings (for both) and the second STRING LIST item will be
used as the delimiter '#'.
The MESSAGE DEFN table could be as follows, defining the four message parts:
Field
Character
ID
ID Type
Alignment
1 1 1 Type 1: Fixed Length Left Byte Aligned

MESSAGE
DEFN
2 1 2 Delimited Left Byte Aligned

. . . more columns:

Multiplier
Character
Delimiter
Depends
Length
Length
Depend
Value
Value
Size
Upon
ID
1 1 ISO 8859-1 5 Byte 0 0 0

MESSAGE
DEFN
2 1 ISO 8859-1 0 Bit 0 0 2

3 1 ISO 8859-1 0 Bit 0 0 2
4 1 ISO 8859-1 0 Bit 0 0 2
The Field IDs refer to the numbered entries in the FIELD table (by position).
The first row defines a fixed length, 5 byte, byte aligned, left justified message field (the
'#REQ#').
The other three rows define the three delimited, byte aligned, left justified message fields.
These four fields are defined in the FIELD table:

NM Default LM Default
Max Length Attributes
String String
1 1 1 1 Fixed Text
2 0 0 20 Data Input
FIELD
3 0 0 10 Data Input, Secure
4 0 0 20 Data Input
The first row defines the link to the '#REQ#' string. An arbitrary length is set as this field is not
a 'Data Entry' field.
The next three rows define that the fields are editable and can be up to the indicated lengths
(in practice the required lengths would be obtained from the system definition).
In addition, the third row (password) is a secure field, where typed in characters will be
displayed as asterisks.
When entering the data into Radio Manager, the FIELD table must be filled in first
before those Field IDs can be used in the MESSAGE DEFN table.
Variations (not used in this worked example):

If the 'Flight Number' were known to be always numeric, to minimise user entry errors the
fourth field could be set as 'Data Input, Numerical'.

4.4 Stage 2: Design outgoing forms and selection of them
Using FORM, FORM FIELD, FIELD, LIST, PROTOCOL and STRING LIST tables
The outgoing forms could look as follows:
Normal: Large (Multi-screen):

Request Flight Info
Request
Flight Num.: <flight number>
User Name: <user name> Flight Number:

Password: <password> <flight number>
User Name:
<user name>
Password:
<password>
And be selected from the SDA card with a Family name of 'Flights' ('FL' on the tab) and a
Form name of 'Request'
Note: Flight Number has been made the first field as it is likely that the User Name and
Password will be cached, see FORM table definition.
Design Notes:
The usable virtual screen width, taking into account the scroll bar, is:
121 pixels
In normal mode this is enough for typically 25 characters, and 15 in large mode.
The virtual screen height is:
64 pixels
The coordinates define the text position (top left hand corner), boxes, if required, are then
drawn around them.
A single height text box is:
13 pixels high in normal mode, and 18 in large mode
A double height text box is:
22 pixels high in normal mode, and 33 in large mode
Boxes around action fields (a navigable field with an associated action, a button for example)
and reverse video fields are drawn outside the text boxes making them larger.
It is recommended that x and y coordinates are no less than 5 and that the most right
definition (x plus width) is 121 or less. For boxes with actions (buttons) these should be 6 and
120 respectively.
A field is only displayed if the whole of that field (or the entire first line for a multi-line field) can
be displayed.

Single line scrolling fields, fields defined in FORM_FIELD to be navigable, should be a

minimum width of:
26 pixels in normal mode and 35 pixels in large mode
This will ensure that the field can be scrolled and viewed correctly. A smaller width could
be used if the number of characters to be displayed can be restricted.
The form is cancelled and the user returned to the top level screen after a period of inactivity
defined by 15x terminal parameter [Screen Timeout Period].

An alternative would be to put User Name and Password entry onto one form with Flight
Number on its own form. This would separate the functionality. It would be advisable to
display (the first few characters of) the password (as a non editable field) to indicate
when it has expired (by the displayed asterisks not being shown). 'Use cache' would
need to be enabled and the password cached when sent, together with an appropriate
Secure Timeout. The Username / Password form would include a 'Save' button with an
associated 'Save to Permanent Cache' action.
Using the definition above, the PROTOCOL (Family) table would be:
Name Form List ID
PROTOCOL 1 3 1
Indicating one Protocol family (Flights) which references the first parameter set in LIST.
It is now possible to extend the STRING LIST table with more strings:
Type Value
3 8 Bit Text Flights
4 8 Bit Text Request
5 8 Bit Text Request Flight Info
6 8 Bit Text Flight Num:
STRING LIST
7 8 Bit Text User Name:
9 8 Bit Text Flight Number:
10 8 Bit Text Request
Once the form can be seen on the real screen it may be necessary to alter some of these
strings, in particular to shorten some in order to have longer editable fields.

A LIST table is now defined that links the Protocol - Form List ID to the yet be defined FORM
table.
ID Entry Type Entry
LIST 1 1 Form ID 1
This definition links the incoming ID (from PROTOCOL) with a FORM entry (Entry Type of
'Form ID') indicating to use the first parameter set in the FORM table.
If we were to adopt the approach of separating the request and the login, then:
There would be no change to the PROTOCOL table;
We would need to modify the STRING LIST to reflect the definition change (add
'Login' for example)
And add an entry in the LIST table (shown below), linking ID 1, via Entry Type = 'Form
ID', to a new Entry, 4 for example, indicating a fourth FORM definition.
ID Entry Type Entry
LIST 2 1 Form ID 4
The order in a LIST table defines the order the Forms are displayed on screen when
selecting a form.
The FORM table can now be defined, as follows:

Message Action
Name Attributes
ID ID
Saving Disabled & Caching
FORM 1 4 1 0
Enabled
Defining a form that:
Gets its name from the fourth STRING LIST entry;
Nominates the first parameter set in the MESSAGE table to transmit this forms
information;
When the green telephone key is pressed (assuming the field with focus has no
associated actions) performs the default actions of Send SDS Message and Save To
Permanent Cache;
And enables 'Caching' (in order to display the cached information when a new form is
displayed), to reduce the amount of re-keying of information.
If we were to adopt the approach of separating the request and the login, then:
There would be two entries in the FORM table, one for Request (as above) and one
for Login (shown below);
The Login would:
o share the same Message ID;
o point to an ACTION table entry defining the action to be 'Save To Permanent
Cache', i.e. the data is not sent, only stored;
o and enable caching.
Message Action
Name Attributes
ID ID
Saving Disabled &
FORM 2 34 1 2
Caching Enabled

Each of the items on the form is defined in the FIELD table, the new ones being:
NM LM
Max
Length
String String
Fixed Text,
5 5 10 1
Underline
7 7 7 1 Fixed Text
8 8 8 1 Fixed Text
The editable fields already exist in the FIELD table, having been entered from the MESSAGE
DEFN stage above.
These four items are the fixed text titles and labels.
In some cases the normal and large mode strings are the same (same string reference
number) and in some cases different, reflecting the space restrictions.
The first definition above relates to the page title and has an underline attribute.
And the fields are referenced from the FORM FIELD table, together with layout information:
Action
Field
Order
Nav.
ID
ID
1 1 5 0 20 5 90 1 25 5 80 1 0
2 1 6 0 5 20 42 1 5 25 116 1 0
3 1 4 0 50 20 70 1 5 45 116 1 1
FORM FIELD 4 1 7 0 5 35 42 1 5 70 116 1 0
5 1 2 0 50 35 70 1 5 90 116 1 2
6 1 8 0 5 50 42 1 5 115 116 1 0
7 1 3 0 50 50 70 1 5 135 116 1 3
This table defines, in this order, the title, flight name label, flight name data, user name label,
user name data, password label and password data.
The common ID indicates they are all part of the same Form, i.e. the first form.
The related fields are referenced by ID (to the position in the FIELD table).
None of the fields require specific actions.
The positioning data, at this stage, is a best guess based on the guidelines above (design
notes) and will be fine tuned when the form is tested.
The Navigation Order indicates that some fields (being used as titles / labels for example) are
not navigable (set to '0') and also indicates the order in which Up and Down will select the
others. The lowest non zero numbered field will be the first field to have focus when the form
is first displayed.
Three extra columns, not shown, define the following:
Local Validation Rules ID
Local Validation Help Message ID
Local validation is not part of this example so all entries in these columns are zero.
When entering fields into FORM FIELD it is advisable to put the field being used as a
label field in the preceding 'slot' of the associated edit / display field, in order to assist
the display scrolling process in keeping them together.
before those Field IDs can be used in the FORM FIELD table.

4.5 Stage 3: Model incoming message structures, for checking and for
displaying
Using MESSAGE, MESSAGE DEFN, FIELD and STRING LIST tables
The process here is similar to Stage 1.

As a reminder the incoming messages are restated as (see also 4.2 );
Error Messages: #ERROR#<error code>#<error text>#
Information Messages: #RESP#<flight number>#<status code>#<details>#
The Error Message is made up of:
Fixed text;
and two delimited fields.
The Information Message is made up of:
Fixed text;
and three delimited fields.
The check mechanisms will use these fields, in conjunction with the PID and Source ISSI, to
identify these messages (see Stage 4).
The expression of these messages as forms will also use these fields, together with fixed
strings (see Stage 5).
The additions to the MESSAGE table would be:

PID Character Set Address ID Message Defn ID
2 232 Not Used 1 2
MESSAGE
3 232 Not Used 1 3
The PID, Character Set and Address ID are not required (but must be set to something) for
incoming messages (as they are part of the incoming message mechanisms).
The Message Defn ID refers to the ID=2 entries in the MESSAGE DEFN table (for the Error
message) and the ID=3 entries in the MESSAGE DEFN table (for the Response message).
The following values are likely to be required and are declared in the STRING LIST table:
Type Value
11 8 Bit Text #ERROR#
STRING LIST
12 8 Bit text #RESP#
Where the Type is 8 bit ASCII strings and the strings will be used as part of the check
process.

The MESSAGE DEFN table is extended to include the two new message definitions:
Field
Character
ID
ID Type
Alignment

MESSAGE

DEFN

. . . more columns:
Multiplier
Character
Delimiter
Depends
Length
Length
Depend
Value
Value
Size
Upon
ID
5 2 ISO 8859-1 7 Byte 0 0 0

6 2 Numeric 0 Bit 0 0 2
MESSAGE
7 2 ISO 8859-1 0 Bit 0 0 2

DEFN
8 3 ISO 8859-1 6 Byte 0 0 0

9 3 ISO 8859-1 0 Bit 0 0 2
10 3 Numeric 0 Bit 0 0 2
11 3 ISO 8859-1 0 Bit 0 0 2
The Field IDs refer to the new entries in the FIELD table defining the actual field parameters:
where Field ID 9 is the #ERROR#, 10 is <error code>#, 11 is <error text>#, 12 is
#RESP#, 13 is <flight number>, 14 is <status code> and 15 is <details>.
A new Field ID has been allocated to the incoming <flight number> to ensure it does not
share data with the outgoing <flight number>. In some situations it may be advantageous for
incoming and outgoing data to share a Field ID.
Other parameters are set similar to the preceding MESSAGE DEFN table except that the two
numbers (<error code> and <status code>) are defined as 'Numeric'.
The new fields are defined in the FIELD table:

NM Default LM Default
Max Length Attributes
String String
9 11 11 1 Fixed Text
10 0 0 1 Fixed Text
11 0 0 1 Fixed Text
13 0 0 1 Fixed Text
14 0 0 1 Fixed Text
15 0 0 1 Fixed Text
FIELD 9 and 12 define links to the #ERROR# and #RESP# strings.

No specific attributes are set at this stage. If required, they will be set in this table at the form
design stage (see Stage 5).
As all fields are not 'Data Input' fields, their lengths have been set to an arbitrary non zero
value. Enough space will be allocated, on demand, as the fields are filled from the message.
before those Field IDs can be used in the MESSAGE DEFN table.

4.6 Stage 4: Model the matching process
Using MESSAGE CHECK, CHECK VALUE, STRING LIST, ACTION and LIST
tables
It is now necessary to consider the check processes required for the two incoming messages.
Taking into account the requirement to display the incoming message information, the
following check procedure will be adopted:
For the Error message:
A match is declared:
If the PID is correct;
and if the Source-ISSI is correct;
and if the first field is '#ERROR#';
and if the third field exists;
and if the second field is:
o a '1' (in which case associate the message to a form that displays the text
equivalent of the error code);
o or a '2' (in which case associate the message to a form that displays the text
equivalent of the error code).
This is defined as two checks.
For the Response message:

A match is declared:
If the PID is correct;
and if the Source-ISSI is correct;
and if the first field is '#RESP#';
and if the fourth field exists;
and if the third field is:
o a '1', '2', '4' or '5' (in which case associate the message to a form that displays the
text equivalent of the status code);
o or a '3' (in which case associate the message to a form that displays the text
equivalent of the status code and display it immediately with an Alert).
This is defined as five checks.
The MESSAGE CHECK table therefore contains the following seven check start points:
Message ID Form ID Check Value ID Action ID
1 2 2 1 0
2 2 3 2 0
3 3 4 3 0
MESSAGE CHECK 4 3 5 4 0
5 3 6 5 1
6 3 7 6 0
7 3 8 7 0
The second row defines that the incoming message will be deconstructed using the second
MESSAGE table entry and the check sequence defined in the parameter sets of the CHECK
VALUE table where the ID equals 2. A successful match would associate this message with
the third form definition and no actions.
Other rows define similar checks with row 5 initiating an action definition if a match is found.

The consequent CHECK VALUE table is:

ID Field ID Value
1 1 PID 13
2 1 Source ISSI 14
3 1 9 11
4 1 11 15
5 1 10 16
6 2 PID 13
7 2 Source ISSI 14
8 2 9 11
9 2 11 15
10 2 10 17
11 3 PID 13
12 3 Source ISSI 14
CHECK VALUE 13 3 12 12
14 3 15 15
15 3 14 16
. . 4 . . . . .
. . 5 . . . . .
. . 6 . . . . .
31 7 PID 13
32 7 Source ISSI 14
33 7 12 12
34 7 15 15
35 7 14 20
Taking the first block, where the ID is 1, this defines five tests to be performed on the
incoming message:
A check that the PID equals the thirteenth STRING LIST value;
A check that the Source-ISSI equals the fourteenth STRING LIST value;
A check that field 9 (the first field in the message definition) equals the eleventh STRING
LIST value, i.e. the #ERROR# string;
A check that field 11 (the third field in the message definition - the <error text>) is present
and contains ANY value (including being empty, just the delimiter);
A check that field 10 (the second field in the message definition - the <error code>)
equals the sixteenth STRING LIST value, i.e. '1'.
Similar definition sets then exist for the second Error message and the five Response
messages (sets 4, 5 and 6 not shown).
The order of the checks should be defined to ensure that the check fails as early as possible.
In the above example we therefore filter down to a specific PID and Source-ISSI first, then
inspect the message contents.
before those Field IDs can be used in the CHECK VALUE table.

Additional entries in STRING LIST are required to support the above, as follows:
Type Value
13 Numeric 232
14 Numeric 1
15 8 Bit Text ANY
16 Numeric 1
STRING LIST
17 Numeric 2
18 Numeric 3
19 Numeric 4
20 Numeric 5
These values represent the PID, the Source-ISSI address (reference to the ADDRESS table),
the ANY value (for the field presence check) and the values against which the <error code>
and <status code> are checked.
An ACTION table is required:

1 1 Display Immediate 0 0
ACTION
This action initiates the functions:
Display Immediate (no parameters required)
and sound an Alert. The Alert function only requires one parameter and this is obtained
from the LIST table, in this case Alert 3 (a beep).
The extension to the LIST table is:

ID Entry Type Entry
LIST 2 2 Unsigned Integer 3

For the incoming Error message, an alternative to the above approach could be to only
have one check:
for the PID;
for the Source-ISSI;
for the #ERROR# string;
and for the third field being present.
as above
and for the <error code> being 1 or 2.
The form would then display the actual error code, possibly annotated that 1 = Unknown
Username/Password and that 2 = Unknown Flight Number.
This approach would need:
one MESSAGE CHECK entry (instead of two);
fewer (and less repetitive) CHECK VALUE entries;
a STRING LIST entry of '1, 2' to check for 1 or 2, potentially removing some of the
single value entries.
A similar approach could be adopted for the incoming Response messages (where the
<status code> is 1, 2, 4 or 5) with an even greater saving but at the expense of
readability. The required STRING LIST comparison value would be '1, 2, 4, 5'.
It may also be desirable for an incoming Error message to beep. This would be achieved
by an entry in the Action ID column of the MESSAGE CHECK table, either leading to the
existing Alert function or a new one.

4.7 Stage 5: Design the incoming message display forms
Using FORM, FORM FIELD, FIELD and STRING LIST tables
The Error message incoming forms could look as follows (when shown full screen):

Flight Request Info
Flight Info
ERROR
Unknown Username / Pwd ERROR
<error text> Username/Pwd
<error text>
Where 'Unknown Username / Pwd' could be 'Unknown Flight Number' depending on the
<error code>.
The Response message incoming forms could look as follows (when shown full screen):

Flight Request Info
Flight Info
Flight Num: <flight number>
On Time <flight number>

<details> On Time
<details>

Where 'On Time' could be other texts depending on the <status code>, and would be
displayed in reverse video if Status Code = 'Boarding'.
See Stage 2 - Design Notes for specific layout information.
Care needs to be taken to ensure that the design is satisfactory when shown in the
tabbed Inbox, in particular in Large Mode when only the first two lines can be seen.
From the above the STRING LIST table can be extended with the following:
Type Value
21 8 Bit Text Flight Request Info
22 8 Bit Text Flight Info
23 8 Bit Text ERROR
24 8 Bit Text Unknown Username / Pwd
25 8 Bit Text Username / Pwd
26 8 Bit Text Unknown Flight Number
STRING LIST
27 8 Bit Text Flight Number
28 8 Bit Text On Time
29 8 Bit Text Delayed
30 8 Bit Text Boarding
31 8 Bit Text Cancelled
32 8 Bit Text Landed
If space were limited in the terminal or definition, it might be beneficial to rationalise

some similar strings and to define smaller unique strings once and combine them on
the screen ('Unknown' and 'Flight Number' for example).
A FORM table is required to define the seven forms outlined above, and referenced (by
position) from MESSAGE CHECK as forms 2 to 8:
Name Message ID Action ID Attributes
2 0 2 0 Saving & Caching Disabled
FORM 5 0 3 0 Saving & Caching Disabled
Each form is linked to the appropriate MESSAGE table parameter set (by the Message ID) in
order to obtain the message definition, has no actions and is not saved when the terminal is
powered off.
In this example the message definition is the same as the message check message definition.
It may be required to check against one message definition but display that message using
another definition. The table above would allow that situation to be defined.

New displayable items need to be defined in the FIELD table, essentially in this example the
fixed texts:
NM LM
Max
Length
String String
Fixed Text,
16 21 22 1
Underline
Fixed Text, Reverse
17 23 23 1
Video
FIELD
Fixed Text, Reverse
21 30 30 1
Video
Where the referenced strings are in the STRING LIST table and are displayed with the
indicated attributes.
Finally the FORM FIELD table, referencing the fields for each form, defining the layout:
Action
Field
Order
Nav.
ID
ID
8 2 16 0 20 5 90 1 25 5 80 1 0
9 2 17 0 40 20 40 1 30 25 60 1 0
10 2 18 0 5 35 116 1 5 45 116 1 0
11 2 11 0 5 50 116 3 5 65 116 3 1
12 3 16 0 20 5 90 1 25 5 80 1 0
13 3 17 0 40 20 40 1 30 25 60 1 0
14 3 24 0 5 35 116 1 5 45 116 1 0
15 3 11 0 5 50 116 3 5 65 116 3 1
16 4 16 0 20 5 90 1 25 5 80 1 0
17 4 6 0 5 20 42 1 10 70 10 1 0
18 4 13 0 50 20 65 1 5 20 116 1 1
FORM FIELD 19 4 19 0 50 35 65 1 5 40 116 1 0
20 4 15 0 5 50 116 3 5 65 116 3 2
5
6
7
36 8 16 0 20 5 90 1 25 5 80 1 0
37 8 6 0 5 20 42 1 10 70 10 1 0
38 8 13 0 50 20 65 1 5 20 116 1 1
39 8 23 0 50 35 65 1 5 40 116 1 0
40 8 15 0 5 50 116 3 5 65 116 3 2
This table defines the contents of the seven forms.
For the first two groups (IDs 2 and 3), the Error message forms, the contents of each group
are (in this order): the title, the ERROR text, the <error code> equivalent text and the <error
text>.

For the next five groups (IDs 3 to 8, sets 5, 6 and 7 not shown), the Response message
forms, the contents of each group are (in this order): the title, the Flight Number label (normal
mode only), the <flight number>, the <status code> equivalent text and the <details>.
The definition of the sets where the ID is 5, 6 or 7 is identical to the ID sets above and below,
except that the <status code> equivalent text is defined by Field IDs 20, 21 and 22
respectively.
Note that the Flight Number label (see row 17 for example) has been hidden in large mode by
placing it under the <details> definition (see row 20).
As before, no actions are required and the positioning data is provisional until the forms can
be tested.
If actions were required, they would be defined in the ACTIONS and LIST tables.
As before local validation is not required and the contents of those columns (not shown) are
zero.
before those Field IDs can be used in the FORM FIELD table.

Variation
If the approach described in Stage 4 - Variants were adopted, then only three forms would
be needed here, one for the incoming Error message, one for the incoming Response
message when the <status code> is 'Boarding' and one for other incoming Response
messages.
Other action functions could also be used to, for example:
Display the flight number on the top line of the display under certain
circumstances;
Delete the messages after they have been read / displayed;
Create further forms or response forms that could be navigated to.

4.8 Conclusion
To extend the above example, for example to add further protocols / families, follow the
procedure outlined above for each addition. Each addition can then be tested in isolation
making the process of identifying problems easier. With experience it may be time saving to
attempt the definition in one pass.
ID driven tables do not have to start at one and any byte values may be used, in any
order.
The following real screens were generated:

Selection of the Form: The Request Form:
In Normal mode In Normal mode
In Large mode In Large mode

An Error Response: An Information Response:

In Normal mode In Normal mode
In Large mode In Large mode

MOD-14-1723 Short Data Applications - Terminal Considerations
5 TERMINAL CONSIDERATIONS
For terminal operation refer to the Terminal User Guide.
The following terminal operation design issues should be noted:
The UI design layout uses a virtual screen of 128 wide by 64 high. This screen is
mapped to the product physical screen when in use.
Large mode and normal mode displays will need independent form designs (strings,
sizes, positioning, etc.) but will share a common navigation order.
When in Large mode it may be necessary to bring important information to the top
line as only that line can usually be seen when navigating the Inbox. A second line
can be seen if placed close below the first.

MOD-14-1723 Short Data Applications - Glossary
6 GLOSSARY
Term Description
ETSI European Telecommunications Standards Institute
OPTA Operational Tactical Address
PID Protocol Identifier
SDA Short Data Applications
SDS Short Data Services
SwMI Switching and Management Infrastructure
TETRA Terrestrial Trunked Radio

MOD-14-1723 Short Data Applications - 7 Bit Text Conversion Rules
7 APPENDIX A - 7 BIT TEXT CONVERSION RULES

The following rules apply when 7 bit text characters are packed into transmitted / received
messages. The full rules are specified in ETS 300 392-2, section 29.5.4.2.
Basic packing of two 7 bit characters:

Bits number
7 6 5 4 3 2 1 0
Octet 1 2g 1a 1b 1c 1d 1e 1f 1g
Octet 2 0 0 2a 2b 2c 2d 2e 2f
Where:
1g is the least significant bit of the first 7 bit character;
1a is the most significant bit of the first 7 bit character;
2g is the least significant bit of the second 7 bit character;
2a is the most significant bit of the second 7 bit character;
'0' is padding of unused bit positions.
Example: 7 bit packing of the string'1234':

The characters are (in hex and 8 bit binary equivalents):
'1' = 0x31 = 0011 0001
'2' = 0x32 = 0011 0010
'3' = 0x33 = 0011 0011
'4' = 0x34 = 0011 0100
The most significant bit is discarded before the following.
These are then packed into octets as follows:

Bits number
7 6 5 4 3 2 1 0
Octet 1 0 0 1 1 0 0 0 1
Octet 2 1 1 0 1 1 0 0 1
Octet 3 1 0 0 0 1 1 0 0
Octet 4 0 0 0 0 0 1 1 0
Producing the final hex message data: 0x31D98C06
Note that when packing, if the last byte is to be padded with seven '0's then it is padded with a
<CR> (00011012) instead.


MOD-14-1723 Short Data Applications Design Guide - Issue 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MOD-14-1723 Short Data Applications Design Guide - Issue 1

Uploaded by

Copyright:

Available Formats

Sepura TETRA Terminal

Short Data Applications Design Guide

© SEPURA PLC 2014

Issued by Sepura Marketing Commercial-in-Confidence

Issue 1 18 July 2014 Initial Version

{1} ETSI specification ETS 300 392-2 Edn 2 (v2.3.2) - http://www.etsi.org/

{2} Data Interface User Guide

{3} Terminal User Guide

{4} Radio Manager - Templates

{5} Radio Manager - Import and Export

{6} Radio Manager - Programming Radios

Issued by Sepura Marketing Commercial-in-Confidence

Note icon, emphasizes related, reinforcing, or important information.

Tip icon, suggests alternative methods for accomplishing tasks or procedures.

The use of square brackets will denote a customisable parameter. Where

Issued by Sepura Marketing Commercial-in-Confidence

1.2 Basic Transmit Scenario................................................................................................ 9

1.3 Basic Receive Scenario ................................................................................................. 9

2 THE DEFINITION TABLES ..................................................................... 11

2.2 The ACTION table ......................................................................................................... 13

2.3 The ADDRESS table ..................................................................................................... 25

2.4 The CHECK VALUE table ............................................................................................. 26

2.5 The EVENT CHECK table ............................................................................................. 28

2.6 The FIELD table ............................................................................................................ 30

2.7 The FORM table ............................................................................................................ 33

2.8 The FORM FIELD table ................................................................................................. 35

2.9 The LIST table ............................................................................................................... 39

2.10 The MESSAGE table ................................................................................................... 41

2.11 The MESSAGE CHECK table ..................................................................................... 43

2.12 The MESSAGE DEFN table ........................................................................................ 45

2.13 The PROTOCOL (Family) Table ................................................................................ 51

2.14 The STRING LIST table .............................................................................................. 52

2.15 The VR LIST Table ...................................................................................................... 54

Issued by Sepura Marketing Commercial-in-Confidence

2.16.3 Decoding Message Fields To Be Displayed On The UI .............................................................................. 59

2.17 Definition Tables and Links ....................................................................................... 62

4 WORKED EXAMPLE .............................................................................. 66

4.2 Example scenario and detail information .................................................................. 67

4.3 Stage 1: Model the outgoing message structure ...................................................... 68

4.4 Stage 2: Design outgoing forms and selection of them ........................................... 70

4.6 Stage 4: Model the matching process ........................................................................ 77

4.7 Stage 5: Design the incoming message display forms ............................................ 80

4.8 Conclusion .................................................................................................................... 85

5 TERMINAL CONSIDERATIONS ............................................................. 87

7 APPENDIX A - 7 BIT TEXT CONVERSION RULES ............................... 89

Issued by Sepura Marketing Commercial-in-Confidence

Issued by Sepura Marketing Commercial-in-Confidence

1.1 What are Short Data Applications?

Selecting a Family and Form The selected Form display

They are controlled by:

There are fourteen Tables making up the Definition, dealing with:

Issued by Sepura Marketing Commercial-in-Confidence

Forms and their contents;

1.2 Basic Transmit Scenario

See the Terminal User Guide for guidance on terminal operation.

1.3 Basic Receive Scenario

Issued by Sepura Marketing Commercial-in-Confidence

The sequence of operations and Definition requirements are as follows:

The basic process is therefore:

Issued by Sepura Marketing Commercial-in-Confidence

2 THE DEFINITION TABLES

Tables and table links

Issued by Sepura Marketing Commercial-in-Confidence

The Definition Tables are: