ГОСУДАРСТВЕННЫЙ КВАЛИФИКАЦИОННЫЙ ЭКЗАМЕН ПО ПРОФЕССИОНАЛЬНО ОРИЕНТИРОВАННОМУ ПЕРЕВОДУ

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 futuremodification 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,element3}). • 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 thesame as accepted in the C language.

6. The simplest type of statement is a command statement. In a commandstatement, 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,object1:option1,object2:option2.

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 @, 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 @ character is reached. • Note that the @ 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 alphanumericcharacters 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 objectbelongs. 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 %x…x% prefix (here x…x 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,on:1d23h3m55s • 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/log&size • 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/log&count • 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 id[2];33 ) • 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.