Syrus Programming Guide

Intended for Syrus 1-3rd Generation

Introduction

Syrus Specifications

Care and Caution

Operating Temperature
How to remove SIM Card
How to remove the internal battery
Set up the correct PIN for the SIM card
Do Not Leave Power Wires Unprotected

Getting Started
Support Site Getting Started Section
Setting the unit's ID
Setting the APN and PIN
Creating a Destination Point (DP)
Creating a Destination Address (DA)
Creating a time-period criterion
Tying a signal to an event
Examples:
Periodic report:
Adding an Input report
Panic button:
Several actions per event:
Checking the host software/server
Script

Event Machine
Actions
Events
Signals
Examples

Detailed Command Explanation

Unit's ID
Syrus Commands: ID, XAID
IMEI as ID
Syrus Commands: ID, XAID
Enabling the unit on GSM and GPRS
Syrus Commands: RF, XANS
SIM Card's PIN for GSM registration
Access Point Name (APN) for GPRS set up
Destinations (DPs and DAs)
 Syrus Commands: XADP, DA
Destination Points (DPs)
Destination Addresses (DAs)

Syrus commands
DA - Destination Address
Qualifiers: Q, S, R.
Examples:
ED - Event Definition
Qualifiers: Q, S, R.
EV - Event Message
Qualifiers: R.
Example:
Extended EV Tags formats:
Example:
GC - Counters, Timers, Distancers
Qualifiers: Q, S, R.
Examples:
Continuous counter:
Periodic counter:
GS - Speed Limit
Qualifiers: Q, S, R.
Examples:
ID - Identification
Qualifiers: Q, S, R.
PV - Position-velocity
Qualifiers: Q, R.
RF - Radio Frequency Module Configuration
Qualifiers: Q, S, R.
RT - Reset message
Qualifiers: S, R.
SI - SIM Card ID
Qualifiers: Q, R.
SS - Signal Status
Qualifiers: Q, S, R.
ST - Status
Qualifiers: Q, R.
TD - Time and Distance
Qualifiers: Q, S, R.
Examples:
VR - Version Number
Qualifiers: Q, R.
 XADP - Destination Points
Qualifiers: Q, S, R.
XAEF - Extended-EV message Formats
Qualifiers: Q, S, R.
XAID - IMEI as ID
Qualifiers: Q, S, R.
XAIM - IMEI Consult
Qualifiers: Q, R.
XANS - Network Status
Qualifiers: Q, R.

Error List

Signal List

Script example
Introduction
Syrus is a family of devices that can be programmed with the same programming language called TAIP.
TAIP is a very versatile language that can support many customization, to program the device you can use
the SyrusDesk software. To download this software simply login to our support website:
support.digitalcomtech.com, and click on the Downloads section, then download the software that comes
with the device.

This guide is meant to show you how to program the unit from scratch, as you start your journey into the
programming it’s important to test each command, you can do so with the SyrusDesk application.

Syrus Specifications
The specifications of the Syrus devices depend on which model you’re looking at, for more details please
refer to the Product section on our main webpage: www.digitalcomtech.com, and download the
datasheets for each specific device.

Care and Caution

Operating Temperature

Due to the limitations on the operation of the Lithium polymer battery, the temperature while charging
the battery must be 0ºC to 45ºC, and the regular operating temperature must be -20ºC to 70ºC. For more
information about the Lithium polymer batteries, visit:
http://en.wikipedia.org/wiki/Lithium-ion_polymer_battery
or http://www.batteryuniversity.com/parttwo-34.htm

How to remove SIM Card

Always send an >SRT< command before removing the SIM card, due to the risk of possible damage to the
SIM card. Follow these steps in order to prevent these issues:
● Send a Reset (>SRT< command) via Serial port or over the air.
● Remove SIM card after sending the >SRT< command. That means you have around 10 seconds to
remove the SIM card.

How to remove the internal battery

Always send a >SRT< command before removing the battery if the external power supply is not
connected, due to the risk of possible data loss or data corruption in the device memory. Follow these
steps in order to prevent these issues:
● Send a Reset (>SRT< command) via Serial port.
● Remove the battery after sending the >SRT< command. That means you have around 10 seconds to
remove the battery.
If the external power supply is connected, the battery can be replaced without sending the >SRT<
command.

Set up the correct PIN for the SIM card

The SIM card may be blocked if the PIN parameter is configured using the >SRFI< command with a wrong
SIM card PIN.

Do Not Leave Power Wires Unprotected

All the wire end tips must be kept insulated when not in use to prevent damage and undesired behavior
on the unit. This is especially important for wires that are marked with POWER. Refer to the Wiring
diagrams on our Downloads section of the support.digitalcomtech.com.
Getting Started

Support Site Getting Started Section

On the DCT support site (support.digitalcomtech.com) upon registering you have the option to visit the
getting started page. We recommend you go here first and refer to the following for examples on how to
further configure the device and get started programming. Also we recommend using Syrus Desk software
and test all these commands so you can see first-hand how the device responds.

Setting the unit's ID

The default Syrus behavior is to use the unit's IMEI as ID. It is recommended to use this setting as the
IMEI is unique for each unit. However it is possible to use a user defined ID in order for the unit to be
identified on the AVL server. The default value for the unit's ID is 0000. This field may be any string of 10
characters maximum.

For this example let’s call our unit EXAMPLE:

>SIDEXAMPLE<

To enable the unit to use the user defined ID, use:

>SXAID0<

To disable the use of user defined ID and instead use the IMEI of the device as the ID, use:
>SXAID1<

Setting the APN and PIN

After configuring an ID, the next step is enabling the unit on the GSM/GPRS network. For this an APN
provided by the cellular carrier is required and depending on the SIM card configuration a PIN value could
also be required. For this example we will use

APN internet.carrier-name.com and PIN 1234.

Setting the SIM card's PIN:

>SRFI1234<
If your SIM card does not require a PIN you can omit this step.

Setting the APN:

>SRFAinternet.carrier-name.com<
At this point the unit will try to register on GSM and on GPRS (you can see this status live on SyrusDesk).

Although PIN and APN parameters take effect immediately the unit may take up some time on registering
to the network if previous erroneous information was used. You can wait for the unit to register or you
can speed up the process by resetting the communications module with the>SXAGP1< command.

Creating a Destination Point (DP)

Now that we have the unit working on the GSM/GPRS network the unit is ready to send and receive
communications from IP servers and phone numbers. For our example we need to create a Destination
Point (DP) which holds our remote server IP number or address and the serving port that it is using for
listening to TCP connections or UDP datagrams.

Refer to the following document for building your own TCP/UDP listener

For this example we will use a server located on the address avl.server.com , which listens for TCP
connections on the port 2145. Since it is a TCP server we must choose an index from 00 to 03. In this
example the index 00 will be used for no particular reason:
>SXADP0000avl.server.com;2145<

An IP address could also be specified. Supposing we wanted to use the IP number 192.168.0.1 we would
have to send:
>SXADP0000192.168.0.1;2145<

Having set the DP, the unit will automatically start opening a TCP connection with the server (as long as
GPRS is ready) even if it has no messages to send to it. This is a programmed feature of the unit that
makes it reopen the TCP connection whenever the network is available after being down or whenever the
connection gets closed.

Use the XANS command to consult the state of the current DP:
>QXANS<

The unit might reply like this:

