GPS Receiver Interface Language (GRIL).

1
??????????????? ???????????????? ?????????
??????????????? ???????????????? ????????

• ?????????? ??????? ??????
• ? ????? ???????????????? ????????????
• ?? ????
• GPS Receiver Interface Language (GRIL).
• ????????? ?????? ????? ????????????
• ???????????? ???????? ????? ????? ??????????

2
IntroductionWhat is GRIL?

• GRIL is an interfacing language enabling the user
  to effectively communicate with GPS/GLONASS
  receivers by accessing all of their capabilities
  and functions.
• A GPS Receiver is a device that receives Global
  Positioning System (GPS) signals for the purpose
  of determining the device's current location on
  Earth. GPS devices are used in military,
  aviation, marine and consumer product
  applications. GRIL represents a generic receiver
  language structure for the entire range of TPS
  hardware.
• This language structure is receiver-independent
  and open to future modification or expansion.
  GRIL is based on a unified approach allowing the
  user to identify a TPS receiver with an
  appropriate set of named objects. Communication
  with these objects is then achieved through
  predefined commands and messages.
• There are no specific constraints on the number
  or type of the receiver objects used.

3
How is GRIL used?

• Any system communicating with the TPS receiver
  through one of its ports (serial, parallel or
  modem) will use GRIL command/messages to
  accomplish the required task.
• A pair of typical applications where GRIL plays a
  very important part are, first, using hand-held
  controllers to communicate with the receivers
  during field operation in survey and RTK projects
  or, second, when downloading data from the
  receivers into desktop systems for further post
  processing. These examples are just two from a
  long list of possibilities where GRIL is an
  absolute must.
• One important feature of GRIL is that it can be
  effectively used for the automatic or manual
  control of TPS receivers. For manual control, the
  user will enter necessary GRIL commands into the
  receiver through a terminal, for example, typing
  in the command line of PC-CDU.

4
Objects

• In the context of the model that GRIL is based
  on, a TPS receiver is identified with a set of
  named objects. Object is defined as a
  hardware or software entity of the receiver's
  that can be addressed, set, or queried.
• Hardware entities are commonly referred to as
  devices, whereas firmware objects are normally
  files and parameters. Receiver ports and memory
  modules are all good examples of devices.
• Note that a set of devices may have a unique
  name and may be treated as an object. All
  devices, files and parameters are treated in a
  uniform way by GRIL.
• Every object has an associated set of properties
  that can be accessed, defined, and/or changed
  through GRIL.

5
Receiver Input Language

• The receiver input language comprises case
  sensitive statements. Statements, which are the
  minimal entities that the receiver can handle,
  are delimited with linefeed (LF) and/or
  carriage-return (CR) characters.
• Each statement is represented by a list of
  elements enclosed inside curly braces and
  delimited with commas (e.g. element1,element2,ele
  ment3).
• In turn, elements of a statement may themselves
  consist of some other elements (e.g.
  e1,ee21,ee22).
• Strictly speaking, an element may be a name, a
  constant, a list of elements, or may just be
  empty. For constants, they may be integers,
  floats, string literals or symbolic constants.
• Note that the syntax of constants must be the
  same as accepted in the C language.

6

• The simplest type of statement is a command
  statement. In a command statement, its first
  element, called command, denotes an action
  made, whereas all the following elements (if any)
  designate this command's arguments. Note that
  curly braces surrounding the command statement
  can be omitted.
• The GRIL command set is simple and relatively
  small. Arguments are made up of objects and their
  options (if any). An object may have one or more
  optional values (option list) associated with
  it.
• In each statement, the command element and its
  object(s) are separated by commas (,) whereas
  options are delimited from their objects with
  colons (). The following are examples of valid
  statement formats
• 1) Command,object,
• 2) Command,object option,
• 3) Command,object1,object2,
• 4) Command,object1option1,object2option2.

7

• It is possible to enable the checksum mechanism
  when communicating with the receiver. In other
  words, any command may be issued with or without
  the corresponding checksum.
• The checksum, which is actually a check byte in
  hexadecimal format preceded by the auxiliary
  character _at_, is appended to the end of the
  statement.
• When running a command with the checksum, the
  receiver will compare the input checksum HH
  against that computed by the firmware. Checksum
  is computed starting with the statement's first
  non-blank character until the _at_ character is
  reached.
