This documentation is owned by SkyWave Mobile Communications Inc. (SkyWave) and protected by
applicable copyright laws and international treaty provisions. Other copyrighted names used are the property
of their respective owners. Therefore, you must treat this documentation like any other copyrighted material.
You may not make the documentation, or copies thereof, available in any manner or form, or use, copy or
transfer any part, to anyone outside your company.
If you received this documentation by electronic transmission or download, by installation or use of the
documentation, you acknowledge that you have read and understand this license agreement and agree to be
bound by its terms and conditions.
This documentation is provided on an as-is basis without any warranty of any kind. You assume the entire
risk as to the results or performance of the software. Under no circumstance shall SkyWave be held liable for
any direct, indirect, consequential, or incidental damages arising from the use or inability to use the software
or documentation.
All trademarks or registered trademarks are the property of their respective owners. INMARSAT, the
Inmarsat logo and IsatData Pro are trademarks of Inmarsat used under license by SkyWave. Inmarsat is not
responsible for the operation and regulatory compliance of the products and services referred to in this
document that connect to the Inmarsat system.
SkyWave reserves the right to make changes to products and or specifications without notice.
From www.SkyWave.com login, and follow the link to the downloads section. The complete Software and
Documentation License Agreement is distributed as a part of the IDP Developer Toolkit.
Contact Information
SkyWave Mobile Communications Inc.
Online:
Website www.SkyWave.com
Online Documentation:
Login at support.skywave.com and follow the link to the downloads section
Note: Refer to the SkyWave Customer Support website for any updates or a possible
Errata Sheet available after the release of this document. Always check the site
for the most current documentation releases.
What's New?
Changes since the last release of this document are listed below. The updates below
include new functionality for the low power firmware release 1.1.0.
Updated S50 Power Mode and S51 Wake-up Interval information to show that
they are non-volatile (Sections 5.4.3, 5.4.7 and 5.4.8)
Updated for Low Power Release 1.1.0
Added new S registers for low power: S50 Power Mode and S51 Wake-up
Interval (Sections 5.4.3, 5.4.7 and 5.4.8)
Added new to-mobile setSleepSchedule message (Table 5 and
Appendix B.2)
Added new from-mobile sleepSchedule message (Table 6 and Appendix C.3)
Added low power to Trace Class and Subclass (Table 17)
Added a new Low Power Trace Record table (Class 2, Subclass 2) (Table 20)
Added low power to the modemRegistration message (Appendix C.1)
Additional Updates
New %UTC command to display UTC date and time (Section 5.6.13)
New Response Result Code added (Table 15)
Added DSP RomDB Version to Class 2, Subclass 1 (Table 19)
Minor updates throughout
Purpose
This document describes the behavior and interfaces of the IDP 100 series of modems.
The primary modem serial interface is the AT command interface implemented in the
modem.
Audience
This document is for technical readers. Familiarity with the Hayes command set is
advantageous.
Notation
This document is associated with modem firmware version 3.3 or higher.
An OEM Integrator is a SkyWave customer who purchases an IDP 100 series modem for
integration into their own enclosure. In order to become an OEM Integrator certain
commercial criteria must be met. Contact your Account Executive for further details.
A forward message is a message sent to the mobile device from the gateway, while a
return message is one sent from the mobile device.
Reference
The content of the following documents may be useful in conjunction with this guide.
These SkyWave documents are available from the IDP Developer Toolkit or
support.skywave.com.
[N200] IsatData Pro Network Services
[T201] IDP 100 Modem Series Hardware Guide
Other Third Party Reference Documents:
ITU1-T Recommendations V.250 – Serial asynchronous automatic dialing and control
(07/2003)
Limited Liability
SkyWave’s liability is limited to the cost of repair or replacement of any of SkyWave’s
products during the warranty period. To the maximum extent permitted by applicable
law, SkyWave's total liability for damages of any kind, whether based on breach of
contract, tort (including negligence), product liability, incidental, special, consequential,
indirect or similar damages with product application and usages will be limited to an
amount equal to the product's original price paid by the Purchaser to SkyWave and this
limitation of liability is reasonable given the price of SkyWave's products. In no event
will SkyWave be liable to the Purchaser, any resellers of the Purchaser or any end user
for any lost profits or savings, lost business, loss of data, any telecommunications
breakdown, unavailability, downtime, interruption or delay, any suspension of service by
any third party service provider including Inmarsat or any incidental, special, indirect, or
consequential damages, whether based on breach of contract, tort (including negligence),
product liability, incidental, special, consequential, indirect or similar damages and
whether or not SkyWave has been advised of the possibility of such occurrence or
damage. The parties agree that the foregoing represents a fair allocation of risk
hereunder.
The IDP 100 series are IsatData Pro satellite modems. Each provides satellite messaging
for a host application. The modem's primary interface is the AT command. Using AT
commands, a host can configure, control and exchange data with the IDP modems. The
modems' AT commands are based on the ITU-T Recommendation V.250. In addition to
an AT command interface, the modems provide a trace log interface for provisioning and
diagnostics.
This document describes the IDP modem's serial command interfaces that allow
developers to build host applications to send and receive IsatData Pro messages.
This document is also applicable to developers who are using the IDP 600 series
terminals configured for pass-through mode. In pass-through mode, the modem's serial
interface is available on the IDP 600 terminals' RS-232 interface.
The IDP modem must be registered on the IsatData Pro network to send and receive
messages. On a power-up, the modem transmits a modemRegistration message to the
IsatData Pro gateway. The modemRegistration message notifies the Gateway that the
modem is active and which beam to use to send to-mobile messages. When the Gateway
receives the modem registration message it transmits a modemRegistrationConfirmed
message back to the modem that authorizes the modem to receive messages.
2.1.1 Traffic Channel Acquisition
On a wake up from sleep, the modem tunes directly to its previous traffic channel. It does
not send a modemRegistration message.
2.1.2 Acquisition Times
On startup or reset, the modem must determine its operating satellite beam. The modem
determines its beam by first getting a GPS fix to determine its current location. After
determining its location, the modem calculates its beam by checking its current location
against all beam definitions. All beam definitions are part of the broadcasted IsatData Pro
network information which is stored in the terminal.
If the modem was previously operating in the current region, it also has the traffic
channel information. In this case, the modem tunes directly to the traffic channel. If the
modem had not been previously powered in the current region, it may first need to get
information from the bulletin board channel. More information on the bulletin board and
how it is used is found in [N200].
2.1.3 Modem Registration Message
On a power-up or reset, the modem transmits a modemRegistration message once it is on
the traffic channel.
A modem registration message is not sent when the modem wakes up from a sleep mode.
This is one of the advantages of using the modem's sleep mode instead of turning the
modem's power off.
2.1.4 Beam Switch
An operating modem can roam between different satellite beams. When a modem roams
it switches beams, transmits a ReportBeamChange message and operation continues
transparent to the customer. The ReportBeamChange message lets the Gateway know the
modem's new satellite beam.
A beam switch is transparent to the customer. Typically, the beam switch occurs within
10 seconds. The 10-second window provides time for the modem to transmit a
ReportBeamChange and for the modem to receive a ReportBeamChangeConfirmed
message. The modem suspends all from-mobile messages if a beam switch is pending. If
either a from-mobile or a to-mobile message is in transmission prior to a beam switch, all
subsequent retries are transmitted on the new beam.
The modem determines if it is roaming by monitoring the GPS and the signal strength of
all adjacent traffic channels. As per Figure 1, if the modem is located in an overlapping
region of three beams, it monitors the SNR of all the beams. If it is located in two
regions, it monitors the SNR in two regions. The GPS location is monitored every
12 hours. SNR of adjacent traffic channels is measured every 20 minutes. Adjacent traffic
channels are not always monitored; they are only monitored if the GPS fix indicates that
the adjacent beam is overlapping the current operating beam.
Figure 1 Beam Switch
Beam 3
Beam 1 and 2
Adjacent channel SNR monitoring does not affect how the modem is sending or
receiving. The modem only samples the adjacent beams when it knows it is not receiving
a message and when it has no messages to transmit.
2.1.5 Blockage
When a modem can no longer acquire the traffic channel, it does not know if the traffic
channel has changed or if the satellite signal is blocked.
Note: The modem attempts to acquire the most recent beam. Failing that, it
periodically scans all possible beams until it is able to connect.
2.1.6 Muting
When a modem is deactivated it is muted so that it no longer can transmit messages. The
modem supports a modem command that causes the modem to stop transmitting all user
services messages. When muted, the modem may still transmit modem registration and
beam notification messages.
2.2 Message States
Figure 2 illustrates the message states for both from-mobile and to-mobile messages.
When a to-mobile message is received, it is automatically stored and marked as
Rx Completed. The state changes to Rx Retrieved once the to-mobile message has been
retrieved. The to-mobile message remains in the partition (Figure 6) until the IDP modem
requires the memory space for additional messages. At this point the message is deleted
to make space for a new message. A to-mobile message can be repeatedly retrieved until
it is overwritten.
2.2.1.1 Rx Completed
The host only knows about messages that have completed and gone to the Completed
state. The host is not notified when a to-mobile message fails.
The Gateway breaks to-mobile messages into fragments for transmission. The modem
acknowledges each fragment in a pre-assigned timeslot. If the Gateway does not receive
an acknowledgement, it immediately submits the fragment for retransmission.
2.2.1.2 Rx Retrieved Messages
It is the host's responsibility to manage the from-mobile message buffer to ensure that
messages are deleted so new messages can be added – the host cannot delete to-mobile
messages. The IDP modem maintains the message for as long as it can so the message
can be read again by the host. When the modem needs additional storage for either
another incoming message or a newly submitted outgoing message, messages are deleted.
The file system that manages the message buffer selects the message to delete. The
algorithm is not based on message age; instead it selects the message buffer that has been
used the least in order to maximize the flash lifetime. Refer to Section 2.4.1 for more
details.
2.2.2 From-Mobile States
The from-mobile message is added to non-volatile storage when received from the host
or, by the modem. Initially, the from-mobile message's state is Tx Ready. The modem
may not be ready to send the message either because it is not yet registered on the
network, there are a number of messages already in progress (sending state) or the
modem is not receiving a valid satellite signal.
Once the modem starts the transmission, the modem automatically changes the message's
state to Tx Sending when it starts transmitting the message. When a message is in the Tx
Sending state, it cannot be deleted. Once the message transmission is complete, the state
changes to Tx Completed or Tx Failed. The from-mobile message is automatically
deleted from the message partition when an AT command reads either the Tx Completed
or Tx Failed state.
2.2.2.1.1 Transmit Failure
Before transmitting the message, the modem breaks the message into message fragments.
Each message fragment must be acknowledged by the Gateway or else the fragment is
retransmitted. If the modem does not receive an acknowledgement it immediately
resubmits the message fragment for transmission.
When a message or the first fragment transmission starts, the modem starts a message
completion timer. The timer is reset every time a message fragment is acknowledged. If
the modem does not receive any message fragment acknowledgements in a 3 hour
window, the modem declares the message failed.
2.2.2.2 Submit Before Registration
If a from-mobile message is received before the message registers on the network, the
message is added to the transmit queue. The message stays in the queue indefinitely.
Once the modem receives a valid signal and registers, if required, it starts to transmit the
message.
The AT commands are used to send from-mobile messages and receive to-mobile
messages. Message records can be extracted from the message buffer using AT
commands. Separate AT commands are provided for to-mobile and from-mobile
messages.
2.3.1 From-Mobile Messages
The from-mobile message is submitted via an AT command that contains a number of
parameters. These parameters are shown in Figure 3.
As per Figure 3, the host must assign an outgoing message name to all from-mobile
messages that are submitted for transmission. The outgoing message name is an eight
character ASCII string. It is the host's responsibility to ensure that the outgoing message
name is unique. If a new message is submitted with the same name as a stored message,
the modem rejects the new message.
The host can use the outgoing message name to reference the message and either check
the message status or delete the message before it starts transmission. The outgoing
message name is not transmitted to the Gateway.
As per Figure 3, once the modem starts to send a message, the IsatData Pro network
assigns a network reference number. The network reference number is in the form aa.ss,
where aa is a message number and ss is a sequence number. For diagnostic purposes, the
network reference number is also available on the Gateway so that numbers can be
compared.
The host can specify up to four priorities when submitting a from-mobile message
(Figure 3). The priority field is not transmitted to the Gateway. The modem selects the
message with the highest priority from the message queue to transmit.
The modem can deliver up to eight messages (Figure 4), or two for each priority in the Tx
Sending state. Once a message is in the Tx Sending state, it cannot be deleted, although a
higher priority message can be submitted.
Figure 4 Priority Messages
The modem always gives priority to the high priority message when selecting the next
message fragment to transmit. However, if there are network slots available for a lower
priority message, the modem interleaves this message to maximize the network
resources. The number of network slots available for low priority messages depends on
message size, coding rate and the number of outstanding acknowledgements at any one
time.
A high priority does not guarantee that the message is delivered before a lower priority
message. As the modem can process up to eight messages at once time, a low priority
message may arrive before a high priority message depending on its length and number
of message retries.
If the host wants to ensure a priority message transmission, it is recommended to use
priority levels appropriately.
2.3.2 To-Mobile Messages
Figure 5 describes the message flow for a to-mobile message. Like the from-mobile
messages, to-mobile messages are sent as a sequence of message fragments.
The IDP modem creates an incoming message name based on the network reference
number. The modem receives the network reference number and the message length in
the first packet. As the incoming message name is based on the network reference
number, it is in the form FMaa.ssn where aa.ss is the network reference number and n is a
number assigned by the modem. In most cases n is absent. However, if the message
partition contains an older message with a matching network reference number, n is
incremented.
The host does not send an unsolicited message when a to-mobile message is received. If
the host does not use the hardware notification (Section 2.6), the host can poll the tomobile message state (Figure 5) to determine if there are new un-retrieved messages. AT
commands can be used to obtain a list of un-retrieved messages, or all messages stored in
the message buffer. The number of messages in the list could be as large as the maximum
number of messages stored in the message buffer.
The modem has internal volatile and non-volatile flash memory (4 MB) to store the
following:
Satellite Messages
Network Configuration
S Registers
Internally, the modem uses a file system that partitions the available storage into preallocated files of different sizes. All files are stored with a CRC to ensure that the
integrity of all data stored in the flash. By pre-allocating files, the effect of a single
corrupted file is isolated to that file only and does not propagate throughout the file
system. The file system also ensures that single flash memory locations are not
continually overwritten. The allocation of files from flash memory storage and the
individual flash memory pages are written using a wear-leveling technique to maximize
the 100,000 write cycle life of each flash memory page.
From the user perspective the file system is transparent – the modem does not provide
file access commands. Instead, the modem provides specific AT commands to access
customer data stored in flash.
The modem stores all non-modem messages in non-volatile storage. All non-modem
messages survive power-up and reset. From-mobile messages are stored non-volatile
memory; to-mobile messages are stored in non-volatile memory once they are full
received.
In order to maximize the number of stored messages, satellite messages are stored in four
separate partitions based on the message's size. There is a partition for small, medium,
large and extra-large messages. Both to-mobile and from-mobile messages are stored in
the same partition (Figure 6) based on their size.
Figure 6 Message Partitions
Small Messages
(1-235 Bytes)
(236-1235 bytes)
Large Messages
(1236-5235 bytes)
(5236-10000 bytes)
The message partitioning (Figure 6) ensures a conservative flash lifetime of 5 years
(Table 1) when the modem sends or receives up to 1 MB of data a month. The number of
writes is calculated from the maximum manufacturer’s flash writes per sector (i.e.,
100,000) times the number of message partitions.
Table 1 Maximum Flash Size
If the intended partition is full, the modem attempts to store the new message in a larger
partition. The modem solely manages how it allocates messages to individual message
partitions. As such, the modem does not report the partition where messages are stored,
and it does not report the amount of available memory in any given partition.
If the larger partitions are not available for immediate reuse, the new message is
discarded. The modem transmits a protocolError message that notifies the Gateway that
the message was received but discarded. As the message is discarded, it is critical that the
host application read to-mobile messages and not fill the partitions full of from-mobile
messages in order to ensure that any incoming to-mobile message is not discarded.
On power-up, all stored from-mobile messages, regardless of age, are transmitted by the
modem. This includes messages that may have been partially transmitted before a reset or
power down occurred.
2.4.2 Network Configuration
The modem automatically updates its network configuration file when it receives new
information on the IsatData Pro bulletin board. The contents of this file are for internal
modem use.
2.4.3 S Registers
Some S registers are configuration settings that are persistent during power down and
stored in non-volatile memory. These S registers are stored files in the serial flash
memory.
On power-up and reset, the non-volatile S registers from the serial flash are automatically
loaded into the modem. AT commands can be used to temporary modify the current
active S registers. An AT command is provided that can copy the current active
S registers into flash storage.
If an S register file is corrupted, or non-existent, the factory S register defaults are loaded
into the current active S registers instead.
2.5 Trace Table
The modem stores a trace table in non-volatile memory. The trace table is a fixed length
table that contains a row entry for each key event. When a key event occurs, the trace
record is updated. The trace records are intended for advanced modem users to help them
diagnose problems with the assistance of SkyWave Customer Support.
The trace records can be extracted from the trace table using either AT commands or by
going into trace log mode.
Trace logs are described in more detail in Section 6.
2.6 Modem Outputs
As per Figure 7, the modem has two general purpose outputs that are under modem
firmware control. The hardware characteristics of these two outputs are defined in
[T201].
New incoming satellite messages, modem reset, new GPS position or
transmit compete
GPS Position
A new GPS fix obtained
Modem Reset
Mobile has reset. A reset includes the power up
Modem Registered
Modem registered
Message Transmit Complete
A new message is complete. Complete includes both success and failure
Reset Out
Event Notification
Figure 7 Modem General Purpose Outputs
Modem
2.6.1 Reset Out
Reset out can be asserted by sending an over-the-air modem message. Reset out is a
pulsed signal with a fixed 1millisecond duration.
2.6.2 Event Notification
Event Notification is asserted by the modem depending on the status of a number of
configurable conditions. These conditions are defined by an S register and stored in nonvolatile memory. Table 2 defines the configurable condition and its trigger condition. The
data fields for the reset conditions are defined in the S register definition.
All trigger conditions are automatically released when the event notification indicator
[T201] status register is read. Once the event notification condition is read, a new trigger
condition automatically asserts the event notification output. Once the condition is set, it
is necessary to confirm that the trigger condition was not set directly prior. For example,
if the event notification condition is set to trigger the output, the modem should first
check if there is a new incoming message.
2.7 GPS
The satellite modem and GPS share a common receiver.
The GPS may operate in different modes. Some applications may only request
intermittent GPS fixes in order to operate with minimum power. Other applications may
need continuous GPS fixes and not be concerned with minimizing power consumption.
Table 2 Configurable Conditions
2.7.1 GPS Request Sources
The modem, the host and a modem message can independently turn on the GPS and
initiate a single GPS fix.
The IDP modem initiates a GPS fix in following cases
On startup or reset to determine its operating beam
At least every 12 hours to confirm any IsatData Pro transmit timing offsets due to
the position of the satellite
If a GPS fix is obtained due to an AT command or other trigger, the satellite modem may
delay its request for a GPS fix.
2.7.1.2 AT Command
An AT command for a GPS fix does not necessarily turn on the GPS. If the modem
previously obtained a GPS fix within the specified stale time that GPS fix is used. If there
is no previous fix with the stale time, the modem turns on the GPS and starts to get a GPS
fix. The stale time is the maximum acceptable age for a GPS position. For example, if the
stale time is 5 minutes, the modem uses a previous GPS fix if it was obtained within the
last 5 minutes.
The AT command's wait time parameter specifies the time for the AT command to wait
for a GPS fix - it does not specify the time the GPS stays on waiting for a fix. Once an
AT command initiates a GPS fix, the AT command cannot turn off the GPS. The GPS
remains on until one of the following occurs:
The modem gets a GPS fix
A 3-minute timeout (if the wait time is shorter than 3 minutes)
The modem reaches the wait time as specified (if the wait time is longer than
3 minutes)
2.7.1.3 Over-the-Air Request
A GPS fix can be initiated by a modem message that requests a position report. When
this modem message is received, the modem acknowledges the message. The modem
turns on the GPS; attempts to get a GPS fix and transmit a modem message containing a
GPS report. If a GPS fix is not obtained, the returned modem message contains an invalid
GPS position.
2.7.2 GPS Fix Type
If the modem requests a GPS fix to get a position for system purposes, the GPS fix must
be a 3D fix.
If a user requests a GPS fix using an AT command, the GPS normally waits for the first
3D fix. However, if the modem only has a partial view of the sky, only a 2D fix may be
possible. In this case, a 2D fix report is used if a 3D fix is not available after the wait time
expires. The wait time is the time specified by the AT command to wait for a GPS fix.
2.7.3 GPS Fix Times
The GPS can perform both warm and cold start GPS. A warm fix is always attempted.
The GPS shares the antenna with the satellite modem. When the modem transmits long
bursts as when it sends from-mobile message, a GPS fix cannot be obtained. However, it
can obtain a GPS fix when it is transmitting acknowledgements for to-mobile messages.
Note: The modem allows simultaneous GPS and message transmission providing the
GPS is able to update its ephemeris data at least every four hours.
2.8 Broadcast Messages
A broadcast message is a message that is sent to a broadcast ID that is programmed into
multiple modems. Each modem can have up to 16 different broadcast IDs. The OEM
Integrator is responsible to configure the set of beams where the broadcast message is
transmitted.
Note: The OEM Integrator cannot configure the broadcast IDs on the modem. The
broadcast IDs must be configured by SkyWave at either the factory or over-theair.
The Gateway can either send messages to individual modems or can broadcast to
multiple modems.
3.1 Message Lengths
All messages, both to-mobile and from-mobile, consist of a data block and a length.
Maximum message sizes are given in Table 3. The lengths shown include the Service
Identification Number (SIN) and the Message Identification Number (MIN), if a MIN
was specified.
Table 3 Message Lengths
3.2 Message Types
The first byte of both to-mobile and from-mobile messages defines the message type. The
first byte is the SIN. The SIN identifies the message type. There are three message types
as defined in Table 4.
The second byte of a message is the MIN. The MIN is defined based on the SIN. Only
MIN for the modem message is relevant as the modem passes through the terminal core
services and user services messages.
3.2.1 Modem Messages
The modem directly initiates and responds to all incoming modem messages. Modem
messages do not require any interaction from an external host application. Consequently,
all to-mobile modem messages are not delivered to the host.
Some modem messages are available to the customer at the Gateway others are reserved
for system use. The reserved messages are used to update IsatData Pro parameters such
as bulletin board frequencies and beam regions definitions. A list of the user visible
modem messages are listed in Table 5 and Table 6. Refer to APPENDIX B and
APPENDIX C for further details.
Incoming modem messages allow the IsatData Pro network to update the modem and
retrieve diagnostic information.
Message data in message indicates type of reset.
Modem can reset the host using a dedicated output
setSleepSchedule
0
70
Sets a low power modem's wake up interval
setTxMute
0
71
Disables modem transmissions but modem still sends
registration messages
getPosition
0
72
Polls for a position report
getConfiguration
0
97
Same data as the modem registration message
pingRequest
0
112
Echo of the message
pingResponse
0
113
Echo of the message
getBroadcastIDs
0
115
Request for a list of broadcast IDs
Modem Message
SIN
MIN
Description
modemRegistration
0 0 Response include the modem's configuration and reset
cause
protocolError
0 2 Modem error cause
sleepSchedule
0
70
Sent in response to change in sleep schedule
position
0
72
Sent in response to a position request
configuration
0
97
Same data as the modem registration message
pingResponse
0
112
Echo of the response
pingRequest
0
113
Echo of the response
testMessage
0
114
The network requires a quality test, no payload
delivery
broadcastIDs
0
115
Sent in response to a request for broadcast IDs
Table 5 To-Mobile Modem Messages
Table 6 From-Mobile Modem Messages
3.2.2 Terminal Core Services
Terminal core service messages are passed through the modem to the host application.
These messages are reserved for SkyWave IDP terminals.
3.2.3 User Services
User service messages are passed through the modem to the host application. These are
message types host applications can use to send and receive data over the IsatData Pro
network.
On startup the modem can optionally enter a boot loader mode. The boot loader mode
supports modem firmware updates.
After startup, the modem supports the following operational modes
AT Command Mode
Trace Log Mode
4.1 Mode Switches
The boot loader mode is a special startup mode. It can only be entered after reset if a
special command sequence (<Ctrl>B<Ctrl>B) is received.
After reset, the modem enters one of the configured operating modes. By default the
modem enters AT command mode. However, the user can configure the startup mode to
use any startup mode.
Trace mode exits to AT command mode when <Enter> is pressed.
4.1.1 Baud Rate
On reset, the modem defaults to following serial port settings
Flow control: none
In AT command mode the baud rate can be configured and saved.
On exit from AT command mode to another mode, the modem does not change baud
rates. It continues to use the baud rate as defined by the AT command.
In AT command mode, data is interpreted as commands to the modem. While in AT
command mode, the modem receives, processes, and responds to AT commands.
This section describes the AT command syntax and the AT commands and responses. For
convenience the AT commands are split into the following groups
Basic command set (non-S register commands)
S register command set
Extended command set
SkyWave-proprietary command set
A complete list of all AT commands is found in APPENDIX A.
5.1 Syntax Definition
5.1.1 Conventions
The following definitions apply:
<cr> Command line termination character. Its value is specified in register S3.
<lf> Response formatting character. Its value is specified in register S4.
<…> Items enclosed in angle brackets indicate a syntactical element. The actual
element appears on the command line rather than the angle brackets.
[...] Indicates optional items. Brackets themselves do not appear in the command line.
| Indicates or. E.g., <data>|<length> indicates that one of data or length must be
specified.
The examples in this document intentionally omit <cr> and <lf>.
5.1.2 Command Rules
The IDP 100 series modems follow the basic AT command rules below:
At commands must begin with either AT or at, although the rest of the command
can be a mix of upper and lowercase.
Several commands can be combined in a single command line using ";" to
delimit extended commands and SkyWave-proprietary extended commands. It is
not mandatory to delimit basic commands.
If a numerical parameter in a basic command is not entered, it is assumed to be
zero.
Whitespace in commands is ignored.
5.1.3 AT Command General Format
A command line is a string of characters sent from a host to the IDP modem while the
mode is in a command state. A command line has three elements: the prefix, the body,
and the terminationcharacter.
Commands to the modem are prefixed with AT or at.
The body is made up of individual commands and their optional parameters, specified
later in this document, and terminated by the command line termination character
(defined in register S3, default = 13 (ASCII carriage return)).
Multiple commands can be included in one command line, extended commands and
SkyWave-proprietary extended commands must be delimited by ";". It is not mandatory
to delimit basic commands.
Examples:
Disable Echo:
ATE0 or
atE0 or
ate or
ATE000 or
AT E 0 or
at e
Request identification information, model information, and revision information:
ATI+GMM;+GMR or
ati0;+GMM;+gmr; or
at I +gmm; +gmr
5.1.3.1 Command Line Editing
A command line can be edited with the command line editing character (defined in
register S5, default = 8 (ASCII backspace)).
The IDP modem first checks characters from the host to see if they match the termination
character (register S3) and then the editing character (register S5) before checking for
other characters. This ensures that these characters are properly recognized even if they
are set to values that the IDP modem uses for other purposes. If registers S3 and S5 are
set to the same value, a matching character is treated as matching register S3.
5.1.3.2 Command Line Echo
The IDP modem may echo characters received from the host during command state back
to the host depending on the setting of the E command.
5.1.3.3 Repeating a Command Line
The IDP modem immediately executes the command when it receives the prefix A/ or
a/.
5.1.3.4 AT Response Format
The format of the response is dependent upon the current quiet setting (Q command) and
the verbose setting (V command).
<cr><lf>SkyWave Mobile
Communications<cr><lf><cr><lf>+GMM:IsatData Pro - Modem
<cr><lf><cr><lf>OK<cr><lf>
The syntax of information responses and result codes for the different verbose settings is
as follows (where <cr> and <lf> represent the ASCII characters configured in
registers S3 and S4 respectively):
Table 7 Effect of V Parameter on Response Formats
When the quiet setting is enabled (via Q1), the result code is suppressed. No portion of
any result code (header, result text, line terminator, or trailer) is transmitted.
When using the quiet and verbose setting defaults (Q0 & V1), and register S3 and S4
defaults, the response to an AT command line comprised of multiple commands is:
<cr><lf><command 1 Information Response><cr><lf>
…
<cr><lf><command n Information Response><cr><lf>
<cr><lf><Verbose Result Code><cr><lf>
Example:
On a serial interface, the dialogue would appear as follows:
AT i +GMM
SkyWave Mobile Communications
+GMM: IsatData Pro - Modem
OK
5.1.3.5 Error Detection
The integrity of AT command lines and responses can be ensured via Cyclic Redundancy
Checks (CRC).
When error detection is enabled, the IDP modem requires a CRC sequence at the end of
each AT command line to allow verification of the command line data before the
command line is executed. When error detection is enabled, a CRC sequence follows AT
responses to allow verification of the response data by the host.
The AT command line CRC sequence is comprised of the CRC prefix character (stored in
register S64), default character is "*", followed by four ASCII-Hex digits. The value of
the command line CRC includes all command line characters starting with A or a (of the
leading AT or at) up to the character that precedes the CRC prefix character, including
any spaces or delimiters (;). E.g. for ATS5?*2FBD, 2FBD is the CRC of ATS5?.
The AT response CRC sequence is comprised of the CRC prefix character (stored in
register S64), followed by four ASCII-Hex digits, and <cr> and <lf> (where <cr> is
the register S3 value, and <lf> is the register S4 value). The value of the response CRC,
includes the characters of all information responses, and result code, including their
formatting (<cr> and <lf>) characters. E.g., in verbose (V1), the response with CRC
sequence to ATS5?*2FBD<cr> is:
<cr><lf>008<cr><lf><cr> <lf>OK<cr><lf>*DC04<cr><lf>
The CRC used is the CRC-16-CCITT with initial value 0xFFFF.
Error detection is enabled or disabled via the %CRC command.
The following exemplifies CRC sequences associated with AT command lines (denoted
by bold) and corresponding responses (using the default value * as the CRC prefix
character):
Load Current Configuration with Factory Default Values
[<value>]
&V
Display Current and Stored Configuration
[<value>]
&W
Store Current Configuration to NVM
[<value>]
Null
Null Command
-
A/
Repeat Last Command (no leading AT or trailing <cr> )
-
Description
Echo
The echo command defines if the IDP modems echo
characters received from the host in command state. As the
parameter is stored in an S register, this setting can be made
non-volatile if the S registers are saved.
Parameters
None|0 – Disabled
1 – Enabled
Information Response
-
5.2 Transfer Mode
While in transfer mode, the IDP modem transfers data via the XMODEM–CRC protocol
using block sizes of 128 bytes.
Entry into transfer mode may occur via the %MGFG and %MGRT commands.
Exit from transfer mode occurs once the XMODEM transfer is complete or times out.
The information exchange of an AT command that supports transfer mode is structured
as in Table 8.
Table 8 AT Command Information Exchange
5.3 Basic Command Set
The format of the basic command set is either a single character or the & character
followed by an optional single character. The basic AT commands supported are
described in Table 9.
Setting is stored in an S register so any change becomes non-volatile (persist reset or power
cycle) when S registers are stored via the &W command.
IDP 100 Modem Series - Developer Guide
Description
Display current and stored configurations
Parameters
None(0)|0
Information Response
Current and stored S register values
Description
Store the current configuration. Configuration includes all the
modem's S registers
Parameters
None(0)|0
Information Response
-
Description
Null command
Parameters
None
Information Response
-
Description
Repeat last command
The modem immediately executes the body of the preceding
command line when it receives the prefix A/ or a/.This
command is issued without the leading AT or trailing <cr>, no
Direct S register reference (e.g., ATS4). Sets the current register for
subsequent operations until another S register is referenced, read, or
written.
Sn
ATSn?
Direct S register read. Reads the value of the register (e.g., ATS4?)
Sn?
ATSn=<value>
Direct S register write. Sets the value of the register where the new value is
a decimal value in the range of the minimum value and maximum value
(Table 11) (e.g., ATS4=8).
Sn=<value>
AT?
Referenced S register read. A question mark (?) is used to read the value of
the current S register. The current register is the one that was most recently
acted upon by a direct reference, write or read command (e.g., AT?).
?
AT=<value>
Referenced S register write. An equal sign (=) is used to write a value to
the current S register. The current register is the one that was most recently
acted upon by a direct reference, write or read command (e.g., AT=8).
=<value>
3
5.4 S Register Commands
5.4.1 Command Format
S register commands are described in Table 10.
Table 10 S Register Command Format
S registers are used to configure various AT command related values, and other (non AT
command related) values.
5.4.2 S Register Types
Different sizes of S registers exist. S registers can be 1, 8, 16, or 32 bits in size and can
contain unsigned or signed values. S registers can be read/write or read-only.
There are two types of S registers. They are used to
Store configuration parameters
Provide modem status and configuration parameters
All S registers that map to configuration parameters have factory default values. The
modem allows users to change and save the factory defaults. Once configuration data is
changed, the settings are only temporary (i.e., do not survive power down) until all new
settings are explicitly saved to nonvolatile memory. The saved S registers from nonvolatile memory are loaded on every reset.
The factory default values of S registers can be loaded by the user to restore the modem
to its factory configuration. The factory default values are also used by the modem if the
stored configuration parameters cannot be read from non-volatile memory (e.g., are
corrupted).
This command sets and returns the conditions that cause the assertion of the Event
Notification hardware signal [T201].
Syntax
ATS88?
See Table 10 for other command formats
Information Response Syntax
<eventBitMap>
Parameters
An unsigned number of Boolean flags (0=false, 1= true) if condition
Bit 00 – New GPS fix
Bit 01 – New message received
Bit 02 – Transmit completed (either success or failure)
Bit 03 – Modem registered on network
Bit 04 – Modem reset
Bits [05…07] – Reserved
Result Codes
OK
Success
ERROR
Example
Enable assertion of Event Notification on a new GPS fix, new incoming message
and modem reset.
This command returns a bit map of status conditions that result in the assertion of
Event Notification hardware signal [T201]. A status condition must be both enabled
and active to report as true.
When the register is read or written, all status conditions are automatically cleared.
Syntax
ATS89?
See Table 10 for other command formats
Parameters
None
Information Response Syntax
<eventBitMap>
Parameters
Bit 00 – New GPS fix
Bit 01 – New Message Received
Bit 02 – Transmit completed (either success or failure)
Bit 03 – Modem registered on network
Bit 04 – Modem reset
Bits [05…07] – Reserved
Result Codes
OK
Success
ERROR
Example
Modem status indicates that a new to-mobile message has been received and that
this event is asserting the hardware Event Notification signal.
This command set configures a trace class and subclass. Once class and subclass are
configured, the trace tables are searched for the most recent match trace record. If a
match is found, the trace record is copied to the captured report.
The captured report can then be obtained by reading S93…S123 (when the Result
Code is OK).
Syntax
ATS90=n S91=m S92=p
See Table 10 for other command formats
Parameters
n – Trace record class (Table 17)
m – Trace record subclass (Table 17)
p – 1 to trigger a trace record capture
Information Response Syntax
None
Result Codes
OK
Success
ERROR
Example
The trace tables are searched for a satellite status general event (Class 3,
Subclass 1). The OK response indicates that a trace record was found and moved
to the capture record.
ATS90=3 S91=1 S92=1
OK
The following command attempts to capture a trace record for a satellite event.
The ERROR response indicates that there is no matching trace record in the logs.
ATS90=3 S91=1 S92=1
ERROR
Trace log information can also be obtained via %EVNT. When the value 1 is
written to S92, the most recent trace log information corresponding to the class
specified in S90 and subclass specified in S91, is captured in S93...S123. The AT
command result code is OK if the trace log information was successfully
captured (i.e., trace log information corresponding to the specified class and
subclass existed), or ERROR otherwise.
GPS information within age limit of <staleSecs> is unavailable and fresh
GPS information not obtained within <waitSecs>, parameter out of range,
or syntax error
No information response exists when result code is ERROR.
This command obtains the data of a specific to-mobile message.
The <dataFormat> parameter specifies whether the data is presented in text
format bounded by double-quote (") characters, ASCII-Hex format, Base64 (MIME)
format, or via transfer mode.
When text format is specified, ASCII data is bounded by double-quote (") characters,
although the following special characters are represented by a backslash (\) character
followed by two hexadecimal digits representing the special character’s ASCII value:
00..1F,22("),5C(\),7F..FF (all values are in hexadecimal).
When transfer mode is specified, transfer mode is entered after the information
response to exchange the data (and AT command mode automatically resumes once
the data exchange is complete).
The maximum length of a to-mobile message is 10,000 bytes, including the SIN byte
and the MIN byte.
Syntax
%MGFG="<fwdMsgName>",<dataFormat>
Parameters
<fwdMsgName>
The to-mobile message name reported by %MGFS or %MGFN
<dataFormat>
0 Transfer mode to be entered after information response to transfer
message data (and AT command mode automatically resumes once the
data transfer is complete)
1 Text format message data (bounded by double-quote (") characters)
included in information response
2 ASCII-Hex format message data included in information response
3 Base64 (MIME) encoded message data included in information response
2 Rx Completed (Entire message received and available, but not yet
read)
3 Rx Retrieved (Message has been retrieved/read (via %MGFG) and
message data is still available)
<length>
Total message length in bytes (including SIN byte and MIN byte)
<dataFormat>
0 Transfer mode to be entered after information response to transfer
message data (and AT command mode automatically resumes once
the data transfer is complete)
1 Text format message data (bounded by double-quote (") characters)
included in information response
2 ASCII-Hex format message data included in information response
3 Base64 (MIME) encoded message data included in information
response
<data>
Message data, formatted as specified by
<dataFormat>
See above for details
Example
The examples below all represent identical message (with message data ¡Olé!)
This command is similar to the %MGFS command, but only lists messages that have
not been retrieved (via %MGFG) nor marked as Rx Retrieved (via %MGFM). It may
be used to query the state of all Completed to-mobile messages (when
="<fwdMsgName>" is omitted, or ="" is specified), or a specific to-mobile message
(when ="<fwdMsgName>" is specified). When ="<fwdMsgName>" is omitted, the
response includes all to-mobile messages with the state Completed.
Syntax
%MGFN[="<fwdMsgName>"]
Parameters
<fwdMsgName>
The to-mobile message name in the form FMaa.ss where aa is the active
message number and ss is the system assigned 2-digit message sequence
number. An empty string ("") denotes all to-mobile messages.
If a to-mobile message is received with the same active message number and
message sequence number as an existing message, the existing message is
deleted if its state is Rx Retrieved, and the new message is saved with the
name of the deleted message.
If the existing message has not been read (state is Completed), the new
message is saved with a name using the format FMaa.ssx where x is a
character (a to z) that supports a message with a unique fwdMsgName.
Message number in the form active message number followed by '.' And
message sequence number
<priority>
Always 0 for to-mobile messages
<sin>
Service identification number
<state>
2 Rx Completed (Entire message received and available, but not yet
read)
<length>
Total message length in bytes (including SIN byte and MIN byte)
<bytesRxd>
Number of bytes received (including SIN byte and MIN byte)
Note: <cr><lf> are used to delimit multiple messages.
Result Codes
OK
If all to-mobile messages were specified (via %MGFN or %MGFN="") even
if no Completed to-mobile messages exists, or a match was found when a
specific msgName was specified (via %MGFN="<fwdMsgName>").
ERROR
Match not found when a specific msgName was specified (via
%MGFN="<fwdMsgName>"), or a syntax error
This command queries the state of a specific to-mobile message (when
="<fwdMsgName>" is specified), or all current to-mobile messages
(when ="<fwdMsgName>" is omitted or ="" is specified). Current messages
include to-mobile messages with state Completed or with state Rx Retrieved that
have not yet been automatically deleted (to make room for new messages).
Syntax
%MGFS[="<fwdMsgName>"]
Parameters
<fwdMsgName>
The to-mobile message name in the form FMaa.ss where aa is the system
assigned 2-digit message number and ss is the system assigned 2-digit
message sequence number. An empty string ("") denotes all to-mobile
messages.
If a to-mobile message is received with the same active message number and
message sequence number as an existing message, the existing message is
deleted if its state is Rx Retrieved, and the new message is saved with the
name of the deleted message.
If the existing message has not been read (state is Completed), the new
message is saved with a name using the format FMaa.ssx where x is a
character (a to z) that supports a message with a unique fwdMsgName.
The to-mobile message name in the form FMaa.ss where aa is the system
assigned 2-digit message number and ss is the system assigned 2-digit
message sequence number
Message number in the form aa.ss where aa is the system assigned 2digit message number and ss is the system assigned 2-digit message
sequence number
<priority>
Always 0 for to-mobile messages
<sin>
Service identification number
<state>
2 Rx Completed (Entire message received and available, but not yet
read)
3 Rx Retrieved (Message has been retrieved/read (via %MGFG) and
message data is still available)
<length>
Total message length in bytes (including SIN byte and MIN byte)
<bytesRxd>
The number of bytes received (including SIN byte and MIN byte)
Note: <cr><lf> are used to delimit multiple messages.
Result Codes
OK
If all to-mobile messages were specified (via %MGFS or %MGFS="") even if
no to-mobile messages exist, or a match was found when a specific
msgName was specified (via %MGFS="<fwdMsgName>")
ERROR
Match not found when a specific msgName was specified (via
%MGFS="<fwdMsgName>"), or syntax error
From-mobile message name specified in the corresponding %MGRT
command
<MsgNum>
From-mobile message number in the form aa.ss where aa is the system
assigned 2-digit message number and ss is the system assigned 2-digit
message sequence number. Note that the from-mobile message number is
reported as 0.0 until a valid number is assigned.
4 Tx Ready (Ready to transmit)
5 Tx Sending (Transmission in progress)
6 Tx Completed (Transmission complete and successful)
7 Tx Failed (Transmission failed)
<length>
Total message length in bytes (including SIN byte and MIN byte)
<bytesAcknowleged>
The number of message bytes acknowledged by the gateway (including
SIN byte and MIN byte)
Result Codes
OK
If all from-mobile messages were specified (via %MGRS or %MGRS="")
even if no from-mobile messages exist, or a match was found when a specific
msgName was specified (via %MGRS="<msgName>")
ERROR
Match not found when a specific msgName was specified (via
%MGRS="<msgName>"), or syntax error
User-specified from-mobile message name, maximum 8 characters, used by
the IDP modem only and not sent to the gateway. The msgName must be
unique and not match any previously submitted msgName.
<priority>
1 High
2 3 4 Low
<sin>[.<min>]
Service identification number (16…255), optionally followed by "." And
message identification number (0…255)
0 Transfer mode to be entered after information response to transfer
message data (and AT command mode automatically resumes once the
transfer is complete)
1 Text format message data (bounded by double-quote (") characters)
included in information response
2 ASCII-Hex format message data included in information response
3 Base64 (MIME) encoded message data included in information response
<data>
See <dataFormat> above. Text bounded by double-quote (") characters,
ASCII-Hex, Base64 (MIME) encoded, omitted for transfer mode. The
<data> field can be a maximum of 6398 bytes if the (optional) MIN is
specified, or 6399 bytes if the (optional) MIN is not specified.
<length>
Number of valid data bytes to be exchanged via transfer mode (note that 128
byte blocks are used, and that data beyond <msgLen> bytes in the last block
are discarded)
Information Response Syntax
None
Result Codes
OK
Message successfully added
ERROR
Otherwise
Example
All of these commands represent identical messages.
Command not recognized, command line maximum length exceeded,
parameter value invalid, or other problem with processing the
command line
1005
Invalid command line CRC sequence
1015
Unknown command encountered in command line
1025
Invalid command parameter encountered
1035
Message length exceeds permitted size for specified data Format
1045
Transfer mode error occurred
1055
System error
1065
Insufficient resources
1075
Message name already in use
1085
Timeout occurred
1095
Unavailable
5
5.7 Error Result Codes
The error result codes that follow information responses are listed in Table 15. Error
codes greater than 100 apply to SkyWave proprietary AT commands.
Table 15 Response Result Codes
ERROR (or numeric code 4) is returned for this code. Register S80 and S81 are populated with a
SkyWave-proprietary numeric result code to help identify the reason for the ERROR result code.
Traces are sent to a trace table in volatile memory. A new trace record overwrites an old
trace record of the same type. In trace log mode, the traces are also sent to the host.
Each trace record field is displayed as lines of comma delimited fields. All fields are
show in decimal format.
6.1 Trace Log Mode Commands
<Enter> exits trace log mode.
6.2 Trace Types
The modem stores trace records of key events in a trace table. The key events can be
grouped in the following classes.
Hardware Faults
System Events
Satellite Events
GPS Events
Message Events
6.3 AT Command Access
The AT commands have access to the trace log file. Using S registers the AT command
can select a specific trace log class that it wants to read. Once the record type is selected,
the modem copies the newest matching record into a trace capture record. S registers, that
map into each field of the trace capture record can then be used to read the requested
record.
Trace records consist of a common header followed by class specific data.
Figure 9 Trace Record Format
6.4.1 Trace Record Header
The common header format for all trace records is shown in Table 16.
Table 16 Common Trace Log Information
The header contains the class and subclass numbers. The definition for trace class and
subclasses are defined in Table 17. Refer to Section 5.4.19 for an explanation of how S
registers map to trace classes.
Fix statistics (when a fix is received by the GPS server)
2
Status (when GPS server changes its state)
5
Message Event
1
Receive message statistics
2
Transmit message statistics
3
Transmit message utilization
Name
Description
Size (bytes)
Trace Data 0
Data specific to trace record
4
Trace Data 1
Data specific to trace record
4 … …
…
Trace Data 23
Data specific to trace records
4
Table 17 Trace Class and Subclasses
6.4.2 Class Data
A trace record consists of a block of 24, 32-bit data entries. Not all the data indices in the
class specific block contain data. The number of data indices containing valid data is
defined by the first data entry in the trace header.
7 – Registration in progress
8 – Receive only
9 – Receiving global bulletin board
10 – Active
23
Beam Search State
Beam search state:
0 – Idle
1 – Search for any traffic channel
2 – Search for the last acquired traffic channel
3 – Reserved
4 – Search for another traffic channel ID
5 – Search for a global traffic channel
6 – Delay the traffic channel search
7 – Delay the last acquired traffic channel search
8 – Search for a traffic channel better than the current one
Transmit status:
0 – Accepted
1 – Acknowledgement received
2 – No acknowledgement received
3 – Fail
4 – Unable to send (lost signal)
5 – Unable to send (priority or Tx disabled/suspended)
6 – Missed Acknowledgement (acknowledged
subframe not received)
7 – Modem error
1
Channel Type
Channel type:
0 – Half second channel
1 – Once second even channel
2 – One second odd channel
3 – Small packet channel
4 – Acknowledgement channel
2
Subframe Time
Transmit subframe
3, 4
Reserved
Reserved
5
Message Type
Modem message type
6
Reserved
Reserved
7
Slot
Slot (for quarter second packets or acknowledgments)
8
Modem Return Code
Modem return code
9
Message Number
Message number
10
Packet Type
Packet type:
0 – Acknowledgement
1 – Transmit data half second coding rate (0P33)
2 – Transmit data half second coding rate (0P50)
3 – Transmit data half second coding rate (0P75)
4 – Transmit data half second coding rate (0P95)
5 – Transmit data one second coding rate (0P33)
6 – Transmit data one second coding rate (0P50)
7 – Transmit small packet
11
Packet Size
Packet size
12
Packet Index
Packet index
13
Sequence Number
Packet sequence number
14
Priority Packet
Priority packet
15
First Packet
First packet (0/1)
16
Retry Send
Retry flag (0/1)
17
Acknowledgement Subframe
Expected acknowledgement subframe
18
Acknowledgement Bitmask
Expected acknowledgement bitmask
Data Index
Name
Description
0
Subframe Number
Received subframe number
1 to 15
Reserved
Reserved
Table 22 Transmit Status Trace Record (Class 3, Subclass 2)
Table 23 Satellite Acquire Trace Record (Class 3, Subclass 3)
Geographic position of the modem. Latitude degrees *100
12
Longitude
Geographic position of the modem. Longitude degrees *100
Data Index
Name
Description
0
Success
Successful receive
1
Subframe Number
Subframe number of this receive
2
Beam Number
Beam number
3 to 8
Reserved
Reserved
9
Number Packet Symbols
Number of packet symbols in this receive
10
Number Packet Errors
Number of packet errors
11
C/N
C/N (x100)
12
Number Packets Detected
Number of packets decoded
Data Index
Name
Description
0
Total C/N
Accumulated C/N (x100)
1
Total Error Rate
Accumulated error rate (x100)
2
Total UW Error Rate
Accumulated unique word error rate (x100)
3
Total Receives
Count of completed receive requests
4
Total Receive OK
Count of receives with good CRC
5
Number Samples
Number of samples (for accumulated stats)
6
Total Receive Fail
Number of failed receive requests (no signal or modem error)
Table 26 Satellite Event Log Data (Class 3, Subclass 6)
Table 27 Rx Metrics Trace Record (Class 3, Subclass 16)
The Rx metrics are defined below. Rx metrics are reported as accumulated totals over the
last full minute, last full hour and last full day. The average values can be calculated by
dividing the totals by the number of samples. The subclasses for the Rx metrics are:
Last Full Minute - Subclass 17
Last Full Hour - Subclass 18
Last Full Day - Subclass 19
Table 28 Rx Metrics Trace Record (Class 3, Subclass 17, 18 and 19)
The average values are calculated by dividing each total by the numSamples value
times 100 (68800).
avg C/N0 = 3122952/68800 or 45.4 dBHz.
avg Channel Error Rate = 23/68800 or 3.3 x 10e-4
avg. UW Error Rate = 2/68800 or 2.9 x 10e-5
The Tx metrics counts are reported over the last full minute, last full hour and last full
day. A subclass is provided to support each Tx metrics type.
Last Full Minute - Subclass 21
Last Full Hour - Subclass 22
Last Full Day - Subclass 23
Table 29 Tx Metrics Trace Record (Class 3, Subclass 20, 21 and 22)
Message control block message service identification number
7, 8
Reserved
Reserved
Data
Index
Name
Description
0
Reserved
Reserved
1
Error
0 – None
1 – Unknown type
2 – Too large
3 – No message number available
4 – Service not available
5 – No data
6 – Format not configured
7 – Priority disabled
8 – No system resources
2, 3
Reserved
Reserved
4
Priority
Message control block message priority
5
Reserved
Reserved
6
SIN
Message control block message service identification number
7 to 9
Reserved
Reserved
Data
Index
Name
Description
0
Packets Formatted rate 1
Number of unique packets submitted for rate 1 (.5 s/.33)
1
Packets Transmitted rate 1
Number of packets transmitted (including retries)
2
Flags, rate 1
Bit 00 – Rate permitted in current location
Bit 01 – Rate disabled due to excessive errors
3
Packets Formatted rate 2
As above, for rate 2 (.5 s/.50)
4
Packets Transmitted rate 2
5
Flags, rate 2
6
Packets Formatted rate 3
As above, for rate 3 (.5 sec/.75)
7
Packets Transmitted rate 3
8
Flags, rate 3
9
Packets Formatted rate 4
As above, for rate 4 (.5 sec/.94)
10
Packets Transmitted rate 4
-
11
Flags, rate 4
As above, for rate 3 (.5 sec/.75)
12
Packets Formatted rate 5
As above, for rate 5 (1.0 sec/.33)
13
Packets Transmitted rate 5
As above, for rate 2 (.5 s/.50)
14
Flags, rate 5
Reserved
15
Packets Formatted rate 6
As above, for rate 6 (1.0 sec/.50)
16
Packets Transmitted rate 6
As above, for rate 3 (.5 sec/.75)
17
Flags, rate6
-
18
Packets Formatted rate 7
As above, for rate 7 (small pkt)
6.5.4 Receive Message (Class 5)
Table 32 Receive Message Trace Record (Class 5, Subclass 1)
Table 33 Transmit Message Trace Record (Class 5, Subclass 2)
Table 34 Transmit Message Trace Record (Class 5, Subclass 3)
Indicates the type of reset and whether queued from-mobile message are kept or
flushed.
0 – (modem preserve) Modem software reset with messages preserved (note this
resets both the DSP and microcontroller processors). Messages are reattempted
from packet 1 after the reset.
1 – (modem flush) Modem software reset with messages flagged as not delivered.
Messages are not reattempted after the reset.
2 – (terminal) Terminal application processor hardware reset
3 – (terminal/modem flush) Modem software reset and terminal processor
hardware reset (modem messages flagged as not delivered and are not
reattempted)
4 to 255 – Reserved
0-255
APPENDIX B To-Mobile Messages
All parameters include the SIN and the Message Type.
B.1 reset (MIN 68)
Definition
This message causes various types of mobile device resets. The Gateway may restrict
some types of resets.
Note: Reset types 2 and 3 cause a hardware reset of the terminal application
processor using the designated digital output port on the mobile device which is
connected to the reset pin on the terminal board. Application messages can be
sent over-the-air to the terminal to cause other types of terminal resets.
Length of time the modem sleeps between attempts to receive to-mobile
messages.
0 – Off (terminal receives every 5 seconds)
1 – Reserved
2 – Reserved
3 – 3 minutes
4 – 10 minutes
5 – 30 minutes
6 – 60 minutes
0-6
Field
Description
Value
TxMute
This sets the transmission control state
0 – Unmute
1 – Mute
B.2 setSleepSchedule (MIN 70)
Definition
This message sets the wake-up period for a low power mode modem. The response to the
setSleepSchedule is a sleepSchedule confirmation from the modem.
Syntax
setSleepSchedule
Fields
WakeupPeriod 8 bits
Details
B.3 setTxMute (MIN 71)
Definition
This message controls an individual mobile's transmit capability.
If muteFlag is set to 1 (mute) the transmission control level is only allows registration,
beam login, and responses to to-mobile messages.
If muteFlag is set to 0 (unmute) the transmission control level allows all messages
Specifies the wake-up interval currently set in the
mobile.
0 – Always on (5s)
>0 – Low power
0-255
LastResetReason
Specifies the reason of the last registration/login.
0 – Power on
1 – Low voltage
2 – Reset pin
3 – Watchdog
0-255
Traffic Channel
Specifies the to-mobile traffic channel that the
mobile communicates with and is registering in.
1-4095
0 – Invalid
Beam
Specifies the beam number of the traffic channel
that the mobile communicates with.
1-15
0 – Invalid
APPENDIX C From-Mobile Messages
C.1 modemRegistration (MIN 0)
Definition
The mobile device registration message is sent by the mobile when it is powered-on or
reset. This is the first message a mobile sends after a reset. It is the mobile's way of
requesting activation within the IsatData Pro network. The mobile receives the
registration reply message prior to conducting any other communication.
The Gateway aborts any from- or to-mobile messages in progress (sending state) when
the registration message is received. Any from-mobile messages in progress are restarted
by the modem unless the registration is due to a restart which marks the messages in the
queue as failed.
A variable length byte array containing ASCII text. The length is determined by
the message length.
-
Field
Description
Value
ID
An array of 16 ID fields, each 24 bits
-
C.8 testMessage (MIN 114)
Definition
This message is generated automatically by the mobile device as a means to continually
test the satellite network. The message content, length and repeat period are specified
using the command line interface. The command line interface starts and stops the
process.
Syntax
testMessage
Fields
Text variable size
Details
C.9 broadcastIDs (MIN 115)
Definition
This message is the response to the getBroadcastIDs message. The response contains the
entire list of 16 broadcast IDs. IDs of 0 are null (no broadcast service).