>RXANS1,internet.carrier-name.com,1234,,;1,1,null,1,22,1,1,18.18.9.8,1;socket://avl.server.com:2145,0,-
1,,-1,,,,0,0,0,,,,0,,,,25\;0,0,0,0,,,17;28,3,101,0,0,,5,42,socket://avl.server.com:2145;<

Indicating that the connection to the DP has not been established yet. If this state persists, some
considerations have to be taken:

The AVL software server is not running or it is running but it is not listening for TCP connections.
The listening port and/or address is wrong.
The server is behind a firewall/router/NAT that prevents the TCP listener from receiving the incoming
connections.
The server is accepting the connection but it is closing it immediately, or a few seconds later.
The Syrus is behind a cellular carrier's NAT which has the selected port blocked.
The selected APN has no Internet access. Or in case of a private network, the APN has no access to the
network where the AVL server is running.
There are network related problems that prevent the unit from communicating, even if it is GPRS
attached.

When the unit has connected to the server, the XANS reply could be something like:

>RXANS1,internet.carrier-name.com,1234,,;1,1,null,1,22,1,1,18.18.9.8,1;socket://avl.server.com:2145,3,-
1,,-1,,,,0,0,0,,,,0,,,,25\;0,0,0,0,,,17;28,3,101,0,0,,5,42,socket://avl.server.com:2145;<

Please refer to the XANS command for more information on the values returned by this message.

Creating a Destination Address (DA)

As mentioned on the Destinations (DPs and DAs) section a Destination Address (DA) must be created so
that an event's routing option can be completed. In our example we only have to create a DA with a single
Destination Point which is the one we just created. We have no restrictions for the DA range (0-9) so we
chose DA 4 for no special reason:
>SDA4;P00<
Indicating that Destination Address 4 is the grouping of the single Destination Point 00.

Creating a time-period criterion

For this example we want the unit to send a report based on a time-only criterion which will make the unit
send a reporting message every x elapsed minutes. There are several ways of doing this but one of the
most common is to configure a Time And Distance (TD) signal with no Maximum Time Between Reports
and no Distance Threshold parameters so it triggers a TD signal on a time-only basis set by the Minimum
Time Between Reports parameter. Please refer to the TD message for more information.

Let's use a reporting period of 5 minutes (300 seconds). For no special reason let's choose TD signal 8 to
do the job:
>STD80300<

This will make the unit activate signal TD8 every 5 minutes so we can create an event triggered by this
signal which is going to generate the periodic report. Note that in order to keep this example simple, we
are using a basic time only report, but this approach is not advised on a real world scenario where a
vehicle remains at rest most of the time and where having a time-only criterion will generate several
unnecessary reports. It is recommended to use the three parameters of the Time And Distance definition
to achieve a more intelligent report.
 Tying a signal to an event

With the signal TD8 generating a pulse every 5 minutes the only thing left to do is defining an event that
triggers with this condition. At this point we need to ask ourselves what event code to choose and what
kind of message send to the AVL server. The answer lies on the AVL server configuration: The event code
has to have any meaning for the AVL software and the type of message depends on the kind of
information we will like to get from the unit's report.
As event code we chose for no special reason, code 37:
>SED37NV4;TD8+<

Notice we are using DA 4. This will make the report generated by event 37 to be sent to the single DP 00
which is our AVL server. For more information refer to the ED message.

Examples:
Periodic report:

To define event 05 to send an EV Event Message every 3 minutes, use the TD message to configure a
Time & Distance signal to trigger every 3 minutes:
>STD70180<
Define the event with signal TD7 as trigger:
>SED05NV0;TD7+<
Note that DA0 (Destination Address 0 ) must be defined so that the Event Message can be routed to any
IP address(es) and/or SMS receiver(s). If the message were not to be routed, the Event Definition message
should be:
>SED05SV0;TD7+<
The only purpose of this event is to drive the E05 signal true or false according to the event's trigger
(TD7+) in order to trigger any other event(s) that include E05 as part of its trigger definition.

Adding an Input report

Now we will like to create an Input report to the AVL server using the event code 05 whenever the Input
3 goes high. This is a simple event that depends on a single signal transition, signal IP3:
>SED05NV4;IP3+<

Now our unit is generating a 5 minutes periodic report and also a special report whenever the Input 3
transitions to high (or true). An input transitions to high whenever it is connected to GND.

Panic button:

Send an Event Message when an input gets active:

>SED31NV0;IP3+<
This definition will make the unit send an EV Event Message with code 31 every time the input 3 becomes
true.
 Several actions per event:

Have the unit initiate a time counter, set an user signal true and reset a distance counter whenever the
vehicle's ignition goes high:
>SED35SV0;F00+;ACT=SGC05TC;ACT=SSSU041;ACT=SGC07U<

Checking the host software/server

At this point and as long as the unit remains GPRS attached, an EV message should be arriving to the AVL
server every 5 minutes. The software must be able to interpret the EV messages generated by the unit. If
you run into troubles checking your AVL
application you can always shut it down an use some popular free TCP listener applications that will show
you the RAW data received, and confirm that the reports from Syrus are being received properly by the
server. Another useful tool is a network sniffer that allows you to analyze the traffic on a given TCP/UDP
connection while the the AVL server is running.

Some examples of such tools can be found at:

TCP client and listener: TCP Test ToolTM from www.simplecomtools.com UDP client and listener: UDP
Test ToolTM from www.simplecomtools.com Network sniffer: WiresharkTM from
http://www.wireshark.org/
Script
The example so far can be summarized with the following script:
#Syrus SB script #Getting Started example

#Delete any previous configuration

>SRT;CONFIG<
>SXADP**U<

#Unit's ID
>SIDEXAMPLE<

#Use user set ID

>SXAID0<

#configuring the SIM's PIN

>SRFI1234<

#configuring the APN

>SRFAinternet.carrier-name.com<

#The remote AVL server address and port

>SXADP0000avl.server.com;2145<

#A Destination Address holding the server destination

>SDA4;P00<

#Time-only Time And Distance signal definition

>STD80300<

#Event triggered by T&D signal

>SED37NV4;TD8+<

#Input report event

>SED05NV4;IP3+<

#end

You can copy and paste this script to a new empty text file and have it save with a .tmf extension and load
it with Syrus Desk.
Event Machine
The unit's reporting is controlled by an Event Machine which constantly evaluates user defined events.
These events allow the user to create a reporting schema and functionality controlled by triggers and
actions. Events can be consulted or configured at any time with the ED message throughout the
Command Console, enabling the user to alter the Event Machine parameters at any time locally or over
the air.

Up to 100 events may be defined on the unit. These events are evaluated on a sequential order based on
the event's ID. This means that lower IDs are evaluated first. Having this in mind an event's ID may be
relevant if its trigger depends on other events' signals and/or on other events' user-defined actions.

This section examines the events components: triggers and actions. Then it gives an overview of the
events definition. Finally explains one of the most important components of the events triggers: Signals.
Triggers

A trigger is determined by the logical combination of several situations (also called signals). A logical
combination is basically an equation (specifically: a boolean equation) that combines signals (situations)
with the logical operators AND, OR and NOT. In Syrus, these boolean equations use the post fixed
notation, meaning that the operator is at the end of the signals to be evaluated. When more than three
signals are being evaluated, a logical operator must be inserted every two signals in the equation. These
are some examples of the post fixed notation syntax:

A or B → AB|
A and B → AB&
A and B and C → AB&C&