• Note that the _at_ character is also used to compute
  the checksum.

8
Object Identifier

• As mentioned in the introduction, a receiver is
  considered as a set of objects (devices, files
  and parameters) in the context of the GRIL model.
  Each receiver object is uniquely identified.
  Objects in the receiver are logically organized
  into groups. A group itself is also an object.
  The object name is unique inside the group to
  which the object belongs.
• Object name should contain only alphanumeric
  characters or an underscore and should not begin
  with a digit. With the object hierarchy, a unique
  object identifier is built from the names of all
  groups to which the object belongs. The
  identifier can be considered as the path from the
  root group to the object, starting from the root
  group and using the forward slash (/) as the
  delimiter.
• Some examples of object identifiers are
• i) Receiver ID /par/rcvid
• ii) Contents of the file NAME /log/NAME
• iii) Serial Port A baud rate /par/dev/ser/a/rate
  
• Note that all the names for receiver parameters
  begin with /par. For our purpose in this
  document, we should mention that in addition to
  /par for parameters, the receiver root list
  includes /dev for devices, /log for log files and
  /msg for various supported messages.

9
Receiver commands

• GRIL's flexibility allows for future expansion of
  the current command list or use of only part of
  the existing command list.
• set and print
• We begin this section with general information
  about the set and print
• commands. The set command allows the user to
  change the value applied to the named object.
  This command generates no response unless it
  starts with a xx prefix (here xx designates
  an arbitrary piece of text or an empty string) or
  an error will occur1.
• Format set,object name,value
• Options none
• If object name does not begin with /, the affix
  /par/ will be automatically
• inserted before object name prior to executing
  this command.
• The print command allows the user to query the
  value assigned to the
• corresponding named object. The first argument of
  the print command is the object identifier. This
  command will always generate a response message.
  If the object specified in the command statement
  does not exist, an error will be reported.
• Format print,object name
• Options either no option or the string name
• If object name does not begin with /, then
  /par/ is automatically inserted
• before the object name prior to executing this
  command.

10
General parameters

• ? Put receiver into sleep mode
• Parameter /par/sleep
• Type boolean
• Values on off
• With the set,/par/sleep,on command, the receiver
  is changed to sleep
• mode.
• If a character is received on one of the serial
  ports while the receiver is in sleep
• mode, power will be immediately switched on.
• Also, the wake-up time option is available for
  this parameter.
• For example, the command
• set,/par/sleep,on1d23h3m55s
• instructs the receiver to go into sleep mode and
  then wake up on next Monday (2d) at 23h3m55s GPS
  time.

11

• ? Name of current log file
• Parameter /cur/log
• Type string
• This parameter contains the name of the current
  log file, if such a file exists, or an empty
  string, otherwise. If there is no current log
  file, then setting this parameter to an existing
  file's name will instruct the receiver to open
  this file for data appending thus making it the
  new current file.
• If the current log file exists, then changing
  this parameter will instruct the receiver to
  close the existing current file and then open a
  new current file. If the command refers to the
  file that does not exist the receiver will open
  such current file.
• ? Information about current log file
• Parameter /cur/logsize
• Type integer
• Size of current log file (in bytes). An error
• message will be reported if there is no
• current log file.
• Parameter /par/out/cur/logcount
• Type integer
• Number of different message types enabled for
  output to the current log file. An error message
  will be reported if there is no current log file.

12
Receiver Messages

• General Format of TPS Messages33
• Each standard message begins with its identifier.
  A message identifier is followed by the length
  of message body descriptor, which in turn is
  followed by the message body itself.
• Message Identifier
• Each standard message begins with the unique
  message identifier comprising two ASCII
  characters.
• Any characters from the subset 0 thru (i.e.,
  decimal ASCII codes in the range of 48..126)
  can be used in standard message
  identifiers.Format a1 id233 )
• Message Body
• Message body follows immediately after the length
  of message descriptor. Recall that a message's
  body can have a maximum of 4095 characters.
• Non-standard Messages
• TPS receivers support both standard and
  non-standard (aka non-conforming) messages.
• The format of standard messages has been
  described above.
• Non-standard messages do not meet the standard
  message format's
• requirements. The main purpose that non-standard
  messages serve is that you can insert them
  between standard messages thus generating a
  combined stream of standard and non-standard
  messages.