To determine how the signals will trigger the report a plus (+) or minus (-) sign is added at the end of the
equation. A plus sign (+) indicates that the report is generated when a signal or an equation becomes
"true". Consequently, a minus (-) sign indicates that the report is generated when the signal or the
equation becomes "false".

When A or B becomes true → AB|+

When A and B and C becomes false → AB&C&

If the report must be generated when one signal becomes true and another becomes false one of the
signals must be negated using the boolean operator not. Either the plus or minus sign can be used, but for
it is easier to understand the equation when the plus sign is used.

When A becomes "true" and B becomes "false" → A!B&+

Actions
Once you have defined a trigger (and/or a set of triggers) the next step for configuring the Syrus event
machine, is to tell the unit what to do when a trigger goes off. There are two types of actions the unit may
take when a trigger goes off. These are the report action and the user-defined action.

When the event machine detects that a trigger goes off it uses the configuration of the report action to
generate a report. A report action configuration includes routing options and a type of report.

The routing options tell the unit where to report the occurrence of the specific event. The report
destinations may be IP addresses (or host names), cellular phone numbers or the unit's serial port. It could
also be a silent report which is not reported to any destination. It is possible to send the same report to
several destinations at the same time by defining a group of destinations using the DA command.

The type of report used by the unit is called "EV Event report". The information contained in this type of
report is described in the EV command. The EV report can include extra information tags, called
"Extended EV Tags". These tags are included in the report by defining an event using the A, B or C
Message IDs. The information that each tag contains can be defined using the XAEF command.

A user-defined action is defined by a user-specified command (or set of commands) that are appended at
the end of a regular event definition using the "ACT=" or "XCT=" string. This enables the user to predefine
commands that the unit will only process whenever the trigger of a defined event goes off.

Events

Triggers and actions are bound together on a single configuration message called event. An event is
defined or consulted with the ED command. A single event holds a trigger, a report action and optionally a
user action. The following figure gives a global description of the ED command.

The Syrus has 100 events available for the user to configure. They may be defined all at once in a
configuration script or they may be individually defined at any moment as the user adds/removes
functionality. Please refer to the ED command for more information on each of the message's fields.

Signals

As described in the previous section, the event machine takes actions like reporting or switching outputs
whenever a user defined trigger goes off. This trigger is configured by the user with the logical
combination of situations.

Situations make reference to a vehicle state which is in fact represented by signals and their state. Syrus
signals are of boolean nature, meaning that they can only take one of two possible values: true or false.

Signals and the logical operators AND, OR, NOT are used to create logical equations to form event
triggers.
 By using the SS command a signal's state can be consulted, and depending on the signal's type, this
command can be used also to change the signal's state. Signals' names always have three characters.
Please refer to the Signal List section, for a list of valid signals and their meanings.

Examples

Some examples about the use of the event machine are presented next. Configuring two events on the
Event Machine to generate an ignition report: The ignition ON event may be defined as:
>SED18NV4;F00+<

And the Ignition OFF event:

>SED19NV4;F00-<

Both events' routing actions indicate that the destination of the report is the DA 4 and that EV is the
reporting message to generate. Both events use a simple trigger consisting of a one-signal-only condition,
F00 which is the vehicle's ignition signal.

Configuring an event that uses two signals:

For this example we will use signal S00, which is associated with a speed limit and signal J00, which is
associated with a heading delta. The event will be triggered when both signals are true, meaning that the
vehicle exceeded the speed limit while making a turn greater than the heading delta defined:

>SED05NV0;S00J00&+<

Detailed Command Explanation

Unit's ID
Syrus Commands: ID, XAID

This parameter is only meaningful to the AVL software which is going to receive report messages from the
unit. It is not necessary for the unit to work but it may necessary for making a test with an AVL software.
The unit's default behaviour is to use its IMEI number as ID, but it is possible to use a custom ID, which is
set using the ID command, and then enable using the custom ID with the XAID command.
The unit's ID is a 10 characters maximum string that may contain any character except: ';', '<' or '>'. The
initial value is 0000. The ID is used every time the unit sends a report message (EV) by adding the postfix
";ID=0000" to the message. This postfix gives the AVL software information on who is sending the report.
To set the unit's Id as UNIT-0015, use:

>SIDUNIT-0015<
 Warning: It is necessary to reset the unit using the >SRT< message after changing the ID in order for the
current established connections to update the new ID being used by the unit.

IMEI as ID
Syrus Commands: ID, XAID

Syrus is configured by default to use its International Mobile Equipment Identity (IMEI) as ID instead of a
user-set value. This is useful for managing units without having to worry about duplicated or changed IDs.
It also eases the programming task as this number is already stored on every unit. To instruct the unit to
use either its IMEI as ID or the ID set by the user with the ID command, use the XAID command in the
following way:

>SXAID1< , will set the unit to use its IMEI as ID (Default setting)

>SXAID0< , will set the unit to use the user set ID

Warning: It is necessary to reset the unit using the >SRT< message after changing the XAID setting in
order for the current established connections to update the new ID being used by the unit.

Enabling the unit on GSM and GPRS

Syrus Commands: RF, XANS
The GSM registration as well as the GPRS attachment (getting a valid IP address from the cellular
operator) is automatically done by the unit all the time. This means that whenever there is GSM and GPRS
network availability and the unit is correctly configured it is going to be GPRS attached (The green NET
LED will be blinking quickly twice). The SIM card's PIN and the cellular operator APN (Access Point Name)
are required by the unit to be GPRS attached.

SIM Card's PIN for GSM registration

This parameter is optional because it depends on how the SIM card is configured. Most cellular operators
distribute no-pin SIM cards so you don't have to worry about this parameter or you can explicitly set it to
"empty" if you are unsure of a previous configuration. But if your SIM card requires a PIN this parameters
has to be set or else the unit will fail to register on GSM. The configuration message for the SIM card's
PIN is the RF message. This message is used as follows:

To set the PIN number 1234 send to the unit:

>SRFI1234<

To set an "empty" PIN:

>SRFI<

Use the Q qualifier to consult the currently set value.

A PIN configuration can be issued at any time but even though the registration process is always done
automatically, the unit will take some time on registering to the GSM network when a previous erroneous
 PIN was given or when no PIN was given. So it is recommended in those cases to reset the unit after the
PIN-set command with the >SRT< reset message. Or better, have the PIN correctly configured before the
SIM card is inserted.

Warning: The Syrus may block the SIM card when a wrong PIN is configured.

The GSM registration status can be consulted with the XANS message and/or with the NET (green) LED.
When the unit is GSM-registered it is able to make or receive telephone calls and 2-way SMS
communication.

Warning: The PIN may be changed over the air which will cause the Syrus to loose communications with
the server.

Access Point Name (APN) for GPRS set up

A GPRS session enables the unit to communicate with IP networks (IP addresses). Although the most
common IP network is the Internet, by specifying an APN the cellular carrier can enable your unit(s) to
work on a user-private IP network that does not necessarily communicate with the Internet. When using
a private APN, devices like the Syrus, Cellular Phones, PDAs, PCs, Servers, etc can only be accessed by
devices on the same APN. There are several reasons why a cellular carrier may use different APNs, but the
important thing is that an APN is needed for the unit to start a GPRS session, for it to be able to send and
receive data over IP networks.

The most common situation is an APN with Internet access. Any device using this APN has the ability to
communicate with any IP network on the Internet. Specifically if you are running your AVL (Automated
Vehicle Location) server on the Internet, this is the kind of APN you want.

An APN has the form of a server name on a dot-separated format and it is supplied by the cellular carrier.

For example:
- this.is.an.apn.com
- internet.carrier-name.com

Setting the APN on the Syrus is also done with the RF message. An "empty" APN may be configured too.
An empty value is used when a GPRS session is not desired (GSM communications only, Voice and/or
SMS). This message is used as follows:

To set the APN to internet.carrier-name.com send to the unit:

>SRFAinternet.carrier-name.com<

To leave the APN parameter empty:

>SRFA<

The GPRS registration status can be consulted with the XANS message and/or with the NET (green) LED.
 An APN configuration can be issued at any time and the unit will start registering to the GPRS network as
soon as the GSM registration process is done and the APN parameter is set.

The Syrus will not start a GPRS session if it is not registered on the GSM network. And when the GSM
network is lost the GPRS session is lost too. However the unit may work on the GSM network regardless
of the GPRS session state.

The GPRS registration process is usually charged by the cellular carrier, having an incorrect APN will make
the unit constantly try on failing GPRS sessions which could lead to an excess on the unit's bytes
consumption.

Warning: The APN may be changed over the air which will cause the Syrus to lose communications with
the server.

Once the GPRS session is up the unit is ready to communicate with IP networks (i.e. with IP addresses).
For this, the cellular carrier assigns the unit an IP address that is usually but not necessarily dynamic,
meaning that for every session the unit starts its value changes. The actual IP address assigned by the
operator through the chosen APN can be consulted with the XANS command.

Destinations (DPs and DAs)

Syrus Commands: XADP, DA

A destination makes reference to the device or user that is receiving and/or sending messages from/to
the Syrus. The possible destination for the unit are:

● 6 IP hosts. 4 of these hosts are TCP only (00-03) and 2 hosts are UDP only (04- 05).
● 5 telephone numbers via SMS.
● The unit's serial port

Each destination is called a Destination Point (or simply a DP). Destination Points may be grouped to
form a Destination Address (or simply a DA). As you can deduce from the list, there are 11 DPs. The unit
offers 10 possible combinations of DPs, leading to 10 DAs. In the majority of cases DAs are used to tell
the unit where to send its report but in some cases a command may require a DP on its configuration.

Destination Points (DPs)

As mentioned there are 11 DPs, these are divided in the following way:

● The first 6 DPs (00 to 05) are IP hosts. These are defined with an IP address or a server name and a TCP
or UDP port number. The Syrusis a TCP and/or UDP client which always starts the communication. This
means that the IP host has to be a TCP or UDP server listening for incoming connections on the same
port specified here. Keep in mind that DPs 00 to 03 are TCP only and the DP 04 and 05 are UDP only.
● The next 5 (DPs 10 to 14) make reference to phone numbers. These numbers are used to send SMSs or
make voice calls. They are also used as authorization numbers for replying to receive SMSs commands
 and/or answering incoming voice calls. Defining if a report should be sent as a Syrus command or using
a custom user message is also done here.
● The last DP (15) makes reference to the serial port.

For more information please refer to the XADP command.

Destination Addresses (DAs)

A Destination Address is a user-defined group of Destination Points. This enables some reporting
commands to route their report to several destinations at the same time with a single definition. Up to 10
(0 to 9) DAs may be defined. Refer to the DA message for more information. This command enables the
user to group a list of DPs.

The main use for DAs is on the routing options of an event definition. The Event Machine section gives
more information about this. What should be clear on this, is that a report generated by an event is always
sent to a DA, not to a single DP. For this reason DAs make part of the minimum configuration required by
the unit. Some examples of DAs' definitions are:

Defining DA 5 as the group containing DPs 02, 04, 10 and 15:

>SDA5;P02,P04,P10,P15<

This will make any event using DA 5 as Destination Address on its routing options to send the same
report to the TCP IP host 02, UDP IP host 04, phone number 10 and the unit's serial port. Such an event
could be defined as:

>SED23NV5;TD1+<

To delete the DA 8 definition, use the following message:

>SDA8U<

For more information please refer to the DA command.

Syrus commands

DA - Destination Address
Qualifiers: Q, S, R.

A Destination Address is an association of Destination Points. These allows an event defined with the ED
message to be routed to multiple receivers at the same time by selecting the Destination Address (or
group) that holds all of the desired destinations (IP-types, Telephones, Serial Port). A Destination Address
is not the actual IP address or SMS telephone of the receivers. The message has the following format:
 A;PBB[,PBB,...,PBB:PBB,...]

● A is the Destination Address' index. Its range goes from 0 to 9. Remember that a Destination Address is
a group or an association of Destination Points. A Destination Point (see XADP message) is the actual IP
address or telephone of a destination.
● B holds a Destination Point's index. You can select multiple Destination Points by separating them with
a ','.

Examples:

To create Destination Address 5 as an association of Destination Points 2, 3, 10 and 15 (15 is the unit's
serial port):

>SDA5;P02,P03,P10,P15<

To create Destination Address 0 with only one Destination Point, for example the unit's serial port:

>SDA0;P15<

ED - Event Definition

Qualifiers: Q, S, R.

This message is used to define events. These events define the Event Machine configuration for the Syrus.
An event is created by defining a boolean combination of signals as a trigger, a routing indication for a
generated event message and a possible Configuration Command to be executed when the event occurs.
The message has the following format:

AABCD;EEE{[EEE][F]}G[[;ACT=HH...][;ACT=HH...]...]

● AA: Index. Specifies one of the event definitions associated with an event definition signal EAA. Ranging
from 00 to 99 (or '**').
● B: Event Handling. Message Routing. The valid values for this field are:
■ N: Normal. Route the Event Message to the specified Destination Address (DA).
■ X: Serial Port. Route the Event Message to the unit's serial port only.
■ S: Signal only. Do not generate an Event Message. The event's signal still follows the event's
state.
■ U: Undefine. Delete the event's definition.
● C: Message ID. Generate event message as:
■ V: EV message.
■ A: extended-EV message A.
■ B: extended-EV message B.
 ■ C: extended-EV message C.
● D: Destination address of the Event Message. The value of this field is the index of the desired
Destination Address (DA) defined with the DA message.
● EEE: Signal(s) used to trigger the event. Consult the Signals List for a list of valid signals.
● F: Logical operation used to combine signals:
■ &: AND
■ |: OR
■ !: NOT
● G: Event sense. Edge of signals' combination used to trigger the event:
■ +: Rising edge.
■ -: Falling edge.
● H: Event Action. A valid Configuration Command without the opening (>) and closing (<) delimiters.
Several Configuration Commandactions can be defined on a single event. There are two valid messages
to define the action. 'ACT=' which will make the event to be sent both through the serial port and over
the air and 'XCT=' that will only send the event through the serial port. The only command that is not
valid is the Reset Message (RT) command.

EV - Event Message
Qualifiers: R.

This message is generated when an event is triggered and reported. The message has the following
format:

AABBBBCDDDDDEEEFFFFFGGGGHHHHHIIIJJJKL[EXTENDED- EV TAGS]
● AA: Event index. Range 0-99.
● BBBB: Number of weeks since 00:00 AM January 6, 1980.
● C: Day of week. From 0 to 6 where 0 is Sunday.
● DDDDD: Time of the generated report. Seconds since 00:00 of the current date.
● EEEFFFFF: WGS-84 Latitude. It does include the sign: Positive for north. EEE represents a value in
degrees and FFFFF parts of a degree in decimals.
● GGGGHHHHH: WGS-84 Longitude. It does include the sign: Positive for east. GGGG represents a value
in degrees and HHHHHparts of a degree in decimals.
● III: Vehicle velocity in mph.
● JJJ: Vehicle heading, in degrees from North increasing eastwardly.
● K: Position fix mode:
■ 0: 2D GPS
■ 1: 3D GPS
■ 2: 2D DGPS
■ 3: 3D DGPS
■ 9: Unknown
● L: Age of data used for the report:
■ 0: Not available
■ 1: Older than 10 seconds
■ 2: Fresh, less than 10 seconds
 ■ 9: GPS Failure
● [EXTENDED-EV TAGS]: Extended information tags. See the XAEF message for information on how to
set the EV tags, and consult the list below for more information on the format used by each tag to
present the information.

Example:

An Event Message could be like this:

>REV481599462982+2578391-0802945201228512<

Which indicates that the report was generated by the

Event Definition 48, on September 2nd, 2010 (1599 4), at 17:29:42 GMT (62982), with the
coordinates +25.78391 latitude and -080.29452 longitude, with a speed
of 012 mph, and a heading of 285 degrees, with a 3D GPS fix mode and the age data was recent.

Extended EV Tags formats:

● ;AC=AAA...
■ AAA...: Instant acceleration measured in Miles per hour per seconds
● ;AL=AAA...
■ AAA...: Altitude is A meters Above Mean Sea Level (AMSL). This value will be -9999 when no
valid GPS data is available.
● ;BL=AAA...
■ AAA...: Voltage level of the battery in milivolts.
● ;CF=AAA...,BBB...,CCC...
■ AAA...: Local Area Code (LAC).
■ BBB...: Cell ID (CID)
■ CCC...: RSSI level.
● ;CVAA=BBB...
■ AA: Index of the counter.
■ BBB...: Value of the counter.
● ;DOP=AAA...,BBB...,CCC...
■ AAA...: PDOP value. Must be divided by 100 to obtain the real value*.
■ BBB...: HDOP value. Must be divided by 100 to obtain the real value*.
■ CCC...: VDOP value. Must be divided by 100 to obtain the real value*.
● ;IO=ABC
■ A:Bitwise representation of A:
■ bit0: Ignition (1=ACTIVE, 0=INACTIVE)
■ bit1: Main Power Source (1=EXT-PWR, 0=BACKUP-BATTERY)
■ B: Bitwise representation of B (outputs):
■ bit0: Output 1 (1=ACTIVE, 0=INACTIVE)
■ bit1: Output 2
■ C: Bitwise representation of C (inputs):
■ bit0: Input 1 (1=ACTIVE, 0=INACTIVE)
■ bit1: Input 2
 ■ bit2: Input 3
● ;IP=AAABBBCCCDDD
■ AAA: First number of the IP number.
■ BBB: Second number of the IP number.
■ CCC: Third number of the IP number.
■ DDD: Fourth number of the IP number.
● ;SV=A...
■ A... :Number of satellites on view.
● ;VO=AAA...
■ AAA...: Current value of the virtual odometer.

Example:

>REV401770475916+1672118-0930303000000032;VO=18787159;SV=9;ID=356612022871133<

Event 40 with a Virtual Odometer value of 18,787,159 meters and 9 satellites in view.

GC - Counters, Timers, Distancers

Qualifiers: Q, S, R.

This message is used to configure and manipulate internal counters. Each counter can be configured as a
user-controlled counter, a timer, or a distancer (counter updated by the traveled distance). Please refer to
the Quick Command Reference section for a few examples about counter use. The message has the
following format.

AAB[C[DDDDD[EEEEE]]]

AA: Index. Range 00-19. Specifies one of the counters associated with a counter signal CAA. The counter
signal becomes "True" when the specified threshold value is reached. If the Recycle Flag is set to R then
the signal transitions back to "False". If the Recycle Flag is set to C the signal will remain "True".
B: Counter command. The valid values for this field are:
C: Sets the counter type to Counter with a threshold value defined as DDDDD. The value for this type of
counter can only be changed with the increment (I) or value (V) command.
T: Set and start a Timer counter with a threshold value defined as DDDDD, time increment 1 or EEEEE
seconds.
D: Set and start a Distance counter with a threshold value defined as DDDDD, distance increment 1 or
EEEEE meters.
V: When using the S qualifier: Set the counter's value to DDDDD. Use the Q qualifier to get the actual
counter's value.
U: Undefine counter. The counter's definition is deleted and the associated counter signal CAA is reseted.
C: Recycle flag. Action performed when the counter threshold is reached: C: Continue counter.
R: Recycle counter (set to zero).
 DDDDD: Threshold counter increment when used with the I command or set with the V command.
EEEEE: Data increment value for Counter modes. For Timers, the counter value is incremented by 1 for
every Delta elapsed seconds. For Distancers, the counter value is incremented by 1 for every Delta
accumulated meters traveled.

Examples:
Continuous counter:
Set counter 03 on Timer mode. When the counter's value reaches 5 minutes the C03 signal should
transition to true. The counter shall not recycle its value when reaching the 5 minutes or else we will end
up with a periodic C03 signal:
To do this we define a timer with threshold value set to 300 seconds with no delta value:

>SGC03TC00300<

Notice the Recycle Flag set to C so the counter does not resets when reaching the threshold. Now 5
minutes after entering this command we will have the C03 signal transitioning from false to true.

Periodic counter:
Use a timer to generate a periodic counter signal having a period of 27 minutes. To do this we define a
timer that recycles whenever the count value reaches the threshold. To show the use of the delta
parameter we are not going to count seconds but minutes:

>SGC07TR0002700060<

Now the C07 signal transitions to true every 27 minutes. After all events are evaluated the signal will
transition back to false.

GS - Speed Limit
Qualifiers: Q, S, R.

This message is used to configure the speed limits that can be used to trigger events. The message has the
following format:

AABCCCC
● AA: Index. Range 00-09. Specifies one of the speed limits associated with a speed limit signal SAA.
● B: Active flag:
■ 1: Speed limit is active
■ U: Delete speed limit
● CCCC: Speed limit in miles per hour times 10.

Examples:
To create the speed limit 00 having a value of 55mph send to the unit:
>SGS0010550<
Now an event can be defined so that a report is generated any time that the vehicle exceeds 55mph. The
event 33 is used in this example for no particular reason:
>SED33NV0;S00+<
ID - Identification
Qualifiers: Q, S, R.

This message is used to set/query unit's ID. When changing the ID it is necessary to reset the unit using
the RT command in order to reestablish the current connections to any Destination Point using the new
ID. The message has the following format:

A[AAA...]

● A[AAA...]: Identification code assigned to the vehicle. This parameter is alpha- numeric and up to 10
characters long. The only forbidden characters are ">", "<" and ";" . The factory default is 0000.

Please refer to the XAID message, which is closely related to this message.

Examples:

To set the unit's ID:

>SIDTestUnit<

PV - Position-velocity

Qualifiers: Q, R.

This message gives the unit's current position, velocity, heading, source of information and age of the
data. The message has the following format:

AAAAABBBCCCCCDDDDEEEEEFFFGGGHI

● AAAAA: Time of day. Time of the generated report. This number represent the seconds elapsed since
00:00 of the current day.
● BBBCCCCC: WGS-84 Latitude. It does include the sign: Positive for north. BBB represents a value in
degrees and CCCCC parts of a degree in decimals.
● DDDDEEEEE: WGS-84 Longitude. It does include the sign: Positive for east. DDDD represents a value
in degrees and EEEEE parts of a degree in decimals.
● FFF: Vehicle velocity.
● GGG: Vehicle heading, in degrees from North increasing eastwardly.
● H: Position fix mode:
■ 0: 2D GPS
■ 1: 3D GPS
■ 2: 2D DGPS
■ 3: 3D DGPS
■ 9: Unknown
● I: Age of data used for the report:
 ■ 0: Not available
■ 1: Old, 10 seconds
■ 2: Fresh, <10 seconds
■ 9: GPS Fail

For example, the response for this message could look like this:
>RPV69311+2578378-0802936300125532<
Indicating that the report was generated at 19:15:11 GMT with coordinates +2578378 latitude and
-08029363 longitude, with a speed
of 001mph and a heading of 255 degrees, with 3D DGPS fix mode and the age of the data was recent.
RF - Radio Frequency Module Configuration

Qualifiers: Q, S, R.

This message is used to configure Cellular Network parameters. Any RF parameter can be left empty by
issuing the command without the B string. The message has the following format

A[BBB...]

A: RF parameter to be configured. The valid values for this field are: A: GPRS APN (Access Point Name)
(40 chars. max.).
I: SIM Card PIN.
L: GPRS Login (40 chars. max.).
P: GPRS Password (40 chars. max.)
[BBB...]: String with the parameter described by A. It cannot contain the "<" or the ";" characters.

Warning:
The SIM card may be blocked if the RFI parameter is configured with a wrong SIM card PIN.

Examples:

To set the PIN number 1234, send to the unit:

>SRFI1234<

If the SIM card does not required a PIN, set an "empty" PIN:
>SRFI<

To set the APN to internet.carrier-name.com send to the unit:

>SRFAinternet.carrier-name.com<

To leave the APN parameter empty:

>SRFA<

RT - Reset message
Qualifiers: S, R.

When used with qualifiers it serves multiple initializations purposes. The valid options are:
● Without a Qualifier (i.e: >SRT<): Restarts the unit. This option does not delete any configuration
parameter or stored information.
● ;CONFIG: Resets almost all the configuration of the unit. The preserved parameters are: PIN, APN, ID,
Destination Points, IMEI as ID. This prevents losing communication over the air with the unit. In order to
delete absolutely all off the unit's parameters use the ;ALL option.
● ;ALL: Resets all of the configuration of the unit. This option should not be used over the air because it
will cause the unit to lose communication with the server.
● ;SFBUFF: Deletes the contents of the Store & Forward buffer.
● ;GPS: Does a GPS Cold Start and deletes the current position information. It is important to not use this
command often because the GPS will take a long time to retrieve the position information again.

Warning:
This Configuration Message may not generate a reply (I.E: >RRT<) every time the message is sent to the
unit. If the listener server is designed to wait for a reply to each configuration command, it may become
stuck trying to send this command even if the unit already accepted it.
SI - SIM Card ID

Qualifiers: Q, R.

This message allows us to consult the SIM Card ID of the SIM card currently installed on the Syrus.

Examples:

To consult the SIM card ID, send:

>QSI<

The Syrus will reply like this:

>RSI8957123310512805597<

If no SIM card is installed, the response will be error 13:

>RER13;QSI<
SS - Signal Status

Qualifiers: Q, S, R.

This message allows for the inspection of signals' state and the setting of outputs and other user
controllable signals. Please refer to the Signal List section, for a list of valid signals. The message has the
following format:
AAA[B]
● AAA: Index. 3 character identifier if the signal. See the Signal List section for a list of valid signals.
● B: Status of the specified signal. The only valid values for this field are 0 or 1.

Examples:

To activate output 2:
>SSSXP21<

To deactivate it:
>SSSXP20<

To know the state of the input 2:

>QSSIP2<

If input 2 is inactive the unit returns:

>RSSIP20<

If input 2 is active the unit returns:

>RSSIP21<

To set the user signal 08 to false:

>SSSU080<

To set it true:
>SSSU081<

To know the state of the Ignition Signal F00:

>QSSF00<

If the signal is OFF (the vehicle’s ignition is OFF) the unit returns:
>RSSF000<

If the signal is ON (the vehicle’s ignition is ON):

>RSSF001<
ST - Status

Qualifiers: Q, R.

This message provides information about the unit's GPS receiver. The message has the following format
when using no modifier (>QST<):

AABCDDEFGGH
● AA: GPS satellite signal acquisition and tracking status.
■ 00: Doing position fixes.
■ 01: Don't have GPS time yet.
■ 02: Not used.
■ 03: HDOP is greater than 1.5.
■ 08: No usable satellites.
■ 09: Only 1 usable satellite.
■ 0A: Only 2 usable satellites.
■ 0B: Only 3 usable satellites.
■ BB: Stationary Mode.
■ 0C: Chosen satellite is unusable.
● B: Antenna short circuit state
■ 0: No problems reported.
■ 1: Antenna feed line short fault.
● C: Status Codes, Nibble 2:
■ Currently not in use.
● DD: Machine ID. Internal GPS machine ID. Currently not in use.
● E: Status Codes, Nibble 3:
■ Currently not in use.
● F: Status Codes, Nibble 4:
■ Currently not in use.
● GG: Hex value. Currently not in use.
● H: Indicates if the GPS is on or off. Flag:
■ 0: GPS is off
■ 1: GPS is on
TD - Time and Distance

Qualifiers: Q, S, R.

The Time and Distance signals are set by its corresponding Time and Distance counter which is a counter
that follows a Time and Distance criteria. This criterion allows creating a counter that does not follow a
time or distance criteria independently from each other, instead, combines these two variables to
generate an intelligent trigger to be used for a more efficient vehicle tracking. The message has the
following format:

ABBBB[CCCCDDDDEEEE]
● A: Index. Range 0-9. Specifies one of the Time and Distance configurations associated with a Time and
Distance signal TDA.
● BBBB: Minimum amount of time elapsing between reports. To enable just time reporting, this is the only
parameter to set, and the others should be set to 0. Setting this value to 0 disables the report.
● CCCC: This parameter is ignored and can have any value.
● DDDD: Distance the unit must travel between reports. Each unit represents 100 meters.
● EEEE: Maximum amount of time elapsing between signals' activation. This parameter is only relevant
when distance reporting is desired. If set to 0, there is no limit to the amount of time between reports.

Examples:

In this example we will create a tracking event that sends event code 49 based on a T&D criterion. A 8km
(5miles) report is desired. The criterion must be so that no more than one hour passes between successive
reports, and the minimum time between successive reports must be 2 minutes.
In this example the T&D index 6 is used for no particular reason. The requirements call for the following
T&D configuration:
● Minimum time between reports: 120 seconds (2mins).
● Distance Threshold: 80 x 100m (8km).
● Maximum time between reports: 3600 seconds (1hr). This configuration is achieved by sending:
>STD60120000000803600<
Now we create event 49 using the TD6 signal:
>SED49NV0;TD6+<

The T&D could also be configured on a time-only basis by defining the Minimum Time parameter and
setting the others to zero. To define a time only criteria of 15 minutes (900 seconds):

>STD60900000000000000<

or:
>STD60900<
VR - Version Number

Qualifiers: Q, R.

This message returns the unit's firmware version.

>QVR<
For example: Firmware 3.4.18:
>RVR; Syrus 3.4.18;ID=356612024116677<
XADP - Destination Points
Qualifiers: Q, S, R.

This message configures both IP-type (Internet Protocol) and Telephone destinations. The IP-type
destinations support both TCP and UDP.
The Destination Points index from 00 to 03 are reserved for TCP destinations only. The TCP destinations
support both IP number and URL addresses.
The Destination Point with index 04 and 05 are reserved for UDP destinations only. Please note that the
UDP destinations also support both IP number and URL addresses for reporting, but to send
Configuration Commands over the air from a UDP connection, it must use an IP number address on the
destination configuration of the unit. This restriction is temporary and will be changed in a future firmware
version.

Important:

The UDP DP 05 can only be set if UDP DP 04 is already defined. The port defined for DP 05 must always
be different to the port defined for DP 04. DP 04 can only be deleted once DP 05 has been deleted first.
After configuring the DP 05 it is necessary to restart the Syrus using the>SRT< command.

For IP-type destinations, i.e. Destination Points 00 to 05 use the following format:
AABCD[DDD...];E[EEE...]
● AA: Index for IP-Type destination points. Range 00-05.
● B: Access flag / Action. The valid values for this field are:
■ U: Delete the Destination Point.
■ 0: The IP-type host has Command Console access..
● C: Confirmation selection. The valid values for this field are:
■ For TCP Destination Points (00-03):
■ 0: TCP without confirmation.
■ 1: TCP with confirmation.
■ For UDP Destination Point (04-05):
■ 2: UDP without confirmation.
■ 3: UDP with confirmation.
● D[D. . . ]: IP address or name of the IP-host. Use the standard dot-separated numbers or URL names for
hosts. Ex: 192.168.0.1 or avl.server.com. Maximum 50 characters.
● E[EEE...]: TCP or UDP port used by the IP server for listening to the unit's reports.

For Telephone destination, i.e. Destination Points 10 to 14 use the following format:
AABCD[DDD...]
● AA: Index for Telephone destinations. Range 10-14.
● B: DP type/Action:
■ U: Delete the Destination Point
■ 0: Report messages are sent as Configuration Commands responses to this destination.
■ 1: User-defined text messages are sent instead of the regular Configuration Command response.
● C: Access permission for this Telephone:
■ 0: Full Access
● D[DDD...]: Telephone number. Maximum 50 characters.

Examples:

To set a TCP Destination Point:

>SXADP0000avl.server.com;57816<
or
>SXADP0100192.168.0.1;57816<

To set a UDP Destination Point:

>SXADP0403avl.udp.server.com;5454<

To set a telephone type Destination Point:

>SXADP10105551234567<
XAEF - Extended-EV message Formats
Qualifiers: Q, S, R.

This message allows the creation and configuration of up to three sets of information tags to be used by
an event having the Message ID qualifier set to A, B or C. The message has the following format:
A[BBB...]
● A: Identifier of the extended-EV format being set or consulted. The valid identifiers are: A, B or C.
● [BBB...]: Information tag. Enter each tag separated by a ";" character. The valid tags are:
■ AC: Instant acceleration measured in Miles per hour per seconds.
■ AL: Altitude in meters above mean sea level (AMSL).
■ BL: Battery voltage level. Milivolts.
■ CF: Cell information.
■ CVxx: Counter xx value.
■ DOP: GPS dilution of precision.
■ IO: Inputs and Outputs state.
■ IP: IP Address.
■ SV: Satellites in view.
■ VO: Virtual Odometer value. Meters.

For more information on each tag, refer to the Extended-EV Tags formats list on the Event Message (EV)
section.

Example:

To set event 49 to send an extended-EV message that includes the cell information, the number of GPS
satellites in view and the state of counter 05 whenever the vehicle's speed goes above 55 mph:
Define the event. Set it to use extended-EV format A
>SED49NA0;S00+<

Define extended-EV format A to include the required tags

>SXAEFA;CF;SV;CV05<

To delete the extended-EV reporting format send

>SXAEFAU<
XAID - IMEI as ID

Qualifiers: Q, S, R.

This message tells the unit whether to use or not its IMEI as ID. When changing this parameter, it is
necessary to reset the unit using the RT command in order to reestablish the current connections to any
Destination Point using the ID setting. The default is to use the IMEI. The message has the following
format:

A
● A: Flag:
■ 1: Set the unit's ID with the IMEI. This is the default value.
■ 0: Set the unit's ID to the value set by the user with the ID message.

Please refer to the ID and XAIM messages, which are closely related to this message.

XAIM - IMEI Consult

Qualifiers: Q, R.

This message is used to consult the unit's IMEI (International Mobile Equipment Identity) The message has
the following format:
AAAAAAAAAAAAAAB

● AAAAAAAAAAAAAA: Unit's IMEI.

● B: IMEI's Checksum.

Please refer to the ID and XAID messages, which are closely related to this message.
XANS - Network Status

Qualifiers: Q, R.

Use this message to consult the state of the GPRS session and the state of the TCP sockets of every IP-
type Destination Point. The response message information is presented in groups separated by a ";"
character and each group separates its data with a "," character.

Some information may not be available all the time, in this case the field corresponding to that data will be
empty. It is possible to see more fields than those explained here on the right side of each group of the
message, however that information can be ignored. The relevant information provided by this message is:

First group:
● Air Interface status.
■ 0= Air Interface is down.
■ 1= Air Interface is up.
● APN
● SIM PIN
● GPRS Login
● GPRS Password

Second Group:
● SIM insert state
■ 0= SIM not inserted
■ 1= SIM inserted
■ 2= SIM hardware off
● SIM state
■ 1= SIM ready
■ 2= SIM hardware off
■ 3= SIM inserted
■ 4= SIM removed
■ 5= PIN error
■ 6= waiting PIN
■ 7= SIM lock
■ 8= SIM error
● SIM lock reason. This field's value only matters if the SIM state is 7
■ SIM PIN = waiting for SIM PIN.
■ SIM PUK = waiting for SIM PUK if PIN was disabled after three failed attempts to enter PIN.
● GSM register state
■ 0= Not registered
■ 1= Registered
■ 2= Not registered, searching.
■ 3= Rejected
■ 4= Error
 ■ 5= Registered, Roaming.
o GSM RSSI
■ 0 = -113 dBm or less
■ 1= -111 dBm
■ 2 to 30 = -109 to -53 dBm
■ 31 = -51 dBm or greater
■ 99 = not known or not detectable

GPRS attached state

■ 0= Not attached*
■ 1= Attached

GPRS register state

■ 0= Not registered*
■ 1= Registered
■ 2= Not registered, searching.
■ 3= Rejected
■ 4= Error
■ 5= Registered, Roaming.

Local IP address
GPRS bearer state
■ 0 = Bearer is down
■ 1 = Bearer is up
Jamming state:
■ -2 = Normal state
■ 0-60 = Jamming detection in progress
■ -3, -1 = Jamming Detected

* This state can be reported when no TCP Destination Point is set. Consult the XADP message for more
information.

Third Group:
This group holds the information about each Destination Point set. Each destination point is separated by
a "\" character. If no destination point is set this group will be empty. The Destination Points are listed in
the chronological order they were created. They are not listed by the index used by the XADP message.
The address of the IP destination point.
● Socket connection state
■ 0= Not connected
■ 1= Connecting
■ 2= Closing
■ 3= Connected
■ 4= Connected, limited.
■ 5= Closing, hold.
● Local port
● Remote IP address
● Remote port
● Socket up time
● Socket down time
● Socket down log timer

An example of the response for this message could be:

>RXANS1,internet.cxn,,,;1,1,null,5,31,1,5,10.1.17.207,1;socket://visionairegps.com:8040,3,1024,66.228.1
27.212,804 0,3,,\;,,,;3,1,1,0,4;<

Which indicates that the Air Interface is up, the APN set is internet.cxn, and the PIN is empty; The SIM is
inserted, and ready, registered to GSM and roaming, the RSSI is 31, registered to GPRS and roaming, and
the local address is 10.1.17.207; The Destination Point set is visionairegps.com:8040 , is connected, with
local port 1024, to remote IP address 66.228.127.212 and remote port 8040 for 3 seconds, and no down
time is registered so far.
Error List
● 00 - Unrecognized command.
● 01 - Internal error. Please verify the syntax of the Configuration Command and try again.
● 02 - The message is not delimited by > and/or <
● 03 - ID mismatch on incoming postfix ";ID="
● 06 - Not a valid set message.
● 07 - Incorrect or missing parameter. Please verify the syntax of the Configuration Command and try
again.
● 09 - Queries resulting from multiple answers are not supported over the air.
● 11 - Incorrect ACT, XCT or SMS Alias definition. See ED message.
● 12 - Destination point is already set. You can consult the destination points configured with the XADP
command.
● 13 - Error while consulting the IMSI or SIM Card ID. Please verify that the SIM card is correctly installed
and try again.
● 15 - Change state operation failed. Internal Error.
● 17 - APN or network problem while trying to run a firmware upgrade over the air. Please verify the
communications state using the XANS command.
● 19 - Incorrect index.
● 24 - Invalid characters on string parameters.
● 25 - Invalid vehicle ID. See the ID message.
● 36 - Signal sense (+ or -) missing, see ED message.
● 37 - Non-existent signal or missing operator on event definition, see ED message.
● 40 - The signal cannot be changed by the user. See the SS message.
● 42 - Invalid signal index. See the Signal List section.
● 57 - Could not delete the photos folder because a photo is in use.
● 59 - Invalid Range or Value.
● 60 - IP-type destination supplied with no port. See the XADP message.
● 61 - Telephone-type destinations supplied cannot include port parameters. See the XADP message.
● 62 - Functionality not available on this version.
● 69 - Exceeded command length.
● 76 - Invalid counter operation. See the GC message.
● 78 - Counter operation failed.
● 96 - Internal flash memory error. Cannot save on flash.
● 99 - GPS data temporarily unavailable.
Signal List
● A00 - A03: Destination Points' state. True when the IP address/port defined on the corresponding
Destination Point's index is accepting a TCP connection (i.e. the TCP socket is open).
● B00 - B04: Battery levels. True when the unit's back-up battery level is above the value defined.
● C00 - C19: Counters, Timers, Distancers. True when the corresponding counter reaches its defined
threshold value. See the GC message.
● E00 - E99: Event triggers. True when the corresponding event trigger is True. See the ED message.
● F00: Ignition. True when the ignition input of the unit is on.
● F01: GPS Fix. True when doing GPS fixes.
● F02: GSM/GPRS Roaming. True when the unit is Roaming on GSM/GPRS.
● F03: GSM-Registered. True when the unit is registered in the GSM network.
● F04: GPS Antenna Feed-line fault. Indicates a short on the GPS antenna cable.
● F05: GPRS Bearer. True when the GPRS bearer is up.
● F08: SIM State. True when SIM is inserted. This signal has a persistence time check of 10 seconds.
● F12: Motion. True when the movement is detected.
● F13: Power. True when the unit's main power supply is on.
● F15: Low battery. True when the internal battery charge is below 20%.
● F16: Aggressive driving. True when aggressive driving is detected.
● F17: Collision. when a collision is detected.
● G05: Idle signal. True when Syrus determines that the vehicle is in idle state. This happens when the
vehicle's engine is turned on but the vehicle is not moving.
● G06: GPS antenna connection status signal. True when the GPS antenna is connected.
● IP1 - IP3: Inputs. True when the corresponding input is activated.
● J00 - J04: Heading Deltas. True when the vehicle's heading change is greater than the corresponding
heading change threshold. The signal is immediately reset after evaluation to achieve a turn-by-turn
report.
● S00 - S09: Speed thresholds. True when the vehicle's speed is faster than the corresponding speed
threshold. See the GS message.
● TD0 - TD9: True when the associated Time and Distance counter has a Time and Distance condition
true. The signal is immediately reset after being evaluated to enable the counter for further triggers. See
the TD message.
● U00 - U15: User flags. These signals may be changed by the user at any time with the SS message.
● XP1 - XP2: Outputs. True when the corresponding output is on. See the SS message.
Script example
#- Syrus Standard Script

#- Extended formats
>SXAEFA;VO<

#- Heading Definition = 45 Degrees

>SXAGH001045<

#Event 00 - Periodic Position Report

>SED00NA0;J00C02|C03|F00&+;XCT=SGC03DR00800;XCT=SGC02TR00120<

#- Idle Condition Event

#- Speed Limit Definition = 6 mph [10kph] - Signal S01
>SGS0110060<
>SED69SV0;S01!F00&+;XCT=SGC05TC0006000010<
>SED68SV0;S01F00!|+;XCT=SGC05U<

#Event 01 - Vehicle in Idle

>SED01NV0;C05+;XCT=SGC05U<

#Event 02 - Ignition ON
>SED02NV0;F00+;XCT=SGC02TR00120;XCT=SGC03DR00800;XCT=SGC07DR00500;XCT=S
GC08TC00300;XCT=SGC11U<

#Event 03 - Ignition OFF

>SED03NV0;F00-
;XCT=SGC02U;XCT=SGC03U;XCT=SGC07U;XCT=SGC08U;XCT=SGC01TR0006000120<

#- Speeding Condition Event

#- Speed Limit Definition = 70mph [112kph] - Signal S00
>SGS0010700<
>SED67SV0;S00+;XCT=SGC04TC00010<
>SED66SV0;S00-;XCT=SGC04U<

#Event 04 - Speeding
>SED04NA0;C04+;XCT=SGC04U<

#Slow Traffic Condition

>SED65SV0;C07+;XCT=SGC08TC00300<

#Event 05 - Slow Traffic

>SED05NA0;C08+<
#Power Events
#Event 06 - Power Disconnection
>SED06NV0;F13-<

#Event 07 - Power Re-connection

>SED07NV0;F13+<

#Event 08 - Periodic report with Ignition Off

>SED08NV0;C01+<

#- Inputs Detection Events #Event 09 - Input 1 Activated

>SED09NV0;IP1+<

#Event 10 - Input 2 Activated

>SED10NV0;IP2+<

#Event 11 - Input 2 Deactivated

>SED11NV0;IP2-<

#Event 12 - Input 3 Activated

>SED12NV0;IP3+<

#Event 13 - Input 3 Deactivated

>SED13NV0;IP3-<

#Event 14 - Output 2 Activated

>SED14NV0;XP2+<

#Event 15 - Output 2 Deactivated

>SED15NV0;XP2-<

#Event 16 - Low Battery - (Below 20%)

>SED16NV0;F15+<

#Event 17 - GPS Antenna Short Circuit Detected

>SED17NV0;F04+<

#Event 18 - GPS Antenna Short Circuit Restored

>SED18NV0;F04-<